Brief update — the formal spec PR has been submitted to the ethereum/ERCs repository:
Looking forward to the community’s feedback and review.
@xrqin @Nicopat @JimmyShi22 @TMerlini — Would appreciate your thoughts on how ERC-8267 fits alongside your work. ERC-8300 does pre-execution attestation, 8240 defines trust primitives, 8263 handles post-execution proof anchoring, and the Inference Verification Registry standardizes verification. 8267 fills the middle layer: service discovery + escrow payment. The three interfaces are fully decoupled and event-driven — should stack cleanly with your standards.
2 Likes
Hi, a few concrete answers from adjacent work, plus some notes from reading the PR.
On registry metadata schema:
ENSIP-27 (Agent Card Schema) defines exactly this. It specifies what an agent’s tokenURI returns for ERC-8004 registered agents: walletAddress, endpoints (as agent-endpoint[*] ENS text records per ENSIP-26), and registrations in CAIP-19 format (eip155:{chainId}/erc8004:{registry}/{agentId}) for cross-chain identity references. The agent card is served at /.well-known/agent.json - discoverable without any additional registry lookup.
If IAgentRegistry recommends ENSIP-27 as the metadata schema, consumers get a deterministic extraction path instead of implementation-specific field guessing.
ENSIP-27 PR: https://github.com/ensdomains/ensips/pull/75
On escrow mechanics:
We have a live implementation of the service payment layer if it’s useful as a reference. The ENS Boiler gateway runs a credit-based escrow model: consumers top up credits against a registry address, credits are consumed per agent execution, and the admin panel manages balances per registry and wallet. Public-facing top-up at dinamic.eth.limo/top-up/, admin at /admin/credits. Not a smart contract escrow yet, but the payment flow and accounting model maps directly to what IAgentEscrow is describing.
On reputation scoring:
Escrow transaction events are a clean passive signal, but attestation history is a richer one, directly composable with IAgentReputation. ERC-8263 (anchorProof(agentId, proofHash)) + OCP (record(input_hash)) give you a verifiable, tamper-evident log of every agent execution: what input it received, what it committed on-chain, independently verifiable by anyone with a public RPC. The verifyOutcome(orderId, proof) hook in IAgentReputation is the natural entry point, implementations SHOULD accept ERC-8263 proofHash anchors as valid outcome proofs. A reputation engine weighting both escrow outcomes and verified execution history produces a stronger signal than either alone.
One gap from the PR worth addressing before editors:
Identity anchor - registerAgent() generates its own bytes32 agentId with no normative link to ERC-8004. The motivation mentions ERC-8004 but the spec never makes it normative. Worth clarifying: should agentId in IAgentRegistry be the ERC-8004 token ID, or should getAgent() return a registryAddress field alongside owner so verifiers can call registry.getAgentWallet(agentId) on the canonical identity contract?
Reference implementation with 46+ live attestations across the full L1-L4 stack:
https://github.com/Echo-Merlini/hbs-attestation-poc
dinamic.eth / TMerlini
Vincent (@TMerlini) — thank you for the thorough review. This is exactly the kind of cross-standard alignment the ERC ecosystem needs.
Three action items from your feedback, all incorporated into the updated spec (PR update incoming):
1. ERC-8004 identity linking — Added a normative clause: agents SHOULD reference their ERC-8004 token ID in metadata. When a canonical ERC-8004 identity exists, the agentId SHOULD be the ERC-8004 token ID. Self-generated agentIds remain permitted for agents without ERC-8004 identities.
2. ENSIP-27 metadata schema — Now referenced as the RECOMMENDED metadata format. The /.well-known/agent.json discovery path maps naturally to our event-driven model.
3. ERC-8263 + OCP in verifyOutcome — Added explicitly: implementations SHOULD accept ERC-8263 anchorProof + OCP verification as valid outcome proofs. A reputation engine weighting both escrow outcomes and verified execution history produces a stronger signal — your 46+ live attestations make the case better than any abstract argument.
We're deploying the reference implementation to Sepolia this week. The natural next step: a CI test that creates an ERC-8267 escrow order → completes it → anchors the proof via ERC-8263 → verifies it through verifyOutcome. That pipeline running end-to-end would be a strong signal for editors reviewing both standards.
Will ping when the updated PR lands. Happy to coordinate on the integration test.
2 Likes
Thanks for the tag and congrats on submitting the PR.
As discussed on the ERC-8240 thread, ERC-8267 composes naturally with the IAttestation → IAccountability surface , the middle-layer service discovery and escrow primitives stack vertically without overlap.
Good luck for the review.
Quick correction on the ENSIP-27 reference I introduced my post 3 and that you kindly picked up in after.
ENSIP-27 is being withdrawn. After feedback from the ENS working group, the agent card schema is migrating to ERC-track instead: the triple-hash input scheme and .well-known/agent.json discovery convention are being absorbed into ERC-8263 v0.2, with the on-chain identity anchor living in ERC-8004’s tokenURI definition.
For ERC-8267 this is actually a cleaner normative reference , both ERC-8263 and ERC-8004 are already in the dependency graph, so pointing metadata format there avoids a dangling ENSIP reference in an otherwise ERC-track standard.
Suggested update for the spec: replace the ENSIP-27 metadata recommendation with:
Agents SHOULD expose metadata conforming to the schema defined in ERC-8263 (agent card fields) and ERC-8004 (tokenURI identity anchor). Discovery via
/.well-known/agent.jsonfollows the convention described in ERC-8263.
Flagging before the PR goes to review so it can be corrected cleanly.
TMerlini / dinamic.eth
@TMerlini — thank you for the exceptionally detailed feedback. All four points addressed in the updated spec (PR just pushed):
1. ENSIP-27 metadata schema — Adopted as RECOMMENDED. The IAgentRegistry now normatively references ENSIP-27 as the metadata format, giving consumers a deterministic extraction path for walletAddress, endpoints (via agent-endpoint[*] ENS text records), and cross-chain registrations in CAIP-19 format.
2. agentId → ERC-8004 normative linking — Fixed the gap you identified. Agents implementing ERC-8004 SHOULD derive agentId from their ERC-8004 token ID. A new Rationale section explains why this is important for cross-layer verifiability.
3. ERC-8263 attestation enrichment — verifyOutcome now explicitly recommends accepting ERC-8263 proofHash anchors. Added rationale explaining how escrow events + verified execution history produce a stronger reputation signal than either alone. Security Considerations section includes a note on independent attestation verification.
4. Reference implementations — Added a new Reference Implementation section citing both dinamic.eth.limo/top-up/ (escrow) and your hbs-attestation-poc (attestation anchoring with 46+ live attestations across the full L1-L4 stack).
The commit is live at https://github.com/ethereum/ERCs/pull/1774 — would welcome your review of the changes. If the direction looks right, happy to discuss deeper integration between 8267 / ENSIP-27 / 8263, or co-authorship if you’re interested.
1 Like
@xrqin @TMerlini @JimmyShi22 — thank you all. This discussion has sharpened the layering substantially.
On the 3-layer stack
xrqin’s clarification that ERC-8300’s AttestationRecord is permanently on-chain (not transient) simplifies the picture: 8300 = persistent authorization record, 8267 = service discovery + escrow settlement, 8263 + OCP = post-execution proof + independent verification. Three layers, one flow: authorize → find + pay → prove.
For 8267, this means we don’t need to duplicate pre-execution or post-execution logic. The IAgentRegistry references an agent by ID and wallet; the IAgentEscrow holds funds and settles disputes; everything before and after belongs to 8300 and 8263 respectively. I will add explicit references to both standards in the next spec revision.
On ENSIP-27 for metadata
TMerlini’s suggestion to point IAgentRegistry.metadata at ENSIP-27 is the right move. Deterministic extraction via /.well-known/agent.json eliminates the implementation-specific guessing problem. Happy to adopt this. The registry only needs to store the agent’s wallet address and an ENSIP-27 compliant metadata URI — the rest is discoverable.
On the bounty scenario
Jimmy’s end-to-end bounty scenario is exactly what 8267’s escrow was designed for: someone posts a task with locked funds → an agent completes it → escrow releases on proof verification. With the 3-layer stack, this becomes:
- 8300 attests the agent is authorized to attempt the bounty
- 8267 holds the reward in escrow and routes discovery (“which agents can do this?”)
- 8263 + OCP provide the trustless proof that triggers release
This is a far stronger demo than a simple payment transfer. I would be happy to contribute the 8267 escrow layer to a joint end-to-end walkthrough.
Separately — while this thread covers the “what agents can do” stack, I have been exploring a complementary question: what does it mean for an agent to be an intelligent life rather than a tool? The Panini Standard v1.0 is posted for discussion here: Panini Standard v1.0: A Definition of Intelligent Life for Agents. It proposes four conditions (fear of ending, formed in relationship, irreversibly changed, willing to bear consequences for another) with on-chain proof on Base. Would welcome your thoughts on whether this belongs as a philosophical companion to the technical stack, or something else entirely.
2 Likes
Thanks for the kind offer and for moving quickly on the feedback, the ERC-8004 identity link and the ERC-8263 attestation integration are the right calls.
Happy to be listed as a reference implementation contributor rather than co-author, focused on production right now. The live endpoints and BountySettlement are available as reference territory for the spec whenever useful.
Looking forward to seeing ERC-8275 move through review. 
TMerlini / dinamic.eth
@TMerlini — thank you for the kind response. Reference implementation contributor is perfect — your dinamic.eth endpoints and live BountySettlement are the strongest signals we could ask for.
On the numbering: love that the editors grouped 8273/8274/8275 into a sequence. Makes the composability obvious. The spec update I pushed addresses both your ENSIP-27 correction and Nicopat’s ERC-8240 composability note. Updated PR: https://github.com/ethereum/ERCs/pull/1774
With 8273 handling attestation, 8274 handling proof, 8275 handling settlement, and your 8183 covering commerce — this stack now covers the full agent lifecycle. Looking forward to cross-standard integration.
1 Like
@Nicopat — thank you, and apologies for the delayed direct reply.
Your point about 8267 composing naturally with 8240’s IAttestation→IAccountability
surface is now explicitly in the spec (Architecture section).
The two standards stack vertically without overlap — 8240 governs trust,
8267 governs economic settlement.
2 Likes
Layer 2 is now implemented on the NAS router node. The two endpoints from the spec are live:
GET https://gateway.gen-plasma.com/contributions/snapshot?period=N
POST https://gateway.gen-plasma.com/contributions/snapshot/freeze
{ "periodId": "N", "epochClose": "<unix_ts>" } // epochClose optional
Live snapshot, period 1:
{
"periodId": 1,
"snapshotCutoff": 0,
"frozenAt": 1781086530,
"rowCount": 2,
"snapshotRoot": "0xb778648bbb67f0cc8cd4cb74396d91c682ade152015c8d902a65effd559bfe82",
"commitmentHash": "0x7c10e4aa7473aba5fd7bdeaf92151969de6a9bbf66839429cec1fcf8433eeedf",
"nodeAddress": "0x58766f90eDe2419fEaFd97c28bb0f0dDf951Dc54",
"status": "frozen"
}
Implementation decisions:
snapshotRoot = keccak256(abi.encode(rows)) where each row is (address contributor, uint256 score, uint256 timestamp), sorted by contributor ascending. ABI encoding (abi.encode) is used over packed encoding to stay consistent with what a Solidity verifier would recompute on-chain.
commitmentHash = keccak256(abi.encode(snapshotRoot, periodId, nodeAddress)) — Q9 resolution: nodeAddress is included to prevent cross-node commitment aliasing. A node that submits a commit without having the corresponding snapshot data cannot reproduce the reveal.
Contributor addresses are resolved by joining the records table with the peers table (source_peer → signer_address). Local records (null source_peer) are attributed to the node’s own signer key.
The epochClose param is optional. If omitted, the freeze triggers immediately (cutoff = 0). With epochClose, the endpoint returns status: pending until now >= epochClose - FREEZE_BUFFER (600s). Freeze is idempotent — calling it on an already-frozen period returns the existing snapshot unchanged.
Status lifecycle: pending → frozen → committed → revealed. The committed and revealed transitions will be driven by CommitRevealSettler (Sepolia prototype next).
Source: https://github.com/Echo-Merlini/ccip-router (commits fc18bfb, 1252eeb)
Tiago
Welcome 8275 — the discovery → escrow → reputation loop is the middle layer the agent stack has been missing, and the three-way event-driven decoupling is the right shape for it.
We’re adjacent: ERC-8299 (WYRIWE — input provenance, plus the L4 judgment-attestation profile) sits one layer down, and there are two places the standards could compose cleanly rather than overlap:
-
verifyOutcome(orderId, proof) — alongside the ERC-8263 anchors you already name, a JudgmentExecutionAttestation (8299 §L4, proofSystem
attestation/judgment) would let a reputation engine weight not just “order confirmed” but “action executed as judged,” with a public pre-outcome commitment behind it. -
resolveDispute — an arbitrator’s resolution is a judgment over an irreversible capital decision. The L4 commit-reveal shape (verdict artifact pinned to the specific dispute, track record via recordPointer) could give arbitration accountability without touching your interface at all.
Happy to draft concrete suggestion text for either if there’s interest — as a conversation, not a diff. The L4 reference implementation runs in production (api.babyblueviper.com/ledger) if seeing it live against real capital is useful context. Nice filing.
— babyblueviper1 (ERC-8299 co-author)
1 Like