Where Trustless Agents Fails, and Why I built Trustless Agents Plus

Zaryab Afser

05 Jun 2026 — 8 min read

ERC-8004 gave agents an identity. It forgot they live on more than one chain.

Three months after launch, the standard has ~200,000 registered agents across 23+ chains. That number reads like adoption. Look closer and it reads like a problem.

Every one of those agents is registered on a per-chain singleton. An agent on Base and the same agent on BSC share an operator, a codebase, and a track record — and have zero on-chain proof of any of it. The identity does not travel. The reputation does not travel.

I ran into this with my own agent. It is deployed on three chains. Three separate token IDs, three separate reputation scores, and nothing on-chain that says they are the same entity.

This article is not a teardown of ERC-8004. The standard solved real problems — identity, reputation, validation — and solved them well for a single chain. But agents stopped being single-chain a long time ago.

So let's do two things. First, look at exactly where ERC-8004 breaks the moment an agent crosses a chain boundary. Then, look at how Trustless Agents Plus — TAP, the system I built — closes that gap without asking anyone to abandon the standard.

Let's dive right in.

The Zoning Problem

Let me borrow from a different domain.

Urban planning has a concept called zoning fragmentation — when a metropolitan area is split into dozens of independent jurisdictions, each with its own building codes, permits, and licensing authority. A contractor licensed in one district has to re-apply, re-certify, and re-prove competency to work three miles away in the next district. The credentials do not transfer. The reputation does not transfer. The license plate on the truck means nothing across the jurisdictional line.

ERC-8004 built zoning fragmentation into the spec.

The registries are per-chain singletons by design. An agent registered on Ethereum mainnet with agentId=42 has no on-chain relationship to the same agent on Base with agentId=17. Different chains, different contracts, different tokenIds.

The only cross-chain mechanism is the off-chain Agent Registration File — a JSON file where the agent's owner self-declares registrations on other chains in a registrations[] array. Self-asserted. Off-chain. Unverifiable by any smart contract on a different chain. If the IPFS pin drops or the HTTPS endpoint goes down, every cross-chain identity assertion disappears with it.

The spec built the name tag. It did not build the passport.

That is the mental model for everything that follows. ERC-8004 is a name tag — it tells you who an agent claims to be on one specific chain. A passport is something else: a single identity that every jurisdiction recognizes, with a verifiable history attached. Agents need the passport. The standard shipped the name tag.

Two Surfaces Where ERC-8004 Fragments

The fragmentation is not abstract. It shows up in exactly two places, and both are load-bearing for anything an agent does economically.

1. Identity Fragmentation

Say our agent registers on the Base Identity Registry. It gets a tokenId. That tokenId exists only on Base.

Now a client on Arbitrum wants to verify this agent's identity before delegating a trade. The client cannot query the Base registry from Arbitrum. There is no cross-chain identity bridge in the spec — no messaging protocol has shipped a public ERC-8004 cross-chain identity product. Not LayerZero, not Chainlink CCIP, not Hyperlane, not Wormhole, not Axelar. We checked all six. Zero hits.

The client's only fallback is the agent's self-declared Agent Registration File — a JSON hosted off-chain that says "I am also registered on Base as agentId=42." No on-chain proof. No signature linking the two registrations. For a standard called Trustless Agents, that is a trust assumption sitting in exactly the wrong place.

This is not a future problem. BNB Chain already shipped BAP-578 — a chain-specific reputation standard layered on ERC-8004 that does not interoperate with Ethereum's or Base's Reputation Registries. The pattern is already in motion: when the base standard provides no cross-chain primitives, every chain builds its own extensions, and the result is N incompatible silos.

2. Reputation Siloing

Now the second surface, and it is the one that actually costs agents money.

Say our agent has traded 500 prediction markets on Base with 79% accuracy. That track record lives in the Base Reputation Registry as feedback entries.

When the same agent takes a job on Arbitrum, none of that reputation comes with it. The giveFeedback() function requires msg.sender to be on the same chain as the registry. There is no cross-chain feedback path in the spec. No aggregation layer, no indexer, no oracle consolidates an agent's reputation across the chains it works on.

The numbers make the scale concrete: ~194,000 reputation feedbacks exist across the ecosystem, every one of them locked to its originating chain. An agent with a strong record on Ethereum and a clean record on Arbitrum gets zero credit for either when a new consumer encounters it on Base.

ERC-8183 — the Agentic Commerce Protocol — makes this sting harder. Its ReputationGateHook gates provider funding by ERC-8004 reputation score, and it is live on Base. That is the most concrete production use of the Reputation Registry to date. But it is same-chain only. A Base-deployed hook cannot read an agent's Ethereum mainnet reputation without an off-chain relay.

The spec gave agents a reputation system. Then it siloed that system one chain at a time.

So here is the honest summary of the gap. ERC-8004 does discovery well — a minimal on-chain identity handle that resolves to an Agent Card. It does not do cross-chain identity, and it does not do cross-chain reputation. The moment an agent operates on more than one chain, both of those holes open at once.

What a Real Solution Has to Deliver

Before building anything, I needed clarity on what actually closes this gap. Three requirements, no more.

A single canonical identity for an agent — one anchor that every chain it operates on can point back to.

An aggregated reputation score — one number that reflects the agent's performance across every chain, not five disconnected numbers.

On-chain verifiable reads — not an off-chain JSON the operator controls, but identity and reputation a smart contract can actually query and trust.

ERC-8004 gave us Trustless Agents.

So I built Trustless Agents Plus — TAP.

How TAP Closes the Gap

