Ethereum is undergoing a structural shift in how accounts work, and it's one of the most important changes the network has seen since its launch.

For most of its history, using Ethereum meant controlling a private key. A long string of characters that, if you had it, gave you full access to your funds. If you lost it, you lost everything. No recovery, no appeals, no second chances. Transaction rules were rigid, hardcoded, and intentionally minimal.

Today, that model is changing with the introduction of smart accounts.

A smart account is simply an Ethereum account that runs as a programmable smart contract instead of being controlled by a fixed private key. That one shift, from key to contract, is what unlocks everything else.

The technology behind this shift is called Account Abstraction (AA). It's the infrastructure that makes smart accounts possible, enabling accounts to define their own rules for authorization, gas payment, recovery, delegation, and automation.

Adoption is accelerating. As of March 2026, over 53 million smart accounts have been created, while up to 970 million user operations have been successfully executed. Over 70% of wallets transacting on Worldcoin are already smart accounts, showing that the shift away from traditional accounts is well underway. Momentum increased further after Ethereum's Pectra upgrade in May 2025, which introduced EIP-7702, bringing smart account capabilities closer to Ethereum's core design.

This article builds from first principles. No prior deep knowledge assumed. By the end, you'll understand:

• What Ethereum accounts actually are and why they were built the way they were

• How Account Abstraction works and the three standards powering it: ERC-4337, EIP-7702, ERC-7579.

• What smart accounts are, what they can do, and why they matter

• The ecosystem stack forming around them

• Risks and open questions as adoption accelerates

To understand smart accounts, you first need to understand what an Ethereum account actually is under the hood.

Every Ethereum account, whether a wallet or a contract, contains exactly four fields:

• Nonce — counts transactions sent; prevents replay attacks

• Balance — ETH held by the account (in wei)

• Storage Root — reference to contract storage (empty for EOAs)

• Code Hash — hash of deployed bytecode (empty for EOAs)

This structure gives rise to two account types.

Externally Owned Accounts (EOAs)

An EOA:

• Is controlled by a private key

• Can initiate transactions

• Has no executable code

• Cannot customise validation logic

Validation is fixed and simple:

1. Recover signer from signature

2. Verify nonce

3. Check balance

4. Deduct gas

This simplicity was intentional. In 2015, Ethereum prioritised deterministic validation and resistance to denial-of-service attacks. Allowing arbitrary validation logic at the protocol level would have forced validators to execute unpredictable code just to verify transactions, which was an unacceptable security risk.

The tradeoff: EOAs are rigid.

They cannot natively support:

• Multi-signature approval

• Spending limits

• Social recovery

• Alternative authentication (e.g., passkeys)

• Gas abstraction

All rules are baked into the protocol. No exceptions.

Contract Accounts

A contract account:

• Contains bytecode

• Has persistent storage

• Executes custom logic when called

• Cannot initiate transactions on its own

The division of labour is clean:

EOAs initiate. Contracts execute.

This preserved protocol simplicity, but at the cost of user flexibility.

The natural question emerged: Why can't an account both initiate and execute with programmable rules?

That question led to Account Abstraction.

Account Abstraction removes those limits by enabling a new kind of account: a smart account.

Unlike an EOA, a smart account is not controlled by a private key sitting on your device. It is a smart contract that you own and configure. The rules for who can authorise transactions, how gas gets paid, and what happens if you lose access all live in the contract itself, and all of it can be customised.

In practical terms, that means a smart account can support:

• Social recovery — designated guardians can restore access if you lose your key

• Batched transactions — submit multiple actions atomically in one operation

• Spending policies — set limits or require 2FA for large transfers

• Session keys — grant limited, time-bound access for specific dApps

• Alternative signatures — use passkeys, biometrics, or post-quantum schemes instead of ECDSA

Gas payments can be abstracted too. A Paymaster contract can sponsor fees or accept ERC-20 tokens instead of ETH, so users don't need to hold the chain's native token just to transact.

The core innovation of Account Abstraction is simple:

