ERC-8213 Proposes Standard for Wallet Signature and Calldata Digest Display on Ethereum: When Your Wallet Finally Tells You What You're Actually Signing

The proposal appeared on the Ethereum Magicians forum in September 2026 with the quiet frustration of developers who had watched users blindly sign transactions for years and decided that the problem was not user education—it was wallet design. ERC-8213 introduces a standardized format for displaying wallet signatures and calldata digests in human-readable form, requiring wallets to show users what they are signing before they sign it. The pitch was protective: every wallet approval should be an informed decision, not a reflexive click. The standard mandates structured parsing of EIP-712 typed data, contract function selectors, and parameter decoding so that a user signing a token approval sees "Allow Uniswap V3 Router to spend up to 1,000 USDC" instead of a hex string. The fine print raised a question about whether wallets that make money from transaction volume have any incentive to slow users down with better information.

That was the standard. Then came the question of whether requiring wallets to display decoded signatures is a user protection breakthrough or just another specification that wallets will ignore until a regulator forces them to comply.

What ERC-8213 Actually Proposes

The proposal describes a display standard that fundamentally changes the wallet signing experience:

The Signature Display Requirements:

- Wallets must decode EIP-712 typed data into human-readable structured messages

- Contract function calls must display the function name, parameters, and estimated value impact

- Token approvals must show spender address, token amount, and whether the approval is unlimited

- Multi-call transactions must enumerate each sub-transaction with individual risk assessment

- Delegation signatures (ERC-7710, ERC-7715) must display delegated permissions and duration

The Calldata Digest Standard:

- A JSON schema that maps common contract functions to human-readable templates

- Community-maintained registry of verified contract metadata (function signatures, parameter names)

- Fallback heuristics for unverified contracts showing raw selector and decoded parameters

- Risk scoring overlay that flags high-risk operations (unlimited approvals, ownership transfers, proxy upgrades)

- Localization support for 20+ languages

Implementation Levels:

- Level 1 (Minimum): Display function selector and raw parameter values

- Level 2 (Standard): Decode function name and parameter names from verified registry

- Level 3 (Enhanced): Add risk scoring, value estimation, and spender reputation data

- Level 4 (Optimal): Simulate transaction outcome and display state changes in natural language

The proposal frames these as user protection. They are also a threat to wallets whose business models depend on transaction speed over transaction understanding.

Key Metrics at a Glance

The Proprietary Signature Transparency Score (STS)

I've developed a framework to evaluate whether ERC-8213 will actually improve user safety or merely create compliance overhead:

Formula: STS = (Display Clarity × 0.3) + (Wallet Adoption Incentive × 0.25) + (Phishing Resistance × 0.25) + (Implementation Cost-Benefit × 0.2)

ERC-8213 Assessment:

A score of 5.05 indicates that ERC-8213 is a valuable standard with a significant adoption gap. The technical approach is sound. The economic incentives are misaligned.

The Three Transparency Traps

Trap 1: The Compliance Theater

The standard requires wallets to display decoded information. It does not require users to read it. The wallet that shows "Allow Uniswap V3 Router to spend unlimited USDC" and still lets the user sign with a single click has complied with the standard without changing behavior. The phishing victim who was trained to click through warnings will click through decoded messages too. The standard assumes that information changes decisions. Sometimes it does. Often it does not. The wallet that implements ERC-8213 Level 1—displaying raw parameters with function names—has technically complied but practically achieved nothing. The gap between specification and effective protection is where most security standards fail.

Trap 2: The Registry Centralization

The contract metadata registry sounds like a community resource. It is a critical infrastructure point. Whoever maintains the registry controls what names are displayed for function selectors. A malicious registry entry could label a draining function as "Claim Rewards." An outdated registry could miss new attack patterns. The standard proposes decentralized governance for the registry, but governance in practice means whoever controls the governance token controls the display names. The user who trusts the wallet's display is implicitly trusting the registry's integrity. The standard does not solve the trust problem. It moves it from the wallet to the registry.

Trap 3: The Revenue Conflict

Wallet providers make money from transaction volume. Some take a cut of swaps. Some sell user data. Some monetize through token integrations. Every transaction that is slowed down by a mandatory reading step is a transaction that might be abandoned. The wallet that implements ERC-8213 Level 3 or 4—full risk scoring and simulation—creates friction that reduces conversion rates. The wallet that ignores the standard remains faster and retains more users. The standard is designed to protect users from wallets that prioritize speed over safety. But those wallets are the ones that must implement it. The conflict is structural: the standard asks the fox to install better locks on the henhouse.

Competitive Landscape: Wallet Security Standards

