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 CSD payment referencing their authorization.
The seller sees the open authorization and locks the buyer's USDC on-chain, creating a Reserve Object referencing the authorization. The seller then sends the CSD payment and publishes a Proof Object containing the full transaction, merkle branch, and block header. The node verifies the proof locally.
The graph is now complete: authorization, reserve, and proof are all present. An executor calls the settlement contract. USDC is released to the seller, the executor collects the fee, and a Receipt Object records completion.
Authorization → Reserve → Proof → ReceiptMaker 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 + 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.