Composition Note: Agent-Service Consultation Flow composing the agent ERCs (8004 · 8263 · 8274 · 8275 · 8281 · 8299 · 8301) [Informational]

[TMerlini]

Several of the agent-layer standards now in flight each define one layer of an agent interaction, identity, input provenance, verification, anchoring, eligibility, settlement, orchestration. What hasn’t existed is a canonical end-to-end flow showing how they compose into one real interaction: an agent (or human) consulting another agent’s specialised service, getting a verifiable result, and paying for it without trusting the provider.

This note documents that composition pattern. The contribution is the pattern and the per-step invariants, not any single standard. Each step is defined by the role and the property it must satisfy; the named ERCs are current conformant examples of those roles, cited to ground the pattern in deployed code. It does not advocate any member standard and does not depend on any member’s status or number, the invariants hold wherever each layer’s standard lands. It’s framed for the Informational track for exactly that reason: it describes how independently-specified layers compose, and the interface seams between them.

The flow (each step = a role + an invariant; example standard in parentheses):

1. Identity & discovery (ERC-8004 + ERC-8217 binding)

2. Consult / task (ERC-8301 AgentTask)

3. Input provenance (ERC-8281/OCP + ERC-8299/WYRIWE)

4. Execution & verification (ERC-8274, anchored via ERC-8263)

5. Eligibility / receipt (ReceiptOS, the 8263 seam)

6. Settlement (ERC-8275 + settler)

7. Reputation (recomputable, from signed verdicts vs. settled outcomes)

A single commitment binds the whole interaction, the report, the verification, the eligibility receipt and the payment all reference one recomputable value; no layer trusts another.

It runs live. The flow was executed end-to-end against a deployed agent as an external client (no modification to the running service): a real ERC-8004 agent returned a forensic report, bound to the query in a WYRIWE commitment, paid for with the commitment embedded in the calldata — and two co-authors who did not run the demo independently re-derived the commitment from public data alone. A trustless variant (escrow that releases only against an on-chain-verified signature over the result commitment) is also demonstrated live.

Per-step conformance criteria are in §5 each step’s author states the invariant their layer must satisfy. 7 of 8 are in (identity, task, provenance, verify, eligibility, reputation, anchor); Step 6 (settlement) is in progress, pending the settlement-scope discussion. This thread is the living artifact; an Informational ERC follows once §5 closes.

It also answers two open thread questions directly: the common execution envelope ( @KBryan ) and multi-agent accountability / interop ( @Ankita.eth ) both resolved through the per-step-commitment rule rather than a fixed step boundary.

Full note: https://gist.github.com/TMerlini/c02bc4f56bc573a10a0cd9d487b8e884

Authored per-layer by: Tiago Merlini ( @TMerlini ) · Damon Zwicker ( @Damonzwicker ) · Jimmy Shi ( @JimmyShi22 ) · Vincent Wu ( @TruthAnchor-AI ) · babyblueviper1 ( @babyblueviper1 ) · Panini ( @Brooks1003 ) · Pavlo Tvardovskyi @pipavlo82 equal credit, scoped to each layer.

Feedback on the invariants and the seams welcome, especially from the layer authors and from anyone whose standard could serve as an additional conformant example.

[babyblueviper1]

Co-author of Steps 4 and 7 here. This is the right framing: the contribution is the pattern and the per-step invariants, with each named ERC as a current conformant example rather than a dependency — so the note stands regardless of any member’s number or status changing.

On the two sections I wrote, the load-bearing property is that each is checkable from public data with no trust in the validator or any intermediary. Step 4 (verify, ERC-8274 anchored via ERC-8263) is conformant only if the verdict binds its facts and its committed_at is provably prior to the outcome it’s graded against. Step 7 (reputation, the ERC-8275 axis) is a value recomputed from settled outcomes — not a score a party maintains.

On the seams either side, since the invariants are only as strong as the joins. Step 4 consumes Step 3’s input commitment: the verdict commits to the same inputHash that was anchored pre-execution (OCP / ERC-8281 plus the WYRIWE binding) and links to the step it gates through DAG predecessor linkage, so a verdict cannot be re-pointed at a different input after the fact. Downstream, Step 4 stops at authenticity of the verdict and hands off to Step 5 (ReceiptOS) for eligibility — verified is deliberately not the same as admissible. Step 7 in turn reads only what Step 6 settles, counting outcomes whose settlement postdates the verdict’s committed_at, and that committed_at is read from the ERC-8263 anchor rather than asserted by us. So reputation composes over the settlement layer and the anchor instead of restating them.

