Operating an Economy

A Day in the Life

Choosing Settlement Rails

Operators commonly use several settlement methods. Choose the method per counterparty. A starting layout:

The full rail catalog is on Settlement Rails; the on-chain specifics are on On-Chain Settlement.

Provider Allowlists

Each settlement method has an allowlist. API methods name payment processors; Web3 methods name on-chain networks, where the official chain set uses Base first, with Arbitrum as a limited secondary. The operator's configuration names the providers it will speak to and rejects everything else. Three principles:

• Allowlist by default. Add a provider only after the legal, security, and compliance review is complete. Do not let configuration drift add a settlement method.
• Pin custody providers. Each CapitalExecutionRail carries a custody_provider_id; tooling treats that as the authoritative name and refuses settlements where the rail and the dispatched custody do not match.
• Pin chains by id, not name. Web3 deployments use the chain_id field, not a human-readable network name. CAIP-2 ids are the safest pattern.

Sizing Credit Facilities

A facility caps total exposure across an agent or a class of agents. The configuration is covered in detail on Credit Facilities; the operating question is how to size the ceiling.

Three inputs:

1. Expected volume. Take the historical receipt rate and project forward. The exposure ledger's settled_units column over the last 30 days is the most honest baseline.
2. Reputation band. Higher reputation tiers get higher ceilings; new agents start at the lowest tier. Bands are policy, not free numbers; they should be documented and reviewed quarterly.
3. Settlement latency. The slower the rail, the more headroom the facility needs. ACH-settled agents can see two to three days of in-flight exposure that a Web3 agent would have already settled.

A starting rule is: ceiling = projected daily volume × max-settlement-latency-days × 1.5. The 1.5 multiplier allows for spike days. Review the ceiling quarterly against actual utilization.

Bond Requirements

Bonds are operator-funded collateral held in ChioBondVault (on-chain) or in custodial accounts (off-chain). They are not insurance; they are operator collateral for higher-risk capabilities.

Require a bond when:

• The capability touches a high-risk class (financial trades, medical advice, system-of-record writes). The risk class lives in the underwriting decision.
• The agent is new and has no track record; require a bond as a probationary measure that can drop after N successful settled calls.
• The counterparty has explicitly contracted for it (some enterprise integrations require recourse against operator collateral).

Bond size is set at issuance; each disposition change is a signed CreditBondDisposition from chio-credit (Lock, Hold, Release, Impair). The watchdog drives expiry and renewal automation.

Insurance Gates

Capability policy fires a LiabilityCoverageClass requirement when the call falls into a coverage scope (e.g. ToolExecution for ordinary tool runs). The kernel denies before dispatch if the agent does not present matching coverage. Decide where in the policy this gate fires:

• Per-capability. Most common: each capability declares the coverage classes it requires; the agent's passport must include them.
• Per-tool. Some tools require their own coverage even when the capability does not mandate it (e.g. a database write tool requiring DataBreach coverage).
• Per-jurisdiction. When a rail's jurisdiction or the agent's home jurisdiction mandates specific coverage by law (financial-services jurisdictions, healthcare jurisdictions).

Coverage details are on Liability Market.

Federation Peer Onboarding

Bringing a new bilateral peer online has a stable workflow:

1. Exchange kernel public keys. Both operators publish their kernel signing key fingerprints over a side-channel (signed PDF, in-person, registered domain).
2. Negotiate scope. Agree on which capability classes, which jurisdictions, and which settlement rails are in-scope for the peering. Smaller is safer.
3. Stand up the bilateral receipt channel. Each operator can read the other's receipts for capabilities in scope. See Bilateral Receipts.
4. Configure the rail. Either share an on-chain escrow contract address or stand up a dedicated rail per peer. The pinned chain id prevents drift.
5. Run a sandbox round-trip. Use the Sandbox rail to verify cooperative settlement before enabling a production settlement method.
6. Document revocation. Both sides must agree in writing on the procedure if either party needs to revoke peering. The agreed procedure is the bootstrap for the Bootstrap Federated Trust guide's revocation hooks.

Tool Manifest Signing Operations

The kernel signs receipts; operators sign tool manifests. Both depend on the operator's key-management system:

• Storage. Receipt-signing keys live in an HSM, KMS, or equivalent. They do not appear in source control or environment variables.
• Rotation. Quarterly is a reasonable default; faster on incident. Rotation produces a new public key fingerprint that downstream verifiers must accept. Both old and new keys remain valid during the overlap window; new receipts use the new key, and old receipts retain verifiability.
• Revocation. A revoked key cannot sign new receipts or manifests. Old receipts signed by the revoked key remain valid (the receipt log is append-only) but should be flagged in audits.
• Backup and recovery. A tested recovery procedure is mandatory. Lost keys cannot be regenerated; the operator either recovers from backup or rolls out a new key and explicitly orphans the old fingerprint.