Move validation logic from the protocol into user-controlled smart contracts.

Here's what that means at a glance:

But making this work safely at scale required architectural innovation. That's where the three standards come in.

Three standards shape today's AA landscape, each solving a different layer of the problem:

• ERC-4337 — Application-level abstraction

• EIP-7702 — Protocol-level delegation for EOAs

• ERC-7579 — Modular smart account architecture

Together, they define how smart accounts are built, deployed, and used.

ERC-4337 is the most important of the three. It is the standard that makes smart accounts fully operational, without requiring any changes to Ethereum's core protocol.

Its core idea: move user transactions into a new parallel infrastructure layer.

Each user intent is encoded in a UserOperation, a structured object containing signatures, gas parameters, paymaster data, and calldata. These go into a dedicated off-chain mempool, not Ethereum's default transaction pool.

From there, independent nodes called Bundlers collect many UserOperations, simulate each one to confirm it will succeed, pack them into a single Ethereum transaction, and submit it to a standardised EntryPoint smart contract.

The EntryPoint is the trust anchor of the entire system. It calls each smart wallet's validation logic, checks gas, and executes the bundled calls in sequence. Bundlers earn fees from that single combined transaction.

No consensus-layer changes needed. Users never submit transactions directly to Ethereum; the bundler does. The only participant that still needs an EOA is the bundler itself.

Here are the four key components powering ERC-4337:

1. UserOperation

Not a normal Ethereum transaction. A UserOperation is a structured request containing:

• The account initiating the action

• The intended calldata

• Gas parameters

• A signature

• Optional paymaster data (for sponsored gas)

Think of it as a transaction intent, describing what you want to happen, not how to execute it at the protocol level.

UserOperations go into a separate mempool, not Ethereum's default transaction pool.

2. Bundlers

A Bundler:

• Collects UserOperations from the off-chain mempool

• Simulates each one to ensure it will validate successfully

• Packages them together

• Submits a single Ethereum transaction to the EntryPoint

Bundlers play a role similar to block builders, but specifically for smart account operations.

3. Paymasters

Paymasters are optional contracts that agree to cover a UserOperation's gas under custom policies.

They sit between the user and the EntryPoint. When a UserOperation includes paymaster data, the EntryPoint checks with the Paymaster contract first, confirming it's willing to sponsor the gas before executing anything.

This enables three powerful models:

• Sponsored gas — a dApp pays fees on behalf of its users entirely

• Token-based gas — users pay in stablecoins or other ERC-20 tokens instead of ETH

• Subscription models — flat-fee or prepaid gas arrangements

This is the key unlock for gasless onboarding. New users can interact with a smart account without ever holding ETH, removing one of the biggest friction points for mainstream adoption.

4. EntryPoint Contract

A singleton smart contract, meaning one shared instance for all ERC-4337 smart accounts.

When a bundled transaction arrives:

1. Checks with the Paymaster (if included) to confirm gas sponsorship

2. Calls validateUserOp() on each smart account

3. If validation passes, executes the requested call

4. Handles all gas accounting internally, reimbursing the Bundler

Here's the full flow:

The crucial design choice: all validation happens inside the EVM and is fully gas-metered. Ethereum's consensus rules remain unchanged, preserving network safety while enabling fully programmable smart accounts.

ERC-4337 gave smart accounts everything they needed, but it didn't replace EOAs.

EOAs still exist. They still have special treatment in Ethereum's core rules. And they're still the default for most users.

This creates friction. To get the benefits of a smart account, users have to:

• Deploy a new smart account contract

• Fund it separately

• Migrate all their activity

• Manage two mental models at once

EIP-7702, introduced in Ethereum's Pectra upgrade (May 2025), reduces that barrier significantly.

What it does:

It allows an EOA to temporarily attach executable code to itself for the duration of a single transaction. Once that transaction completes, the account reverts to normal EOA behaviour.

This creates a hybrid model:

• The account remains an EOA

• But it can behave like a smart account when needed

