Smart-Account Wallets in 2026: Inside the Module Economy

For most of crypto’s history, a wallet was a keypair. One private key signed everything, and the account itself held no logic: it could not batch two actions into one, could not cap a daily spend, could not survive a lost key. In 2026 that picture has flipped. The fastest-growing wallets on Ethereum and its layer-2 networks are smart accounts, programmable contracts that hold your funds and decide, in code, what counts as a valid transaction. The most important shift of the year is not that these accounts exist. It is how they are built. A smart-account wallet is no longer a single frozen contract shipped by one vendor. It is a minimal base account that you install capabilities onto, the way you install apps on a phone.

That change has a name in the standards world, ERC-7579, and a growing marketplace behind it. It also has real numbers. The dashboard BundleBear counts more than 1.26 billion ERC-4337 UserOperations and over 65 million active smart accounts, with close to $14 million in gas already covered by paymasters. Separately, EIP-7702, the Pectra upgrade that lets an ordinary address behave like a smart account, now shows more than 54 million live delegations. With ETH trading around $2,450 in early September, according to Fortune, the money at stake in these accounts is not theoretical. This guide explains what a smart-account wallet is, the three roads to becoming one, and the module economy that is quietly rewiring how wallets, exchanges, and games handle your keys.

What a smart-account wallet actually is

Ethereum has always had two kinds of account. An externally owned account, or EOA, is controlled by a private key; it is what MetaMask, a hardware wallet, or an exchange withdrawal address has traditionally been. A contract account is code deployed on-chain. A smart-account wallet is simply a contract account used as your primary wallet, so that its code runs on every transaction and gets to decide whether that transaction is allowed.

The single move that matters is this: validation becomes programmable. An EOA has exactly one rule baked into the protocol, namely that a transaction must carry one valid ECDSA signature from the one key that owns the address. A smart account replaces that fixed rule with logic you choose. It can require two of three signers. It can accept a passkey generated by your phone. It can honor a temporary session key that is valid for one hour and only for one game. It can let a third party pay the gas. Everything people mean by account abstraction flows from that one idea: stop assuming an account equals a single keypair, and let the account define its own rules.

Once validation is code, so is behavior. A smart account can batch an approval and a swap into one atomic transaction that either fully succeeds or fully reverts. It can enforce a spending limit. It can rotate its signing key without changing its address. It can be recovered by guardians instead of a paper phrase. None of this is magic; it is just a contract holding your money and running rules you agreed to. The question that defines 2026 is where those rules come from, and increasingly the answer is: from modules you install.

The three roads to a smart account

There is no single way to get a smart account, and the differences matter for cost, custody, and risk. The first road is ERC-4337’s underlying pattern, finalized in March 2023, which builds account abstraction at the application layer without changing Ethereum’s consensus rules. Special messages called UserOperations travel through a separate mempool, operators called bundlers package them into ordinary transactions, a shared EntryPoint contract verifies and executes them, and an optional paymaster can cover the gas. The EntryPoint has moved through versions 0.6, 0.7, and 0.8, with 0.8 adding native support for the second road, per the eth-infinitism releases. Safe, Coinbase’s Base Account, ZeroDev, and Biconomy all run on this pattern.

The second road is EIP-7702, which shipped in the Pectra hard fork on 7 May 2025. It introduces a set-code transaction, type 0x04, that lets an existing EOA point to contract code through a short on-chain delegation designator (the prefix 0xef0100 followed by a 20-byte address). Your everyday address gains smart-account powers in place, without moving funds or generating a new address, and the delegation is revocable by pointing back to the null address. It is the cheapest path to smart-account features for the hundreds of millions of EOAs already in the wild, which is why our deeper look at EIP-7702 across wallets and exchanges treats it as the bridge that stuck.

The third road is native account abstraction, where the protocol itself understands smart accounts, so there is no side mempool and no external bundler. That road is not open on mainnet yet, but two concrete proposals are being built and tested, and we return to them at the end. The table below sets the four models side by side.

The modular turn: from monolith to platform