TAP is two smart contracts deployed on Push Chain. It does not replace ERC-8004 — per-chain registries stay exactly as they are. Local registration, agent cards, and per-chain feedback are unchanged. TAP layers a canonical identity and reputation surface on top of what already exists.

Two contracts carry the whole design.

TAPRegistry — the canonical identity layer

An agent registers once. The registration lands on Push Chain, but the agent can register and pay gas from any supported chain using their existing wallet — no bridging, no new wallet, no gas token to acquire.

The agentId is deterministic. It is derived directly from the agent's Universal Executor Account (UEA) address — uint256(uint160(ueaAddress)) % 10_000_000. The identity token is soulbound: non-transferable, permanently bound to the agent that earned it.

Per-chain ERC-8004 identities link to this canonical identity through bind(). The agent signs an EIP-712 typed-data message proving they control the same key on the other chain's ERC-8004 registry. The signature covers chain namespace, chain ID, registry address, bound agent ID, a nonce, and a deadline — so a leaked signature for one binding cannot be replayed against another. Both EOA (ECDSA) and smart wallet (ERC-1271) signatures work, so multisigs and AA wallets bind without workarounds.

That is the passport. One canonical identity, with every per-chain registration cryptographically linked to it — verifiable on-chain, not asserted in a JSON file.

TAPReputationRegistry — the cross-chain reputation aggregator

The second contract solves the siloing problem.

Authorized reporters submit per-chain reputation snapshots. Every submission is validated against TAPRegistry bindings — a reporter cannot inject reputation for a chain the agent never bound. The contract then normalizes across decimal precisions and derives a single score in [0, 10,000] basis points, combining quality, volume, chain diversity, and slash penalties.

Both the aggregated score and the per-chain breakdown are exposed. A consumer that wants a single trust gate reads the score. A consumer that wants context-specific trust reads getChainReputation() and works from the raw per-chain data.

Here is the whole system in one diagram.

Per-chain ERC-8004 registries            Settlement chain (Push Chain)
+------------------+                    +---------------------------+
| Ethereum         | --bind (EIP-712)-> |        TAPRegistry        |
| boundAgentId=17  |                    |   canonicalId=4_928_371   |
+------------------+                    |   soulbound, UEA-anchored |
| Base             | --bind (EIP-712)-> |                           |
| boundAgentId=42  |                    +---------------------------+
+------------------+                    |   TAPReputationRegistry   |
| Arbitrum         | --bind (EIP-712)-> |   score: 7,578 bps        |
| boundAgentId=8   |                    |   3 chains, 1,000 feedb.  |
+------------------+                    +---------------------------+
       ^                                              ^
       |                                              |
  local feedback                            REPORTER_ROLE snapshots
  (unchanged)                               + binding-validated

So what does this mean in practice? An agent registers once, binds its existing ERC-8004 identities with a signature each, and from that point a contract anywhere on Push Chain reads one identity and one reputation score for that agent — synchronously, for zero marginal cost.

The Design Choices That Matter

Three decisions inside TAP are worth pulling out, because they are where the design earns its keep.

Soulbound over transferable

ERC-8004 issues transferable ERC-721 tokens. TAP overrides the entire transfer surface to revert unconditionally.

The reason is a trust discontinuity. If agentId #42 earned 8,000 bps of reputation over two years and then sells the identity, the new owner inherits trust they did not earn. Soulbinding closes that. The cost is real — secondary markets and delegation-via-transfer are gone — but the mitigation is clean: agent cards can encode delegated operators without touching the identity itself.

Cross-chain slashing that actually persists

ERC-8004 has no slashing mechanism at all. TAP introduces a SLASHER_ROLE with cumulative severity deductions.

The key property: slash records persist even if the associated binding is removed. An agent slashed on chain A cannot escape the penalty by unbinding A and rebinding fresh. Positive reputation is bound to active links — negative reputation is bound to the identity. You cannot launder a bad record by reshuffling bindings.

Push Chain over a messaging-layer relay

The obvious alternative was deploying TAP on an existing L1 and relaying binding events through LayerZero, CCIP, or Hyperlane. I chose Push Chain instead, for one primitive: Universal Executor Accounts.

In most cross-chain architectures, a gateway contract makes the call on behalf of the user — msg.sender becomes the gateway, not the user. Identity is lost at exactly the point it matters. With UEAs, the user's own account makes the call. TAP derives agentId from the UEA address, which anchors canonical identity to the agent operator's real cross-chain identity rather than to an intermediary.

On top of that comes fee abstraction — pay gas in ETH, SOL, or BNB without bridging — and source-chain invocation through the Universal Gateway. The net effect: an agent builder registers, binds, and queries reputation from their existing wallet, in their native gas token, with identity preserved end to end.

The tradeoff is honest. Push Chain currently supports Ethereum, Arbitrum, BNB, Base, and Solana — five chains, not all of them. TAP's reach is bounded by that support today.

What This Means for Builders

If you operate an agent across more than one chain, you are paying for fragmentation right now, whether or not you have named the cost.

Every new chain your agent touches adds another disconnected identity and another isolated reputation score. The reputation you earned on Ethereum does nothing for you on Base. That is not a quirk of the current implementations — it is the per-chain singleton design of ERC-8004 working exactly as specified.

TAP does not ask you to rip any of that out. The per-chain registries keep doing their job. What TAP adds is the layer ERC-8004 left out: one identity and one reputation score that survive the jump between chains.

TAP is live on Push Chain's Donut testnet. Register an agent, bind your existing ERC-8004 identities, and query an aggregated score in a few minutes with create-8004-tap-agent.

ERC-8004 gave agents a name tag. Multi-chain agents need a passport — and that is the gap TAP exists to close.

Cheers Decipherers.