Why it matters:

Instead of forcing users to migrate, EIP-7702 lets existing wallets gradually gain smart account features, enabling:

• Transaction batching

• Sponsored gas flows

• Custom validation logic

• Safer, incremental migrations into full smart accounts

EIP-7702 is also fully compatible with ERC-4337 infrastructure. Wallets using 7702 can still route through ERC-4337 bundlers and paymasters, and users can move at their own pace. Major wallets including MetaMask and Trust Wallet have already shipped EIP-7702 support.

Think of EIP-7702 as the bridge. It lets the billions of existing EOA users begin experiencing smart account features without leaving their current wallet behind.

As smart accounts proliferated, a new problem emerged: fragmentation.

Different wallets implemented incompatible module systems. You couldn't reuse a validated component across implementations. Security audits couldn't be shared. The ecosystem was pulling apart just as it was gaining momentum.

ERC-7579 fixes this, not by building another smart account, but by standardising how all smart accounts are structured.

It defines a common modular interface so that any module, whether a signing scheme, a recovery mechanism, or a spending policy, works across any compliant smart account. Build it once, use it everywhere.

Instead of one large wallet contract that does everything, responsibilities are split into plug-and-play components around a minimal account core. Four module types are defined: Validation, Execution, Hooks, and Fallback Handlers.

The modular model:

                       Account Core (Kernel)
                   /        |        |        \
          Validation   Execution   Hooks   Fallback
          Modules      Modules             Handlers

The smart account becomes a minimal coordination layer. Everything else is installable logic.

Core components:

1. Account Core (Kernel)

Responsible for:

• Holding funds

• Managing nonces

• Installing and removing modules

• Routing calls to the right module

The core stays intentionally small to minimise attack surface. It's a router, not a feature set.

2. Validation Modules

These define who can authorise transactions on the smart account, under what conditions, and using which signature scheme.

Examples:

• ECDSA validator

• Multi-signature validator

• Guardian-based recovery

• Session key validator

Validation becomes pluggable. Upgrade your signing scheme without redeploying the entire smart account.

3. Execution Modules

These define how the smart account executes calls, whether batching is allowed, whether delegate calls are permitted, and what restrictions apply.

Execution becomes customisable per use case.

4. Hooks

Hooks run pre- and post-transaction logic on the smart account:

• Pre-transaction: enforce spending limits, check policy conditions before a call goes through

• Post-transaction: update internal balances, log activity, enforce policy after execution

This is where a smart account's rules and guardrails live, not baked into the core, but composable and upgradeable.

5. Fallback Handlers

Fallback handlers define what the smart account does when it receives a call it doesn't recognise, specifically a function signature no installed module handles.

Rather than reverting by default, a fallback handler lets the account respond gracefully. As new token standards emerge or protocols evolve, the smart account can support them via a new handler, with no full contract upgrade required.

Think of them as the smart account's catch-all layer. Quietly essential for staying compatible with a living, evolving ecosystem.

Why modularity matters for smart accounts:

Without it:

• Adding features to a smart account increases contract complexity

• Upgrades introduce systemic risk

• Audits become harder and more expensive

• Security boundaries blur

With it:

• Smart account features can be added or removed independently

• Risk is isolated to individual modules

• Signing and recovery logic can evolve without touching the core

• Smart accounts become extensible, auditable platforms

This is more than wallet design. It turns smart accounts into programmable security runtimes, infrastructure you can build on top of, not just use.

How the three standards fit together:

The progression tells a clear story:

• Ethereum (2015) — Fixed EOAs, rigid rules, no programmability

• ERC-4337 — Smart accounts become possible, without consensus changes

• EIP-7702 — Smart account features reach existing wallets

• ERC-7579 — Smart accounts become modular, composable, and interoperable

Ethereum accounts are evolving from static key containers into programmable smart accounts, and the standards to support that are now in place.

Smart accounts are not just a better wallet. They are the foundation for a fundamentally different relationship between users and on-chain value.

