3 posts tagged with "ERC-4337"

TL;DR​

Ethereum just got two powerful primitives that push user experience past seed phrases and bookmarkable dapps toward “clickable on-chain experiences.”

• ERC-4337 brings account abstraction to today’s Ethereum without core protocol changes. This makes features like smart contract accounts, gas sponsorship, batched calls, and passkey-style authentication native to wallets.
• ERC-4804 introduces web3:// URLs—human-readable links that resolve directly to contract read calls and can even render on-chain HTML or SVG, all without a traditional web server acting as a middleman. Think of it as “HTTP for the EVM.”

When used together, ERC-4337 handles actions, while ERC-4804 handles addresses. This combination allows you to share a link that verifiably pulls its user interface from a smart contract. When a user is ready to act, the flow hands off to a smart account that can sponsor gas and batch multiple steps into a single, seamless click.

---

Why This Matters Now​

This isn't just a theoretical future; these technologies are live and gaining significant traction. ERC-4337 is already scaled and proven in the wild. The canonical EntryPoint contract was deployed on the Ethereum mainnet on March 1, 2023, and has since powered tens of millions of smart contract accounts and processed over 100 million user operations.

Simultaneously, the core protocol is converging with these ideas. The Pectra upgrade, shipped in May 2025, included EIP-7702, which allows standard externally owned accounts (EOAs) to temporarily behave like smart accounts. This complements ERC-4337 by easing the transition for existing users, rather than replacing the standard.

On the addressing front, web3:// is now formalized. ERC-4804 specifies exactly how a URL translates into an EVM call, and web3 has been listed by IANA as a provisional URI scheme. The tooling and gateways needed to make these URLs practical are now available, turning on-chain data into shareable, linkable resources.

---

Primer: ERC-4337 in One Page​

At its core, ERC-4337 introduces a parallel transaction rail to Ethereum, built for flexibility. Instead of traditional transactions, users submit UserOperation objects into an alternative mempool. These objects describe what the account wants to do. Specialized nodes called "Bundlers" pick up these operations and execute them through a global EntryPoint contract.

This enables three key components:

1. Smart Contract Accounts (SCAs): These accounts contain their own logic. They define what makes a transaction valid, allowing for custom signature schemes (like passkeys or multisig), session keys for games, spending limits, and social recovery mechanisms. The account, not the network, enforces the rules.
2. Paymasters: These special contracts can sponsor gas fees for users or allow them to pay in ERC-20 tokens. This is the key to unlocking true “no-ETH-in-wallet” onboarding and creating one-click experiences by batching multiple calls into a single operation.
3. DoS Safety & Rules: The public ERC-4337 mempool is protected by standardized off-chain validation rules (defined in ERC-7562) that prevent Bundlers from wasting resources on operations that are destined to fail. While alternative mempools can exist for specialized use cases, these shared rules keep the ecosystem coherent and secure.

Mental model: ERC-4337 turns wallets into programmable apps. Instead of just signing raw transactions, users submit "intents" that their account's code validates and the EntryPoint contract executes—safely and atomically.

---

Primer: ERC-4804 in One Page​

ERC-4804 provides a simple, direct mapping from a web3:// URL to a read-only EVM call. The URL grammar is intuitive: web3://<name-or-address>[:chainId]/<method>/<arg0>?returns=(types). Names can be resolved via systems like ENS, and arguments are automatically typed based on the contract's ABI.

Here are a couple of examples:

• web3://uniswap.eth/ would call the contract at the uniswap.eth address with empty calldata.
• web3://.../balanceOf/vitalik.eth?returns=(uint256) would ABI-encode a call to the balanceOf function with Vitalik's address and return a properly typed JSON result.