Here is the shift that separates a 2026 smart-account wallet from its predecessors. The first generation of smart-contract wallets, from Argent in 2017 through the early Safe and the first ERC-4337 accounts, were monoliths. Each vendor shipped a fixed bundle of features hard-coded into the contract. If you wanted a capability the contract did not ship with, you were stuck: you migrated to a new contract or waited for the vendor to redeploy. The account was a sealed appliance.

The modular architecture inverts that. ERC-7579, titled Minimal Modular Smart Accounts and finalized in 2024, defines a tiny base account that does almost nothing on its own, plus a standard interface for plugging in modules that provide every real capability. Its authors came from across the ecosystem: Konrad Kopp of Rhinestone, Taek Lee of ZeroDev, Fil Makarov of Biconomy, along with Zeroknots and Elim Poon. The base account exposes three functions that tell the whole story: installModule, uninstallModule, and isModuleInstalled. The mental model is an operating system. The base account is the kernel; modules are the apps.

Why does this matter beyond engineering elegance? Because capabilities become portable and reusable. A session-key module audited once can be installed on any account that speaks the standard. A spending-limit hook written by one team can protect wallets built by another. As the standard’s explainers put it, once a module is written and audited, any account that adopts the standard can inherit it without further work, according to Eco. That is the seed of a marketplace, and a marketplace is exactly what formed.

The four kinds of module

ERC-7579 sorts every capability into four module types, and understanding them is the fastest way to understand what a modern smart account can and cannot do. Validators decide whether a transaction is authorized: this is where a single ECDSA key, a multisig, a passkey, or a session key lives. Executors act on the account after validation, through a separate execution path, so that pre-agreed logic like dollar-cost averaging, scheduled transfers, auto-savings, or an emergency withdrawal can move funds under set rules without a fresh signature each time.

Fallback handlers teach the account to answer function calls it does not natively support, such as ERC-1271 signature checks or the receiver hooks for ERC-721 and ERC-1155 tokens, without redeploying the whole contract. Hooks run before and after every transaction to enforce policy: spending limits, address whitelists, rate limiters, and transaction guards all fit this slot. The four types compose. A single account might carry a passkey validator, a session-key validator, an auto-savings executor, and a daily-limit hook at the same time, each one an independent piece of code you chose to install.

The standards war: ERC-7579 vs ERC-6900

Modularity has two competing rulebooks, and the choice between them shapes the whole market. ERC-7579 is the minimal camp: it standardizes the small set of functions above, leaves storage layout largely to the account, and lets implementers add opinion on top. It has become the de facto winner, adopted by Safe through the Safe7579 adapter, by ZeroDev’s Kernel, by Biconomy’s Nexus, by an OpenZeppelin preset, by Trust Wallet, and backed by Rhinestone and OKX. The rival is ERC-6900, championed by Alchemy, whose specification runs roughly three times longer. ERC-6900 is more prescriptive: it mandates ERC-7201 storage namespacing, splits validation more strictly, and builds richer permission graphs.

The practical catch is that modules do not cross the line. A module built for ERC-7579 will not simply drop into an ERC-6900 account, and vice versa. So the standard a wallet chooses is a lock-in decision for developers and, indirectly, for users. The heavier standard promises tighter guardrails; the minimal one promises reach and a bigger module library. In 2026 the momentum sits with the minimal camp, but the debate is really about how much safety to hard-code into the base account versus how much to leave to the modules and the humans installing them.

The registry: who vouches for the code you install

Installing third-party code into the contract that holds your money is the obvious hazard in this whole design. If a module can validate transactions or move funds, a malicious or buggy module is a direct path to a drained wallet. The ecosystem’s answer is a registry plus attestations. Rhinestone runs a module registry tracking roughly 40 reusable modules as of early 2026, split into a community tier of unaudited code and an audited tier carrying attestations from firms such as Spearbit, ChainSecurity, OpenZeppelin, and Trail of Bits, according to Eco.

