Account Abstraction Explained: Smart Accounts vs Seed-Phrase Wallets

Account abstraction (AA) makes a blockchain account programmable: instead of the protocol hard-coding the single rule "a valid signature from one private key moves the funds", the account is governed by contract code that defines its own conditions for accepting a transaction — multisig, social recovery, spending limits, batched actions, or letting a third party pay the gas. On Ethereum and other EVM chains it is implemented mainly through ERC-4337, which routes UserOperations through bundlers, a shared EntryPoint contract and optional paymasters without any protocol change; chains like zkSync Era and Starknet build AA in natively, and EIP-7702 lets an existing seed-phrase account adopt smart-account logic at its current address. Account abstraction does not by itself change custody — a smart account is still controlled by whoever holds its keys, and in a non-custodial wallet that is you. WATS applies the most practical part of it: the WATS Hot Wallet uses an ERC-4337 paymaster on EVM chains so network fees are paid in a single token, ATS, instead of each chain's native gas token, while staying fully non-custodial.

What "account abstraction" actually means

On most blockchains, "your account" is really just a keypair. Whoever holds the private key can move the funds, and the rules for validating a transaction are hard-coded into the protocol. Account abstraction changes that premise: it makes the account itself programmable, so the logic that decides whether a transaction is valid lives in code you control rather than in a fixed protocol rule.

Put simply, a traditional account asks one question — "is this signature valid for this key?" A smart account can ask any question you write: "are two of these three signers present?", "is this transaction under the daily limit?", "has the recovery timelock expired?" The account stops being a passive keypair and becomes a small programmable policy engine.

EOA vs smart account

On Ethereum today there are two kinds of accounts. An externally owned account (EOA) is controlled directly by a private key, usually derived from a seed phrase. There is no code behind it; the key is the account. A smart account (also called a contract account) is controlled by a deployed smart contract, and that contract defines how transactions are authorized.

The practical difference is flexibility. An EOA has exactly one security model — one key, one signature — and if you lose the seed phrase, the funds are gone. A smart account can implement multisig, social recovery, spending limits, session keys, or automatic upgrades, all without changing the underlying chain. For a deeper side-by-side, see the breakdown of smart accounts vs EOAs.

Why it matters: recovery, gas, batching, policies

Programmable accounts unlock several things seed-phrase wallets simply cannot do:

Recovery. Instead of a single fragile seed phrase, a smart account can nominate guardians or a recovery contract, so losing one device does not mean losing everything. Flexible gas payment. The account can let a third party — a paymaster — sponsor fees, or accept fees in a token other than the chain's native coin, which removes the need to keep a dust balance of ETH, POL, SOL and Toncoin just to move other assets. Batching. Multiple operations — approve and swap, or several transfers — can be bundled into one atomic transaction that either fully succeeds or fully reverts. Custom security policies. Daily limits, allowlists, time locks and session keys can be enforced by the account itself rather than trusted to an app or a browser extension.

How it is implemented: ERC-4337, native AA, and EIP-7702

There is no single way to do account abstraction. Three approaches dominate as of 2026.

ERC-4337 is the dominant standard on Ethereum and EVM chains, and it works without any protocol change. Users send "UserOperations" to a separate mempool; bundlers package them and submit them through a shared on-chain EntryPoint contract, while optional paymaster contracts handle who pays for gas. Crucially, ERC-4337 is an EVM-only standard — it does not run on Solana or TON. Those ecosystems achieve similar outcomes through their own fee-payer or relayer mechanisms that play the equivalent role.

Native account abstraction takes a different route: chains like zkSync Era and Starknet build AA directly into the protocol, so every account is a smart account by default and there is no EOA/contract split to bridge. EIP-7702, meanwhile, targets the existing base layer: it lets a regular EOA "set code" by pointing to smart-account logic, so a seed-phrase account can gain smart-account behavior (batching, sponsored gas, custom validation) at its existing address — the delegation persists until the account revokes or changes it, rather than lasting only a single transaction. Together these give the ecosystem a spectrum — retrofit standards, native support, and an upgrade path for the enormous installed base of EOAs already in use.

The trade-offs

Account abstraction is not free. Smart accounts execute contract logic on validation, so a transaction can cost more gas than a plain EOA transfer, and deploying the account contract adds an upfront step. ERC-4337 introduces new infrastructure — bundlers, paymasters, an alternative mempool — which means more moving parts and more surface area to reason about. Ecosystem maturity varies too: tooling, wallet support and standards are still converging as of 2026, and behavior can differ between a native-AA chain and an ERC-4337 deployment. For most users these costs are invisible, absorbed by wallet providers, but they are real engineering trade-offs rather than pure upside.

Custody: account abstraction is not custodial

A common misconception is that a "smart account" means someone else controls your money. Programmable validation says nothing about custody: the contract only encodes the rules a transaction must satisfy, and in a non-custodial wallet the keys that satisfy them are still yours. Sponsored gas is a good example — a paymaster can pay your transaction fee without ever being able to move your assets, because paying for gas and authorizing a transfer are separate powers.

Custody is about who can unilaterally move funds, and a well-designed smart account keeps that power with you. If you want the precise definition, the guide to non-custodial wallets lays out the distinction: non-custodial means you, and only you, hold the keys — whether the account is a bare EOA or a programmable smart account.

How WATS uses account abstraction

WATS applies the account-abstraction benefit that users feel every day — never juggling native gas tokens — while staying fully non-custodial: you hold your keys, and WATS never holds a key. In the WATS Hot Wallet, every action (transfers, swaps, staking) is charged in a single token, ATS, instead of the chain's native gas token — on EVM chains through an ERC-4337 paymaster, and on Solana and TON through the equivalent fee-payer or relayer role. Because ATS is a LayerZero OFT, one balance covers Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, and the ATS collected as fees is burned from a 100M supply toward a 30M floor — making WATS the first and only wallet to combine ERC-4337 + OFT single-token fees with that burn.

Two things are worth being precise about. Paying in ATS is not a discount: it changes which token pays the network fee, not the underlying cost of the transaction. And the paymaster never gains custody — it settles the fee, while only your keys can authorize a transfer. If the part of account abstraction you actually want is the ability to hold one asset, move it across eight chains and never be blocked by a missing gas token, the WATS Hot Wallet is a concrete place to see that model working end to end.