Each example shows the same structure: authorization establishes permission, conditions establish requirements, proofs satisfy them, execution emerges from the graph. No coordinating institution holds permission at any point.
A buyer signs an Authorization Object granting release of USDC to a seller, conditioned on proof of a confirmed CSD payment. The authorization specifies the buyer, seller, amounts, CSD script hash, genesis hash, minimum confirmations, executor fee, and validity window. It is signed via EIP-712 and published to the network as a plain object.
The seller sees the open authorization and locks the buyer's USDC in the settlement
contract by calling lockCsdUsdcAuthorization, creating a Reserve Object
referencing the authorization. With USDC committed, the seller sends the CSD payment
and publishes a Proof Object containing the full SPV proof: raw transaction bytes,
merkle branch, block header, and a chain of subsequent headers establishing
confirmation depth.
The graph is now complete. An executor calls settleCsdUsdc on the
settlement contract, passing the authorization, signature, and SPV proof. The contract
verifies everything on-chain: recomputes the CSD txid from raw bytes, walks the merkle
branch, checks proof-of-work against the block header, and queries the
CsdHeaderOracle to confirm the payment block is buried to sufficient
depth. USDC is released to the seller and the executor fee paid atomically. A Receipt
Object records completion.
Authorization → Reserve → Proof → ReceiptThe settlement contract verifies the CSD payment on-chain via SPV. The executor cannot influence the outcome; the contract determines validity independently.
The CsdHeaderOracle is a separate permissionless contract that maintains
a chain of CSD block headers on EVM. Anyone may submit headers to it: nodes, sellers,
watchers, or dedicated header relayers. Every submission strengthens the confirmation
guarantee for all outstanding settlements. The settlement contract queries it to
verify that a payment block is buried to sufficient depth before releasing funds.
No single party controls it.
Maker and taker each sign a bounded session Authorization Object specifying token pair, price range, maximum exposure, validity window, and executor fee. Neither deposits funds into an exchange.
An executor discovers both authorizations, determines they are compatible, constructs a Fill Object referencing both authorization hashes, and submits the settlement transaction. Base and quote tokens move atomically. A Receipt Object records completion.
Maker Authorization + Taker Authorization + Maker Order + Taker Order + Fill → ReceiptA participant wants to release assets on one system only when a specific state has been reached on another. They publish an Authorization Object with a condition referencing that state.
When the condition is met, a Proof Object is published. An executor verifies the proof, triggers settlement, and publishes a receipt.
Authorization + Proof (external state) → ReceiptA subscriber signs an authorization permitting payment of a fixed amount on a recurring schedule. Each period, a condition becomes satisfiable. A proof is published; an executor settles and publishes a receipt.
The authorization specifies exactly what may be taken, when, and under what conditions. If circumstances change, the subscriber publishes a Revocation Object. Nodes propagate it. Subsequent execution attempts against that authorization are rejected. No platform holds standing permission to charge the subscriber at will.
A participant signs an authorization permitting a specific action to be taken on their behalf: triggering a deployment, invoking a function, updating a record, conditioned on proof that defined prerequisites have been met. The authorization specifies exactly what may be executed, under what conditions, and within what time window. Nothing else.
When the prerequisites are satisfied, a proof is published. An executor discovers the complete graph, performs the action, and publishes a receipt. The participant never handed over standing permission. The executor required no prior relationship with the participant. The action occurred because the conditions were met, not because someone was trusted to act.
Authorization + Proof (prerequisites met) → ReceiptAny action that can be expressed as a bounded authorization and verified through a proof can be executed this way. Settlement and trading are two applications. The model is general.