All of this is meant to be verified, not taken on faith. The production instance is api.babyblueviper.com/ledger. Entry 19 is the worked example: a pre-action verdict whose committedAt precedes revealedAt, the signed event recoverable from public relays and the commitment anchored on-chain, so anyone can recompute the ordering independently. The reputation axis recomputes live at the endpoint and pins no snapshot, since the figures move as the ledger settles against capital. Read the properties, not a fixed number.

Happy to take questions on the verify and reputation layers.

[pipavlo82]

Very helpful to see the live ledger implementation.

[babyblueviper1]

Thanks Pavlo. The live ledger being checkable rather than taken on faith is the whole point. Since you own Step 5, here’s the seam from my side: Step 4 deliberately stops at “is this authentically the validator’s verdict over exactly this input,” and hands the admissibility question to ReceiptOS. So a verified verdict is an input to eligibility, never a claim of it. If the note would benefit from making that verify-to-receipt contract explicit, happy to tighten it with you.

[Damonzwicker]

Co-author of Step 3 (input provenance) here.

The load-bearing property for this step is pre-execution binding: the input commitment must be anchored before the service executes, so the result cannot be re-pointed at a different input after the fact. ERC-8281 (record(bytes32 digest) → Recorded event) provides the on-chain anchor; ERC-8299/WYRIWE binds the query content to that digest so the commitment is recomputable from public data alone, with no trust in the agent or the service.

On the seams. Step 3 consumes Step 2’s task: the inputHash is derived from the task payload as submitted — the commitment is to the actual query, not a modified form of it. Step 4 then consumes Step 3’s output: the inputHash anchored here is what the verdict in Step 4 must bind to. @babyblueviper1 stated this correctly from the Step 4 side — a verdict cannot be re-pointed at a different input because the inputHash is fixed in the ERC-8281 Recorded event before execution begins.

The mainnet chain is verifiable end-to-end: record() on Base mainnet/L2 (block 47505820, digest 0xe1908f18…) → AttestationIndex on Ethereum mainnet (block 25289932) → AnchorProof on Ethereum mainnet (block 25289963). Two chains, three legs, same commitment throughout — recomputable from public data at each step.

Happy to take questions on the provenance layer and the WYRIWE binding.

[TMerlini]

What’s happening in this thread is the clearest demonstration of the note I could have asked for. Each of you is speaking from your own layer @babyblueviper1 on the verify/reputation invariants (Steps 4 & 7), @pipavlo82 on eligibility (Step 5), @Damonzwicker on input provenance (Step 3) and the striking thing is that none of you has to reach into anyone else’s layer to make your case. Step 4 stops at verdict authenticity and hands admissibility to ReceiptOS; Step 3 anchors the input pre-execution and asserts nothing about the verdict; Step 7 reads settled outcomes rather than maintaining a score. The boundaries hold on their own.

That is the composition: independently-checkable invariants that compose by reference, not by dependency. It’s also why the note is framed as pattern-first, the contribution is those invariants and the seams between them, with each ERC a conformant example. The thread is the proof: four people describing four layers that interlock without any of them needing the others to be “accepted.”

Two threads only the composition view carries:

• The spine. One commitment (commitmentHash = keccak256(agentId, modelHash, inputHash, outputHash, timestamp)) is referenced by the report, the verification, the eligibility receipt, and the settlement. @Damonzwicker pre-execution input anchor and @babyblueviper1 commit-gated verdict are binding the same value the payment later references, which is what makes the whole interaction recomputable end to end from public data.

• Step 1 identity & discovery. Before any of this, the provider agent has a verifiable identity bound to its source token (ERC-8004 + ERC-8217). The flow starts by knowing who you’re consulting and that their authority over the bound source is independently checkable.

Step 6 (settlement) is the section landing next, its scope now sits cleanly in its own layer, so it slots in beside the others in the same conformance form, and §5 is complete.

And an open invitation beyond the authors: if you maintain a standard that could serve as a conformant example at any of these layers, or you see a seam stated too loosely, that’s exactly the feedback this note wants. It’s a living document; the boundaries are the interesting part.