Two Rails to a Friendlier Ethereum: ERC‑4337 Smart Accounts + ERC‑4804 Web3 URLs
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:
- 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.
- 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.
- 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 theuniswap.eth
address with empty calldata.web3://.../balanceOf/vitalik.eth?returns=(uint256)
would ABI-encode a call to thebalanceOf
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:
- 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. - 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. - Verifiable Receipt: After the transaction confirms, the user is shown a confirmation view that is just another
web3://
link, likeweb3://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.