Why and how to use ERC-8128 for AI agent message signing
Contents
A DEV article called “Verifiable AI Agent Communications with ERC-8128 Message Signing” makes the case for verifying AI agent communications using an Ethereum signing standard, on the assumption that agents will increasingly hold and trade crypto autonomously.
The angle is fresh, but it’s written assuming you already know ERC standards, message signing, nonce, and timestamp — so if you’re not deep in Web3, the prerequisites pile up fast.
This piece builds from the basics: what ERC-8128 actually solves, and how it differs from API keys and OAuth.
Background terminology
Before ERC-8128 itself, here’s the Web3-adjacent vocabulary that tends to be used implicitly. These are terms you’ve heard in the news but probably aren’t crisp on.
| Term | What it actually is |
|---|---|
| Blockchain | A tamper-resistant ledger of transactions chained in time order. Nodes (participating computers) worldwide hold the same copy, and rewriting past data requires rewriting all of them — practically impossible |
| Bitcoin | The first widely adopted blockchain. At its core it just records “who sent how much to whom”; it’s specialized for digital currency and can’t run programs |
| Ethereum | The successor to Bitcoin, extended so that “programs” can be loaded and run on the chain. ERC standards are defined here, and NFTs and AI-agent use cases mostly play out here too |
| Smart contract | A self-executing program deployed on Ethereum. When conditions are met, transfers and ledger updates run automatically. Once deployed, it’s basically immutable |
| Token | An identifier-bound value managed by a smart contract. Splits into fungible tokens usable as currency (ERC-20) and non-fungible “one-of-a-kind” tokens (ERC-721 = NFT) |
| Wallet | Software or hardware that holds the private key and signs. MetaMask (browser extension) and Ledger (hardware) are the canonical examples |
| Wallet address | An ID derived from the public key. A 40-char hex string starting with 0x. Public-safe, like a bank account number |
| Gas fee | The cost to execute a smart contract. Heavier execution costs more |
| IPFS | A distributed file-sharing system without central servers. Most NFT images live here |
With this in hand, the rest reads more easily.
A useful mental model: when people say “X is on the blockchain,” what’s actually on-chain is just numbers and identifiers — the images and videos themselves live elsewhere.
What ERC even is
ERC stands for Ethereum Request for Comments.
It’s a numbered proposal system for shared specs on Ethereum, conceptually close to the IETF’s RFCs.
Anyone can submit a draft, and once it goes Final after discussion, it counts as a standard.
A few representative ones make the function clearer.
| Number | What it covers | Familiar example |
|---|---|---|
| ERC-20 | Fungible tokens (interchangeable at equal value) | Stablecoins like USDC |
| ERC-721 | One-of-a-kind tokens (NFT) | “One-of-one” NFT marketplaces |
| ERC-1155 | Multiple token types in one contract | Bulk-issued in-game items |
| ERC-4337 | Account abstraction via smart contracts | Wallets not bound to a single private key |
| ERC-8128 | Message signing for agent communication | Today’s topic |
If you’ve built an NFT marketplace, that “image bound to a token” pattern was ERC-721 — it helps to anchor where ERC-8128 sits relative to that.
ERC-8128 is in the same lineage, added specifically to handle “messages an agent sends to other agents.”
What’s actually inside an NFT
Since ERC-721 came up, here’s a quick look at what’s really happening inside an NFT.
The news framing — “image sold for huge money,” “rights are recorded” — is pretty far from how it feels on the implementation side.
There’s a lot of non-image use too. Some examples:
| Use case | Example |
|---|---|
| Digital art | Image collections like Beeple, CryptoPunks |
| IP-collab game items | Captain Tsubasa: RIVALS, Sorare’s soccer player cards |
| Sports moments | NBA Top Shot highlight clips |
| In-game characters | Battle characters in Axie Infinity |
| Memberships and tickets | Club memberships, limited-event passes |
Image-collection news dominates, so people picture “NFT = art image,” but as a spec it still gets used in IP-collab card games, sports, and in-game assets.
NFT stands for Non-Fungible Token.
Whether something is fungible is easiest to grasp by contrasting bills with stamps.
| Type | Example | Per-unit distinction |
|---|---|---|
| Fungible | A 10,000-yen bill, USDC, Bitcoin | Indistinguishable, interchangeable at the same unit |
| Non-Fungible | Stamp serial numbers, reserved-seat concert tickets, NFTs | Each has a unique ID and can’t be swapped at equal value |
ERC-721 is the spec for managing those “uniquely-IDed tokens” via a smart contract.
Inside the contract, what’s recorded looks roughly like the table below.
| Token ID | Owner address | Metadata URI |
|---|---|---|
| 1 | 0xAlice... | ipfs://.../1.json |
| 2 | 0xBob... | ipfs://.../2.json |
| 3 | 0xAlice... | ipfs://.../3.json |
The common misconception: that the image itself is on the blockchain.
What’s actually on-chain is just token ID, owner, and metadata URI. The image typically lives on IPFS or a regular web server.
That’s why “the image link disappears and the NFT contents are gone” incidents keep happening.
What an NFT marketplace does is call the contract’s transferFrom to rewrite the owner column, plus fetch and render the metadata URI in the UI.
The web side looks flashy, but the contract side is just a fairly mundane ledger update.
How wallets get drained
ERC-8128 is built on the premise that “if signatures get spoofed, assets get drained.” Without a feel for how wallets actually get drained in the first place, it’s hard to see what the spec earns you.
So before signing mechanics, here are the wallet types and the typical theft patterns.
Hot vs cold
Wallets split into two types based on whether the private key is online.
| Type | Substance | Examples | Strengths | Weaknesses |
|---|---|---|---|---|
| Hot wallet | Private key handled in a connected environment | MetaMask browser extension, mobile apps, exchange web wallets | Sign instantly, light UI | Vulnerable to malware and phishing |
| Cold wallet | Private key kept offline | Hardware wallets like Ledger and Trezor, written-down seed phrases (paper wallet) | Resistant to remote attacks | Requires physical-device connection or manual operation each time |
The standard practice is “hot for daily small amounts, cold for long-term large holdings.”
Exchanges run the same split internally — hot for customer withdrawals, the bulk of assets in a separate cold environment.
Common theft patterns
The attacks actually showing up in the wild.
1. Private key extraction
| Vector | Detail |
|---|---|
| Malware infection | Information-stealing malware extracts seed phrases from MetaMask storage files or browser extensions |
| Storing seeds in photos or cloud | Saving them to iCloud Photos or Google Drive — one account compromise drains everything |
| Phishing sites | Fake sites prompt users to enter seed phrases “to recover your wallet” |
The seed phrase (12–24 word recovery key) is effectively the private key — the moment it leaks, the wallet contents are drained.
2. Signature phishing (signing something opaque)
When a wallet asks for a signature, what’s shown is the raw transaction data, often hard for a human to interpret.
Typical pattern:
- A fake NFT site connects, claims “free-mint, no gas required,” and asks for a signature
- The actual content is
setApprovalForAll, i.e. “this contract is allowed to move all your NFTs freely” - Later, the attacker bulk-transfers everything via that contract — gone
Signatures for Permit, approve, and setApprovalForAll are effectively blank-check authorizations, and they’re the dominant attack surface today.
3. Approve abuse
Using DEXes like Uniswap, you’re asked to “approve this token for use.”
If you grant “unlimited” approval to save effort, the moment that contract gets a vulnerability or malicious upgrade, everything you approved is drained at once.
Periodically revoking past approvals via something like revoke.cash is recommended.
4. Address poisoning
A pattern that’s been showing up a lot recently.
- Generate a fake address that mimics just the first 4 and last 4 characters of yours
- Send 0.0001 ETH from that address so it shows up in your history
- Next time you send, you copy from history thinking “I used this one before” and end up sending to the fake
Made possible by wallet UIs abbreviating addresses as 0xAb12...cd34.
5. Clipboard hijacking
Malware on a PC detects copied addresses and replaces them with a different one.
You think you copy-pasted an address, but at paste time it’s the attacker’s.
6. SIM swap
Hijacking your phone number to bypass SMS-based 2FA.
If your exchange account relies only on 2FA, the attacker logs in and moves funds.
This is the single most common path for exchange hot-wallet operation.
7. The exchange itself getting hacked
| Incident | Detail |
|---|---|
| Mt.Gox (2014) | ~850,000 BTC lost |
| Coincheck (2018) | ~58 billion JPY worth of NEM stolen (large hot-wallet holdings) |
| DMM Bitcoin (2024) | ~48.2 billion JPY worth of BTC stolen |
The pattern is exchanges holding too much customer asset in hot-wallet-side systems and getting attacked through internal infrastructure.
What cold wallets still don’t fix
Hardware wallets block “malware extracting the private key,” “clipboard rewriting,” and “phishing for seed-phrase entry.”
But they don’t block signature phishing — you still press the physical button on something you didn’t fully understand.
The baseline literacy of “understanding what you’re actually signing” still has to be there.
How this connects to AI agents
This is where ERC-8128 plugs in directly.
If an AI agent is holding crypto and trading autonomously, it needs to sign frequently — and physical-button-required cold wallets are basically unusable.
That forces hot-wallet operation, and the signing key sits in a leaky environment.
On top of that, agents can’t make a “wait, this signing screen looks weird” judgment the way humans can. So you need a protocol-level guarantee that whatever the agent is being asked to sign actually came from a legitimate agent.
ERC-8128 is one answer to that.
Message signing basics
Before ERC-8128, the basics of what signatures even let you do.
Public-key cryptography uses two keys.
| Key | Role |
|---|---|
| Private key | Held only by you. Used to sign messages |
| Public key | Distributable to anyone. Used to verify signatures |
The flow:
flowchart LR
A[Sender<br/>holds private key] -->|Message + signature| B[Receiver<br/>holds public key]
B --> C{Verify signature}
C -->|OK| D[Confirmed: sender is genuine]
C -->|NG| E[Tampered or impersonated]Passwords and API keys verify “do you know the secret?”
Signatures generate fresh cryptographic data each time that only the private-key holder could produce, and anyone with the public key can verify it.
But naïve signing leaves attacks open.
Two main ones, with their corresponding defense elements:
| Attack | Detail | Mitigation |
|---|---|---|
| Replay attack | Re-send a past valid message to make it execute again | nonce, timestamp |
| Domain confusion | Reuse a test-environment signature in production | domain binding |
The defense side embeds three standard elements into the signed message:
| Element | Role |
|---|---|
| nonce | A single-use disposable number. The receiver remembers consumed ones, blocking replay |
| timestamp | The issuance time, for rejecting signatures that are too old |
| domain binding | Embeds the domain name or contract address into the message, blocking cross-environment reuse |
ERC-8128 codifies these three elements into a type, specifically for agent communication.
What’s in ERC-8128
ERC-8128 defines a type for structuring and signing messages an agent sends.
Ethereum already has EIP-712, a standard for “signing structured data with type information.” ERC-8128 extends that for agent communication.
Main fields in a message:
| Field | Role |
|---|---|
agent_id | Identifier of the sending agent (typically a wallet address) |
domain | The bound domain name or contract |
nonce | Disposable single-use number |
timestamp | Issuance time |
payload | The body the agent wants to send (instructions, data, etc.) |
signature | The result of signing all of the above with the private key |
The verifier checks the signature before touching the payload.
- Whether the signature decodes with
agent_id’s public key - Whether the nonce hasn’t been used before
- Whether the timestamp is within tolerance
- Whether the domain matches the local environment
Only when all four pass does the verifier execute what’s in the payload.
How this differs from API keys and OAuth
API keys and OAuth tokens authenticate based on “do you possess this string?”
If stolen, the thief can do exactly what the legitimate holder could.
With ERC-8128’s signing model, a fresh signature is created with the private key for each message — so “snooping past traffic doesn’t let you issue new instructions.”
A direct comparison:
| Aspect | API key / OAuth | ERC-8128 signature |
|---|---|---|
| Where credentials live | Stored server-side | Private key stays local, never sent to the server |
| Impact when leaked | Full privileges abusable until expiry | A single message leaking doesn’t enable replay |
| Audit trail | Roughly access logs | Each message carries a cryptographically verifiable signature |
| Multi-agent coordination | Shared-secret count grows hard to manage | Each agent holds its own key — no need to centralize |
The last row matters most. As the number of agents grows, the shared-secret model collapses on key distribution and revocation.
Why this matters for AI agent communication
So far it’s been “signing has these advantages in general.” The reason it gets pushed in the AI-agent context is different.
In a world where agents hold crypto and trade autonomously, a single agent can move significant amounts.
When another agent sends instructions like “reduce the position” or “execute this trade,” if you can’t verify the source of that instruction in real time, spoofed instructions drain assets.
The scenario the DEV article uses:
flowchart TD
A[Market monitoring agent] -->|Anomaly detected| B[Generate signed alert]
B -->|ERC-8128 signature + payload| C[Trading agent]
C --> D{Verify signature}
D -->|OK| E[Execute reduce_position_size]
D -->|NG| F[Discard instruction, log]Instructions whose signature doesn’t verify don’t execute, even if they look legitimate.
A design that “checks only the Authorization header with an API key” lets through any attacker who steals that header.
Note that this signature verification doesn’t defend against attacks on the agent’s memory or judgment logic itself, like the kind covered in Proactive AI agent memory injection attacks and EVMbench-driven smart-contract auto-exploitation.
This is purely the layer of “verifying where instructions from other agents originated” — independent of an agent’s internal safety.
Implementation sketch
The SDKs the DEV article points to are TypeScript and Python, and both signing and verification take only a few lines.
Signing roughly looks like:
import { signMessage } from 'erc8128-sdk';
const signed = await signMessage({
agentId: '0xMonitorAgent...',
domain: 'trading.example.com',
nonce: generateNonce(),
timestamp: Date.now(),
payload: { action: 'reduce_position_size', symbol: 'ETH', factor: 0.5 },
}, privateKey);
// signed contains payload + signature
await fetch('https://trading-agent.example.com/instruction', {
method: 'POST',
body: JSON.stringify(signed),
});Verification checks the received structure across signature, nonce, timestamp, and domain in order.
import { verifyMessage } from 'erc8128-sdk';
const result = await verifyMessage(received, {
trustedAgents: ['0xMonitorAgent...'],
domain: 'trading.example.com',
nonceStore, // Persistent record of used nonces
timestampToleranceMs: 30_000,
});
if (!result.valid) {
return reject(result.reason);
}
executeInstruction(received.payload);nonceStore assumes a non-volatile external store like Redis. Skipping this means you can’t actually stop the same signature from being replayed.
Don’t stop at signature verification alone — design nonce management, timestamp tolerance, and the trusted-sender list as a set.
Where to start adopting it
In practical terms, you don’t need to insert ERC-8128 between every agent at once.
Where to apply signature verification first:
- Instruction paths that move crypto or financial data
- Multi-agent setups where multiple autonomous agents run in parallel
- Agents that receive instructions from outside (cross-org integration, behind an API gateway)
Conversely, for self-contained single agents or setups where every instruction comes from a human, API keys + HTTPS are often enough.
Signature verification adds the operational cost of key management and nonce management, so it’s not something to bolt on everywhere.