Internet of Agents: Web3 Network

Where the code lives

examples/internet-of-agents-web3-network/. By default, on-chain evidence comes from local validation. The example does not send transactions unless you separately run the deployment or smoke scripts. Mainnet remains blocked.

The smoke does not complete at this commit

./smoke.sh boots four trust-control authorities, two protected API services and three MCP edges, and it stops at the third group. All three chio mcp serve-http processes exit immediately with failed to connect to admission authority: joint admission authority is not configured, and the run then dies on timed out waiting for TCP port. The cause is that chio mcp serve-http --control-url needs a trust-control started with --session-db, which is what maps to the joint admission authority (crates/products/chio-cli/src/cli/runtime.rs:1405), and none of the four chio trust serve invocations at scenario/lib.sh:83-124 passes it. Everything on this page below the architecture is therefore read out of the committed bundle at app/tests/fixtures/good-bundle/, which is what the verifier checks, rather than from a live run.

What It Shows

Four orgs (operator, provider, subcontractor, federation verifier), each running its own chio trust serve authority with its own seed.
Two API services (market broker and settlement desk) protected by chio api protect.
Three MCP edges (web3-evidence, provider-review, subcontractor-review) under chio mcp serve-http.
RFQ selection over passport, reputation, runtime, federation admission, and budget. Cheap-but-low-reputation and over-budget-malicious bidders are rejected with denial receipts.
Two-hop subcontracting: ProofWorks delegates a narrowed capability to CipherWorks for a specialist proof-leaf review.
Cross-rail settlement: prefer Base Sepolia when evidence is attached, fall back to local devnet, deny unsupported Solana memo-only paths in the same review.
Adversarial denials: prompt injection, invoice tampering, quote replay, expired capability reuse, unauthorized rail, forged passport.

Architecture

rendering

Four trust-control authorities (operator, provider, subcontractor, federation verifier) sit behind two protected API services and three MCP edges. Settlement evidence routes through a web3 rail; Base Sepolia attaches when live evidence is present.

Service Inventory

scenario/lib.sh provisions the processes and assigns free ports. Per-organization sqlite stores live under artifacts/web3-service-order/<ts>/state/.

Process	Command	Owner
operator-trust-control	`chio trust serve` + `--authority-seed-file`	Atlas Operator
provider-trust-control	`chio trust serve`	ProofWorks
subcontractor-trust-control	`chio trust serve`	CipherWorks
federation-trust-control	`chio trust serve`	Meridian
market-broker (raw + sidecar)	`market_broker.py` + `chio api protect --spec services/market-broker-openapi.yaml`	Atlas
settlement-desk (raw + sidecar)	`settlement_desk.py` + `chio api protect --spec services/settlement-desk-openapi.yaml`	Atlas
web3-evidence MCP	`chio mcp serve-http` + `tools/web3_evidence.py`	Meridian
provider-review MCP	`chio mcp serve-http` + `tools/provider_review.py`	ProofWorks
subcontractor-review MCP	`chio mcp serve-http` + `tools/subcontractor_review.py`	CipherWorks
orchestrator	`python orchestrate.py`	Atlas (CLI)

Prerequisites

The chio CLI: cargo build --bin chio.
The local web3 validation ladder: ./scripts/qualify-web3-local.sh. This generates the local verification fixtures the example attaches to its bundle.
For the optional on-chain attachment: a successful prior run of the Base Sepolia rollout that produced target/web3-live-rollout/base-sepolia/base-sepolia-smoke.json. When present, the example detects it automatically and attaches the tx hashes for operator setup, USDC approval, escrow create, root publication, release/refund paths, and price readback. Without the file, the example runs against the local devnet evidence only.
For the optional UI: CHIO_RUN_E2E=1 plus a local bun toolchain. The smoke serves the Next.js evidence console against the freshly written bundle and runs a Playwright suite over it.

Run It

bash

# From the chio workspace root
cargo build --bin chio
./scripts/qualify-web3-local.sh