If we follow the trajectory, the destination becomes clear.

Smart accounts become programmable agents. In this world:

• Users authenticate with biometrics, faceID or passkeys, with no seed phrases to lose

• Gas is abstracted away entirely, and users don't need to know it exists

• Smart accounts enforce your rules automatically: spending limits, approvals, policies built into the account itself

• Permissions are granular and time-bound; grant a dApp $50 of access for 24 hours, then it expires automatically

• Agents transact autonomously on your behalf, within boundaries you define

At that point, the distinction between "wallet" and "smart contract" disappears.

There are only programmable accounts, and they work the way users actually need them to.

Smart accounts are no longer just a standards discussion. A full ecosystem has formed around building, deploying, and scaling them.

Here's how the layers break down:

Core Standards

ERC-4337, EIP-7702, ERC-7579.

These define how smart accounts function and interact. Everything else builds on top of them.

EntryPoint & Bundler Infrastructure

Bundlers aggregate UserOperations and submit them on-chain. Without a reliable bundler network, smart accounts can't operate at scale.

Key players: @stackup_fi @pimlicoHQ @Alchemy

Paymasters (Gas Abstraction)

Paymasters sponsor gas or accept ERC-20 tokens instead of ETH, one of the most important unlocks for smart account adoption. They enable:

• Gasless onboarding for new users

• Token-based gas payments

• Subscription-style fee models

Key players: @biconomy, @OpenZeppelin

Smart Account Frameworks

Reusable, audited smart account implementations so developers don't build from scratch.

Key players: @safe @zerodev_app @rhinestonewtf @candidelabs

Safe is the most battle-tested, securing billions in assets. ZeroDev's Kernel and Candide are optimised specifically for the ERC-4337 ecosystem, lightweight, modular, and developer-friendly.

Wallet & Consumer Layer

Where smart accounts finally meet end users.

Key players: @baseapp, @ready_co @MetaMask, @phantom, @TrustWallet

Coinbase has made ERC-4337 smart accounts the default for new users. Ready (Argent) pioneered smart account UX long before ERC-4337 existed. MetaMask, Phantom, and Trust Wallet are bringing smart account capabilities to tens of millions of existing users, without asking them to switch wallets.

The stack is maturing fast. What was a fragmented set of experiments two years ago is now a coherent infrastructure layer with clear separation of concerns, competitive markets at each level, and major consumer products driving smart account adoption at scale.

Smart accounts introduce powerful capabilities, but also new tradeoffs worth understanding clearly.

Smart contract risk. Smart accounts are more complex than keypairs. A bug in a validation module can be catastrophic at scale. Complexity invites exploits.

Module trust. A smart account is only as secure as its weakest installed module. Third-party modules require rigorous auditing, and users need to understand what they're actually installing into their account.

Bundler centralisation. If a handful of bundlers dominate transaction processing, censorship becomes possible. This mirrors the MEV centralisation risk in block building and deserves the same level of scrutiny.

EIP-7702 delegation risk. An EOA that delegates to malicious code, even for a single transaction, can be drained. The security model shifts from don't lose your key to don't sign malicious delegation requests. That's a subtler threat and harder to communicate to everyday users.

UX vs. self-sovereignty. Abstracting key management makes smart accounts easier to use. But if the underlying keys are custodied by a wallet provider, users may be trading self-sovereignty for convenience without fully realising it.

None of these is a dealbreaker. They're the expected friction of a maturing technology, and the ecosystem is actively working through each of them.

But they're worth understanding clearly as smart accounts move from early adopters to mainstream defaults.

Ethereum is replacing a rigid, one-size-fits-all EOA model with Smart Accounts. This alternative is programmable, recoverable, and composable, built to match how people actually want to use and manage money.

For developers, Smart Accounts are a new primitive to build on. For users, they are the foundation for a version of crypto that is finally safe and simple enough for everyone.

The shift from EOAs to Smart Accounts may be the most consequential UX change in Ethereum's history.

And smart account adoption is just getting started.

