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 → ReceiptThe buyer never deposited into an exchange. The executor required no permission from the network; only a valid graph to act on.
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 + Fill → ReceiptBoth parties signed explicit, bounded permission. The executor competed to find the match. No entity was assigned the role.
A 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) → ReceiptEach system remains the source of truth for its own state. AON coordinates the authorization relationship between them without becoming the source of truth for either.
A 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.