How it works

Pay nearby. Prepare to send farther.

Keep local settlement local. Move an exact payment between homes through preparation, verified release and one destination decision.

A local payment stays in its home

Alice authorizes exact inputs, Bob’s output, change and fees. The domain’s admitted validators execute the command and use Byzantine consensus (PBFT) to order it. Under that quorum’s stated fault bound, a valid certified output can be spent in the next local command. It waits for neither a distant vote nor mining maturity.

The community needs locally homed RLD, a responsive accepted quorum and operating resources. An issuance grant is needed to mint, not to circulate existing money. A minority partition must wait rather than claim competing spending authority.

Arrange receiving capacity in advance

Bob’s destination supplies a receiving capability: a finite funded coupon naming one source domain, recipient policy, amount limits, fees, accepted authorities and data/proof bounds. It leaves Alice’s future inputs and future source head unspecified. Each coupon is usable once.

Once compatible capacity reaches Alice, she can select funds later and send forward without a payment-specific stellar permission round trip. A new source, unknown destination or depleted coupon inventory still needs setup. Capacity is a retained obligation; local timeouts cannot silently free it.

BETWEEN DOMAINS

Follow the payment. Explore its outcomes.

A conceptual payment under the paper’s assumptions. Import and rejection are alternative destination decisions.

EVIDENCE JOURNEY / 02Paper mechanism · alternative outcomes
SOURCE / CANCELABLE ESCROW

Prepare locally

With compatible receiving capacity already available, the owner selects exact inputs and fees. The source locks escrow in an independent controller. Historical proving proceeds while other local payments continue. Before release, certified controller cancellation permits one local return; performed preparation service remains paid.

Receiving capacity is arranged before this journey. Preparation can cancel locally before release. After release, choose either destination outcome above: import or permanent rejection. Rejection follows an alternative branch; it cannot refund an imported payment. Actual progress depends on accepted quorums, available data and physical contacts.

Preparation locks only the selected funds

Alice’s native ledger commits exact escrow and delegates it to an independent controller. Other payments continue. Any prover with retained witnesses can prove that historical creation while the ordinary ledger advances; a later head does not invalidate the fixed preparation.

Cancellation belongs before release

The controller makes one certified terminal decision. Canceled permits one local return and closes the coupon. Exported releases a proof-ready payment package and excludes cancellation. Original preparation charges remain paid. An unavailable controller can strand the escrow; a new native committee cannot seize it.

A complete package supports independent receipt

Bob’s domain checks execution proofs, matching quorum certificates, the original coupon and complete current data. It either imports once or permanently rejects. After import, Bob can spend locally without a source reply. After release, source recovery requires certified rejection. Silence, delay and a lost receipt never refund a released payment.

The recipient chooses acceptable exposure

An acceptance cover lists the authority families and rules Bob accepts. Execution proves the payment’s actual ancestry fits that policy. Amounts with exactly the same cover can coalesce. A wider cover needs explicit owner approval and verified inclusion; a narrower one needs additional ancestry evidence. Incidents can quarantine an entire covered portion.

Proofs and ordering answer different questions

Recursive receipts establish valid monetary execution under an authenticated program. PBFT separately excludes competing uses under its fault assumptions. A valid proof cannot reveal a hidden, separately valid quorum fork. Complete current data is also needed to make the next payment; a root or receipt alone is insufficient.