Forem: Aniket Misra

Architecting Account Abstraction: EOA vs. ERC-4337 vs. zkSync Native AA

Aniket Misra — Sun, 24 May 2026 18:27:11 +0000

The default Ethereum account model is fundamentally flawed for mass adoption. If you want to interact with a decentralized system, you are forced into a rigid cryptographic box: the Externally Owned Account (EOA).

As we move toward protocol-level scaling, Account Abstraction (AA) has become the standard solution. But "Account Abstraction" is an umbrella term. The way it is architected on a standard EVM rollup like Arbitrum (via ERC-4337) is drastically different from how it is implemented on a ZK-rollup like zkSync Era (Native AA).

Here is a technical breakdown of the architectural leap from EOAs to Smart Accounts, and why protocol-level enshrinement matters.

1. The Legacy Architecture: EOAs

An Externally Owned Account (EOA) is simple, but structurally limited.

The Key is the Account: An EOA is strictly bound to a single ECDSA secp256k1 public-private key pair.
Execution: EOAs cannot contain code. They are passive entities that can only initiate transactions.
Gas: EOAs must hold the native network token (e.g., ETH) to pay for gas.

The Flow:
When an EOA sends a transaction, the protocol natively checks the ECDSA signature, verifies the nonce, deducts the gas fee from the balance, and executes the call. The logic is hardcoded into the EVM consensus layer. If you lose your private key, you lose the account. There is no programmability.

2. The Application-Layer Hack: ERC-4337 (EVM / Arbitrum)

Because changing the Ethereum base layer is notoriously difficult, the community rallied behind ERC-4337. This standard brings Account Abstraction to EVM-compatible chains (like Mainnet, Arbitrum, or Optimism) without altering the consensus protocol.

Instead of changing the EVM, ERC-4337 shifts the abstraction to a higher-level smart contract infrastructure.

The ERC-4337 Architecture

In this model, your account is a Smart Contract, not an EOA. But since smart contracts cannot initiate their own transactions, the architecture introduces several new off-chain and on-chain actors:

UserOperations (UserOps): Instead of standard transactions, users sign UserOperations—structs containing the execution instructions, signatures, and custom logic.
Alternative Mempool: UserOps do not go into the standard Ethereum mempool. They sit in a separate, specialized UserOp mempool.
Bundlers: Specialized nodes (Bundlers) listen to this mempool, pack multiple UserOps into a single standard Ethereum transaction, and submit them on-chain. The Bundler pays the ETH gas fee upfront.
The EntryPoint Contract: The Bundler sends the batch to a singleton EntryPoint smart contract. The EntryPoint is the global orchestrator; it verifies signatures, charges the Smart Accounts for the gas (refunding the Bundler), and routes the execution calls to the respective Smart Account contracts.
Paymasters (Optional): Third-party contracts that can sponsor gas fees for users or allow users to pay in ERC-20 tokens.

The Trade-off: ERC-4337 is highly flexible, but because it is an application-layer standard, it relies on a parallel mempool and introduces significant gas overhead due to the massive EntryPoint contract routing.

3. Protocol-Level Enshrinement: zkSync Native AA

Unlike Arbitrum or Ethereum Mainnet, zkSync Era was built with Native Account Abstraction enshrined directly into the protocol layer.

In zkSync, there is no distinction between an EOA and a Smart Contract at the architectural level. All accounts are treated as smart contracts.

The zkSync Architecture

Because AA is natively supported, zkSync eliminates the need for the clunky off-chain infrastructure required by ERC-4337.

Unified Mempool: There is no separate UserOp mempool. Smart contract transactions and traditional EOA transactions live in the exact same mempool.
No Bundlers: Because the protocol natively understands smart contract initiated transactions, there is no need for third-party Bundlers to wrap and submit them.
The Bootloader (The System EntryPoint): Instead of an application-layer EntryPoint contract, zkSync uses the Bootloader. The Bootloader is a system-level smart contract that handles block construction, transaction validation, and fee processing natively.
Enshrined Paymasters: Paymaster logic is built directly into the transaction processing flow, making gas sponsorship native and highly efficient.

When an EOA is used on zkSync, the protocol under the hood maps it to a default smart contract implementation that validates ECDSA signatures. If you upgrade to a custom Smart Account, the protocol simply points to your custom validation logic.

Architectural Comparison: ERC-4337 vs. zkSync Native AA