Ethereum is undergoing a structural shift in how accounts work, and it's one of the most important changes the network has seen since its launch.

For most of its history, using Ethereum meant controlling a private key. A long string of characters that, if you had it, gave you full access to your funds. If you lost it, you lost everything. No recovery, no appeals, no second chances. Transaction rules were rigid, hardcoded, and intentionally minimal.

Today, that model is changing with the introduction of smart accounts.

A smart account is simply an Ethereum account that runs as a programmable smart contract instead of being controlled by a fixed private key. That one shift, from key to contract, is what unlocks everything else.

The technology behind this shift is called Account Abstraction (AA). It's the infrastructure that makes smart accounts possible, enabling accounts to define their own rules for authorization, gas payment, recovery, delegation, and automation.

Adoption is accelerating. As of March 2026, over 53 million smart accounts have been created, while up to 970 million user operations have been successfully executed. Over 70% of wallets transacting on Worldcoin are already smart accounts, showing that the shift away from traditional accounts is well underway. Momentum increased further after Ethereum's Pectra upgrade in May 2025, which introduced EIP-7702, bringing smart account capabilities closer to Ethereum's core design.

This article builds from first principles. No prior deep knowledge assumed. By the end, you'll understand:

• What Ethereum accounts actually are and why they were built the way they were

• How Account Abstraction works and the three standards powering it: ERC-4337, EIP-7702, ERC-7579.

• What smart accounts are, what they can do, and why they matter

• The ecosystem stack forming around them

• Risks and open questions as adoption accelerates

To understand smart accounts, you first need to understand what an Ethereum account actually is under the hood.

Every Ethereum account, whether a wallet or a contract, contains exactly four fields:

• Nonce — counts transactions sent; prevents replay attacks

• Balance — ETH held by the account (in wei)

• Storage Root — reference to contract storage (empty for EOAs)

• Code Hash — hash of deployed bytecode (empty for EOAs)

This structure gives rise to two account types.

Externally Owned Accounts (EOAs)

An EOA:

• Is controlled by a private key

• Can initiate transactions

• Has no executable code

• Cannot customise validation logic

Validation is fixed and simple:

1. Recover signer from signature

2. Verify nonce

3. Check balance

4. Deduct gas

This simplicity was intentional. In 2015, Ethereum prioritised deterministic validation and resistance to denial-of-service attacks. Allowing arbitrary validation logic at the protocol level would have forced validators to execute unpredictable code just to verify transactions, which was an unacceptable security risk.

The tradeoff: EOAs are rigid.

They cannot natively support:

• Multi-signature approval

• Spending limits

• Social recovery

• Alternative authentication (e.g., passkeys)

• Gas abstraction

All rules are baked into the protocol. No exceptions.

Contract Accounts

A contract account:

• Contains bytecode

• Has persistent storage

• Executes custom logic when called

• Cannot initiate transactions on its own

The division of labour is clean:

EOAs initiate. Contracts execute.

This preserved protocol simplicity, but at the cost of user flexibility.

The natural question emerged: Why can't an account both initiate and execute with programmable rules?

That question led to Account Abstraction.

Account Abstraction removes those limits by enabling a new kind of account: a smart account.

Unlike an EOA, a smart account is not controlled by a private key sitting on your device. It is a smart contract that you own and configure. The rules for who can authorise transactions, how gas gets paid, and what happens if you lose access all live in the contract itself, and all of it can be customised.

In practical terms, that means a smart account can support:

• Social recovery — designated guardians can restore access if you lose your key

• Batched transactions — submit multiple actions atomically in one operation

• Spending policies — set limits or require 2FA for large transfers

• Session keys — grant limited, time-bound access for specific dApps

• Alternative signatures — use passkeys, biometrics, or post-quantum schemes instead of ECDSA

Gas payments can be abstracted too. A Paymaster contract can sponsor fees or accept ERC-20 tokens instead of ETH, so users don't need to hold the chain's native token just to transact.

The core innovation of Account Abstraction is simple:

