Operating an Economy

This page is the synthesis. Every primitive elsewhere in the Agentic Economy section has its own dedicated doc; this is the view of how an operator wires them together to stand up an end-to-end economy and keep it running. No new mechanisms, just the configuration patterns and the operating cadence.

A Day in the Life

Choosing Settlement Rails

Most operators run a portfolio rather than a single rail. The decision is per-counterparty, not global. A reasonable starting layout:

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

Provider Allowlists

Each rail has an explicit allowlist. Stripe, Adyen, Worldpay, etc. are payment processors; Base, Arbitrum, Optimism are on-chain networks. 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 paperwork is done. Never let configuration drift add a rail.
• 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 reasonable rule of thumb: ceiling = projected daily volume × max-settlement-latency-days × 1.5. The 1.5 multiplier absorbs spike days. Quarterly review either justifies the ceiling against actual utilization or rebalances.

Bond Requirements

Bonds are operator-funded collateral held in ChioBondVault (on-chain) or in custodial accounts (off-chain). They are not insurance; they are skin-in-the-game collateral that backs 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 and tracked over its lifecycle through BondLifecycleStatus (Active, Released, Impaired, Expired). 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 DataIntegrity 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 end-to-end cooperative settlement before flipping any production rail on.
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 key management you actually run, not key management you wave at:

• Storage. Receipt-signing keys live in an HSM, KMS, or equivalent. They never 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 thresholds are operator policy; the inputs are signed receipts. Three tiers cover most operators:

Demotion is faster than promotion. A single confirmed dispute can drop an agent two tiers; 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: "stripe-prod-us"
    kind: api
    custody_provider_id: "stripe.com"
    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: "chio-escrow:base"
    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:
  tiers:
    new:
      promote_after_settled_calls: 50
      max_risk_class: low
    established:
      max_risk_class: medium
    trusted:
      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

This page is the hub. The dedicated pages:

• 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