Chio/Docs

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?

For an end-to-end guide to wiring settlement into an agent deployment (rail selection, payment adapters, escrow setup, reconciliation), see the Settlement guide. This page focuses on what each integrated chain supports and how the on-chain artifacts map back to chio's receipts.

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.

ChainAssetsFinalityStatus
Base (L2)USDC · ETHOptimisticL2 · L1FinalizedProduction
Ethereum MainnetUSDC · ETHL1FinalizedProduction
ArbitrumUSDC · ETHOptimisticL2Production
OptimismUSDC · ETHOptimisticL2Production
SolanaUSDC · SOLSolanaConfirmed · SolanaFinalizedProduction

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.

rendering…
The kernel never talks to a chain. It authorises; the settle runtime executes. Settlement receipts flow back into the receipt log so every on-chain transaction is reachable from the capability that triggered it.

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 SignatureMerkle Proof
Who signsCounterparty + chio operatorAnyone, once the receipt batch is anchored
Trust modelMutual signature at release timeTrust the Merkle root; verify inclusion
Best forLow-volume, high-value transfersHigh-volume batched settlement
CostTwo signatures per escrowOne 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.

json
{
  "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.

ModeMeaningTypical latency
OptimisticL2Inclusion on the L2 sequencer~2 s (Base)
L1FinalizedIncluded in an L1-finalised block~13 min (Ethereum)
SolanaConfirmedConfirmed by a supermajority of stake~1 s
SolanaFinalizedRooted 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

EVM anchoring is fast enough to be verified on-demand during disputes. Bitcoin anchoring is slow but approaches nation-state-resistant immutability. Running both gives callers a choice between latency and durability at verification time without forcing either trade-off at publication time.

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
Settlement · Chio Docs