Move validation logic from the protocol into user-controlled smart contracts.

Here's what that means at a glance:

But making this work safely at scale required architectural innovation. That's where the three standards come in.

Three standards shape today's AA landscape, each solving a different layer of the problem:

• ERC-4337 — Application-level abstraction

• EIP-7702 — Protocol-level delegation for EOAs

• ERC-7579 — Modular smart account architecture

Together, they define how smart accounts are built, deployed, and used.

ERC-4337 is the most important of the three. It is the standard that makes smart accounts fully operational, without requiring any changes to Ethereum's core protocol.

Its core idea: move user transactions into a new parallel infrastructure layer.

Each user intent is encoded in a UserOperation, a structured object containing signatures, gas parameters, paymaster data, and calldata. These go into a dedicated off-chain mempool, not Ethereum's default transaction pool.

From there, independent nodes called Bundlers collect many UserOperations, simulate each one to confirm it will succeed, pack them into a single Ethereum transaction, and submit it to a standardised EntryPoint smart contract.

The EntryPoint is the trust anchor of the entire system. It calls each smart wallet's validation logic, checks gas, and executes the bundled calls in sequence. Bundlers earn fees from that single combined transaction.

No consensus-layer changes needed. Users never submit transactions directly to Ethereum; the bundler does. The only participant that still needs an EOA is the bundler itself.

Here are the four key components powering ERC-4337:

1. UserOperation

Not a normal Ethereum transaction. A UserOperation is a structured request containing:

• The account initiating the action

• The intended calldata

• Gas parameters

• A signature

• Optional paymaster data (for sponsored gas)

Think of it as a transaction intent, describing what you want to happen, not how to execute it at the protocol level.

UserOperations go into a separate mempool, not Ethereum's default transaction pool.

2. Bundlers

A Bundler:

• Collects UserOperations from the off-chain mempool

• Simulates each one to ensure it will validate successfully

• Packages them together

• Submits a single Ethereum transaction to the EntryPoint

Bundlers play a role similar to block builders, but specifically for smart account operations.

3. Paymasters

Paymasters are optional contracts that agree to cover a UserOperation's gas under custom policies.

They sit between the user and the EntryPoint. When a UserOperation includes paymaster data, the EntryPoint checks with the Paymaster contract first, confirming it's willing to sponsor the gas before executing anything.

This enables three powerful models:

• Sponsored gas — a dApp pays fees on behalf of its users entirely

• Token-based gas — users pay in stablecoins or other ERC-20 tokens instead of ETH

• Subscription models — flat-fee or prepaid gas arrangements

This is the key unlock for gasless onboarding. New users can interact with a smart account without ever holding ETH, removing one of the biggest friction points for mainstream adoption.

4. EntryPoint Contract

A singleton smart contract, meaning one shared instance for all ERC-4337 smart accounts.

When a bundled transaction arrives:

1. Checks with the Paymaster (if included) to confirm gas sponsorship

2. Calls validateUserOp() on each smart account

3. If validation passes, executes the requested call

4. Handles all gas accounting internally, reimbursing the Bundler

Here's the full flow:

The crucial design choice: all validation happens inside the EVM and is fully gas-metered. Ethereum's consensus rules remain unchanged, preserving network safety while enabling fully programmable smart accounts.

ERC-4337 gave smart accounts everything they needed, but it didn't replace EOAs.

EOAs still exist. They still have special treatment in Ethereum's core rules. And they're still the default for most users.

This creates friction. To get the benefits of a smart account, users have to:

• Deploy a new smart account contract

• Fund it separately

• Migrate all their activity

• Manage two mental models at once

EIP-7702, introduced in Ethereum's Pectra upgrade (May 2025), reduces that barrier significantly.

What it does:

It allows an EOA to temporarily attach executable code to itself for the duration of a single transaction. Once that transaction completes, the account reverts to normal EOA behaviour.

This creates a hybrid model:

• The account remains an EOA

• But it can behave like a smart account when needed