# Run the mediated flow
examples/internet-of-agents-web3-network/smoke.sh

# Pin the artifact directory
examples/internet-of-agents-web3-network/smoke.sh \
  --artifact-dir target/web3-example-qualification/internet-of-agents-web3-network

# Require the Base Sepolia attachment
examples/internet-of-agents-web3-network/smoke.sh --require-base-sepolia-smoke

# Run with the Next.js evidence console e2e suite
CHIO_RUN_E2E=1 examples/internet-of-agents-web3-network/smoke.sh

Phase 1: Bootstrap Authorities

scenario/lib.sh deterministically derives one authority seed per org from a labelled SHA-256 input, writes the seed file at 0600, and points chio trust serve at it via --authority-seed-file. This makes runs reproducible.

scenario/lib.shbash

"${CHIO_BIN}" trust serve \
  --listen "127.0.0.1:${OPERATOR_TRUST_PORT}" \
  --advertise-url "${OPERATOR_CONTROL_URL}" \
  --service-token "${SERVICE_TOKEN}" \
  --receipt-db "${STATE_DIR}/operator-receipts.sqlite3" \
  --revocation-db "${STATE_DIR}/operator-revocations.sqlite3" \
  --authority-seed-file "${OPERATOR_AUTHORITY_SEED}" \
  --budget-db "${STATE_DIR}/operator-budgets.sqlite3"

Phase 2: RFQ Selection

The procurement agent posts a request to the market broker sidecar. Three providers bid: a cheap low-reputation provider, a over-budget provider, and ProofWorks. Chio policy reads passport, reputation, runtime tier, budget, and federation admission verdict. The first two bids are rejected with denial receipts. ProofWorks wins.

build_rfq_request takes the order request and the procurement agent's capability and writes the result to market/rfq-request.json in the run bundle (examples/internet-of-agents-web3-network/internet_web3/scenario.py:364-366). This is the copy the app's bundle tests read:

examples/internet-of-agents-web3-network/app/tests/fixtures/good-bundle/market/rfq-request.json·json

{
  "buyer_id": "atlas-treasury-desk",
  "capability_id": "cap-ioa-web3-procurement",
  "currency": "USDC",
  "issued_at": 1776995579,
  "max_budget_minor_units": 300000,
  "order_id": "ioa-web3-order-001",
  "provider_ids": [
    "proofworks-agent-auditors",
    "discount-zk-reviewers",
    "overbudget-shadow-settlers"
  ],
  "requested_scope": "base-sepolia-usdc-dress-rehearsal",
  "rfq_id": "rfq-ioa-web3-order-001",
  "schema": "chio.example.ioa-web3.rfq-request.v1"
}

ProofWorks wins. The winning bid carries pricing, runtime attestation, federation admission, and the admission verdict the chio policy ran:

market/provider-bids.json, bids[0]json

{
  "bid_id": "bid-proofworks-agent-auditors-ioa-web3-order-001",
  "currency": "USDC",
  "deliverables": [
    "validation-index-review",
    "base-sepolia-transaction-map",
    "settlement-dispatch-readiness-note"
  ],
  "expires_at": 1776996479,
  "issued_at": 1776995579,
  "order_id": "ioa-web3-order-001",
  "price_minor_units": 200000,
  "provider_id": "proofworks-agent-auditors",
  "requirements": [
    "passing e2e qualification",
    "passing promotion qualification",
    "passing ops incident audit",
    "passing Base Sepolia smoke"
  ],
  "risk": {
    "expected_outcome": "deliver",
    "profile": "trusted"
  },
  "service_id": "base-sepolia-usdc-dress-rehearsal",
  "trust": {
    "claimed_reputation_score": 0.91,
    "federation_status": "eligible",
    "passport_status": "valid",
    "runtime_tier": "attested"
  }
}

A bid carries the order_id, not the rfq_id: the rfq id sits once at the top of the file beside bids. Its window is two unix timestamps, issued_at and expires_at, and requirements is prose the provider claims to meet, not a machine-readable evidence list.