Feature	EVM / Arbitrum (ERC-4337)	zkSync Era (Native AA)
Protocol Integration	Application layer (Smart Contracts)	Enshrined at the Protocol level
Mempool	Requires an alternative UserOp mempool	Single, unified mempool
Transaction Initiation	Requires third-party Bundlers	Handled natively by the protocol
Gas Overhead	High (Routing via `EntryPoint`)	Low (Handled by the system `Bootloader`)
EOA Treatment	EOAs and Smart Accounts are entirely separate	EOAs are just default Smart Accounts

Building at the Protocol Level

Understanding the difference between application-layer workarounds (ERC-4337) and protocol-layer enshrinement (zkSync) is critical when designing low-level blockchain infrastructure. Native AA offers a glimpse into what the future of Ethereum must look like to achieve true mainstream viability without sacrificing decentralization or UX.

As I continue to dive deeper into protocol engineering and ZKP implementations, analyzing these architectural trade-offs is step one. I’ll be sharing more code-level deep dives into building custom validators and Paymasters soon.

The End of Blind Signing: Deep Diving into ERC-7730, ERC-8213, and Clear Signing

Aniket Misra — Tue, 19 May 2026 18:16:51 +0000

For years, the status quo of interacting with Ethereum protocols has been a security nightmare masquerading as a routine task. You open a frontend, click "Swap" or "Stake," and your hardware wallet prompts you to sign a blob of unreadable hexadecimal data.

You are blind signing. You are trusting that the frontend hasn't been compromised, that the RPC URL hasn't been poisoned, and that a malicious actor hasn't swapped out the destination address or function arguments. When the Lazarus Group drained $1.4 billion from Bybit, they didn't break cryptography; they exploited this exact UI gap. They tricked users into blind signing data that did something entirely different from what was shown on the screen.

The Ethereum Foundation, alongside an industry working group (including Ledger, Cyfrin, MetaMask, and Trezor), launched Clear Signing—a unified security standard designed to enforce the principle of "What You See Is What You Sign" (WYSIWYS).

This deep dive breaks down the technical layer of this release: ERC-7730, ERC-8213, and how they work together to eliminate blind signing without forcing on-chain breaking changes.

1. ERC-7730: The Clear Signing Metadata Standard

Originally proposed by Ledger and now under the stewardship of the Ethereum Foundation’s Trillion Dollar Security Initiative, ERC-7730 establishes a standardized, machine-readable JSON format that describes exactly what a smart contract’s function calls and EIP-712 typed messages mean in plain text.

Because this metadata lives entirely off-chain, it requires zero changes to existing smart contracts.

How It Works Under the Hood

Wallets and hardware devices cannot natively store the ABIs and translation logic for millions of deployed contracts. ERC-7730 solves this by creating a highly structured schema that maps raw calldata bytes to human-readable display formats.

An ERC-7730 file is broken down into three core blocks:

Context: Binds the descriptor to specific contract deployments across multiple EVM chain IDs.
Metadata: Contains high-level project data (e.g., protocol name, official legal entity, canonical URLs).
Display: The execution mapping logic. It dictates how function selectors and specific parameters are parsed and rendered on a wallet UI.

Here is a simplified architectural look at how a descriptor file (calldata-SwapRouter.json) maps execution data:

{
  "$schema": "[https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json](https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json)",
  "context": {
    "$id": "uniswap-v3-router",
    "contract": {
      "deployments": [
        { "chainId": 1, "address": "0xE592427A0AEce92De3Edee1F18E0157C05861564" }
      ]
    }
  },
  "metadata": {
    "owner": "Uniswap Labs",
    "info": { "url": "[https://uniswap.org](https://uniswap.org)" },
    "contractName": "SwapRouter"
  },
  "display": {
    "formats": {
      "0x415565b0": {
        "title": "Swap Exact Tokens for Tokens",
        "description": "Swaps {amountIn} of {tokenIn} for at least {amountOutMin} of {tokenOut} via route {path}."
      }
    }
  }
}

The Neutral Registry and Attestation (ERC-8176)

Metadata files are a security asset in their own right. If a malicious actor submits a fraudulent ERC-7730 file that translates a transferFrom(all_your_tokens) call into a display message that says "Claim Free Airdrop", the system breaks.

To prevent this:

