Building on Ethereum in 2026: What EIP-4844, EIP-7702, and ZK-Native AA Change for Developers
Three protocol upgrades have quietly restructured the Ethereum builder stack. Here's what the shift to blobs, delegated EOAs, and ZK-native account abstraction actually means if you're shipping on L2 today.
By TRAGenX Desk
Two years ago, Ethereum mainnet was where your contract lived and L2 was where some of your users ended up. That mental model is obsolete. Three interlocking upgrades — EIP-4844, EIP-7702, and the maturation of ZK-native account abstraction — have shifted the calculus so far that building directly on L1 without a deliberate reason now looks like the unusual choice, not the default.
EIP-4844: Blobs Solved the Data Cost Problem
When Ethereum's Dencun upgrade shipped on March 13, 2024, it introduced blob-carrying transactions (EIP-4844, proto-danksharding). Rollups post their data in blobs instead of calldata — consensus clients verify availability, then discard the data after roughly 18 days. The permanent-storage overhead disappears, and with it went the majority of L2 data fees.
The drop was immediate: L2 data costs fell by up to 10× in the days following activation, with rollup data across Optimism, Arbitrum, and Base all showing comparable reductions. Ethereum's Pectra upgrade in May 2025 then doubled the blob target from 3 to 6 blobs per block, keeping fees low as rollup activity continued to grow. PeerDAS, shipped via the Fusaka upgrade in December 2025, extends this further toward full Danksharding without a hard capacity ceiling.
EIP-7702: Smart Wallet Features Without Burning Your Existing Address
The biggest quality-of-life change for wallet UX also shipped in Pectra. EIP-7702 lets an EOA store a 23-byte delegation pointer (0xef0100 + implementation address) so that for the duration of a transaction, the EVM treats calls to that EOA as calls to the pointed-to smart contract. No deployment, no new address, no migration path to manage.
What that delegation unlocks in practice:
- Batched transactions — approve and swap in a single user signature
- Gas sponsorship — a paymaster covers fees; the user never needs to hold ETH
- Session keys — time-scoped or permission-scoped signing authorities for dApps
- Granular permissions — per-dApp spending caps without a new contract deployment
MetaMask, Rabby, and Coinbase Wallet all shipped EIP-7702 support during 2025. The key point for builders: if your users already have EOAs (they all do), you can deliver smart-wallet UX today without forking them onto a new address space. ERC-4337 and EIP-7702 are complementary — 7702 serves the existing user base now; 4337 remains the long-term standard for native smart-contract wallets.
ZK-Native AA: Starknet and zkSync at Production Scale
Starknet and zkSync were built with account abstraction at the protocol layer — every account is a smart contract by default, no ERC-4337 bundler required. Multi-call batching, custom signature schemes, and session keys are first-class primitives, not bolted-on middleware.
Starknet's 2025 upgrade cycle was the most consequential to date. The Stwo prover replaced the earlier Stone prover and delivered approximately 100× improvement in proving throughput. Pre-confirmation latency dropped from ~2 seconds to ~0.5 seconds, and block times tightened from 30 seconds to 4 seconds. The ZK confirmation loop is now fast enough that production consumer apps can use it without UX apologies — a claim that wasn't credible two years ago.
What This Means If You're Building Now
- Default to L2. Mainnet is settlement and security; L2 is where users and gas budgets live. The blob fee floor is stable and expanding.
- Implement EIP-7702 if your users have EOAs. It's the lowest-friction path to gasless onboarding without address migration and fits inside the existing ERC-4337 paymaster ecosystem.
- Evaluate ZK-native chains if you need AA as a first-class primitive. Starknet's proving improvements and zkSync's native AA model are mature enough for production; you get batching and session keys without middleware.
- Don't assume ERC-4337 and EIP-7702 compete. Most infrastructure — bundlers, paymasters, SDKs — is ERC-4337-centric. EIP-7702 delegates into this ecosystem rather than replacing it.
The Ethereum builder stack in 2026 is not the same stack as 2022 or even 2024. The infrastructure bets that looked speculative then have compounded into a coherent, battle-tested platform — and the compounding isn't done.
FAQ
Frequently asked questions
- What is EIP-4844 and why did it reduce L2 fees so dramatically?
- EIP-4844 (proto-danksharding), activated in the Dencun upgrade on March 13, 2024, lets rollups post batch data in temporary blobs rather than permanent calldata. Consensus clients verify availability and discard blobs after ~18 days, eliminating the permanent-storage cost that dominated L2 data fees. The reduction reached up to 10× immediately after activation.
- Do I need to redeploy my wallet or contract to use EIP-7702?
- No. EIP-7702 works by storing a delegation pointer in an existing EOA's account state. Your address stays the same; the EVM routes calls through a smart-contract implementation for the duration of a single transaction. There is no redeployment, no migration, and no new address for users to manage.
- What is the difference between EIP-7702 and ERC-4337?
- EIP-7702 is a protocol-level mechanism that temporarily delegates an EOA to a smart-contract implementation per transaction — it upgrades wallets users already have. ERC-4337 is an application-layer standard for deploying dedicated smart-contract wallets with a UserOperation mempool and bundler network. They are complementary: 7702 improves the existing EOA user base now; 4337 is the long-term standard for native smart wallets.
Sources