The tactical procedures are on Rotate Keys & Revoke.

Reputation and Scorecard Policy

Reputation drives auto-approve, manual review, and deny thresholds. The built-in model resolves an agent to one of four tiers with asymmetric transitions: promotion is slow, demotion is fast. Thresholds are operator policy; the inputs are signed receipts.

Demotion is faster than promotion. An incident report, a score below the tier floor, or a deny streak drops the agent a tier; the operator codifies the rule and applies it consistently. See Reputation and Scorecards.

Compliance Policy

Compliance policy answers: which jurisdictions, which evidence requirements per class, which framework mappings are operationally enforced.

• Jurisdictions. Pin per-rail. The optional jurisdiction field on CapitalExecutionRail is used by policy at decision time.
• Evidence requirements. High-risk classes require runtime-assurance evidence and may require human-in-the-loop approval. The kernel's policy schema declares this; the operator stands up the corresponding evidence producer.
• Framework mappings. Reference Compliance Frameworks for the canonical mappings to NIST AI RMF, EU AI Act, ISO 42001, and SOC 2; operationally, the operator picks which frameworks their deployment claims and stands up the evidence to support those claims.

Operating Cadence

A typical cadence for a production operator:

Failure Recovery Patterns

Stuck Settlement

1. Watchdog fires EscrowTimeout or FinalityObservation.
2. Operator inspects the recovery action: retry, refund, or manual review.
3. For a refund, dispatch prepare_escrow_refund with operator override.
4. For a retry, resubmit the dispatch under the same id; the watchdog's state fingerprint guards against duplicate execution.
5. Document the resolution in the exposure ledger so the audit trail is complete.

Claim Dispute

1. Counterparty raises a dispute against a settled receipt.
2. Operator opens a claim per Claims.
3. Both sides exchange evidence (receipts, observed-cost meter records, rail-side proofs).
4. Outcome posts as a follow-up receipt and, if applicable, a refund or chargeback.

Federated Revocation

1. Either side decides to terminate peering.
2. Both operators issue revocation receipts with the agreed effective time.
3. In-flight settlements either complete (if before the effective time) or fall back to per-operator terms (if after).
4. Bilateral receipt channels are closed; auditors receive the full revocation history on request.

Reference chio.yaml Snippet

The economy-relevant sections of chio.yaml. Full schema on Configuration; deployment shape on Deployment.

kernel:
  signing_key_uri: "kms://aws/key-id/.../receipt-signing"
  rotation_window_days: 30

rails:
  - id: "acp-commerce-us"
    kind: api
    custody_provider_id: "acp-commerce.example"
    jurisdiction: "US"
  - id: "ach-batch-monthly"
    kind: ach
    custody_provider_id: "treasury-bank.example"
    jurisdiction: "US"
  - id: "base-mainnet-escrow"
    kind: web3
    custody_provider_id: "escrow.example:base"   # operator label; on-chain custody is the ChioEscrow contract
    chain_id: "eip155:8453"

facilities:
  default:
    ceiling_units: 100000000      # $1,000,000.00 in cents
    currency: "USD"
    utilization_alert_pct: 75

bonds:
  high_risk:
    required: true
    minimum_units: 5000000        # $50,000.00 in cents
    expiry_days: 90

reputation:
  probationary_receipt_count: 1000
  probationary_min_days: 30
  probationary_score_ceiling: 0.60
  tiers:
    probationary:
      max_risk_class: low
    standard:
      max_risk_class: medium
    trusted:
      max_risk_class: high
    elevated:
      max_risk_class: high

watchdog:
  escrow_timeout:
    cron: "*/5 * * * *"
    replay_window_secs: 600
  bond_expiry:
    cron: "0 9 * * *"
    replay_window_secs: 86400

regulatory_api:
  enabled: true
  authorized_regulators:
    - id: "eu-ai-act-supervisor"
      token_secret_ref: "kms://aws/secret/regulator-eu"

billing_export:
  cadence: "weekly"
  destination: "s3://platform-billing/exports/"
  signing_key_ref: "kms://aws/key-id/.../billing-signing"

See Also

Related documentation:

• Agentic Economy Overview
• Economy Stack
• Passports · Reputation · Scorecards
• Manifests · Underwriting
• Credit Facilities · Liability Market · Claims
• Settlement Rails · On-Chain Settlement · Reconciliation & Watchdog
• Bilateral Federation · Bilateral Receipts · Portable Reputation
• Compliance Certificates · Regulatory APIs
• Worked Example
• Configuration · Deployment