Simplifying crypto apps experience using native account abstraction

Blockchain technology and cryptocurrencies have undoubtedly brought innovation and transformative innovations to the financial and technological landscapes. However, to make these innovations accessible to everyday users, the complex nature of blockchain systems needs to be simplified. Account abstraction is one such solution that aims to make the crypto user experience smoother, more secure, and, ultimately, more appealing.

To understand its significance, let's begin with a high-level overview of why account abstraction emerged.

Current State of Cryptocurrency UX and Associated Challenges

Cryptocurrencies have long been criticized for their steep learning curve. The existing crypto landscape requires users to understand many intricate technical concepts. From managing private keys and gas fees to interacting with dApps, navigating the crypto space can be daunting for newcomers and experienced users.

Within the Ethereum blockchain ecosystem, two primary account types exist: Externally Owned Accounts (EOAs) and Contract Accounts. EOAs are the regular user accounts familiar to anyone using wallets like MetaMask. They are controlled by private keys stored in the browser, making every blockchain action dependent on this single point of control.

However, this system has notable drawbacks. It limits the user-friendliness of Ethereum-based applications and leads to security challenges if the key is lost or stolen. Due to these challenges, users often default to custodial accounts offered by exchanges like Coinbase, which feel easier and more secure. However, these custodial solutions present a single point of failure and carry much higher risks of losing users’ funds.

Layer 2 protocols like Starknet and zkSync offer a promising alternative with native account abstraction, eliminating reliance on EOAs. Account abstraction separates the entity holding tokens (account) from those authorized to move them (signer). This decoupling helps mitigate security risks associated with private keys.

The Need for Account Abstraction

Enhanced Security

In traditional Ethereum accounts (EOAs), users must manage seed phrases and private keys for self-custody. Losing these means permanently losing access to assets. Many users store backups in Google Drive, iCloud, or password managers, which introduces security vulnerabilities.

Account abstraction changes this by allowing the account on the blockchain to act as your identity, holding your assets. At the same time, another entity called a signer is used to sign data and move assets on behalf of the account. This is similar to an authorized signer permitted by an account owner to access funds in a bank.

This setup allows trusted third parties to help recover accounts and enables biometric verification for two-factor authentication (2FA). Users no longer need to actively manage or back up private keys, reducing the risk of losing access to their accounts.

User-Friendly Experience

DeFi transactions today require multiple steps for approval and spending, involving numerous clicks and confirmations. This process is time-consuming and complex. High gas fees and the difficulty of managing these approvals further complicate the user experience.

Account abstraction streamlines this process with features like multicall and session keys:

  • Multicall: Users can batch multiple transactions into a single call, reducing the number of clicks and confirmations needed.

  • Session Keys: Temporary keys allow users to sign multiple transactions within a defined session without repeated approvals. Users can set parameters like token access, spending limits, and gas limits, simplifying the transaction experience.

Greater Flexibility

Smart contract wallets empower users to automate transfers, schedule recurring payments, and extend functionalities beyond EOAs. This opens opportunities for DAOs, salary payments, and blockchain-compatible subscription plans, enhancing financial automation while maintaining self-custody.

These enhancements are also very useful for non-financial apps like gaming or social media, where you don’t want to ask for approvals each time a user takes an action. Similarly, it can enable interesting financial use cases like SIPs, where a user gives permission to invest in an asset once every week.

Simplifying Transaction Fees via Gas Abstraction

Gas abstraction empowers dApps to sponsor gas fees for users, lowering the technical and financial barriers for everyone to use blockchain applications. For example, when users start using a dApp for the first time, they might not have tokens like MATIC or ETH to pay for transaction fees. Gas abstraction allows dApps to pay the transaction fee on behalf of a new user or enable them to pay using a token they already hold.

ERC 4337 vs. Native Account Abstraction

There are two ways to implement account abstraction: non-native and native.

Non-Native Account Abstraction: In this approach, EOAs are still the primary accounts, but developers deploy smart contracts on behalf of the users. This setup can lead to compatibility issues, as the infrastructure and dApps are mainly built for EOAs, causing smart contract wallets to be overlooked. Developers need to create new tools and infrastructure to make smart contract accounts work and scale. For example, in EVM, a smart contract cannot initiate a transaction itself, so a separate layer called “relayers” is needed to sign and process the transactions on behalf of the smart contract-based wallets.

Native Account Abstraction: In this approach, each account on the chain is by default a smart contract. This design provides a seamless experience for developers and users, as every single account adheres to the principles of account abstraction. For example, Starknet has strategically embedded the account abstraction mechanism directly into its protocol, making it easier to build and scale applications that leverage account abstraction.

Within the Ethereum ecosystem, smart contract wallets are like outliers or second-class citizens. The infrastructure and dApps lean towards EOAs, neglecting the distinctive needs of smart contract wallets. Many dApps, inherently designed with EOAs in mind, may not seamlessly integrate with smart contract wallets. This second-class citizen status limits the user experience and functionality.

At the same time, app developers need to decide between leaving the existing EOA user base to build the best experience for smart contract account-based users or compromising and applying a completely new logic to support both EOAs and smart contract wallets. All these complications make the adoption of smart contract wallets extremely challenging for chains that don’t support native account abstractions. Chains with native account abstraction can offer a very smooth experience for app developers and users since every single account is a smart contract.

An analogy to understand it would be designing a state-of-the-art car from scratch instead of retrofitting an old model. In this process, you incorporate essential components into the car's design, such as advanced engines and safety features, right from the start. The alternative is making adjustments to an old model to meet future standards.

Unlike Ethereum, Starknet has strategically embedded the account abstraction mechanism directly into its protocol (native account abstraction). In simple terms, every account on Starknet naturally adheres to the principles of account abstraction. This design is forward-looking, anticipating the future standard for building blockchain applications.

Special thanks to Julien from Argent for helping us with his knowledge on account abstraction while writing this article!


JediSwap is a 100% community-driven, fully permissionless, and composable AMM on Starknet. JediSwap enables the lightning-fast, near-gasless exchange of assets in a trustless manner.

Stay tuned for our blog updates by subscribing.

For any questions or requests, feel free to reach out to us in Discord.

Subscribe to JediSwap
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.