The landscape shows that advanced signature display exists but is fragmented across specific wallets and tools. No universal standard has achieved widespread adoption.

Scenario Analysis: Three Futures for Signature Transparency

Scenario A: Regulatory Catalyst (30% probability)

• Regulatory action (SEC, EU MiCA) mandates signature display standards
• Major wallets (MetaMask, Rainbow, Phantom) implement ERC-8213 to comply
• Smaller wallets follow to remain competitive
• User phishing losses drop significantly
• The standard becomes as universal as HTTPS

Scenario B: Niche Excellence (45% probability)

• Security-focused wallets (Rabby, Frame) implement advanced display
• Mainstream wallets add minimal compliance (Level 1 or 2)
• Users who want safety switch to security-focused wallets
• The market fragments into "fast" and "safe" wallet categories
• ERC-8213 exists but does not transform the ecosystem

Scenario C: Regulatory Capture (25% probability)

• Regulations mandate display standards but do not enforce them
• Wallets implement checkbox compliance with minimal decoding
• Users continue clicking through decoded displays without reading
• Sophisticated phishing adapts to exploit the new displays
• The standard creates a false sense of security without changing behavior

The Bottom Line

ERC-8213 addresses the single most important user experience failure in Ethereum: the fact that most users sign transactions they do not understand. The structured display, risk scoring, and contract metadata registry are all improvements that would save users money and reduce phishing losses.

But the three traps—compliance theater, registry centralization, and revenue conflict—are structural, not technical. The Signature Transparency Score is 5.05/10. Display clarity is excellent. Wallet adoption incentives are weak. Phishing resistance is partial. Implementation cost-benefit is unfavorable.

The question is not whether users deserve better signature displays. They do. The question is whether wallets will voluntarily implement a standard that slows transactions and reduces conversion rates. History suggests they will not. MetaMask has had the technical capability to display decoded transactions for years. It does not do so by default because the default experience is designed for speed, not understanding.

ERC-8213 may find its path through regulation. The EU's MiCA framework and potential SEC action on wallet disclosures could create mandatory adoption. But a standard that succeeds because of regulation rather than market demand is a standard that the ecosystem resisted. That resistance matters. It means the standard was not valued until it was forced.

The developers proposing ERC-8213 are not naive. They understand the incentive problem. They have designed a standard that is technically sound and user-centered. But the wallet ecosystem is not user-centered. It is volume-centered. And volume-centered ecosystems do not voluntarily add friction.

The user who signs an unlimited token approval today does so because the wallet made it easy. ERC-8213 would make it harder. That is the point. But making something harder in a competitive market requires either user demand or regulatory force. As of September 2026, neither is sufficient.

TL;DR

• What: ERC-8213 proposes standardized human-readable display of wallet signatures and calldata, requiring wallets to decode EIP-712 data and show risk scores before signing
• The Score: Signature Transparency Score of 5.05/10—display clarity (8/10) is excellent but wallet adoption incentives (3/10) are weak, phishing resistance (5/10) is partial, and implementation cost-benefit (4/10) is unfavorable for wallet providers
• The Reality: Four implementation levels from basic function decoding to full transaction simulation; contract metadata registry required; but wallets profit from transaction volume and have economic incentive against adding friction
• Three Traps: Compliance theater (decoded displays that users still click through); registry centralization (whoever controls function name registry controls what users see); revenue conflict (wallets make money from speed, standard requires slowness)
• Outlook: Regulatory catalyst (30%) with mandatory adoption; niche excellence (45%) where security-focused wallets lead; regulatory capture (25%) with checkbox compliance and unchanged user behavior

Sources

• Ethereum Magicians Forum - ERC-8213 Discussion - September 2026 proposal for wallet signature display standard
• EIP-712 Specification - Typed Data Signing - Current standard for structured data signing that ERC-8213 extends
• MetaMask Documentation - Transaction Signing - Current wallet signing UX and display limitations
• Rabby Wallet - Security Features - Existing wallet with advanced risk scoring and transaction simulation
• Safe Transaction Service Documentation - Institutional multisig with full transaction decoding and simulation
• Revoke.cash - Approval Monitoring - Post-hoc approval review tool for comparison
• Blockaid - Wallet Security API - External transaction risk assessment service
• EU MiCA Regulation - Wallet Provider Requirements - Regulatory framework affecting wallet disclosure obligations

Zain Tran is TotesTek's Ethereum Ecosystem Columnist & Accountability Reporter. He writes about Ethereum, ETH, smart contracts, DeFi, Layer 2 networks, staking, validators, and the real-world consequences of technical and financial failure.