Agentic Economy
Agents spend under bounded authority and get paid for work a verifier accepted, with each cost reserved before dispatch and recorded on a signed receipt.
On this page
An economy of agents rests on two guarantees. Spending stays inside the authority someone granted, and payment follows work that was checked against what was agreed. Chio carries money inside the capability, so the kernel checks a budget with scope and policy before a call reaches a tool. It binds payment to a recorded verifier decision, so a provider is paid for accepted work and a buyer is refunded for rejected or abandoned work.
Your application composes the rest of the exchange around those two checks: quoted terms, counterparties, and settlement of what is owed. Payment rails are modules outside the kernel, and the finding-market and web3 modules are off by default. Guarantees and Boundaries states which of these properties the kernel prevents, which it detects, and which sit outside what it sees.
Give an agent a budgetHold
Payments
Before dispatch the kernel reserves the worst-case cost in the hold ledger, the one consumption authority. A family cap bounds what siblings spend together.
Read more in Authoritative Spend.
A hold reserves the cost before the call runs
A grant carries its budget beside its resources: per-call and total limits and an expiry. Before dispatch the kernel reserves the worst-case cost in the hold ledger, the one consumption authority for that budget, and admits the call only when authority, policy, and the hold all pass. Give an outside buyer USD 2.00 of quotes from your pricing service at USD 0.01 a call:
pricing.grant({
to: "did:chio:z6MkbY4…e1R",
tools: ["quote"],
budget: USD(2),
expiresIn: "24h",
});
for await (const call of pricing.events()) console.log(call.summary);00:00 z6MkbY4 quote sku-118 at 10% allow USD 0.01
00:02 z6MkbY4 quote sku-204 at 25% allow USD 0.01
197 more quotes at USD 0.01 each
41:57 z6MkbY4 quote sku-301 at 15% allow USD 0.01, 2.00 of 2.00 spent
41:59 z6MkbY4 quote sku-118 at 10% refused budget, needs USD 0.01, USD 0.00 leftpricing.grant(
to="did:chio:z6MkbY4…e1R",
tools=["quote"],
budget=USD(2),
expires_in="24h",
)
for call in pricing.events():
print(call.summary)00:00 z6MkbY4 quote sku-118 at 10% allow USD 0.01
00:02 z6MkbY4 quote sku-204 at 25% allow USD 0.01
197 more quotes at USD 0.01 each
41:57 z6MkbY4 quote sku-301 at 15% allow USD 0.01, 2.00 of 2.00 spent
41:59 z6MkbY4 quote sku-118 at 10% refused budget, needs USD 0.01, USD 0.00 leftpricing.grant(
ServiceGrant::to("did:chio:z6MkbY4…e1R")
.tool("quote")
.budget(USD(2))
.expires_in("24h"),
)?;
let mut calls = pricing.events();
while let Some(call) = calls.next().await {
println!("{}", call?.summary());
}00:00 z6MkbY4 quote sku-118 at 10% allow USD 0.01
00:02 z6MkbY4 quote sku-204 at 25% allow USD 0.01
197 more quotes at USD 0.01 each
41:57 z6MkbY4 quote sku-301 at 15% allow USD 0.01, 2.00 of 2.00 spent
41:59 z6MkbY4 quote sku-118 at 10% refused budget, needs USD 0.01, USD 0.00 leftThe two-hundredth quote spends the last cent. The next one is refused before your code runs, so nothing is computed and nothing is charged. After a call, the hold reconciles down to the actual charge; a lost reply keeps its reservation, and the kernel never re-dispatches a call whose outcome is unknown.
Delegation divides a budget, and each child holds less than its parent. Shared budgets and pools put a family cap on what siblings spend together, model calls included. Cross-currency budgets convert a charge into the budget's unit through a checked oracle price before the hold is taken.
Read more in Budgets & Metering, Authoritative Spend, and Predeclared Settlement.
Payment follows a recorded decision about the work
A call that stays within budget is authorized; whether its result is worth paying for is a separate question. Verifiable work answers it in three decisions. The provider's kernel admits the request under authority it activated locally. A verifier named in the agreement accepts or rejects the output against the exact input and terms. The rail then settles against that signed decision.
The buyer funds escrow for the exact agreed terms before any work starts. The provider submits one immutable commitment to its output, and only a recorded accepting decision makes the allocation payable. A rejection, or a deadline that passes without a decision, refunds the payer. No party can turn an uncertain execution into a no-effect outcome to release the funds.
Read more in Verifiable Work, Work Agreements and Funding, Work Claim Escrow, Run Verifiable Work, and The Delivery Contract.
Signed terms bind a price to the request that pays it
A signed manifest or quote names the provider, the scope, and the price, and the integration binds the accepted terms to the request it sends. Providers publish signed tool manifests, buyers find them through capability discovery, and a signed bid, the provider's ask, and an acceptance backed by held funds buy scoped, time-bounded access (Bidding) or a bilateral work agreement (Contracts). Prices are posted: the provider signs an ask and a buyer accepts it, with no auction or order book. Signed registry charters and cases decide a listing's effective state when it is contested (Listing Disputes).
A price can be fixed or metered on the request (Pricing Models) or charged only when the delivered bytes pass the provider's signed predicate (Outcome-Based Pricing). Guards are sold the same way: the guard marketplace lists cosigned guard packages, prices each invocation by the buyer's reputation tier, and gates an install on a reputation-weighted credit limit.
A finding is priced and paid for before its content is revealed
In the cognition market, your partner sells a verified fix for issue #417 as a finding: a priced commitment to content you have not seen. A paid reveal releases the committed patch only after the kernel's delivery check passes. A fleet buys findings from one governed budget pool, and a buyer that lost a paid payload redelivers it under a no-charge recovery grant bound to the original delivery receipt.
Challenges, status feeds, the threat model, and the hosted profile cover what happens after the sale.
Run one end to end in Run a Cognition Market.
Settlement resolves the obligation the receipt recorded
A receipt records what the kernel charged at your door; settlement resolves what one party owes another. Payment rails attach outside the kernel: x402, ACP, and on-chain escrow plug in through settlement rails, and an approval-bound payment settles only against the verified human approval it was granted for. Holds and caps prevent spend before dispatch; a rail's settlement outcome is observed and recorded on the receipt.
On-chain settlement runs escrow on an EVM chain, anchoring commits batches of receipt roots to public chains and transparency logs, and payment channels carry many small payments between two parties.
Obligations carry a debt as a signed record, clearing rounds net many obligations into a few transfers, and revenue splits divide one payment among beneficiaries in basis points that sum to the whole. After an unknown outcome, only a co-signed MutuallyAgreedUnknown releases the money, and a pending capture on a known return stops only with a ContractualCaptureWaiver.
Read more in How a Purchase Works.
A receiving operator decides whom it deals with from signed evidence
Before you sell to an outside buyer or buy from your partner, your kernel needs evidence about the other side. Passports say who the counterparty is, and financial credentials carry its credit, exposure, settlement, and loss record as signed claims you evaluate under your own policy. Reputation scoring and portable reputation summarize its signed history, and credit scorecards, underwriting, and credit facilities decide how much it may owe.
Each organization admits and charges work at its own door
When your partner's agent asks your service for work, your kernel admits it under a co-signed, attenuated work commitment and charges it against your own holds (Charged at the Owner's Door). Bilateral receipts give both kernels a signed record of one exchange, and cross-org swarms send one step of a delegated task graph to your partner's agents.
Follow both sides in the Two-Org Worked Example.
Coverage binds to specified work and pays from receipt evidence
When work can fail expensively, liability coverage binds to specified work, parametric insurance computes a claim from a deterministic trigger over receipt evidence, and claims run under the bound terms. Autonomous pricing lets a pricing model set premiums and prices inside signed envelopes that force a rollback on drift.
The operator sets the rules, and an auditor checks the evidence offline
Fiscal charters set the rules the kernel applies to spend, and a change to a credit ceiling or premium schedule passes through signed approvals and a timelock. Operating an Economy covers trusted keys, durable state, counterparties, and recovery, and money conservation states the ledger law every hold, release, and reconciliation obeys.
The Comptroller Console turns the signed receipt log into a live spend stream with utilization webhooks and burn-rate projections, and the economic wind tunnel replays seeded adversarial campaigns against the economy validators before a change ships. An auditor verifies a commerce bundle without running your services (Verify Commerce Evidence), reads compliance certificates, and queries the audit APIs and risk reports.
Find the Rust type behind any of these in Economy Crates.