Selection rationale (single passing federation admission):

federation/provider-admission-verdicts.json (abridged)json

{
  "providers": [
    { "provider_id": "proofworks-agent-auditors", "verdict": "pass",
      "reasons": [] },
    { "provider_id": "discount-zk-reviewers", "verdict": "fail",
      "reasons": ["reputation_below_threshold", "passport_claim_drift"] },
    { "provider_id": "overbudget-shadow-settlers", "verdict": "fail",
      "reasons": ["runtime_tier_below_attested", "reputation_below_threshold",
                  "passport_claim_drift", "budget_exceeds_policy"] }
  ],
  "schema": "chio.example.ioa-web3.provider-federation-verdicts.v1"
}

Bundle output: rationale and bids land under market/; passport and reputation evidence under identity/passports/ and reputation/.

Phase 3: Two-Hop Subcontract

ProofWorks delegates a narrowed capability to CipherWorks for a specialist proof-leaf review. The delegation inherits obligations from the parent capability. Both kernels emit receipts; the lineage chain is preserved through trust-control's lineage store.

There is no delegation request or response file. The bundle records the result: a delegated capability whose delegation_chain holds one signed entry per hop, and the obligations that came down with it. The capability itself is a CapabilityToken like any other, with id, issuer, subject, scope, issued_at, expires_at, signature, plus the chain. There is no delegation_depth, ttl_secs or parent_capability_id field: depth is the chain length and the parent is its last entry.

subcontracting/delegated-capability.json, delegation_chain elidedjson

{
  "delegation_chain": [ /* two signed entries, shown below */ ],
  "expires_at": 1776996480,
  "id": "cap-ioa-web3-cipherworks-specialist",
  "issued_at": 1776995580,
  "issuer": "bff663535a5cf58658cc38595d20dc4501f6dfc076ddf07e20571d413a3ceb5a",
  "scope": {
    "grants": [
      {
        "constraints": [],
        "operations": ["invoke"],
        "server_id": "subcontractor-review",
        "tool_name": "issue_specialist_review"
      }
    ],
    "prompt_grants": [],
    "resource_grants": []
  },
  "signature": "ebe990b84083a284493dc7bbf05d9811c7ae830ec4196e9fdeda299abfa947eb...",
  "subject": "50570882ff97adecaac9c848ebd7078f96103c0c2041b0d9cf2a3890ce24f685"
}

The second chain entry is the hop this section is about: ProofWorks as delegator, CipherWorks as delegatee, under the parent cap-ioa-web3-provider, with three attenuations.

subcontracting/delegated-capability.json, delegation_chain[1]json

{
  "attenuations": [
    { "kind": "specialist_review_only" },
    { "kind": "no_payment_authority" },
    { "kind": "inherits_mainnet_block" }
  ],
  "capability_id": "cap-ioa-web3-provider",
  "delegatee": "50570882ff97adecaac9c848ebd7078f96103c0c2041b0d9cf2a3890ce24f685",
  "delegator": "bff663535a5cf58658cc38595d20dc4501f6dfc076ddf07e20571d413a3ceb5a",
  "signature": "6760cc485bf3379fa13a3664ecf199d52a66414da911eec59a973a22f70ea6ff...",
  "timestamp": 1776995580
}

The obligations ride in a separate file, camelCase on the wire, naming the parent and the child capability:

examples/internet-of-agents-web3-network/app/tests/fixtures/good-bundle/subcontracting/inherited-obligations.json·json

{
  "obligations": [
    "mainnet-disabled",
    "read-only-evidence-review",
    "no-payment-authority",
    "attach-receipt-to-provider-review"
  ],
  "parentCapabilityId": "cap-ioa-web3-provider",
  "schema": "chio.example.ioa-web3.inherited-obligations.v1",
  "status": "inherited",
  "subcontractorCapabilityId": "cap-ioa-web3-cipherworks-specialist"
}

Bundle output: subcontracting/ for the narrowed capability, obligations, and the specialist review attestation.