The Ethereum Foundation hosts a central, open-source registry at Clearsigning.org.
ERC-8176 introduces an attestation framework built on top of the Ethereum Attestation Service (EAS). Independent security firms and auditors review these JSON files against verified on-chain code and cryptographically attest to their validity. Wallets can then choose which independent auditors they trust before displaying the translation to the user.

2. ERC-8213: The Bytes-Level Fallback

ERC-7730 works perfectly when a contract is known, indexed, and audited. But what happens when you are interacting with an immutable, freshly deployed contract, a highly custom gas-optimized protocol using packed encodings, or an air-gapped system where the wallet cannot fetch the latest JSON descriptor?

If ERC-7730 cannot resolve the metadata, the wallet falls back to ERC-8213.

Authored by Cyfrin, ERC-8213 addresses a physical human vulnerability: eyeballing raw hex data fails. Humans cannot effectively verify 500 bytes of calldata on a small hardware wallet screen without missing an altered character.

Instead of displaying the entire unreadable byte string, ERC-8213 enforces that wallets calculate and display short, reproducible cryptographic fingerprints called Digests.

The Calldata Digest Formula

For standard transactions containing calldata, ERC-8213 specifies a strict, length-prefixed hash calculation:

$$\text{calldataDigest} = \text{keccak256}(\text{uint256}(\text{len}(\text{calldata})) \mathbin{\Vert} \text{calldata})$$

By prefixing the raw calldata bytes with their explicit 32-byte length representation before hashing, it eliminates length-extension vulnerabilities and provides a deterministic snapshot of the execution vector.

The EIP-712 Digest

For off-chain signatures (like those used in snapshot voting, Permit2 allowances, or Safe multi-sig tracking), ERC-8213 mandates the standard exposure of the EIP-712 structured digest:

$$\text{EIP712Digest} = \text{0x1901} \mathbin{\Vert} \text{domainSeparator} \mathbin{\Vert} \text{hashStruct}(\text{message})$$

Why This Matters for Hardware Verification

If a frontend gets compromised via an XSS injection, the attacker will swap out the underlying transaction parameters (e.g., modifying the recipient address in the transaction payload).

Because the frontend is compromised, the user's browser extension might lie about what is happening. However, the hardware wallet calculates the ERC-8213 Calldata Digest directly from the raw bytes sent over the USB/Bluetooth line.

By comparing the digest shown on the physical screen with an independent source (like a block explorer, a separate terminal tool, or local execution), the user has deterministic proof that the data was not modified in transit.

3. The Clear Signing Workflow

When an application triggers a signing event, the execution pipeline functions as follows:

[ Frontend Action ] 
        │
        ▼
[ Raw Calldata / EIP-712 Struct Generated ]
        │
        ▼
[ Wallet Interception ]
        │
        ├───► Has ERC-7730 Metadata & Valid ERC-8176 Attestation?
        │           │
        │           ├───► YES: Display Human-Readable UI ("Swap 1 ETH for 3,000 USDC")
        │
        └───► NO (Fallback to ERC-8213)
                    │
                    └───► Compute deterministic Keccak256 Calldata/EIP-712 Digest
                    └───► Render concise cryptographic fingerprint on screen

Intent to Build

Clear signing closes one of the oldest attack surfaces in the EVM ecosystem. Moving forward, security is no longer just about writing secure Solidity or Rust circuits; it includes ensuring that the execution intent matches the user's perception at the exact millisecond they hit "Sign."

As I focus on building protocol-level infrastructure, implementing ERC-7730 descriptors and ensuring ERC-8213 compatibility will be core to the development lifecycle of my applications. I will be documenting my project implementations, gas considerations, and architectural patterns here in public. Stay tuned for the engineering updates.

0 to 1: notes to future blockchain dev self

Aniket Misra — Sat, 25 Apr 2026 23:29:38 +0000

I’m starting this blog to document my transition into protocol-level blockchain development.

My upcoming work will focus exclusively on:

Solidity & Solana: High-performance smart contract development. Often comparative and learnings to be fossilized for self.

Zero-Knowledge Proofs: Research and application of ZKP systems.

This will be a space for tracking progress, detailing project roadblocks, and sharing architectural notes as I build these systems in public.

Though not limited to given topics, as general and adjacent webdev intrigues keep me occupied, purpose of blogging for me is to keep grounded in the field i expect to be my profession.

No polish though. Just notes out of a register.