[Draft ERC] Know-Your-Agent (KYA) Framework — trust assertions for agents, ZK-KYA profile, ERC-8004 binding

ERCs
, , , ,
1

PR: ethereum/ERCs#2012 · Repo / reference implementation: garyyang-finchip/kya-standard · Status: Draft, number not yet assigned

What this proposes

ERC-8004 gives agents portable identity and a place to accumulate raw trust signals (Reputation, Validation). It deliberately stops short of trust conclusions — a shared way to say “this agent was checked under principle X, by issuer Y, reached level L, valid until T, not revoked.”

This ERC standardises the container for such conclusions, not the conclusions themselves:

  • Scheme Registry — registers a KYA Scheme: an addressable, versioned, freezable pointer to a descriptor that says what is checked, how the result is expressed as a uint8 level, which evidence kinds are admissible, and how assertions are admitted (ATTESTED by an issuer, or PROVED by a verifier contract).
  • KYA Registry — records Assertions (subjectKey, schemeId, issuer, level, claimDigest, issuedAt, expiresAt, evidenceHash, status) with per-issuer supersession and revocation, and resolves them: resolve(subject, schemeId, issuers[]) / check(subject, schemeId, minLevel, issuers[]). issuers must be non-empty — same Sybil rationale as 8004’s getSummary requiring clientAddresses.
  • ZK-KYA profile — not a second registry. attestWithProof(subject, schemeId, publicInputs, proof) calls the scheme’s IKYAVerifier, which returns (ok, subjectKey, nullifier, level, claimDigest, expiresAt). The registry enforces subject binding and nullifier consumption and records the assertion with issuer = verifier. Any proving system enters via an adapter; the spec fixes only the public-input layout (kya-public-v1). Proofs can also be presented ephemerally in the handshake without ever touching the chain.
  • Handshake — EIP-712 KYAChallenge / KYAPresentation, /.well-known/kya.json discovery; mutual KYA is two exchanges.
  • Policy (minimal) — registerPolicy(uri, hash) gives relying-party requirements an id that can be named in a challenge; on-chain evaluation is optional.
  • ERC-8004 binding — erc8004 is the MUST-support subject type (chainId, identityRegistry, agentId). Optional supportedTrust: ["kya","zk-kya"], a KYA services entry, a "kya" metadata key, and a KYA Bridge that acts as an 8004 validator and mirrors levels to 0–100 under tag = "kya:<8 hex of schemeId>", so 8004-only clients see KYA outcomes with zero changes to 8004.

The framework never defines a KYA algorithm or a credit rule. That is the point: like 8004 with reputation math, fixing rules on-chain would be obsolete before Final; a container for rules is not.

What is in the repo

Full ERC text; reference contracts (KYASchemeRegistry, KYARegistry, KYAPolicyRegistry, KYABridge8004, a Groth16→IKYAVerifier adapter); JSON Schemas for scheme / policy / discovery documents; deterministic vectors (ids, EIP-712 digests, ERC-165 ids); a 17-case end-to-end suite on an in-process EVM covering attested and proved flows, revocation/expiry, policy evaluation and the full 8004 bridge round-trip.

Where I would most like feedback

  1. Subject abstraction — is (subjectType, subjectData) with erc8004 as MUST and account / erc721 / did as optional the right cut, or should v1 be 8004-only?
  2. Verifier-as-issuer in proved mode — relying parties trust a verifier address the same way they trust an attester. Is that vocabulary acceptable, or should proved assertions carry a separate verifier field?
  3. Bridge design — a curated validator with operator-configured issuers and level→0–100 map, deterministic requestHash bound to (agentId, schemeId). Is mirroring into Validation (not Reputation) the right choice?
  4. Nullifier scoping — scheme vs scheme-epoch; should domain separation (chainId + registry) be MUST rather than SHOULD?
  5. Relationship to ERC-8143 and to generic attestation services — this draft positions itself as the agent-KYA semantic layer that can sit on top of either. Push back welcome.

Prior work from the same author: ERC-8338 (Token-Bound Executable Skills), ERC-8414 (Token-Bound Task Tenders). Those appear here only as informative use cases; nothing in this ERC depends on them.