Why it matters:

Instead of forcing users to migrate, EIP-7702 lets existing wallets gradually gain smart account features, enabling:

• Transaction batching

• Sponsored gas flows

• Custom validation logic

• Safer, incremental migrations into full smart accounts

EIP-7702 is also fully compatible with ERC-4337 infrastructure. Wallets using 7702 can still route through ERC-4337 bundlers and paymasters, and users can move at their own pace. Major wallets including MetaMask and Trust Wallet have already shipped EIP-7702 support.

Think of EIP-7702 as the bridge. It lets the billions of existing EOA users begin experiencing smart account features without leaving their current wallet behind.

As smart accounts proliferated, a new problem emerged: fragmentation.

Different wallets implemented incompatible module systems. You couldn't reuse a validated component across implementations. Security audits couldn't be shared. The ecosystem was pulling apart just as it was gaining momentum.

ERC-7579 fixes this, not by building another smart account, but by standardising how all smart accounts are structured.

It defines a common modular interface so that any module, whether a signing scheme, a recovery mechanism, or a spending policy, works across any compliant smart account. Build it once, use it everywhere.

Instead of one large wallet contract that does everything, responsibilities are split into plug-and-play components around a minimal account core. Four module types are defined: Validation, Execution, Hooks, and Fallback Handlers.

The modular model:

                       Account Core (Kernel)
                   /        |        |        \
          Validation   Execution   Hooks   Fallback
          Modules      Modules             Handlers

The smart account becomes a minimal coordination layer. Everything else is installable logic.

Core components:

1. Account Core (Kernel)

Responsible for:

• Holding funds

• Managing nonces

• Installing and removing modules

• Routing calls to the right module

The core stays intentionally small to minimise attack surface. It's a router, not a feature set.

2. Validation Modules

These define who can authorise transactions on the smart account, under what conditions, and using which signature scheme.

Examples:

• ECDSA validator

• Multi-signature validator

• Guardian-based recovery

• Session key validator

Validation becomes pluggable. Upgrade your signing scheme without redeploying the entire smart account.

3. Execution Modules

These define how the smart account executes calls, whether batching is allowed, whether delegate calls are permitted, and what restrictions apply.

Execution becomes customisable per use case.

4. Hooks

Hooks run pre- and post-transaction logic on the smart account:

• Pre-transaction: enforce spending limits, check policy conditions before a call goes through

• Post-transaction: update internal balances, log activity, enforce policy after execution

This is where a smart account's rules and guardrails live, not baked into the core, but composable and upgradeable.

5. Fallback Handlers

Fallback handlers define what the smart account does when it receives a call it doesn't recognise, specifically a function signature no installed module handles.

Rather than reverting by default, a fallback handler lets the account respond gracefully. As new token standards emerge or protocols evolve, the smart account can support them via a new handler, with no full contract upgrade required.

Think of them as the smart account's catch-all layer. Quietly essential for staying compatible with a living, evolving ecosystem.

Why modularity matters for smart accounts:

Without it:

• Adding features to a smart account increases contract complexity

• Upgrades introduce systemic risk

• Audits become harder and more expensive

• Security boundaries blur

With it:

• Smart account features can be added or removed independently

• Risk is isolated to individual modules

• Signing and recovery logic can evolve without touching the core

• Smart accounts become extensible, auditable platforms

This is more than wallet design. It turns smart accounts into programmable security runtimes, infrastructure you can build on top of, not just use.

How the three standards fit together:

The progression tells a clear story:

• Ethereum (2015) — Fixed EOAs, rigid rules, no programmability

• ERC-4337 — Smart accounts become possible, without consensus changes

• EIP-7702 — Smart account features reach existing wallets

• ERC-7579 — Smart accounts become modular, composable, and interoperable

Ethereum accounts are evolving from static key containers into programmable smart accounts, and the standards to support that are now in place.

Smart accounts are not just a better wallet. They are the foundation for a fundamentally different relationship between users and on-chain value.