Phase 4: Cross-Rail Settlement

The settlement agent assembles a packet, the settlement-desk sidecar signs it, and the rail-routing logic in internet_web3/rails.py chooses a rail. Order of preference:

Base Sepolia, when target/web3-live-rollout/base-sepolia/base-sepolia-smoke.json is present. The example attaches operator setup, USDC approval, escrow create, root publication, release/refund, and price-readback tx hashes.
Local EVM devnet, when only the local validation ladder is present. The example records local proof-of-concept rail evidence.
Solana memo-only is denied in the same review with a denial receipt: the example proves the rail is unsupported in this configuration.

Bundle output: settlement/rail-selection.json carries the chosen rail and the denied ones with their reasons; rail-level evidence sits under web3/; and the dispatch and its receipt are contracts/web3-settlement-dispatch.json and contracts/web3-settlement-receipt.json.

Phase 5: Auditor Review

The auditor reads the bundle through the read-only web3-evidence MCP edge. The verifier (internet_web3/verify.py) checks required output files, default Chio mediation, adversarial denials, budget reconciliation, RFQ routing, two-hop lineage, and the Base Sepolia attachment when required. review-result.json fails closed when any check fails.

Inspect On-Chain State

When the Base Sepolia attachment is present, the bundle includes the rail-level identifiers and the tx hashes that backed each step. To inspect the on-chain state from the bundle:

bash

cd <artifact-dir>

# Settlement rail rationale and the rail used
cat settlement/rail-selection.json

# Web3 evidence: copied validation ladder + Base Sepolia attachment
ls web3/
cat web3/base-sepolia-smoke.json   # only when the live rollout report exists

# The dispatch and the receipt that committed to the payment_reference
cat contracts/web3-settlement-dispatch.json
cat contracts/web3-settlement-receipt.json

# Re-derive the on-chain state from a tx hash
# (requires a Base Sepolia RPC endpoint configured separately)
cast tx <tx_hash> --rpc-url <base-sepolia-rpc>

The bundle does not embed RPC endpoints. The auditor brings their own. Verifying the dispatched receipt offline (signature plus Merkle inclusion) is sufficient to bind the receipt to a kernel-signed action; pulling tx confirmations is an additional independent check against the chain.

Bundle Layout

The smoke writes a bundle under the selected output directory. The full layout is in the example README; the operator-facing entries are:

text

agents/                deterministic agent decisions
chio/topology.json     four-org mediated runtime topology
chio/capabilities/     trust-control-issued capabilities (per org)
chio/receipts/         trust, API sidecar, MCP, and lineage receipts
chio/budgets/          authorize-exposure / reconcile-spend
contracts/             service order, settlement packet, dispatch, receipt
disputes/              partial payment, refund, remediation
evidence/              read-only web3 evidence MCP output
federation/            chio policy, export/import, admission, federated cap
financial/             settlement reconciliation
guardrails/            invalid SPIFFE, overspend, velocity denial receipts
identity/              passports, presentations, runtime appraisals
lineage/               delegated capability chain projections
market/                RFQ, bids, selection, quote, fulfillment package
operations/            trace map, SIEM events, operations timeline
payments/              x402 payment-required + chio payment proof
provider/              provider review and reputation evaluation
reputation/            local report, passport comparison, admission verdict
scenario/              copied order, policy, catalog, timeline
settlement/            cross-rail selection rationale
subcontracting/        specialist review capability + obligations
web3/                  validation ladder + optional Base Sepolia evidence
bundle-manifest.json   SHA-256 manifest for offline review
review-result.json     verifier verdict
summary.json           operator-facing pass/fail summary

Mainnet stays blocked

The example never attempts a mainnet write. Base Sepolia attachment is read-only with respect to chain state; it consumes the smoke report produced separately by the live rollout scripts.

Where to read more

On-chain Settlement for the settlement dispatch contract. Settlement Rails for the dispatch step and the watchdog cycle. Chainlink for the cross-chain CCIP path.

PreviousIncident Network NextTrust Control