BTC/M0 settlement in one hop

Normative source: APP-SPEC v1 draft §13.1, §13.2, §13.3, §13.4, §13.5, §13.6, §PUB, PUB-2 and PUB-6. This page explains; it does not restate rules or parameter values.

The Bitcoin payment is the condition observed; M0 is what the BATHRON lock settles. For example, Alice reserves M0 for Bob, released only if the agreed Bitcoin payment is observed under the lock's rules. Otherwise, once the refund conditions are met, resolution sends the reserved M0 to the refund destination. APP-SPEC v1 draft §13.1, §13.4

Create the agreement

Creating a lock consumes an authorised, unspent transparent M0 output once. The reserved amount leaves the spendable-output set and enters the lock. Its terms identify the beneficiary, refund destination, Bitcoin payment script, required amount and payment window. Changing those terms changes the lock's identity and requires the corresponding authorisation. APP-SPEC v1 draft §13.2

An admissible Bitcoin payment carries the lock's marker, pays the exact required script with a sufficient amount and is included within the payment window. The rules select the first admissible payment in Bitcoin order, using verified scan coverage to establish that it is first. Missing coverage means missing data. APP-SPEC v1 draft §13.3

Resolve or refund

Once that payment reaches the required depth in the block's Bitcoin reference, the reserved M0 moves to the beneficiary. Resolution requires no additional native transaction from the beneficiary. A Bitcoin payment never resolves two §13 locks. BTCSTATE, by contrast, remains a reusable presence test, without this payment-use restriction. APP-SPEC v1 draft §13.1, §13.3, §13.4, §PUB, PUB-6

Refund becomes possible at the specified Bitcoin-height threshold after the payment window, with a complete verified scan establishing that no admissible payment exists. Elapsed time alone is insufficient. Without the scan, resolution waits for data instead of refunding by default. APP-SPEC v1 draft §13.4

Time and responsibility

PUB-2 publishes a time scale of roughly two to four hours for the default delivery depth, and warns of possible waits lasting several hours. This is an order of magnitude, not a completion deadline for an agreement. It accompanies risks including STOP and a revealed secret followed by reorganisation of its claim. APP-SPEC v1 draft §PUB, PUB-2

The payer waits for lock inclusion and the chosen client policy before paying, then rechecks the conditions after waiting. A late Bitcoin payment can transfer BTC without entitlement to the reserved M0. Resolution remains reorganisable; a Bitcoin payment does not recreate a lock removed from the BATHRON history. APP-SPEC v1 draft §13.5, §13.6

Covenants constrain the BATHRON side of an agreement. They never command a Bitcoin spend: a payer still submits the Bitcoin payment, and BATHRON reads the resulting evidence. Contract composition cannot remove that boundary. APP-SPEC v1 draft §SCR.5, §13.3; N-SPEC v0.7, preamble, point 3

See also

Contracts on Bitcoin facts, Covenants and timelocks, and Depth and statuses.