An ultimate guide to Web3 Wallets: Externally Owned Account and Smart Contract Wallet

An ultimate guide to Web3 Wallets: Externally Owned Account and Smart Contract Wallet

On this page

A Web3 Wallet, just like a traditional wallet, is a way to store the assets and interact seamlessly with dApps on various blockchain ecosystems. Unlike traditional wallets that store and manage fiats in a centralized manner, a web3 wallet embraces the decentralization at the core by providing full access of the wallet to the user.  

Why do we need a Web3 wallet? 

Digital signatures are a primary building block in the blockchain ecosystem used to authenticate the transactions on the network. For every transaction on the blockchain, the user has to prove the ownership to the network that they are allowed to perform the transaction. A digital signature typically consists of a public and private key, and a Web3 wallet at its core allows you to manage your private and public key pair. It allows you to sign the transaction using your private key and prove ownership to the network. 

Since the inception of Bitcoin Core in 2009, the first Web3 wallet, wallets have evolved and come a long way. They can be broadly categorized into Externally Owned Account and Smart Contract Wallet.

Externally Owned Account

The term “Externally Owned Account” (EOA) in context of Web3 wallets suggests that it’s an account owned by the user, external to the network. EOAs consist of public keypair, where the private key is only known to the user. This allows the user to maintain ownership and have full control over the account. The public key is used to obtain an EOA address. This address is visible to everyone on the network like 0x95…efe5 on Ethereum, G4Aog…pyKA on Solana and respectively for different networks. You must be wondering, why different blockchain ecosystems have different public addresses. The answer hides in the different elliptic curves also known as ECC - Elliptic Curve Cryptography. Elliptic Curve Cryptography is a mathematical algorithm which is core for secure key generation and encryption in the blockchain ecosystem.  

How is EOA address generated?

Step 1

To kick off the process a 256 bit number is generated, which serves as the private key. This key is essentially a large number and generated randomly. 

Step 2

Using elliptic curve cryptography, the corresponding public key is derived from the 256-bit private key. It's important to note that different blockchain ecosystems use different elliptic curves for this derivation. For instance, Ethereum utilizes secp256k1, while Solana opts for ed25519. 

Step 3

In this step, the derived public key undergoes hashing using a cryptographic hash function like Keccak-256 (also known as SHA-3). However, Solana diverges from Ethereum's method by directly utilizing the public key to generate the address, rather than hashing it. Thus, the public key itself serves as the Solana address.

Step 4

For Ethereum, the resulting hash is truncated, typically taking the last 160 bits to form what's known as the Ethereum Externally Owned Account (EOA) address. These 160 bits constitute the address.

Types of EOA Wallet  

There are a lot of EOA wallet providers including Metamask, Trust, Ledger and Rainbow, etc but they can be mainly categorized into Hardware wallets (aka Cold Wallets) and Software wallets (Hot Wallets).

Software wallets

Software wallets are a piece of code that store your private key securely. It can either be a mobile application or browser extension.These wallets are connected to the internet and are often more vulnerable to hacks and phishing attacks. Metamask, Trust Wallet, Rainbow are such examples.

Hardware wallets

Hardware wallets are physical devices that store your private keys offline. These physical devices are not connected to the internet and require physical approval for each transaction which makes them more secure compared to Software wallets. To perform any transaction, you’ll need to use a Software wallet as an intermediary platform. Existing hardware wallets solutions in the market include Ledger, Trezor and Safepal.

The Challenge of Securely Managing Private Keys

While the Web3 ecosystem has grown rapidly and come a long way, it still fails to onboard new users due to non intuitive user experience of navigating the blockchain ecosystem and managing the wallets. EOA wallets, regardless of type, can only be accessed through private keys. You must have heard the quote, “Not your keys, not your crypto”. The user is solely responsible for safeguarding the private key with the best practices, which can often be overwhelming for the general non tech savvy users. Once the private key is compromised or lost, EOA wallet cannot recover the account and can result in irreversible loss of assets. 

Smart Contract Wallets

Smart Contract Wallets (SCWs) are contracts deployed on chains which can manage digital assets. In comparison to traditional EOA wallets they don’t require the custody of the user’s private key to sign the transactions. 

Advantages of Smart Contract Wallets

Smart contract Wallet solves the problem of onboarding by allowing users to use social logins or other web2 authentication for account management, and recovery. Moreover, SCWs provide more granular control and programmability to users by allowing them to perform batch transactions, certain functions on autopilot - for instance swap ETH to USDT token, when ETH price is $2700, adding limit to their spendings and advanced multi-signature accounts. SCWs can use paymaster to pay the fees in USDT instead of ETH. Thus, they are often seen as a gateway to onboard the next billion users to Web3.

