Settlement

Supported Chains

Settlement is handled by the chio-settle crate and its contract bindings. An operator pins one settlement chain config — contract addresses, operator address, settlement token, and a tiered confirmation and dispute policy. The ChioEscrow and ChioBondVault contracts are EVM-generic, so any EVM chain with them deployed can be the pinned target; Base is the shipped reference. Separate Solana support verifies Ed25519 receipts locally and prepares a canonical release payload; it does not broadcast on-chain.

Architecture

Every settlement starts as a chio.web3-settlement-dispatch.v2 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-execution-receipt.v2 is produced and signed. Both envelopes are canonical JSON-LD, so they verify identically on every client.

Smart Contracts

On EVM, two contracts implement settlement. 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.

Solana support is not a live settlement program. It verifies Chio Ed25519 receipts and key bindings locally, prepares the canonical instruction set, and emits a chio.settle.solana-release.v1 payload for commitment-parity checks. There is no broadcast to Solana mainnet and no on-chain program verification in the shipped API.

Release Paths

An escrow unlocks in one of two ways. Both paths produce settlement receipts; the deployment selects one through policy decision, not a protocol one.

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-execution-receipt.v2",
  "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 the Solana lane the receipt binds to the canonical chio.settle.solana-release.v1 payload and its Ed25519 commitment for parity checks, not a broadcast transaction hash and block number. Because this support verifies locally without submitting on-chain, its receipt records the prepared release and commitment, not a mainnet inclusion proof.

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. The chain-level finality mode comes from chio-web3's Web3FinalityMode, which has three variants:

The mode above describes what a chain considers final. What settlement observation actually reports is separate and chain-agnostic: inspect_finality returns a SettlementFinalityStatus of AwaitingConfirmations, AwaitingDisputeWindow, Finalized, or Reorged. A Reorged observation drives the recovery path — ResubmitAfterReorg and the rest of the SettlementRecoveryAction set.

Dispute Policies

The dispatch envelope includes dispute policy. 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 process; it fails closed for each configured anchor, so a checkpoint is only considered anchored if EVM publication, Bitcoin attestation, and (where configured) a Solana memo record all succeed.

Next Steps

• Settlement guide · 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