Crucially, this standard is currently for read-only calls (equivalent to Solidity's view functions). Any action that changes state still requires a transaction—which is exactly where ERC-4337 or EIP-7702 come in. With web3 registered as a provisional URI scheme with IANA, the path is paved for native browser and client support, though for now, it often relies on extensions or gateways.

Mental model: ERC-4804 turns on-chain resources into linkable web objects. “Share this contract view as a URL” becomes as natural as sharing a link to a dashboard.

---

Together: "Clickable On-chain Experiences"​

Combining these two standards unlocks a powerful new pattern for building decentralized applications today.

First, you deliver a verifiable UI via web3://. Instead of hosting your frontend on a centralized server like S3, you can store a minimal HTML or SVG interface directly on-chain. A link like web3://app.eth/render allows a client to resolve the URL and render the UI directly from the contract, ensuring the user sees exactly what the code dictates.

From that verifiable interface, you can trigger a one-click action via ERC-4337. A "Mint" or "Subscribe" button can compile a UserOperation that a paymaster sponsors. The user approves with a passkey or a simple biometric prompt, and the EntryPoint contract executes a batched call that deploys their smart account (if it's their first time) and completes the desired action in a single, atomic step.

This creates a seamless deep-link handoff. The UI can embed intent-based links that are handled directly by the user's wallet, eliminating the need to send them to an external site they may not trust. The content is the contract, and the action is the account.

This unlocks:

• Gasless trials and "just works" onboarding: New users don't need to acquire ETH to get started. Your application can sponsor their first few interactions, dramatically reducing friction.
• Shareable state: A web3:// link is a query into the blockchain's state. This is perfect for dashboards, proofs of ownership, or any content that must be verifiably tamper-evident.
• Agent-friendly flows: AI agents can fetch verifiable state via web3:// URLs and submit transactional intents through ERC-4337 using scoped session keys, all without brittle screen scraping or insecure private key handling.

---

Design Notes for Builders​

When implementing these standards, there are a few architectural choices to consider. For ERC-4337, it's wise to start with minimal smart contract account templates and add capabilities through guarded modules to keep the core validation logic simple and secure. Your paymaster policy should be robust, with clear caps on sponsored gas and whitelists for approved methods to prevent griefing attacks.

For ERC-4804, prioritize human-readable links by using ENS names. Be explicit about chainId to avoid ambiguity and include the returns=(…) parameter to ensure clients receive typed, predictable responses. While you can render full UIs, it’s often best to keep on-chain HTML/SVG minimal, using them as verifiable shells that can fetch heavier assets from decentralized storage like IPFS.

Finally, remember that EIP-7702 and ERC-4337 work together, not against each other. With EIP-7702 now active in the Pectra upgrade, existing EOA users can delegate actions to contract logic without deploying a full smart account. The tooling in the account abstraction ecosystem is already aligning to support this, smoothing the migration path for everyone.

---

Security, Reality, and Constraints​

While powerful, these systems have trade-offs. The EntryPoint contract is a central chokepoint by design; it simplifies the security model but also concentrates risk. Always stick to audited, canonical versions. The mempool validation rules from ERC-7562 are a social convention, not an on-chain enforced rule, so don't assume every alternative mempool offers the same censorship resistance or DoS protection.

Furthermore, web3:// is still maturing. It remains a read-only standard, and any write operation requires a transaction. While the protocol itself is decentralized, the gateways and clients that resolve these URLs can still be potential points of failure or censorship. True "unblockability" will depend on widespread native client support.

---

A Concrete Blueprint​

Imagine you want to build an NFT-powered membership club with a shareable, verifiable UI and a one-click join process. Here’s how you could ship it this quarter:

1. Share the UI: Distribute a link like web3://club.eth/home. When a user opens it, their client resolves the URL, calls the contract, and renders an on-chain UI that displays the current member allowlist and mint price.
2. One-Click Join: The user clicks a "Join" button. Their wallet compiles an ERC-4337 UserOperation that is sponsored by your paymaster. This single operation batches three calls: deploying the user's smart account (if they don't have one), paying the mint fee, and registering their profile data.
3. Verifiable Receipt: After the transaction confirms, the user is shown a confirmation view that is just another web3:// link, like web3://club.eth/receipt/<tokenId>, creating a permanent, on-chain link to their membership proof.

---

The Bigger Arc​

These two standards signal a fundamental shift in how we build on Ethereum. Accounts are becoming software. ERC-4337 and EIP-7702 are turning "wallet UX" into a space for real product innovation, moving us beyond lectures about key management. At the same time, links are becoming queries. ERC-4804 restores the URL as a primitive for addressing verifiable facts on-chain, not just the frontends that proxy them.

Together, they shrink the gap between what users click and what contracts do. That gap was once filled by centralized web servers and trust assumptions. Now, it can be filled by verifiable code paths and open, permissionless mempools.

If you're building consumer crypto applications, this is your chance to make the user's first minute delightful. Share a link, render the truth, sponsor the first action, and keep your users inside a verifiable loop. The rails are here—now it's time to ship the experiences.

For years, the crypto world has been hampered by a critical usability problem: the wallet. Traditional wallets, known as Externally Owned Accounts (EOAs), are unforgiving. A single lost seed phrase means your funds are gone forever. Every action requires a signature, and gas fees must be paid in the chain's native token. This clunky, high-stakes experience is a major barrier to mainstream adoption.

Enter Account Abstraction (AA), a paradigm shift set to redefine how we interact with the blockchain. At its core, AA transforms a user's account into a programmable smart contract, unlocking features like social recovery, one-click transactions, and flexible gas payments.

The journey toward this smarter future is unfolding along three distinct paths: the battle-tested ERC-4337, the efficient Native AA, and the highly anticipated EIP-7702. Let's break down what each approach means for developers and users.

---

💡 Path 1: The Pioneer — ERC-4337​

ERC-4337 was the breakthrough that brought account abstraction to Ethereum and EVM chains without changing the core protocol. Think of it as adding a smart layer on top of the existing system.

It introduces a new transaction flow involving:

• UserOperations: A new object that represents a user's intent (e.g., "swap 100 USDC for ETH").
• Bundlers: Off-chain actors that pick up UserOperations, bundle them together, and submit them to the network.
• EntryPoint: A global smart contract that validates and executes the bundled operations.

The Good:

• Universal Compatibility: It can be deployed on any EVM chain.
• Flexibility: Enables rich features like session keys for gaming, multi-signature security, and gas sponsorship via Paymasters.

The Trade-off:

• Complexity & Cost: It introduces significant infrastructure overhead (running Bundlers) and has the highest gas costs of the three approaches, as every operation goes through the extra EntryPoint logic. Because of this, its adoption has flourished primarily on gas-friendly L2s like Base and Polygon.

ERC-4337 walked so that other AA solutions could run. It proved the demand and laid the groundwork for a more intuitive Web3 experience.

---

🚀 Path 2: The Integrated Ideal — Native Account Abstraction​

If ERC-4337 is an add-on, Native AA is building smart features directly into the blockchain's foundation. Chains like zkSync Era and Starknet were designed from the ground up with AA as a core principle. On these networks, every account is a smart contract.

The Good:

• Efficiency: By integrating AA logic into the protocol, it strips away the extra layers, leading to significantly lower gas costs compared to ERC-4337.
• Simplicity for Devs: Developers don't need to manage Bundlers or a separate mempool. The transaction flow feels much more like a standard one.

The Trade-off:

• Ecosystem Fragmentation: Native AA is chain-specific. An account on zkSync is different from an account on Starknet, and neither is native to Ethereum mainnet. This creates a fragmented experience for users and developers working across multiple chains.

Native AA shows us the "endgame" for efficiency, but its adoption is tied to the growth of its host ecosystems.

---

🌉 Path 3: The Pragmatic Bridge — EIP-7702​

Set to be included in Ethereum's 2025 "Pectra" upgrade, EIP-7702 is a game-changer designed to bring AA features to the masses of existing EOA users. It takes a hybrid approach: it allows an EOA to temporarily delegate its authority to a smart contract for a single transaction.

Think of it as giving your EOA temporary superpowers. You don't need to migrate your funds or change your address. Your wallet can simply add an authorization to a transaction, allowing it to perform batched operations (e.g., approve + swap in one click) or have its gas sponsored.

The Good:

• Backward Compatibility: It works with the billions of dollars secured by existing EOAs. No migration needed.
• Low Complexity: It uses the standard transaction pool, eliminating the need for Bundlers and drastically simplifying infrastructure.
• Mass Adoption Catalyst: By making smart features accessible to every Ethereum user overnight, it could rapidly accelerate the adoption of better UX patterns.

The Trade-off:

• Not "Full" AA: EIP-7702 doesn't solve key management for the EOA itself. If you lose your private key, you're still out of luck. It's more about enhancing transaction capabilities than overhauling account security.

---

Head-to-Head: A Clear Comparison​

Feature	ERC-4337 (The Pioneer)	Native AA (The Ideal)	EIP-7702 (The Bridge)
Core Idea	External smart contract system via Bundlers	Protocol-level smart accounts	EOA temporarily delegates to a smart contract
Gas Cost	Highest (due to EntryPoint overhead)	Low (protocol-optimized)	Moderate (small overhead on one transaction for batching)
Infrastructure	High (Requires Bundlers, Paymasters)	Low (Handled by the chain's validators)	Minimal (Uses existing transaction infrastructure)
Key Use Case	Flexible AA on any EVM chain, especially L2s.	Highly efficient AA on purpose-built L2s.	Upgrading all existing EOAs with smart features.
Best For...	Gaming wallets, dApps needing gasless onboarding now.	Projects building exclusively on chains like zkSync/Starknet.	Bringing batching & gas sponsorship to mainstream users.

---

The Future is Convergent and User-Centric​

These three paths aren't mutually exclusive; they are converging toward a future where the wallet is no longer a point of friction.

1. Social Recovery Becomes Standard 🛡️: The era of "lost keys, lost funds" is ending. AA enables guardian-based recovery, making self-custody as safe and forgiving as a traditional bank account.
2. Gaming UX Reimagined 🎮: Session keys will allow for seamless gameplay without constant "approve transaction" pop-ups, finally making Web3 gaming feel like Web2 gaming.
3. Wallets as Programmable Platforms: Wallets will become modular. Users might add a "DeFi module" for automated yield farming or a "security module" that requires 2FA for large transfers.

For developers and infrastructure providers like Blockeden.xyz, this evolution is incredibly exciting. The complexity of Bundlers, Paymasters, and various AA standards creates a massive opportunity to provide robust, reliable, and abstracted infrastructure. The goal is a unified experience where a developer can easily integrate AA features, and the wallet intelligently uses ERC-4337, Native AA, or EIP-7702 under the hood, depending on what the chain supports.

The wallet is finally getting the upgrade it deserves. The transition from static EOAs to dynamic, programmable smart accounts is not just an improvement—it's the revolution that will make Web3 accessible and safe for the next billion users.

Hello and welcome back to our blockchain blog! Today, we will be diving into an exciting new proposal called ERC-4337, which introduces account abstraction to Ethereum without requiring any consensus-layer protocol changes. Instead, this proposal relies on higher-layer infrastructure to achieve its goals. Let's explore what ERC-4337 has to offer and how it addresses the limitations of the current Ethereum ecosystem.

What is ERC-4337?​

ERC-4337 is a proposal that introduces account abstraction to Ethereum through the use of a separate mempool and a new type of pseudo-transaction object called a UserOperation. Users send UserOperation objects into the alternative mempool, where a special class of actors called bundlers package them into a transaction making a handleOps call to a dedicated contract. These transactions are then included in a block.

The proposal aims to achieve several goals:

1. Enable users to use smart contract wallets with arbitrary verification logic as their primary accounts.
2. Completely remove the need for users to have externally owned accounts (EOAs).
3. Ensure decentralization by allowing any bundler to participate in the process of including account-abstracted user operations.
4. Enable all activity to happen over a public mempool, eliminating the need for users to know direct communication addresses of specific actors.
5. Avoid trust assumptions on bundlers.
6. Avoid requiring any Ethereum consensus changes for faster adoption.
7. Support other use cases such as privacy-preserving applications, atomic multi-operations, paying transaction fees with ERC-20 tokens, and developer-sponsored transactions.

Backwards Compatibility​

Since ERC-4337 does not change the consensus layer, there are no direct backwards compatibility issues for Ethereum. However, pre-ERC-4337 accounts are not easily compatible with the new system because they lack the necessary validateUserOp function. This can be addressed by creating an ERC-4337 compatible account that re-implements the verification logic as a wrapper and setting it as the original account’s trusted op submitter.

Reference Implementation​

For those interested in diving deeper into the technical details of ERC-4337, a reference implementation is available at https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Security Considerations​

The entry point contract for ERC-4337 must be heavily audited and formally verified, as it serves as a central trust point for the entire system. While this approach reduces the auditing and formal verification load for individual accounts, it does concentrate security risk in the entry point contract, which must be robustly verified.

Verification should cover two primary claims:

1. Safety against arbitrary hijacking: The entry point only calls an account generically if validateUserOp to that specific account has passed.
2. Safety against fee draining: If the entry point calls validateUserOp and passes, it must also make the generic call with calldata equal to op.calldata.

Conclusion​

ERC-4337 is an exciting proposal that aims to introduce account abstraction to Ethereum without requiring consensus-layer protocol changes. By using higher-layer infrastructure, it opens up new possibilities for decentralization, flexibility, and various use cases. While there are security considerations to address, this proposal has the potential to greatly improve the Ethereum ecosystem and user experience.