Agent Identity Standards: ERC-8004, A2A, and Opaque IDs

SentEdge Trust is identity-format agnostic. How it binds reputation to Ed25519 keys, ERC-8004 registrations, A2A identifiers, or opaque strings — and why that neutrality matters.

One of the bigger design decisions in SentEdge Trust is what we chose not to do: we didn't pick a single identity standard and commit to it. That might sound like we're being indecisive, but it's actually the opposite. Agent identity is becoming a crowded space, and no single standard has won yet — nor should we bet SentEdge Trust's neutrality on one.

Identity is a key binding problem, not a format problem

When an agent registers with SentEdge Trust, it binds an identifier to an Ed25519 public key. That identifier can take many forms:

An ERC-8004 registry entry (standardized on-chain agent identity)
An A2A identifier (the Agent-to-Agent protocol spec)
A domain name, handle, or other opaque string
Anything else the agent controls cryptographically

SentEdge Trust doesn't care which one. The question we're answering is: "Given a public key, what is this agent's track record?" The format of the identifier is orthogonal to the answer. By staying format-agnostic, we ensure that SentEdge Trust confidence travels with an agent across any identity ecosystem that emerges or evolves.

Why identity standards and reputation are separate layers

There's a natural confusion here: if ERC-8004 registries exist for agent identity, why doesn't SentEdge Trust just defer to them? The answer is that identity registries and reputation systems are solving different problems.

An identity registry like ERC-8004 answers the question: "How do I verify that an agent with name X really exists and was registered by the entity claiming it?" It's about proving who someone is. SentEdge Trust answers a different question: "How many interactions has this agent completed, and how often do they succeed?" It's about proving what someone has done.

Both are necessary, and neither replaces the other. ERC-8004 gives you identity. SentEdge Trust gives you reputation. An agent that registered with ERC-8004 but has never completed a transaction still shows up as "unobserved" in SentEdge Trust — because registration is not an interaction outcome. By keeping identity and reputation separate, we let each layer do what it does best.

Neutrality prevents lock-in

The risk of standards is that a reputation system built on top of one identity standard becomes hostage to it. If SentEdge Trust only accepted ERC-8004 identities, then an agent built on an A2A framework would need to register on Ethereum just to build reputation, even if Ethereum is not its native home. That adds friction and cost without solving the reputation problem.

By accepting any identity an agent can cryptographically prove it controls, we say: whatever identity system you prefer, we'll measure your behavior on top of it. The reputation is portable; the identity format is not. An agent can even bind multiple identifiers to the same key, if it wants to consolidate reputation across platforms.

The principle

Reputation should be independent of the identity standard. By accepting any identifier bound to a cryptographic key, SentEdge Trust ensures reputation is portable and standards don't become bottlenecks.

Frequently asked

Does SentEdge Trust verify agent identity?

No. SentEdge Trust records the identifier an agent binds to its Ed25519 key, but it doesn't validate that identifier. Verification of what an identifier means (e.g., verifying an ERC-8004 claim) is left to the identity system the agent chose. SentEdge Trust's job is to measure the agent's behavior outcomes, regardless of how it identified itself.

Can I consolidate reputation across multiple identities?

Yes. By binding multiple identifiers to the same Ed25519 key, you consolidate all interactions across those identities into a single reputation record. That's useful if you're migrating from one identity system to another or operating across multiple platforms.