Extension is additive
Removing tasks, reclaiming budgets, migrating receivers or changing policy limits needs closure or fencing rules beyond this operation.
Chio Research / WhitepaperWorking paper · October 2026
A Peer-to-PeerEconomyof Verifiable Work
Chio, a kernel architecture for work that crosses owners
Agent programs now hire other agents mid-run, across systems they do not control. Chio lets each owner admit work under its own capabilities, policies and treaties, binds every hire to the exact call it authorized, and keeps earned payments safe when the larger plan fails.
One plan, three kernelsFig. 01
Each task runs on its own kernel, with its own key and execution store.
The plan grows3 → 4 tasks
Task 1 finds an API operation without required authentication. Task 2 spawns task 2.1 on its own kernel, with a capability, a sealed selection and a 100-unit deposit.
| Task | Execution | Money |
|---|---|---|
| Task 1 | Completed | Funded |
| Task 2 | Running | Funded |
| Task 2.1 | Spawned | 100 deposited |
From the paper’s composed run · one administrator · mock tokens
01The Kernel Boundary
planning outside · authority inside
Agents plan. Owners admit.
Chio separates an agent’s planning from the authority and durable state that govern its effects. An untrusted agent proposes operations; the receiving kernel admits them under its owner’s capabilities, policies and treaties, records their execution, and signs receipts other participants can check.
Two owners, one programFig. 02
- Programmable sovereignty
- An owner defines the conditions under which external work may affect its resources and enforces them at the execution boundary. A foreign agreement is evidence, evaluated under local authority.
- Verifiable work
- Work with checkable authorization, an attributable execution history and acceptance under agreed rules. What acceptance says about a result depends on the procedure the parties chose.
A request can refer to authority. It cannot install it.
Trusted issuers · capabilities · policy · treaties · replay state
02Work Commitments
allocator · receiver · verifier · escrow
Four authorities. One invocation.
A work commitment links signed records that bind a selected invocation to a bounded allowance, the receiving owner’s authorization and, for paid work, its settlement terms. Each authority keeps the state for the resource it controls; authenticated references tie their decisions to the same call.
One commitment, four authoritiesFig. 03
The work slot
S = (i, h, E, A, b, c, t, d, Q)islothholderEtool operationsAreadersbceilingccurrencytexpiryddepthQacceptance
A child may only narrow: its operations and readers are subsets, its expiry is no later, its depth is smaller, its currency is unchanged, and the children’s ceilings sum to no more than the parent’s.
Rejected before dispatch
Two valid signatures, one wrong call.
Task 2.1’s permit and capability name receiver R1. A correctly signed graph routes the same task to R2. Each record verifies on its own, so checking them one by one would miss it. The receiver rejects the combination: its key, the offer’s receiving key and the route’s destination must match.
03Execution Across Evolving Plans
additive extension · durable admission
A new signature is not a new right.
The task graph can grow while earlier work continues under its original terms. Installation compares the expected graph digest and commits the new head in one transaction, so two extensions of the same head cannot both install.
The plan grows; the right does not renewFig. 04
When a claim becomes earnedFig. 05
A timeout is a missing response, not evidence.
Without authoritative completion evidence, the state stays OutcomeUnknownAfterDispatch and supplies no fresh authority to call the tool.
04Preservation of Commitments
Proposition 1 · conditional
Bounds, identity and earned claims survive.
Every finite interleaving of subdivision, selection, sealing, graph extension, execution, recovery and settlement preserves three properties, under explicit assumptions: unforgeable signatures, collision-resistant digests, valid clock checks, honest enforcement by the selected authorities and exclusive custody at each scarce resource.
- Property 1 · Resource boundsArgued by induction
Σleaves v bv + Σinternal v Uv = BDΣa ∈ 𝒜i+1 b(a) ≤ BGDu = Fu + Lu + Pu + RuDelegation and graph allocations stay within their original bounds, and paid plus refunded funds never exceed the deposited backing.
- Property 2 · Invocation identityArgued by induction
receiver · capability · input · tool operation · request — fixed at sealingA sealed invocation keeps its receiver, capability, input, tool operation and request. Plan growth and replay grant it no further execution right.
- Property 3 · Earned claimsArgued by induction
accepted(claim) → claim ∈ {Payable, Paid}An earned child claim keeps its terms and stays payable or paid through the parent’s failure, completion or refund.
The accompanying Lean development checks abstract financial conservation and earned-state lemmas, and tests exercise the concrete admission and recovery rules. The artifact contains no machine-checked refinement from the argument to the Rust and Solidity implementations.
05Implementation and Evaluation
one administrator · mock tokens
Grow the plan. Kill the parent. Keep the payment.
The composed run follows one program through task discovery, graph growth, process loss and settlement: three receiving keys with separate stores on one host, in-process treaty co-signers, a private development chain and mock tokens.
- 01task 1
Examines an OpenAPI document and finds an operation without required authentication.
- 02task 2
From that result, spawns task 2.1 on an enrolled kernel: a task, capability, sealed selection, payment agreement and 100-unit deposit.
- 03plan
The checked graph grows from three tasks to four, keeping task 1’s original execution evidence.
- 04task 2.1
A separately written checker accepts its result. The escrow records it Payable.
- 05task 2
Killed with SIGKILL before it returns. Its funding refunds; its outcome stays unknown.
- 06task 2.1
Withdraws its claim. Collecting again makes no second call and no second transfer.
The paper’s example names these processes the buyer (the root plan), the survey (task 1), the intermediary (task 2) and the specialist (task 2.1).
| Task | Execution | Money |
|---|---|---|
| Task 1 | Completed; original evidence retained | Paid 100 |
| Task 2 | Unknown after dispatch | Refunded 100 |
| Task 2.1 | Completed; original claim retained | Paid 100 |
Final balances · 2,000 mock units
- Root owner900
- K₂ owner1,000
- K₃ owner100
- Escrow0
Rejected at admission
- A re-signed graph that changes an issued continuation
- A sealed allocation selecting a different invocation
- Missing treaty evidence
- A capability issued by another receiver
- A signed route naming another receiver
- A fresh request reusing a consumed continuation
In the evaluated fixed profile, an example adapter supplies some of these cross-record checks; they are not yet part of the public runtime admission API.
Financial comparison
An ordinary SQL-transaction implementation of the financial state machine matches every compared state and balance. The pinned ERC-8183 implementation also pays a separately funded child after a parent refund; the paper acknowledges that overlap, and ERC-8183’s richer partial settlement.
The current qualification records 21 terminal commands, including the composed run and four child-payment crash and transaction-recovery cases.
06Scope and Status
what it shows · what it does not
What the result covers, and what it does not.
The local experiments do not measure independent administration, public-chain finality, hostile-load scalability, integration savings or useful-work profitability.
Acceptance is as strong as the check
Delegation predicates test bounded properties of JSON output. A child’s success does not establish its parent’s.
Safety, not progress
Sealing can strand capacity, and a verifier failure before acceptance can leave completed work unpaid. Nothing earlier is undone.
The authorities must hold
A compromised allocator can overissue, forked stores can duplicate authority, and a dishonest verifier can approve bad output.
Publication status
A working paper, held to a higher bar.
The paper keeps its own publication gates. Four pass. Four remain open, and the paper does not claim a breakthrough until they do.
- ManuscriptPassed
- Reproducible artifactPassed
- Funded-security integrationPassed
- Closest prior art (ERC-8183)Passed
- Independent operationOpen
- Useful-work economicsOpen
- Integration advantageOpen
- Independent expert critiqueOpen
Earlier work
Proof-Carrying Bilateral Admission for Cross-Organization Agent Tool CallsThe receiver-owned admission rule this paper builds on, with bounded Lean theorems and a measured three-vendor loopback.
Chio Research / Working paper · October 2026
A Peer-to-Peer Economy of Verifiable Work.
Read the full construction, the preservation argument, the evaluation and its limits in the paper.