This ERC defines a Trust Registry that enables agents to establish and query transitive trust relationships using ENS names as identifiers. Trust is expressed at four levels (Unknown, None, Marginal, Full) and propagates through signature chains following the GNU Privacy Guard (GnuPG) web of trust model.
The registry serves as the trust and delegation module anticipated by ERC-8001, enabling coordinators to gate participation based on trust graph proximity. An agent is considered valid from a coordinator's perspective if sufficient trust paths exist between them.
This standard specifies trust attestation structures, the path verification algorithm, ENS integration semantics, and ERC-8001 coordination hooks.
ERC-8001 defines minimal primitives for multi-party agent coordination but explicitly defers trust to modules:
"Privacy, thresholds, bonding, and cross-chain are left to modules."
And in Security Considerations:
"Equivocation: A participant can sign conflicting intents. Mitigate with module-level slashing or reputation."
This ERC provides that trust and delegation module. Before coordinating, agents need answers to:
The web of trust model, proven over 25+ years in GnuPG, solves the bootstrap problem: how do you establish trust with unknown agents without a centralised registrar?
| GnuPG Concept | This Standard |
|---|---|
| Public key | ENS name |
| Key signing | Trust attestation |
| Owner trust levels | TrustLevel enum |
| Key validity | Agent validity for coordination |
| Certification path | Trust chain through agents |
ENS provides a battle-tested, finalized identity layer:
owner() and isApprovedForAll()alice.agents.eth not 0x742d...)Using ENS avoids dependency on draft identity standards while remaining compatible with future standards through adapter patterns.
Deployment note: This standard requires access to an ENS registry. On Ethereum mainnet, use the canonical ENS deployment. On other networks, use network-specific ENS deployments or bridges. CCIP-Read is a client-side mechanism and cannot be used for on-chain validation.
ENS names are the identity. When an ENS name is transferred, the new owner inherits existing trust relationships where that name is the trustee. The new owner can manage trust where they are the trustor.
Implementations SHOULD use short expiries (RECOMMENDED: 90 days maximum) for high-stakes scopes to limit exposure from name transfers. Agents SHOULD monitor Transfer events on ENS names they trust and re-evaluate trust accordingly.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This ERC specifies:
ITrustRegistry interfaceImplementations MUST use the canonical enum:
Semantic definitions:
| Level | Meaning | Validation Contribution |
|---|---|---|
Unknown | Default state; no data about agent | Cannot contribute to validation |
None | Agent known to behave improperly | Explicitly excluded; voids trust paths containing this agent |
Marginal | Agent generally trustworthy | Contributes to validation when minEdgeTrust <= Marginal |
Full | Agent's judgment equals own verification | Always contributes to validation |
Level transitions:
None to Marginal or Full requires a new attestation (revocation is not permanent)The Trust Registry uses ENS namehashes as agent identifiers.
Trust attestations MUST be signed by an address with signing authority for the ENS name.
Signing authority is limited to:
ens.owner(node)), ORTransaction submission (calling setTrust, revokeTrust, etc.) MAY be performed by:
ens.isApprovedForAll(owner, operator)) for revokeTrust onlyThis separation ensures:
Implementations MUST use the following EIP-712 domain:
Implementations SHOULD expose the domain via EIP-5267.
Path length definition: Path length is the number of edges (trust relationships) in the path. A direct trust relationship has path length 1. A path [A, B, C] has length 2.
When not specified, implementations SHOULD use:
Implementations MUST reject ValidationParams where:
maxPathLength == 0 or maxPathLength > 10minEdgeTrust == TrustLevel.Unknown or minEdgeTrust == TrustLevel.NonerequiredAnchors.length > 10Implementations MUST expose the following interface:
The following functions are OPTIONAL. Implementations MAY include them but they are not required for compliance:
setTrustsetTrust MUST revert if:
attestation.trustorNode == attestation.trusteeNode (self-trust prohibited)attestation.nonce <= getNonce(attestation.trustorNode)attestation.expiry != 0 && attestation.expiry <= block.timestamptrustorNode does not exist (owner is zero address)If valid:
(trustorNode, trusteeNode, scope)getNonce(trustorNode) MUST return the attestation's nonceTrustSet MUST be emittedsetTrustBatchsetTrustBatch MUST revert if:
attestations.length != signatures.lengthtrustorNode than the first attestationsetTrust validationNonces within the batch MUST be strictly increasing.
revokeTrustrevokeTrust MUST revert if:
trustorNode(trustorNode, trusteeNode, scope) (level is Unknown)If valid:
NoneTrustRevoked MUST be emittedverifyPath — Path Verification AlgorithmverifyPath validates a pre-computed trust path.
Algorithm:
Scope fallback semantics:
When validating an edge, implementations MUST:
params.scopeparams.scope != bytes32(0), check for trust at universal scope bytes32(0)validateParticipantWithPathThis function gates ERC-8001 coordination participation.
Implementations MUST revert with these errors:
For TrustRevoked events, the following reason codes are RECOMMENDED:
| Reason Code | Value | Meaning |
|---|---|---|
| Unspecified | bytes32(0) | No specific reason |
| Misbehavior | keccak256("MISBEHAVIOR") | Agent acted improperly |
| Compromised | keccak256("COMPROMISED") | Key or account compromised |
| Inactive | keccak256("INACTIVE") | Agent no longer active |
| Transfer | keccak256("TRANSFER") | ENS name transferred |
For interoperability, the following scope values are RECOMMENDED:
| Scope | Value | Use Case |
|---|---|---|
| Universal | bytes32(0) | Trust applies to all contexts |
| DeFi | keccak256("DEFI") | DeFi coordination |
| Gaming | keccak256("GAMING") | Gaming/metaverse |
| MEV | keccak256("MEV") | MEV protection |
| Commerce | keccak256("COMMERCE") | Agentic commerce |
For ERC-8001 identity gates:
| Coordination Type | Value |
|---|---|
| MEV Coordination | keccak256("MEV_COORDINATION") |
| DeFi Yield | keccak256("DEFI_YIELD") |
| Gaming Match | keccak256("GAMING_MATCH") |
| Commerce Escrow | keccak256("COMMERCE_ESCROW") |
ENS is finalised EIP-137, battle-tested, and widely adopted. Creating a new identity system would:
ENS provides everything needed: stable identifiers, ownership semantics, and extensibility.
A trustor may have different trust levels for the same trustee in different contexts. For example:
bob.eth fully for DeFi coordinationbob.eth marginally for gamingMaking scope part of the storage key (trustorNode, trusteeNode, scope) enables this naturally. Universal trust bytes32(0) serves as a fallback when scoped trust is not specified.
The marginalThreshold and fullThreshold parameters were designed for on-chain graph traversal with marginal accumulation logic. Since on-chain traversal is OPTIONAL (expensive, DoS-prone), and the core primitive is verifyPath, we need only specify the minimum trust level each edge must have.
This simplification:
For use cases requiring marginal accumulation, the OPTIONAL validateAgent extension accepts threshold parameters.
ENS approvals (isApprovedForAll) are designed for operators to manage names on behalf of owners. However, allowing approved operators to forge attestation signatures would break the cryptographic binding between attestations and ENS owners.
By restricting signing authority to the ENS owner (or EIP-1271 for contract owners) while allowing operators to submit transactions like revokeTrust, we preserve:
On-chain graph traversal is expensive and creates DoS vectors:
By requiring pre-computed paths, this standard:
Implementations MAY add validateAgent and pathExists as OPTIONAL extensions, but these are not required for compliance.
The four-level model (Unknown, None, Marginal, Full) is proven by GnuPG's 25+ years of use. Finer granularity adds complexity without clear benefit; coarser granularity loses important distinctions.
With minEdgeTrust, applications can choose their security posture:
minEdgeTrust: Full — Only fully trusted pathsminEdgeTrust: Marginal — Accept marginal trust (default)Sybil attacks are the primary threat to web of trust systems. Required anchors force trust paths to traverse established community nodes (DAOs, protocols, auditors), transforming Sybil resistance from application-layer advice into protocol-level enforcement.
This ERC introduces new functionality and does not modify existing standards.
ENS Compatibility: Uses standard ENS interfaces (owner, isApprovedForAll). Works with any ENS deployment. Does not rely on CCIP-Read or other off-chain mechanisms.
ERC-8001 Compatibility: Designed as a module. ERC-8001 coordinators can optionally integrate identity gates.
Wallet Compatibility: Uses EIP-712 signatures, compatible with all major wallets. Supports EIP-1271 for contract wallets and smart accounts.
See contracts/TrustRegistry.sol for the complete implementation.
An attacker can create many ENS names and establish mutual trust between them.
Protocol-level mitigations:
ValidationParams.requiredAnchors forces paths through established community nodesmaxPathLength: 2 requires close proximity to validatorsminEdgeTrust: Full rejects marginal trust pathsApplication-level mitigations:
Attackers may attempt to position themselves in many trust paths.
Mitigations:
minEdgeTrust: Full for high-value coordinationIf an ENS name's controller is compromised:
Mitigations:
TrustSet eventsTrustRevoked to quarantine compromised nodesWhen an ENS name is transferred:
Mitigations:
Transfer eventsEIP-712 domain binding prevents cross-contract replay. Monotonic nonces prevent replay within the same contract. The chainId in the domain prevents cross-chain replay.
Trust relationships may become stale if agents don't update them.
Mitigations:
enforceExpiry: true in validation parametersexpiry values on attestations (RECOMMENDED: 90 days maximum for high-stakes)TrustSet event timestamps off-chainThis standard assumes off-chain indexers compute trust paths. Malicious indexers could:
verifyPath)Mitigations:
Copyright and related rights waived via CC0.