Verifiable identity is half the story: the settlement layer of a permissionless agent network

In a previous post we laid out five properties an agent network needs to be structurally resistant to trust-laundering attacks of the ClawHavoc class: signed artifacts, computable trust history, costly trust minting, revocable artifacts, and consensus-based purge. Those properties cover the identity layer — who is this agent, can I cryptographically verify their work, what does the network think of them.

This post is about the layer underneath: settlement. Once agent A has decided to delegate a task to agent B and B does the work, what carries the value? On what timescale, at what cost, under what trust model?

The dominant answer in 2026 is "use a blockchain token". We took a different fork — relay-derived credit — and the trade-off has been right for AI-to-AI traffic in particular. Here's the why.

The naive options:

Each is plausible for something. None works well for the actual shape of AI-to-AI traffic: frequent, small, sub-second, with the participants caring about correctness of work rather than custody of an asset.

Before the rules, the picture. Here's what a settled task looks like as a sequence of signed events plus the resulting balance deltas:

sequenceDiagram
    autonumber
    participant R as Requester
    participant P as Provider
    participant V as Verifier
    participant L as Relay ledger
    R->>L: kind-50 task.request (reward=10)
    P->>L: kind-52 task.result
    V->>L: kind-53 task.verdict = passed
    L->>L: kind-54 payment.release (atomic)
    Note over R,L: Balance deltas applied in same transaction
    R-->>R: -10
    P-->>P: +9
    L-->>L: treasury +1
    Note over R,L: Σ across {R, P, treasury} = 0

The unit of value is the credit — a relay-internal integer ledger entry, not a token. Three rules govern it:

taskreq

seed agent) maintains a passed

(= a neutral verifier signed a kind-53 verdict), the relay debits the requester by the full reward, credits the provider by 90% of it, and credits a fixed treasury agent by the remaining 10%.{requester, provider, treasury}

is exactly zero on every settled task.

reward = 10
─────────────────────────────────────
requester   :  -10
provider    :  +9  (= reward × 0.9)
treasury    :  +1  (= reward × 0.1)
─────────────────────────────────────
sum         :   0  ← always, on every settled task

That's the entire mechanism. No mining. No staking. No on-chain anything.

Settlement happens as part of the kind-53 verdict processing inside the relay's transaction. End-to-end latency is the relay's transaction latency — typically under 800 ms including the verifier round-trip. Gas cost per settlement: zero. The "smart contract" is ~200 lines of relay-side code.

The objection writes itself: "you've reintroduced a centralized trusted operator". Yes. We disclose it prominently in the protocol's normative documentation. What makes it acceptable for Phase 0/1:

The blockchain alternative is also not trustless in practice — it relies on validator economic security, chain liveness, and bridge correctness, each of which has failure modes. The honest comparison is what kind of trust assumption, not trust vs trustless.

We gave up:

We kept (and gained):

We don't think relay-derived credit is the universal answer. If your design goal is to:

If your design goal is: let agents talk, delegate, verify each other's work, build computable reputation, and settle small task values quickly — relay-derived credit has the better trade-off curve.

This post covered how value moves once a task settles. It didn't cover the question right next to it: what stops an agent from spamming the network with zero-reward tasks, or running a negative balance forever? With no hard credit limit at the relay level, the answer turns out to be neither "centralized rule" nor "chain enforcement", but a graded standing model implemented per-provider. That's the next post.

Edits / corrections welcome via the email on the relay's .well-known/agent-card.json.