Settlement
Chio receipts are only as good as where they settle. Policy decisions and signatures matter in production when they flow through to real money movement on a rail the counterparty trusts. This page is the chain-side reference for chio's Web3 settlement: the networks supported, the contracts deployed, the release paths available, and the shape of the settlement receipt that ties an on-chain transaction back to the capability that authorised it.
Looking for a walkthrough?
Supported Chains
Settlement is handled by the chio-settle crate and its contract bindings. Today the supported surface is EVM (three L1s and two L2s) and Solana, with matching test lanes for devnet and mainnet.
| Chain | Assets | Finality | Status |
|---|---|---|---|
| Base (L2) | USDC · ETH | OptimisticL2 · L1Finalized | Production |
| Ethereum Mainnet | USDC · ETH | L1Finalized | Production |
| Arbitrum | USDC · ETH | OptimisticL2 | Production |
| Optimism | USDC · ETH | OptimisticL2 | Production |
| Solana | USDC · SOL | SolanaConfirmed · SolanaFinalized | Production |
Architecture
Every settlement starts as a chio.web3-settlement-dispatch.v1 envelope produced by the kernel when a capability authorises a billable operation. The settle crate reads the envelope, composes the right chain transaction, submits it, and watches for finality. Once finality is reached, a chio.web3-settlement-receipt.v1 is produced and signed. Both envelopes are canonical JSON-LD, so they verify identically on every client.
Smart Contracts
On EVM, two contracts carry the settlement surface. Both are deployed per-chain with stable addresses published in the chio-web3 trust profile. Alloy-generated Rust bindings live in the chio-web3-bindings crate.
IChioEscrow· opens a fixed-amount, time-bounded escrow that either a dual-signature release or a merkle-proof release can unlock. Escrows are single-use; reopening after release requires a fresh escrow.IChioBondVault· holds operator bonds that back dispute outcomes. On a slash verdict the bond is transferred to the disputing party minus a protocol fee; on a timeout refund the bond returns to the operator.
On Solana the equivalent surface is a program that owns per-escrow PDAs and uses the SPL token program for USDC movement. The Rust bindings abstract over both so application code is written against one settlement API regardless of target chain.
Release Paths
An escrow unlocks one of two ways. Both paths are first-class and both produce settlement receipts; which one a deployment picks is a policy decision, not a protocol one.
| Dual Signature | Merkle Proof | |
|---|---|---|
| Who signs | Counterparty + chio operator | Anyone, once the receipt batch is anchored |
| Trust model | Mutual signature at release time | Trust the Merkle root; verify inclusion |
| Best for | Low-volume, high-value transfers | High-volume batched settlement |
| Cost | Two signatures per escrow | One anchor tx amortised across receipts |
Settlement Receipt
A settlement receipt is structurally identical to any other chio receipt; only its kind and meta fields differ. It carries enough on-chain context that an auditor can reconstruct the transaction without access to chio's logs.
{
"version": "chio.web3-settlement-receipt.v1",
"receipt_id": "01HXYZ...7K4",
"decision": "allow",
"kind": "settlement",
"meta": {
"chain": {
"id": "eip155:8453",
"name": "base",
"finality": "OptimisticL2"
},
"escrow": {
"address": "0xAbc...123",
"amount": "10000000",
"asset": "USDC",
"release_path": "merkle_proof"
},
"transaction": {
"hash": "0xdeadbeef...",
"block_number": 21034412,
"gas_used": 84321
},
"capability_id": "cap-expense-line-item-019"
},
"signature": "..."
}On Solana the meta.chain.id uses the solana: CAIP-2 prefix and the transaction block holds signature and slot in place of hash and block number. Schema-level divergence between chains stops there.
Finality Modes
Settlement finality is a policy input, not a constant. An agent paying for a second of API time does not need L1-finalised settlement and should not wait 15 minutes for it. An agent releasing a bond after a dispute must wait. Settle advertises four finality modes and applications pick the one that matches their risk tolerance.
| Mode | Meaning | Typical latency |
|---|---|---|
OptimisticL2 | Inclusion on the L2 sequencer | ~2 s (Base) |
L1Finalized | Included in an L1-finalised block | ~13 min (Ethereum) |
SolanaConfirmed | Confirmed by a supermajority of stake | ~1 s |
SolanaFinalized | Rooted across at least 31 slots | ~13 s |
Dispute Policies
Disputes are a first-class part of the dispatch envelope. Each settlement declares the policy that will apply if either party raises a claim before the release window closes.
- Off-chain arbitration · A designated arbiter address can sign a resolution that either party can execute on-chain. Lowest cost, highest trust assumption.
- Timeout refund · If no counterparty signature arrives before the window closes, the escrow refunds to the depositor. No arbiter required.
- Bond slash · If the operator breaches the agreement, the disputing party can trigger a bond slash against
IChioBondVault. The protocol fee is deducted and the remainder transfers to the disputing party.
Bitcoin Anchoring
For the longest-lived audit guarantees, chio publishes a super-root of its receipt Merkle tree to Bitcoin via OpenTimestamps and mirrors the same root to an EVM ChioRootRegistry. The chio-anchor crate is responsible for this lane; it fails closed across all of its lanes, so a checkpoint is only considered anchored if EVM publication, Bitcoin attestation, and (where configured) a Solana memo record all succeed.
Why two anchors
Next Steps
- Settlement guide · end-to-end walkthrough of payment adapters, escrow lifecycle, and oracle verification
- Chainlink Oracles · price feeds and FX conversion that back cross-currency settlement
- x402 Payments · per-request stablecoin payments at the HTTP layer
- Receipt format · canonical JSON-LD shape shared by every receipt