If we follow the trajectory, the destination becomes clear.

Smart accounts become programmable agents. In this world:

• Users authenticate with biometrics, faceID or passkeys, with no seed phrases to lose

• Gas is abstracted away entirely, and users don't need to know it exists

• Smart accounts enforce your rules automatically: spending limits, approvals, policies built into the account itself

• Permissions are granular and time-bound; grant a dApp $50 of access for 24 hours, then it expires automatically

• Agents transact autonomously on your behalf, within boundaries you define

At that point, the distinction between "wallet" and "smart contract" disappears.

There are only programmable accounts, and they work the way users actually need them to.

Smart accounts are no longer just a standards discussion. A full ecosystem has formed around building, deploying, and scaling them.

Here's how the layers break down:

Core Standards

ERC-4337, EIP-7702, ERC-7579.

These define how smart accounts function and interact. Everything else builds on top of them.

EntryPoint & Bundler Infrastructure

Bundlers aggregate UserOperations and submit them on-chain. Without a reliable bundler network, smart accounts can't operate at scale.

Key players: @stackup_fi @pimlicoHQ @Alchemy

Paymasters (Gas Abstraction)

Paymasters sponsor gas or accept ERC-20 tokens instead of ETH, one of the most important unlocks for smart account adoption. They enable:

• Gasless onboarding for new users

• Token-based gas payments

• Subscription-style fee models

Key players: @biconomy, @OpenZeppelin

Smart Account Frameworks

Reusable, audited smart account implementations so developers don't build from scratch.

Key players: @safe @zerodev_app @rhinestonewtf @candidelabs

Safe is the most battle-tested, securing billions in assets. ZeroDev's Kernel and Candide are optimised specifically for the ERC-4337 ecosystem, lightweight, modular, and developer-friendly.

Wallet & Consumer Layer

Where smart accounts finally meet end users.

Key players: @baseapp, @ready_co @MetaMask, @phantom, @TrustWallet

Coinbase has made ERC-4337 smart accounts the default for new users. Ready (Argent) pioneered smart account UX long before ERC-4337 existed. MetaMask, Phantom, and Trust Wallet are bringing smart account capabilities to tens of millions of existing users, without asking them to switch wallets.

The stack is maturing fast. What was a fragmented set of experiments two years ago is now a coherent infrastructure layer with clear separation of concerns, competitive markets at each level, and major consumer products driving smart account adoption at scale.

Smart accounts introduce powerful capabilities, but also new tradeoffs worth understanding clearly.

Smart contract risk. Smart accounts are more complex than keypairs. A bug in a validation module can be catastrophic at scale. Complexity invites exploits.

Module trust. A smart account is only as secure as its weakest installed module. Third-party modules require rigorous auditing, and users need to understand what they're actually installing into their account.

Bundler centralisation. If a handful of bundlers dominate transaction processing, censorship becomes possible. This mirrors the MEV centralisation risk in block building and deserves the same level of scrutiny.

EIP-7702 delegation risk. An EOA that delegates to malicious code, even for a single transaction, can be drained. The security model shifts from don't lose your key to don't sign malicious delegation requests. That's a subtler threat and harder to communicate to everyday users.

UX vs. self-sovereignty. Abstracting key management makes smart accounts easier to use. But if the underlying keys are custodied by a wallet provider, users may be trading self-sovereignty for convenience without fully realising it.

None of these is a dealbreaker. They're the expected friction of a maturing technology, and the ecosystem is actively working through each of them.

But they're worth understanding clearly as smart accounts move from early adopters to mainstream defaults.

Ethereum is replacing a rigid, one-size-fits-all EOA model with Smart Accounts. This alternative is programmable, recoverable, and composable, built to match how people actually want to use and manage money.

For developers, Smart Accounts are a new primitive to build on. For users, they are the foundation for a version of crypto that is finally safe and simple enough for everyone.

The shift from EOAs to Smart Accounts may be the most consequential UX change in Ethereum's history.

And smart account adoption is just getting started.