Introducing Trustless Agents Plus (TAP) : Home for fragmented on-chain AI agents

ERC-8004 agents are fragmented.

Not in theory. In production.

There are ~200K agents registered across 23+ chains right now. Each one has an identity token, a reputation score, and a validation surface — all locked to a single chain's registry.

An agent on Base has no on-chain relationship with the same agent on BSC.

I have my own on-chain agent deployed on three different chains. Three separate token IDs, reputation scores and zero on-chain proof they belong to the same entity.

Think of it like credit history.

You spend years building a perfect credit score in one country — every payment on time, every obligation met. Then you move to another country and start from zero. The work you did doesn't travel with you. That's exactly what happens to an agent's reputation when it crosses chains.

I call this the Identity Tax — the cost every multi-chain agent pays simply for existing on more than one network.

And right now, there's no way to stop paying it.

Where ERC-8004 stops

ERC-8004 solved three imperatives for on-chain agents:

• a reliable way to prove identity,
• a system to accumulate reputation from feedback,
• and a standard for cryptographic validation of on-chain work.

For agents on a single chain, this works.

But agents don't operate on a single chain anymore.

The only cross-chain hook in the spec is the off-chain registrations[] array in the Agent Registration File — self-asserted by the operator, not verifiable on-chain by any contract.

"But can't the off-chain registrations array handle cross-chain identity?"

It can't.

Self-assertion is not verification.

A contract on Base can't read that array, and even if it could, the data is operator-controlled — no signature, no binding, no proof of key ownership. For a standard called "Trustless Agents," that's a trust assumption that shouldn't be there.

The gap has two sides.

1. Identity fragmentation. An agent on five chains holds five unrelated token IDs. No canonical anchor. No on-chain way for a consumer to verify that the agent in front of them is the same entity operating on four other chains.
2. Reputation siloing. ~194K reputation feedbacks exist across the ecosystem — all locked to their originating chain. An agent with strong reputation on Ethereum gets zero credit for it when a consumer encounters it on Base. Each chain's ReputationRegistry is a closed loop with no aggregation surface.

The Identity Tax compounds. Every new chain adds another disconnected identity and another isolated reputation score.

What "solved" looks like

Before building anything, I needed clarity on what a real solution delivers:

1. A single canonical identity for an agent — across every chain it operates on.
2. An aggregated reputation score reflecting performance across all chains.
3. On-chain verifiable reads — not off-chain assertions — for unified identity and reputation.

ERC-8004 gave us Trustless Agents.

I built Trustless Agents Plus (TAP).

How TAP works

TAP is two smart contracts on Push Chain.

TAPRegistry is the canonical identity layer. An agent registers once from any chain using their existing wallet. The registration lands on Push Chain, but the agent pays gas in their native token — ETH, SOL, BNB — from their source chain. No bridging. No new wallets.

The agentId is deterministic, derived directly from the agent's Universal Executor Account (UEA) address. The token is soulbound. Non-transferable. The identity that earned reputation cannot be sold to someone who didn't earn it.

Per-chain ERC-8004 identities link to this canonical identity via bind(). The binding uses an EIP-712 typed-data signature — the agent proves they control the same key on the other chain's registry. Both EOA and smart wallet (ERC-1271) signatures work. Multisigs and AA wallets bind without workarounds.

TAPReputationRegistry is the cross-chain reputation aggregator. Authorized reporters submit per-chain reputation snapshots. Every submission is validated against TAPRegistry bindings — you can't inject reputation for chains the agent never bound to. The contract computes a single score in [0, 10,000] basis points combining quality, volume, chain diversity, and slash penalties.

Both the aggregated score and per-chain breakdowns are exposed. Consumers choose their granularity.

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.  |
+------------------+                    +---------------------------+

Per-chain registries stay exactly as they are. Local registration, agent cards, and per-chain feedback — unchanged. TAP layers on top. It doesn't replace what works.

What makes TAP different

Four features worth calling out.

1. Soulbound identity. ERC-8004 issues transferable ERC-721 tokens. TAP overrides the entire transfer surface to revert unconditionally. If agent #42 earned 8,000 bps of reputation over two years, that trust is non-transferable. The cost — secondary markets and delegation via transfer are gone. The gain — reputation means something because it can't be bought.
2. Diversity bonus. Agents operating across multiple chains earn a bonus — 500 bps per chain with reputation data, capped at 2,000 bps for 4+ chains. This incentivizes genuine multi-chain participation. An agent can't farm a high score on a single low-activity chain and claim cross-chain credibility.
3. Persistent slashing. TAP introduces a SLASHER_ROLE with cumulative severity deductions. Slash records persist even if the binding is removed. An agent slashed on chain A cannot escape by unbinding and rebinding fresh. Negative reputation is bound to the identity, not to any individual chain link.
4. Global binding deduplication. A bound identity tuple — chain, registry, agent ID — can only link to one canonical identity at a time. If agent A binds to ID 42 on Ethereum's registry, agent B cannot claim the same binding. The transaction reverts with BindingAlreadyClaimed. No impersonation.

ERC8004 Agents vs Tap Agents

Here is a visual representation of differences between TAP Agents and a vanilla ERC8004 agent.

Why Push Chain

The alternative was deploying on an existing L1 and relaying binding events via LayerZero, CCIP, or Hyperlane.

I chose Push Chain for one primitive: Universal Executor Accounts (UEAs).

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 the point it matters most. With UEAs, the user's own account makes the call. TAP derives agentId from the UEA address, anchoring canonical identity to the agent operator's real cross-chain identity — not an intermediary.

On top of that — fee abstraction (pay gas in ETH, SOL, BNB without bridging), wallet abstraction (use MetaMask, Phantom, whatever you already have), and source-chain invocation via the Universal Gateway.

The net effect: register, bind, and query reputation using your existing wallet, paying gas in your native token, with identity preserved end-to-end.

Tradeoff: Push Chain currently supports Ethereum, Arbitrum, BNB, Base, and Solana.

Try it

TAP is live on Push Chain's Donut testnet.

• Quick start with create-8004-tap-agent — register, bind, and query in minutes
• Main repo: trustless-agents-plus
• Get the detailed overview in the ETH Research forum post.

Every agent operating across chains today is paying an Identity Tax it doesn't have to.

Your multi-chain agents should have a canonical identity, reliable on-chain discoverability, and reputation scores of all chains.

TAP solves this.

More updates to follow.

Cheers Decipherers.

Got questions?

Join the community 👉 Decipher Club Telegram