ERC-8004: Trustless Agents

@TMerlini I think you’re right that the scoping question is the important one, and I should compress my point further (they hate me on irc and I don’t fw threads on slack types)

=> I’m not proposing a seventh normative layer, a new registry, or a separate runtime-verification ERC. I’m trying to name the claim shape so the existing pieces compose cleanly.

As I see the boundaries:

Input provenance, whether WYRIWE or another profile, answers: what entered the reasoning boundary?

getAgentWallet() answers: what wallet is associated with this agent identity?

Mandates / authorization answer: who allowed what, under what scope?

ERC-8274 / IProofVerifier answers: does this proof object verify?

ERC-8004: Validation Registry answers: what validation was requested or performed for an agent/action, by whom, under what tag/profile, and where is the result/evidence?

The open question is not “do we add another layer?”

It is:

what exactly is the proof or validation result claiming?

For runtime-sensitive actions, I think the validation subject should bind the authority, the agent handle, the input/output, and the runtime/code measurement:

H(principal, agentId, delegationRef, codeMeasurement, policyHash, inputHash, outputHash, chainId, nonce)

Then the pieces stay small:

Input provenance contributes what entered the reasoning boundary.

Mandates / ERC-8118 authorization contribute authority and scope.

ERC-8274 verifies the proof/evidence family.

ERC-8004 records the validation event/result.

Reputation can interpret the history later.

The reason I keep pushing on code/runtime measurement is because otherwise several valid but different claims can look similar at the registry level:

:brown_circle: agent identity was resolved

:purple_circle: input provenance was checked

:blue_circle: authorization was scoped

:green_circle: proof bytes verified

:yellow_circle: measured runtime exercised the authority

Those are related, but they are not the same claim.

So yes, I think IProofVerifier is the direct overlap worth scoping, but only for proof checking. I would not have the Validation Registry replace it. The split I’d suggest is:

ERC-8274 verifies proof bytes.

ERC-8004 records validation events/results for agent actions.

The subject hash defines what claim was validated.

That keeps the stack smaller, not larger.

No seventh layer. No new authority model. Just an explicit validation subject so implementers can tell which claim a given proof or registry entry is actually making.

1 Like