Web3 Account Concept Guide: Navigating Wallet Usage Without Getting Lost
TechFlow Selected TechFlow Selected
Web3 Account Concept Guide: Navigating Wallet Usage Without Getting Lost
What do the several terms introduced at the recently concluded Devcon represent?
Navigating Web3 tides with focused insights
Author: Zhixian, Founder of UniPass
At the recently concluded Devcon, account abstraction was one of the hottest topics. Lately, you've probably seen abbreviations like AA / EOA / SCW / 4337 popping up frequently in talks, panels, and information feeds.
As narratives shift toward "onboarding the next billion users," new adjectives are increasingly being attached to products—terms like seedless, gasless, social recovery, and non-custodial.
If you're already feeling a bit overwhelmed after reading these two paragraphs, let me do my best to clarify what all these terms actually mean.
Note before reading: This article is not a rigorous technical document. I may use imprecise but easily understandable language or analogies. Feel free to use this as a starting point for deeper exploration into the technical details.
EOA - Externally Owned Accounts
EOA stands for Externally Owned Account. The most familiar example is the address generated by MetaMask, which is an EOA. Its defining feature is simplicity in design. For instance, its generation rule follows:
This process is purely mathematical with no internal structure or logic within the resulting address. When nodes verify whether a transaction has been authorized by the owner of an address, they follow a fixed procedure:
If the comparison matches, signature verification passes and the transaction proceeds; otherwise, it's rejected and not broadcast further.
Another key aspect of EOAs is that they initiate transactions and pay gas fees. In contrast, CA (Contract Accounts) can only be invoked by other CAs or EOAs. Thus, EOAs act as triggers—every transaction, regardless of how many subsequent contract calls occur, must originate from an EOA and include sufficient gas payment.
It should be noted that EOAs are specific to Ethereum and other EVM-compatible (or EVM-like) blockchains. Strictly speaking, major non-EVM chains including Bitcoin do not have this concept.
CA - Contract Accounts
CA stands for Contract Account (also formerly known as Internal Account). You’ve likely encountered ERC-20 token contracts, DeFi application contracts, etc., each having an address that looks very similar to an EOA—that’s a CA.
By design, CAs are native entities in the Ethereum ecosystem. EOAs and ETH serve as triggers and fuel for CA-based business logic. In practice, all assets on Ethereum except ETH itself are managed by CAs, and all DeFi operations are implemented entirely through them. However, the limitation that CAs cannot initiate actions or pay gas themselves restricts their capabilities. As early as 2016, there were proposals aiming to allow CAs to pay their own gas.
In short, CAs are Ethereum accounts with internal logic. This logic can represent either business functions (e.g., token contracts for accounting, staking contracts for lending and liquidation) or account management features (such as multi-signature logic in Gnosis Safe)—the latter being what we refer to as the upcoming concept of “SCW – Smart Contract Wallet.”
CA addresses are deterministically computed using CREATE or CREATE2 methods (details omitted here). Importantly, CAs don’t necessarily correspond to public keys. For example, a Gnosis Safe CA can set multiple public keys to control access to its assets. Alternatively, some CAs may not rely on any cryptographic keys at all—access could instead be governed by logic in another CA. For instance, in a DeFi lending contract, repaying debt allows retrieval of collateralized assets.
SCW/A - Smart Contract Wallet/Account
Smart Contract Wallet is perhaps the most self-explanatory term—it refers to wallet solutions where the user’s account is implemented as a CA, rather than using the public-key-derived address used in traditional EOA wallets.
Thanks to their programmable nature, smart contract wallets enable functionalities impossible with EOAs, such as gas sponsorship, batched transactions, permission controls, offline authorizations, and social recovery.
Here are a few examples illustrating the extensibility of smart contract wallets:
-
Gnosis Safe uses a smart contract wallet architecture to implement multi-signature logic;
-
Users can send different tokens to multiple recipients in a single on-chain transaction, or combine approve and swap steps in Uniswap within one transaction—granting only necessary approvals and avoiding security risks from over-authorization.
-
Users can define varying levels of access permissions across assets—for example, setting higher transfer thresholds for profile pictures (PFPs) compared to standard ERC-20 tokens (e.g., requiring a hardware-wallet-held admin key). This balances convenience and security, protecting high-value assets even if everyday keys are compromised.
-
Users can sign an off-chain authorization stating “whoever sends me 100 ETH can transfer my BAYC,” enabling peer-to-peer atomic trades without granting third-party contracts permanent access.
AA - Account Abstraction
Account Abstraction isn't a new idea—it traces back to discussions in 2015 when Vitalik suggested making Ethereum’s transaction verification cryptography pluggable, for example replacing ECDSA with more efficient algorithms like ed25519 (see here). Over the past seven years, Vitalik and the Ethereum Foundation have continued exploring various account abstraction approaches. This curated link tree offers a helpful historical overview.
So what does account abstraction mean? Let's quote the stated goal from ERC-4337:
Achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require)
Clearly, Ethereum aims to shift away from the current dominance of EOAs, encouraging adoption of SCWs while eliminating ecosystem reliance on EOAs. Beyond EIP-3074, there’s also the more radical and long-term EIP-5003. Here are a few excerpts (abridged):
EOAs … are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one’s own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.
…This EIP provides a path not to enshrine EOAs, but to provide a migration path off of them, once and for all.
It's clear that EIP-5003 aims to permanently migrate all EOAs to CAs, enabling universal use of SCWs and fully resolving backward compatibility issues. (Now that you understand the terminology, these acronyms probably make more sense, right?)
By now, you should have a good grasp of AA’s origins and future direction. But it's important to note that AA is not exclusive to Ethereum or EVM chains—many blockchains natively support varying degrees of account abstraction.
For example, EOS, Polkadot, Near, Solana, Flow, Aptos—even Bitcoin (single sig, multi-sig, Taproot)—were designed with structured accounts featuring built-in permission systems. Others like StarkNet and CKB offer even more advanced account abstraction capabilities.
You might now realize that Ethereum’s AA effort addresses the legacy burden caused by the accidental popularity of EOAs, aiming to make the account layer more advanced and flexible.
4337 - ERC-4337
From the discussion above, it's evident that ERC-4337 is just one of several proposals in the AA space. But why does everyone mention it when talking about AA or SCWs? Let's look at the document's subtitle:
An account abstraction proposal which completely avoids consensus-layer protocol changes, instead relying on higher-layer infrastructure.
In other words, ERC-4337 marks a pivotal shift in AA strategy—from “revolution” to “evolution”—abandoning consensus-layer modifications in favor of user-layer solutions based on SCWs. To improve interoperability, ERC-4337 defines standard interfaces that SCWs should implement, along with frameworks for meta-transactions, gas sponsorship, and related infrastructure.
Its emergence enables diverse SCW implementations to share a consistent user interface and leverage common open infrastructures, accelerating deployment across various use cases.
Additionally, ERC-4337 promotes broader ecosystem readiness for SCWs—such as supporting EIP-1271 for signature validation and revisiting rules in certain DeFi protocols that currently block interactions from contract accounts.
Seedless
Here, “seed” refers to seed phrase—the mnemonic backup often required when creating a wallet. So “seedless” means "no seed phrase needed," or alternatively, "no private key exposure." Note that “no” doesn’t literally mean no cryptographic keys exist, but rather that users aren’t required to back up or even be aware of seed phrases/private keys.
A common concern: If users don’t back up their seed phrase, do they lose control of their account? What happens when switching devices?
Indeed, simply removing seed backup functionality would be poor product design. True seedless aims for users to not *need* to know about seeds, while still retaining full control over their account.
That is, only the user (and no one else) can independently recover account access on a new device—without relying on seed phrases, which are UX-hostile and overly technical. Social recovery, discussed next, is a prime example of such an approach.
Gasless
Here, “gas” refers to gas fees, so “gasless” means "no upfront gas fee payment." Again, this doesn’t mean gas isn’t paid—it means users aren’t forced to understand gas mechanics or pre-purchase native tokens to cover costs.
Who pays the gas? Two main scenarios:
-
When users already hold crypto assets—like play-to-earn tokens, airdrops, or transfers—if those tokens have value and liquidity, relayers may accept them as payment to sponsor gas and earn profit.
-
When users have no valuable tokens (e.g., newly created accounts), apps may subsidize limited-purpose gas to help bootstrap usage, reducing churn. Even with subsidy costs, overall user acquisition cost may be lower. Alternatively, users could watch ads or complete tasks to earn gas credits.
Both strategies work particularly well on L2s with low gas costs.
Social Recovery
Social recovery refers to mechanisms that use social relationships to help users regain account access after losing their keys. If you've ever logged into a new device via WeChat and saw a prompt like “ask two friends to send XXX to your account to log in,” that’s exactly the experience social recovery seeks to replicate—except replacing WeChat with a smart contract as the verifier.
A common misconception is calling wallet login schemes based on social media accounts “social recovery”—this wrongly equates “social relationships” with “social platform accounts.” Established SCW Argent includes built-in social recovery, requiring guardians to provide Ethereum addresses to sign during recovery. However, this assumes guardians are more proficient in managing Ethereum accounts than the user. If a guardian loses access, the user’s account may become unrecoverable. A more robust approach involves leveraging real-world cryptographic tools—like email DKIM signatures or digital passports—to enhance reliability and accessibility of social recovery.
Non-custodial
Non-custodial is arguably one of the most politically correct—and misused—concepts in crypto, as definitions vary widely among projects. Here’s our take, defined by two core principles:
-
Wallet developers cannot unilaterally operate user accounts
-
Wallet developers cannot prevent users from operating their own accounts
If you agree with both, you can classify any wallet as custodial, semi-custodial, or non-custodial using this test:
But does knowing this matter? Users may not care about technical distinctions—as long as it works! Fair point—I partly agree, especially given the industry hasn't reached a paradigm shift in user understanding. In fact, each model suits different contexts:
-
Custodial solutions – Ideal for exchanges, institutional finance, and highly regulated environments (e.g., Coinbase, Fireblocks). Typically serve fewer users with infrequent interactions but high per-user value, justifying expensive, high-security backend systems.
-
Semi-custodial solutions – Suitable for sophisticated individual users who understand that service providers may censor transactions and are capable of preparing backups (e.g., exporting private keys). They enjoy daily convenience and security while retaining asset safety during outages. Requires high operational standards from providers due to large user bases, frequent app interactions, and strict data availability needs—loss of server-side data could permanently lock out unbacked-up users.
-
Non-custodial solutions – Best for mass-market adoption. Counterintuitive at first, but from a cost perspective, only non-custodial models can deliver sufficient security and availability in low-margin scenarios. Applications targeting broad audiences must carefully evaluate whether custodial or semi-custodial alternatives can guarantee reliable service. Otherwise, insider threats, hacks, or force majeure events could compromise all users and potentially collapse the entire business. History repeatedly teaches us: security matters—protecting users ultimately protects yourself.
MPC - Multi-Party Computation
Multi-party computation (MPC) is often paired with zero-knowledge proofs (ZKP) as one of Web3’s two “magics”—once involved, seemingly impossible things suddenly become feasible. In some cases, this holds true: ZKPs trade probability for feasibility; MPC distributes control to achieve risk mitigation or disaster recovery.
MPC is actually a paradigm encompassing various technical implementations. In today’s Web3 context, it mostly refers to TSS.
TSS - Threshold Signature Scheme
Threshold Signature Scheme (TSS) is a distributed multi-party signing protocol involving algorithms for distributed key generation, signing, and re-sharing (updating private key shards without changing the public key).
An m-of-n TSS means one public key corresponds to n private key shards, where any m shards combined can produce a valid signature verifiable by the public key. This resembles multi-sig, differing mainly in public key count.
For example, a 2-of-2 multi-sig is like a door with two locks—both keys must turn simultaneously. A 2-of-2 TSS is like a door with one lock, but the key is split into two parts—both pieces must be used together to unlock. (Note: This analogy simplifies; actual TSS shards never physically reunite—they sign separately, then combine algorithmically for verification.)
Is TSS inherently custodial or non-custodial? Not necessarily—it depends on implementation choices. Non-custodial requires users to independently control their account, meaning they must possess at least the threshold number of shards (e.g., 2 out of 3). A 2-of-2 scheme cannot be truly non-custodial—best case is semi-custodial (e.g., ZenGo). But requiring users to manage more shards increases usability barriers, making mass adoption challenging.
Finally
By now, I believe I've covered most common Web3 account-related terms—around 5,000 Chinese characters worth. With so much content, errors and omissions are inevitable. Please feel free to point them out. If you spot issues or have different views, reach out to me directly on Twitter (@frank_lay2). I’ll keep everyone updated on revisions or additions via Twitter as well.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