Introduction to EIP 4337

Smart contract wallets did exist before EIP 4337 but lacked a standardization across the ecosystem which reduced the interoperability. EIP 4337 helps to standardize account abstraction across all the Ethereum compatible chains. You must be wondering why it’s called account abstraction? We also call it account abstraction (AA) because it helps us abstracts details like validation, gas payment, and execution from the user.  It introduces a new transaction type called UserOperation, to allow users to delegate transaction Bundlers. Bundler uses alternative mempool which keeps track of UserOperation, bundles together and submits them for on chain execution through entry point contract. 

Understanding EIP 4337

EIP 4337 consists of a few main components which help us achieve account abstraction. These components are UserOperation, UserOp mempool, Bundler, EntryPoint, ContractAccount, and Paymaster. Let's delve into the roles and definitions of each component:

UserOperation 

The term UserOperation itself suggests that it represents the operation initiated by the user. UserOperation in EIP3447 is somewhat different from traditional transactions performed through EOAs since it also contains additional field paymasterAndData and signature. 

UserOp mempool

UserOp mempool are alternative pools to have a queue of UserOperations which are not yet processed and bundled. It acts as a waiting room and helps bundlers to keep track of pending UserOperations.

Bundler

Bundler as the name suggests bundles the UserOperation and submits them on chain. The on-chain submission happens through creating a valid handleOps transaction for published global entry point contracts. For multi sig wallets, it can create a handleAggratedOps for entry point contracts since we can not verify the multisig threshold and signatures through handleOps. 

EntryPoint

EntryPoint contracts are global entry points for bundlers to submit the user operations on a chain. It is responsible for handling userOp for accounts and multiple aggregates by validating every userOp, aggregated signatures, and executing the userOp. 

Account Contract

Account Contract is the smart contract deployed on the chain to create SCW which can be controlled by signature, or other authentication methods, for instance social login. Each account following EIP 4337 must have a validateUserOp method, used by EntryPoint contract.

Paymaster

A Paymaster contract is responsible for paying fees for the userOp on behalf of the user. Similar to Account contract, a Paymaster contract also has valdiatePaymasterUserOp, that helps validate the request.

UserOperation Lifecycle

Image from EIP-4337 Proposal
Step 1

Let’s consider, we have submitted a transaction request through SCW. The request will be kept in the userOp mempool until the bundler processes and validates the request before submitting the bundle to handleOps. To validate the request, bundler uses simulateValidation. The simulateValidation calls the Account contract valdiateUserOp and Paymaster contract validatePaymasterUserOp. Upon successful validation the transaction is submitted to EntryPoint. 

Step 2

To submit the userOp on the chain, bundler uses the handleOps method. The method is used to validate the userOp again. handleOps internally calls the account contract validateUserOp, if the validation is successful, it moves ahead otherwise it’s reverted back. 

Step 3 & Step 4

Once the userOp is successfully validated, handleOps also validates the paymaster request if any present by calling the validatePaymasterUserOp of the paymaster contract. Upon successful validation by paymaster contract, it moves ahead. 

Step 5

Once the userOp is successfully validated again, the handleOps executes the userOp and submits on chain by calling the excuteOp of Account contract. If the paymaster field is present in userOp, the paymaster pays the gas fees otherwise the wallet has to pay. 

Step 6

Upon successful execution, the last step is to perform postOp for paymaster. The entry point calls the postOp to calculate the fees used during the execution of userOp. For instance, if paymaster allows users to pay in USDT, the paymaster needs to know how much USDT to charge.

The above steps explains the lifecycle of userOp in brief. To know more, please read EIP 4337.

Conclusion

While EOAs are the first ever wallets created to interact with the Web3 ecosystem, they have their challenges to onboard general users due to complexity involved to manage. The risk of losing funds is potentially higher since there’s no way to recover keys once lost. 

Smart contract wallets solve the above onboarding challenges by abstracting out validation, payment and execution. SCWs provides users the flexibility to choose a way for account management, it can be social logins, an EOA wallet or any other authentication method. SCW is a leap forward in the ecosystem to solve onboarding. 

If you are interested in developing an ERC 4337 compatible wallet, you can check out Web3Auth SafeAuth Kit, which can easily create smart wallets that work seamlessly with ERC-4337.