Account Types

The type of account you choose along with the wallet type determine the capabilities of the wallets you create. Circle supports three account types:

• Externally Owned Accounts (EOA)
• Smart Contract Accounts (SCA)
• Modular Smart Contract Accounts (MSCA)

The following table shows the blockchain networks and their support for EOAs, SCAs, and MSCAs.

EOAs are Ethereum's most commonly used account type and Solana's only supported account type. They consist of a private and public key, with the public key representing the account address. EOAs require secure management of the private key and always require gas tokens to initiate transactions. While EOAs offer the flexibility to initiate any transaction, they have certain limitations, such as the need for a private key and the inability to control them programmatically onchain.

Benefits:

• Zero Cost Creation. Creating an Externally Owned Account (EOA) does not incur any fees, making it an accessible option for users. This is especially important for networks like Ethereum mainnet, where gas costs are higher.
• Versatile Transaction Initiation. EOAs can initiate any transaction on the Ethereum network, allowing users to interact with various decentralized applications and perform a wide range of operations.
• High outbound TPS. EOAs, given their simplicity, allow for higher outbound TPS than SCAs. This makes them suitable for use cases like mass distribution such as airdrops.

Limitations:

• Private Key Dependency. EOAs require the secure management of a single private key that’s paired with the EOA. Users must protect their private key to ensure the security and control of their EOA, as it grants access to account functions and funds. When users lose this private key, they lose the ability to transact tokens in the EOA.
• Native Token Dependency for Gas (EVM). To perform transactions or execute operations on the Ethereum network, EOAs must hold native tokens such as Ether (ETH) to cover gas fees. These tokens must pay for the computational resources utilized during transaction validation and execution. Solana, on the other hand, natively supports gas subsidy with feePayer, which means developers can sponsor gas fees on behalf of the EOA from the users.
• Advanced Onchain use-cases. EOAs cannot support any advanced use-cases that involve onchain code. Some examples of these include multi-sig wallets, session keys, onchain spending limits, etc.

SCAs are another type of Ethereum account that replaces an EOA with a smart contract. SCAs do not have private keys but are controlled by either an EOA, a passkey, or multiple keys, which interact with the deployed smart contract. SCAs allow developers to write customized logic within the smart contract, enabling advanced functionalities. SCAs have been in the Ethereum ecosystem for many years but recently gained popularity thanks to a new standard called ERC-4337 (account abstraction) - a trustless standard the community could build SCAs around. ERC-4337 also introduced the concept of paymaster, which enables simplified gas abstraction, enabling anyone to sponsor gas fees for the end user or let the end user pay for gas in any ERC-20 token.

Benefits:

• Flexibility of keys. SCA allows for configuration of the signing key, which can be an EOA, a passkey, or multiple keys, as well as the recovery of such keys if lost.
• Gas Abstraction and Fee Sponsorship (EVM). SCAs offer gas abstraction, simplifying gas fee management for end-users. Developers can implement mechanisms, such as the paymaster pattern, to sponsor gas fees on behalf of users. This reduces the burden on users to hold and manage native tokens for gas and enhances the overall user experience by providing a seamless gas fee payment process.
• Batch Operations. SCAs allow you to batch related user operations, which can provide a number of important benefits for end-users. With batched operations, the user only has to wait for a single batched transaction, instead of multiple individual transactions. Batched transactions will generally cost less gas than individually submitted transactions. Batched transactions offer atomicity: if any transaction in the batch reverts, the entire batch reverts, ensuring that user operations aren't stuck in an inconsistent state.

Limitations:

• Gas Fees Incurred for Creation. Gas fees are required when creating SCA wallets. However, emerging solutions like the one implemented in Programmable Wallets address this limitation by introducing a lazy deployment mechanism. This process postpones the gas fee payment until the first outbound transaction, easing the initial cost burden of SCA wallet creation.

MSCAs are a type of smart accounts that can be extended with different modules to enhance their functionality (similar to how one can install apps on iPhones and Android to give the smartphone more functionality). Circle's MSCA adheres to both ERC-4337 (account abstraction) and ERC-6900 - an ERC standard that Circle engineers are co-authoring with other ecosystem partners. We enable the creation of MSCAs by default in our Modular Wallet SDK.

Benefits:

• Custom Logic and Functionality. Modular Smart Contract Accounts (MSCAs) allow developers to build custom logic and functionality directly into the account. By deploying smart contracts to control MSCAs, developers can create innovative and customized features, enabling advanced capabilities and automated operations within the wallet.
• Flexibility of keys. MSCA allows for configuration of the signing key, which can be an EOA, a passkey, or multiple keys, as well as the recovery of such keys if lost.
• Gas Abstraction and Fee Sponsorship (EVM). MSCAs offer gas abstraction, simplifying gas fee management for end-users. Developers can implement mechanisms, such as the paymaster pattern, to sponsor gas fees on behalf of users. This reduces the burden on users to hold and manage native tokens for gas and enhances the overall user experience by providing a seamless gas fee payment process.
• Batch Operations. MSCAs allow you to batch related user operations, which can provide a number of important benefits for end-users. With batched operations, the user only has to wait for a single batched transaction, instead of multiple individual transactions. Batched transactions will generally cost less gas than individually submitted transactions. Batched transactions offer atomicity: if any transaction in the batch reverts, the entire batch reverts, ensuring that user operations aren't stuck in an inconsistent state.

Limitations:

• Gas Fees Incurred for Creation. Gas fees are required when creating MSCA wallets. However, emerging solutions like the one implemented in Programmable Wallets address this limitation by introducing a lazy deployment mechanism. This process postpones the gas fee payment until the first outbound transaction, easing the initial cost burden of SCA wallet creation.

The following are the versions of MSCAs supported by Wallets today. The exact version type is displayed in the successful response when creating a wallet.

For a complete list of supported modules and those planned for future support, visit the Modules page.

Based on our experience, SCAs generally provide a more straightforward user experience for most use cases. They allow developers to focus on creating innovative functionalities within the smart contract. However, the specific needs of each project should be carefully considered when choosing between EOA, SCA, or MSCA account types.