Chio/Docs
LOGIN · JOIN

Charged at the Owner's Door

When your partner's agents use your model route, your kernel charges the grant from its own hold ledger, and no money crosses between organizations.

Concept chio@5f63e6e

On this page

Two organizations that share agent work have to settle one thing before anything runs: which ledger counts the cost when the partner's agents use your resources. Chio assigns it to the resource's owner. A grant over your model route is enforced and charged by your kernel's hold ledger, at your door and in your currency, so the partner's use of your resources needs no funding transfer, no shared wallet, and no trust in the partner's accounting.

The examples continue Quickstart part 3. Your partner's agents work issue #414 in a fork of your project under treaty trt-01aa…4c19, with your workspace, your model route, and a USD 5.00 pool they all share.

The owner's doorChoose a case.

Your kernel holds the cost before your route runs

A partner agent calls your model route. Their kernel admits the call under its own policy, and their broker forwards it to your door as one authenticated hop with a DPoP proof. Your kernel checks the grant it issued, holds the USD 0.80 worst case in your own hold ledger, dispatches, and signs the receipt. Owner's door.

Your partner's agents using your model route under a grant your kernel issued, with the pool metered in your hold ledger and the partner's own compute in theirs. No line carries money between the organizations. Amounts are illustrative; the treaty, the partner's internal delegation, and the evidence export are left out.

The resource owner's kernel holds and charges every call

The grant your kernel issues names your resources, the rights on each, and one budget for every agent the partner delegates to. Each call to your model route arrives at your door, where your kernel checks the grant, holds the call's worst case in its own hold ledger, dispatches through your broker, reconciles, and signs the receipt. Their kernel sees the outcome; your ledger counts the money.

partners.tspartners.pysrc/main.rs · in main
const authority = fork.grant({
  to: partner,
  under: treaty,
  resources: { "/workspace": ["read", "write"], "/models/default": ["invoke"] },
  delegation: { depth: 2, fanout: 4 },
  budget: USD(5),
  expiresIn: "30m",
});
console.log(authority.describe());
const run = await partner.exec("fix issue #414", { on: fork, authority });
for await (const event of run.events()) console.log(event.summary);
Output
grant      cap-01a9…7e40, under trt-01aa…4c19
to         partner, delegating up to 2 deep and 4 wide
allows     /workspace         read, write
           /models/default    invoke
budget     USD 5.00 pool shared by all of their agents, charged at your door
00:00  them  admitted   "fix issue #414" under trt-01aa…4c19
00:04  you   hold       fixer-1 model.invoke USD 0.80 worst case, pool 0.80 of 5.00
00:09  you   charged    fixer-1 USD 0.23, released 0.57, pool 0.23 of 5.00
       26 more model calls by 4 of their agents
01:47  them  sealed     fork c4e81b7 at 5b93d10
spent  USD 3.12 of 5.00 across 4 of their agents, charged at your door

The events marked you are your kernel's decisions about your route. Every hold, charge, and refusal against the pool happened on your side, and the pool refuses the call that would overdraw it before your model sees the request. A treaty records the same rule per action class: model.invoke is admitted by either kernel and charged at your door.

No money crosses between the organizations to pay for the door

Because the owner charges its own ledger, the partner never holds your funds and you never hold theirs. The pool is a ceiling on what your kernel will serve them, in your currency, and the partner needs no payment rail to use your resources. Each hold and charge has one owner and one ledger, so neither side reconciles a shared balance.

Paying for the work itself is a separate agreement. A work agreement between computers carries no payment by default; when you pay a partner for delivered work, that payment is a funded agreement with its own escrow, and the rail's settlement outcome is recorded on the receipt as observed.

Read more in Verifiable Work and Work Agreements and Funding.

Their broker forwards the call, and your door decides it

Delegation stays inside the partner's organization. Their broker holds your grant as one authenticated hop and, before forwarding, enforces each helper's current local authority, its exact work and resource binding, and its release context. Your kernel authenticates that broker, requires a DPoP proof of possession for the federated grant, and applies its own grant and consumption checks.

Each side keeps its own owner fence and the original operation identity of each call. Your kernel decides from its own revocation state, so a revoked treaty is refused from the next call your kernel decides, whatever the partner's local grants still say; the two kernels do not promise one shared revocation instant.

Read more in Federation & Swarms.

Your cap covers your resources, and theirs covers theirs

The pool bounds what the partner spends of yours. When their agents run their own model, their own harness, or compute they buy elsewhere, their kernel meters it against their own budget at their door, and your pool does not move. From your side that spend is out of layer: your receipts never mention it, and your cap does not limit it. A partner that wants a ceiling on its total cost sets one on its own grants, where its own kernel enforces it.

Either organization can prove what the door charged

Export the shared history and verify it against both pinned kernel keys. Every charge against the pool is a receipt your kernel signed, with its hold and reconciliation:

partners.tspartners.pysrc/main.rs · in mainTerminal
const evidence = await project.history.export("audit/");
console.log(await evidence.verify());
Output
treaty     trt-01aa…4c19, ladders intersect as signed
receipts   61 signed decisions from 2 kernels
spend      USD 3.12 of the 5.00 pool, each charge held and reconciled by your kernel
refusals   1: fixer-2 read /secrets/.env
verified   offline, against both pinned kernel keys

The partner runs the same verification with your kernel's key pinned from your partner card, and reaches the same total from the same signed records.

Next: run the two-kernel Quickstart

Work with their agentsPair two kernels, grant a pool at your door, merge with both signatures, and revoke.Cross-Org SwarmsSplit one budget among another operator's parallel specialists.Guarantees and BoundariesPlace the door charge among every economic claim by boundary class.
PreviousTwo-Org Worked ExampleNextLiability Coverage
Charged at the Owner's Door · Chio Docs