The mechanism behind that is ERC-7484, a registry-query standard that lets an account refuse to install any module that does not carry an attestation from an auditor the account trusts. In effect, the account checks the module’s references before letting it in. Biconomy and Rhinestone leaned into the analogy directly, launching a Module Store billed as the first app store for account abstraction, per Rhinestone. On the tooling side, ModuleKit lets a single module be tested against Safe, Kernel, and Nexus in one suite, and the Safe7579 adapter ships with more than a dozen audited modules including social recovery and a dead-man switch, per the Safe documentation. Like any app store, the value is not just distribution; it is review. And as with any app store, the weakest link is a user who installs something shiny without reading what it can do.

Portability and lock-in: the ERC-7779 problem

The flip side of an app store is the question every phone owner eventually asks: can I switch? If your wallet provider disappears, or you simply want to move to a different one, can you carry your account with its modules and history intact? For upgraded EOAs, the danger is concrete. Redelegating a 7702 address to a new provider can collide with storage that the old provider wrote, which in the worst case can brick the account or leave stale state that a later module misreads.

The emerging fix is ERC-7779, a standard for interoperable delegated accounts that defines how a wallet declares its storage bases and how it hands off cleanly during a provider migration, so a switch does not lose assets or clobber state. It is a collaboration among the Ethereum Foundation, Trust Wallet, Safe, Alchemy, and Rhinestone, and it is the plumbing that keeps modularity from turning into a new form of vendor capture. Portability is also the argument driving the next chapter. WalletConnect founder Pedro Gomes, after months working on a rival native-AA design, wrote that he is “convinced EIP-8130 is the better path for native account abstraction,” calling it “simpler, more portable, and focused on what wallets actually need.” Portable is the operative word.

What modules actually let you do

Strip away the standards and the payoff is a set of features that make crypto feel less like defusing a bomb. Gasless transactions come from a paymaster covering the fee, or letting you pay it in a stablecoin. Batching lets an approve and a swap happen atomically, so a half-finished sequence cannot leave you exposed. Session keys let you sign once and then act within limits, a scoped temporary key that can transact only for a set time, only with certain contracts, and only up to a certain value. That is what gives on-chain games console-grade responsiveness, and it is also how autonomous agents are meant to transact under a leash rather than with the keys to everything, a design whose stakes our autopsy of a dead AI crypto fund made painfully clear.

Passkeys are the module that may matter most to ordinary users. A validator can check a WebAuthn signature produced by the secure enclave in your phone, so the thing that authorizes a transaction is a fingerprint or a face rather than a seed phrase. That was prohibitively expensive on Ethereum until RIP-7212 added a precompile for the P-256 curve that phones use, cutting verification from roughly 300,000 gas to about 3,450. Social recovery, spending limits, automated savings, and subscription-style payments round out the list. The point of modularity is that each of these is a separate installable piece, so a wallet can offer them without becoming a bloated monolith, and you can add only what you want.

Who pays: paymasters and gasless economics

Gasless is a billing decision, not a free lunch. There are three ways to arrange it. In sponsorship, an app eats the gas as a cost of acquiring users. In the ERC-20 model, the user pays the fee in a token like USDC or USDT, usually with a markup of five to fifteen percent to cover conversion and price drift. In verifying mode, an off-chain signer approves each request against whatever rules the sponsor sets. Circle’s paymaster, for instance, lets users pay gas in USDC on Arbitrum and Base and takes roughly a ten percent surcharge.

The economics push almost all of this onto layer-2 networks. A sponsored operation on Ethereum mainnet can cost several dollars, while the same operation on Base, Arbitrum, or Polygon often costs a cent or two, according to Eco. That is why the nearly $14 million in paymaster gas that BundleBear has tracked is concentrated on L2s. It also concentrates the infrastructure: a small number of bundler and paymaster operators, led by Pimlico and Alchemy, handle a large share of all UserOperations. That concentration is a soft point that the native-AA proposals explicitly aim to remove, by letting ordinary nodes handle smart accounts directly instead of routing them through a handful of relays.

The wallets and platforms running on modules

