EOA vs Smart Account: The Differences That Matter

If you have used a crypto wallet, you have used an account. But not all accounts on Ethereum are the same. There are two fundamentally different kinds, and the difference shapes almost everything about how your wallet behaves: how you sign, who can authorize a payment, how you recover access, who pays the fee, and in which token.

This article walks through the two account types — the externally owned account (EOA) and the smart account — and compares them across the axes a self-custody user actually feels day to day. It is the second article in our account abstraction series; if you have not read Account Abstraction from First Principles, that is a good place to start. Here we zoom in on the EOA vs smart account distinction specifically.

What is an EOA?

An externally owned account is the original Ethereum account. It is defined by exactly one secp256k1 keypair: a private key and the public key derived from it. The address you see — the 0x... string — is derived from that public key. Whoever holds the private key controls the account, full stop.

That single key does all the work. It signs every transaction with an ECDSA signature. There is no code attached to the account, no rules, no conditions. The network's only question when a transaction arrives is: "Is this signature valid for this address?" If yes, the transaction executes.

Most browser-extension wallets you have encountered — the MetaMask-style single-key model — create EOAs. One seed phrase derives the key, the key controls the account, and protecting that seed phrase is the entire security model. It is simple, well understood, and has worked for a decade. It is also rigid: one key, one signer, one signature scheme, and if that key leaks, the account is gone.

What is a smart account?

A smart account is a contract account: an account whose behavior is defined by deployed code rather than by a single key. Instead of "is this one ECDSA signature valid," the account runs its own validation logic to decide whether to accept an operation. That logic is programmable.

Because the rules live in code, a smart account can require two signatures instead of one, accept signature schemes other than plain ECDSA, enforce spending limits, or define a recovery path — whatever its contract specifies. The Safe-style smart-contract wallets are a well-known example of this model. On Ethereum and other EVM chains, the standard that lets these accounts behave like first-class accounts without changing the protocol is ERC-4337.

Control: one key versus custom rules

This is the headline difference. An EOA has exactly one rule baked into the protocol: one valid ECDSA signature from one key authorizes everything. There is no way to add a second required approver or to say "amounts above this threshold need extra confirmation." The key is the account.

A smart account decides for itself. It can require a multisig quorum, gate certain actions, or layer in session keys. SSP uses this to deliver a 2-of-2 multisig: one key lives in the SSP Wallet browser extension, the second in the SSP Key mobile app, and the account's validation logic requires both to approve before any transaction is accepted. A leaked browser extension alone cannot move funds, because the contract simply will not accept a single-key authorization.

Recovery: what happens when a key is lost

With an EOA, the key is the account. Lose the seed phrase and the account is unrecoverable; leak it and an attacker has full control. There is no built-in remedy because there is no logic to appeal to — only the one key matters.

A smart account can define recovery as part of its rules. Because validation is programmable, a contract can specify alternative authorization paths, designated recovery parties, or time-delayed key rotation. SSP's specific model is a 2-of-2: losing access to either device does not hand an attacker your funds, because both signatures are always required. The practical effect is that no single device is a single point of failure.

Who pays gas, and in what token

An EOA pays for its own transactions, and it pays in the chain's native coin. To move an ERC-20 token on Ethereum, the EOA still needs ETH to cover gas. If your account holds tokens but no ETH, you are stuck — a common and frustrating beginner experience.

A smart account can break that link. Under ERC-4337, a component called a paymaster can sponsor the gas for an operation, or accept payment in a token other than the native coin. The fee can be covered by a third party, or paid in the same token you are already moving. We cover this in detail in Gas Sponsorship and Paymasters Explained; the point here is that "who pays, and in what" stops being fixed.

Batching multiple actions

With an EOA, each transaction is a separate, individually signed operation. The classic ERC-20 pattern — approve a contract to spend your tokens, then call the contract — is two transactions, two signatures, two gas payments, in sequence.

A smart account can batch several actions into a single operation that either fully succeeds or fully reverts. Approve-and-swap becomes one step. This is partly convenience and partly safety: there is no half-finished state where you have granted an approval but the follow-up action never happened.

Signature schemes

An EOA verifies one thing: an ECDSA signature over secp256k1. That is the only scheme the protocol checks for externally owned accounts, and it cannot be changed.

A smart account verifies whatever its code is written to verify. It can check multiple signatures, exotic curves, or aggregated signatures. SSP's EVM accounts verify a Schnorr-aggregated signature: the two partial signatures from the browser extension and the mobile app combine — MuSig2-style over secp256k1 — into a single on-chain signature the contract validates. The chain sees one signature; the security model behind it is two independent approvers. This is something an EOA structurally cannot do.

Deployment and addresses

An EOA exists the moment a key exists. Generate a keypair offline and the corresponding address is already valid; it costs nothing and touches no contract. The account simply is.

A smart account is a contract, so it must be deployed on-chain before it can hold code-defined behavior. In practice, ERC-4337 wallets use a deterministic, counterfactual address: the address is computed in advance from the account's parameters, so it can receive funds before the contract is actually deployed, and deployment happens on first use. You can share your address and get paid before any deployment transaction lands.

Cost: the honest trade-off

Programmability is not free. Because a smart account runs validation logic in a contract, its operations cost somewhat more gas than a plain EOA transfer, which is about as cheap as Ethereum transactions get. Deploying the account the first time also has a one-time cost.

For most self-custody users this is a reasonable price for two-key security, recovery options, batching, and flexible gas. But it is a real difference, and worth naming plainly rather than glossing over.

What SSP uses, and when each model makes sense

To state it directly: SSP uses a smart account via ERC-4337 to deliver its 2-of-2 multisig on EVM chains — Ethereum, Polygon, Base, BNB Smart Chain, and Avalanche. The contract requires a Schnorr-aggregated signature built from both your devices, and SSP's EVM implementation was audited by Halborn in 2025. To see how the pieces fit together, read the SSP account abstraction architecture, and for chain-specific detail see Ethereum in SSP.

So when does each model make sense? An EOA is the simplest possible account: cheapest gas, instant existence, no deployment. For a single-user, single-key setup where simplicity is the priority, it is perfectly serviceable. A smart account makes sense when you want properties a single key cannot give you — multiple required approvers, recovery logic, batching, sponsored or token-denominated gas. The trade-off is modestly higher gas and the concept of deployment.

For a self-custodial wallet whose entire premise is that no single key should be a single point of failure, the smart account is the natural fit. That is why SSP is built on one. To go deeper on the Ethereum account model itself, the Ethereum accounts documentation is the authoritative reference, and the ERC-4337 specification is the standard that makes smart accounts practical today.