Component

Paying each other

Members pay each other off-chain: through Lightning channels that live inside leaves, or with vouchers, signed instructions to carve a new leaf out of the signer's balance. The tree changes only when a voucher is redeemed, and then one transition moves the value without changing the total.

Vouchers and CLAIM

A voucher is a message signed by a leaf's owner that names the tree, the owner's leaf (the source) and a new leaf (the claim). The tree is named by a 32-byte identifier fixed when it is created, so a voucher signed for one tree cannot be redeemed against another, even one whose leaves happen to match, and a cohort that is detached into its own output inherits the identifier, so vouchers against its leaves keep working. Anyone holding a voucher can redeem it with the CLAIM transition, without the owner and without the operator. CLAIM is two steps in one transaction: the source leaf shrinks by the claim's amount and its counter seq rises by one, then the claim leaf fills a slot proven empty after the first step. The total never changes. Redemption is single-use for free, because the first step raises the source leaf's counter and the signed message names the old one. The message names the source leaf's keys, lease and counter but not its balance, so the operator raising a leaf's amount leaves every voucher against it redeemable, while any change the owner signs retires them. The caveat is issuance: the covenant prevents redeeming more than the source holds, but nothing prevents its owner from signing more vouchers than that, so a recipient treats a voucher as credit until it is redeemed or the issuer settles it another way. A redemption proves two positions and costs about 1,620 vB at depth 16, more than an exit, so most vouchers are settled off-chain and redemption is the fallback if the issuer stops cooperating.

SPLIT

SPLIT is CLAIM with the authorisation changed: the source leaf's owner signs the spending transaction instead of a voucher. The signature is worthless outside that transaction, so there is no outstanding promise and no credit risk, which suits the common case of a member paying another member and broadcasting the payment themselves. SPLIT still raises the source's seq, so that splitting down and later topping the leaf back up can never restore it byte for byte and revive an old voucher. It needs no opcode for checking signatures on arbitrary messages, so it is the one member-to-member transition that exists in every tier, including MIN.

Channel leaves

A channel leaf is a leaf whose exit key is the funding key of a Lightning channel between the leaf's owner and a counterparty, normally the operator. The channel's funding output does not exist while the leaf is in the tree; it appears as the payout of whatever transaction eventually removes the leaf. Payments between two channel leaves are ordinary HTLC forwards (hash-locked, time-limited payments) through the operator, and nothing touches the tree: no spend, no proof, no fee. A tree of N channel leaves is a Lightning hub with one output on-chain, and because the hash locks and timeouts are the usual ones, the operator can forward between a channel leaf and the public Lightning Network. The price is time: a force close must first get an exit confirmed through the shared output, so HTLC deadlines need about 220 blocks of headroom, against about 40 on the public network. Channel leaves require the FULL, MID or CCV tier, an exact payout and a leaf that no voucher can draw on.

A credit leaf for receiving over Lightning

A user with no on-chain coins can receive into a credit leaf: a leaf the operator funds and owns, whose exit key is the recipient's. Each Lightning payment to the recipient arrives at the operator, which settles the payment first and only then signs a new voucher against the credit leaf for the running total. That costs no on-chain bytes per payment, has no minimum amount and never expires, and the recipient can redeem the latest voucher alone. The order matters: a voucher signed before the payment settled would stay redeemable if the payment then failed, and the operator would have no way to cancel it. The recipient trusts the operator only for the one payment between settling and signing. Whatever the credit leaf holds is the recipient's on every path the operator can take alone, since an exit or an eviction pays the whole leaf to the recipient's key, so the operator funds it with little more than it has vouched for and tops it up as payments arrive. Plain CLAIM would leave a gap, because the operator could sign itself a voucher and drain the leaf first. The variant CLAIM^x closes it by also requiring a signature from the source leaf's exit key, which is the recipient's, for 7 more bytes of script. The arrangement is one-way on purpose: if the recipient could also spend from the leaf, an older and larger voucher would become a stale state, and refuting it would need a contest window, which is what a channel leaf provides. Receiving suits the credit leaf; two-way traffic suits the channel leaf.

Receiving atomically: pending pairs

The credit leaf leaves one gap. After the operator settles the payer's Lightning payment and before it signs the recipient a voucher, the operator holds the payment and the recipient holds nothing enforceable. A pending pair closes it: the recipient gets an enforceable claim before it releases the payment's preimage, and the operator gets its money back if the preimage never comes. This needs three additions to the script set, none of them a new opcode: a reclaim key (R1), a voucher that raises a sibling leaf (R2), and a batch rewrite that moves value into that sibling (R3). A tree opts into them when it is created.

The figure runs three pairs through one window, one for each way a window ends. In words:

1. The pair. P is the pending leaf: operator-owned, exit key the recipient's, evictor RECLAIM_KEY, deadline T. L is the recipient's landing leaf. A recipient that wants payments in flight across a deadline holds two pairs with staggered deadlines.
2. The voucher. For each payment the operator signs a merge voucher (CLAIM^hm) against P: raise the sibling to an absolute level, under the payment hash. It names a level, not an amount, so an older voucher redeemed after a newer one moves nothing, and one voucher covers every payment of the window. The recipient releases one preimage at a time per pair.
3. The reveal. The recipient releases the preimage only once the voucher is in hand and checked. Before that the operator has signed nothing it can lose; after it, the recipient can redeem on-chain and the operator cannot stop it before T.
4. The window closes in one of three ways: the operator's non-interactive batch rewrite (R3), a tower redeeming the voucher, or the operator reclaiming the pending leaf after T (R1) when no preimage came. Value left in P at T is the operator's, which is what makes the timeout work, so the settled total moves to L once per window. The operator keeps any payment whose voucher is outstanding open until its reclaim has confirmed.

Settling first suits a wallet that accepts one payment of trust and wants no deadline. Pending pairs suit one that wants the receive to be atomic, at the price of a window and a tower, or a wallet that wakes before the window closes. The merge voucher is also the first voucher a tower can redeem with no key of the recipient's, since it can pay nobody but the recipient's own leaf.

The window's on-chain cost is per active pair, not per payment. Settled in a batch of 4, 16 or 64 positions, a pair costs about 966, 624 or 547 vB per window under CCV with the hypothetical Merkle-sum opcode, the figures of design/pending-receive.md; settled one pair at a time, with a merge claim and a reclaim, it costs about 1,105 vB.