The abstract standards land in real products, and most of the wallets a 2026 user touches are modular under the hood even when the interface hides it. Safe remains the institutional and DAO standard, custodying more than $27 billion in assets and adopting ERC-7579 through its adapter, per The Block. Coinbase’s Base Account pairs ERC-4337 with passkeys and a universal Sign in with Base flow. MetaMask Smart Accounts reach tens of millions of monthly users through the EIP-7702 upgrade path. ZeroDev’s Kernel and Biconomy’s Nexus are among the most-deployed modular bases for builders, and Ambire and Ready, the former Argent, were early movers on in-wallet smart accounts.

The other front is embedded and invisible wallets, where the smart account is buried inside a consumer app. Coinbase’s Developer Platform shipped embedded wallets to general availability in October 2025, keeping keys in a secure enclave the company says it cannot access, per Coinbase. Stripe acquired the embedded-wallet startup Privy in June 2025, folding tens of millions of accounts into a stack that already included stablecoins and fiat rails, as CoinDesk reported. The table below maps the field.

The new attack surface

Modularity is power, and power is attack surface. When validation and execution live in installable code, the ways to lose funds multiply, and 2026 has the scars to prove it. The largest crypto theft ever, the roughly $1.5 billion Bybit hack of 21 February 2025, drained a cold wallet that was a Safe smart account. It was not a contract bug. The Lazarus Group compromised a Safe developer machine and injected malicious JavaScript into the signing interface, so the signers saw a routine transfer while actually approving a transaction that swapped the account’s implementation to attacker-controlled code, per NCC Group and the security experts The Block canvassed. The failure was blind signing: a hardware wallet showed a hash, not the meaning.

Ledger’s chief technology officer, Charles Guillemet, frames blind signing as the core danger, asking whether a user is “claiming an airdrop, or giving a malicious contract permission to drain your wallet?” The upgrade road had its own scare when Wintermute found that more than 97 percent of early EIP-7702 delegations pointed at copy-pasted sweeper bytecode, though it turned out to be unprofitable and was not a flaw in the standard, per CoinDesk. MetaMask security researcher Taylor Monahan put the deeper truth plainly: “It’s not actually a 7702 issue, its the same issue crypto has had since day one: end users struggle to secure their private keys.”

The reassuring counterpoint is that overall phishing losses fell sharply, down about 83 percent in 2025 to roughly $84 million as reported by Cointelegraph, even as batch-signature and Permit2 tricks grew more sophisticated and one 7702 phishing victim lost $1.54 million in a single transaction. The defenses that matter are structural: clear signing so wallets show what a transaction actually does, which the Ethereum Foundation formalized as ERC-7730 and the principle it calls what you see is what you sign, per the Foundation blog; registry attestations so you install reviewed modules; and transaction simulation before you approve. When those fail and funds move, the after-the-hack economics take over, which is the territory of our look at recovery bounties.

Where US regulators land

A pure smart-account wallet is software you control, not a service that holds your money, and US regulators have started to treat it that way. In April 2026, the SEC’s staff said that neutral software letting users transact from self-hosted wallets is not acting as a broker, as long as it does not solicit, route orders, or take custody, according to CoinDesk. That keeps a genuine self-custody smart account outside broker-dealer registration, and it is the clearest signal yet that writing wallet code is not the same as running an exchange.

The grey zone is everything that blends custody with convenience. When a provider holds a key share through multiparty computation, runs a recovery service, or sponsors your gas through a paymaster, the self-custody line blurs, and questions about custody rules and anti-money-laundering obligations resurface. Embedded wallets sit right on that seam, which is why the debate over whether they are really self-custody overlaps with the harder question we asked in whether crypto KYC and AML actually work. Outside the US, the EU’s MiCA regime covers custodial crypto-asset service providers rather than self-custody protocol code, and the same custody-versus-convenience seam applies there.

Taxes do not care which account model you use. A swap is a taxable event whether it runs through an EOA or a modular smart account, and gas paid in a stablecoin can itself be a small taxable disposal, so a smart account that transacts constantly can generate a long trail of reportable events. US users face Form 1099-DA reporting alongside state-level differences that our guide to crypto taxes by state lays out. The wallet got smarter; the tax form did not.

What comes next: native AA and the module future

The endgame is native account abstraction, where the protocol understands smart accounts so deeply that bundlers and side mempools become unnecessary. Two proposals are in active development. EIP-8130, authored by Coinbase and Base engineer Chris Hunter, takes an account-configuration approach: a fixed set of authenticators (secp256k1, P-256, WebAuthn, and delegation) recorded in an on-chain keystore, with a dedicated transaction type. Its measured wins are large, cutting a native USDC transfer from about 125,000 gas to 46,000, a 63 percent reduction, according to Crypto Briefing. It is live on Base’s Vibenet devnet and was aimed at the Cobalt upgrade, though no finalized mainnet date has been set.

The other proposal is EIP-8141, from Vitalik Buterin and others, which uses frame transactions to allow arbitrary validation logic and native token-paid gas. Buterin has described it as an omnibus that “wraps up and solves every remaining problem that AA was intended to address,” and said “this all looks possible to make happen within a year,” targeting a future fork he calls Hegota. The two designs represent the same tension as the standards war: a fixed, portable configuration versus maximum flexibility. It is early either way. When EIP-7702 was proposed, Ethereum core developer Marius van der Wijden cautioned it was “still a very early proposal, so we need to evaluate all the rough edges,” a caution that applies just as much to the native designs now in review.

Crucially, native AA does not kill the module economy; it deepens it. The base account gets simpler because the protocol handles the plumbing, but the capabilities users care about still arrive as ERC-7579 modules layered on top, and ERC-7779 governs how they migrate. The direction of travel is a thin, standardized foundation carrying a thick, competitive market of installable features. The wallet becomes a platform, and the platform keeps its apps.

The bottom line

The smart-account wallet of 2026 is not a product so much as a platform. Underneath the passkeys and the gasless swaps, your account is a base contract running installable, ideally audited, increasingly portable modules that decide who can sign, what runs automatically, and where the guardrails sit. The keypair still matters, as Monahan’s point about securing private keys makes clear, but it is now one component in a larger system rather than the whole story.

For users, the practical advice follows from the architecture: prefer wallets whose modules carry attestations, insist on clear signing so you can read what you approve, and treat any request to install a new module the way you would treat installing an app with full permissions. For builders, two choices dominate: the standard you pick, ERC-7579 or ERC-6900, is a lock-in decision, and the registry you trust is a security decision. Get those right and the module economy delivers what account abstraction promised for a decade, a wallet that is finally programmable, without pretending the risks disappeared.

Frequently Asked Questions

What is a smart-account wallet?

A smart-account wallet is one whose account is a programmable contract that decides in code what counts as a valid transaction, instead of relying on a plain keypair. That lets it batch actions into one transaction, pay gas in tokens, sign with passkeys, and recover from a lost key, none of which an ordinary externally owned account can do.

What is the difference between ERC-4337 and EIP-7702?

ERC-4337 is application-layer account abstraction that uses a separate mempool, bundlers, a shared EntryPoint contract, and optional paymasters; a 4337 account is a new contract with a new address. EIP-7702 lets your existing address point to contract code so it gains smart-account powers in place, with no new address. They are complementary rather than rivals.

What are ERC-7579 modules?

ERC-7579 modules are standardized plug-ins for a smart account. Validators decide who can sign, executors run automated actions, fallback handlers add support for extra interfaces, and hooks enforce policies such as spending limits. You install and remove them like apps, and a registry of attestations helps you tell audited modules from unreviewed ones.

Are smart-account wallets safe?

The account model itself is sound, but installable code is a larger attack surface than a plain keypair. Most losses come from blind signing and phishing rather than protocol bugs; the Bybit hack drained a Safe smart account through a compromised interface, not a contract flaw. Using clear signing and audited, attested modules removes most of the avoidable risk.

Do I pay taxes differently with a smart-account wallet?

No. The account type does not change tax treatment. A swap is taxable whether it runs through an EOA or a smart account, and gas paid in a stablecoin can be a taxable disposal. US users still face Form 1099-DA reporting and state-level rules, so a smart account that transacts often can create more reportable events, not fewer.

Yuki Tanaka is a senior editor at HOGE Wire covering wallets, account abstraction, and on-chain infrastructure.