Account Abstraction is not new. We’ve been pioneering it since 2019.
Web3 has been buzzing around Account Abstraction (AA) since ETH Denver. Devs are exploring it. Thought leaders are touting it. VCs are trying to define it. Even though Vitalik himself has spoken about how Account Abstraction is the path forward, AA is not a shiny new thing.
Biconomy has been actively building on Account Abstraction since 2019! But don’t take our word for it. Here’s the proof, and we come with receipts.
Impact of Account Abstraction
At its core, AA is all about creating custom user journeys at the onboarding, authentication and transaction layer.
What this simply means — AA is applied to remove web3 UX complexities for the end-user, while executing blockchain operations required by the said user. This results in intuitive user flows, secure transactions, and better UX overall.
There are 4 elements that can be abstracted this way:
- Gas Abstraction (Gasless Transactions)
- Gas Token Abstraction (Pay gas in any ERC20 token)
- Signature Abstraction
- Nonce Abstraction
Gas Abstraction — Gasless transactions
Gas Abstraction, or what we pioneered as Gasless, has become an industry standard. It is also one of the biggest AA features everyone is excited about. When users don’t have to worry about managing or paying gas for their transactions, it becomes a HUGE UX benefit.
We have been enabling gasless transactions for a long time. As of Feb 2023, we have processed 35 million gasless transactions, thanks to how we’ve been pioneering meta-transactions and relayer infrastructure since 2019.
Account Abstraction Receipt No. 1
How did we do this? Having a battle-tested, multi-chain Relayer Infra allowed us to use EIP 2771 to enable Gasless transactions. Taking inspiration from the implementation of EIP 2771, which had the concepts of Paymasters and singleton contracts to manage the relayers, we were able to enable gas sponsorship for users of dApps since 2019.
The user does not have to go through the chaotic process of buying ETH or MATIC or any other native chain’s token to transact. The user could simply sign a transaction and our Relayer Infra would use the Trusted Forwarder as a middleware contract where the nonce and signature verification took place. The Trusted Forwarder contract would then call a destination contract to execute the call.
This is very similar to what happens in the current flow of ERC 4337 AA, where the EOA signs a transaction on its wallet and the trusted contract (Entry Point) handles the next cycle of execution in the transaction.
Gas Token Abstraction — Pay gas in any token
Picture this — It’s your first trip to Bali and you go to the airport’s money exchange to convert EUR to IDR but they tell you that you need to pay some USD to complete the currency exchange. How does that make sense?
But this is exactly what is expected when you go to a Decentralised Exchange (Dex) where, if you want to get DAI for your USDC, you’ll have to pay the native asset (ETH) to complete this transaction.
When a user goes to a new chain, they need to have that chain’s native token to perform any action on that chain. It doesn’t have to be like this.
Account Abstraction Receipt No. 2
This ability to pay gas in any token is not a ‘new’ feature enabled by AA. We have been powering seamless ERC20 token payments for almost 2 years!
We enabled this feature for Sandbox, where Sandbox users don’t need to hold MATIC to use the dApp, they can go gasless for 10 transactions per month per user. Beyond that, they can execute any transaction and pay gas by just holding the SAND token.
Gas token Abstraction is a powerful concept where the actual chain fee is abstracted away from the user and they can use the ERC 20 Tokens they already hold to pay for the gas.
All this is made possible with our ERC20 Forwarder. In AA this will be enabled by Token Paymaster. See also: https://twitter.com/biconomy/status/1534175286698426369?s=20
Signature Abstraction
In typical transactions with an Externally Owned Account (EOA), the user signs some random hex string pop-up which tells him/her nothing about what they are signing. This leads to countless users mistakenly approving scams and losing millions of dollars.
With AA and smart contract wallets, we can create custom pop-ups. In the specs of ERC 4337 AA, there is flexibility to have custom signature mechanisms that are not limited to ECDSA.
Account Abstraction Receipt No. 3
But even in the past, rather than asking a user to sign a random hex string, we implemented the EIP 712 specs in the Biconomy trusted Forwarder contract. This allowed the user to give more insight into what they were signing, which contract was being called, and on which chain Id. The Forwarder has support for two signature schemes and the dApp can choose either to get the user signatures.
In the same way, Smart Contract Wallets support any signature scheme for verification, similar to what our trusted forwarder has been doing for more than 2 years.
Nonce Abstraction
Linear nonces are necessary for a user to protect from replay attacks but it is a pain because they depend on previous transactions being confirmed before the next transaction goes through. This applies even if you’re trying to transact on a completely different dApp.
Account Abstraction Receipt No. 4
This is something easily solved in a centralized banking system as keeping track of transactions is straightforward. Biconomy’s trusted Forwarder, with its implementation of 2D Nonces, lets you send parallel transactions.
The correctness of a user nonce is checked in the Forwarder without dependencies on the linear nonces of the user. This improves the UX massively, especially in the case of a multi-sig transaction where you require others to confirm your Nth transaction while performing your N+1 transaction.
Question: Why the need for ERC 4337?
You might be wondering, if all these features were already possible then why did we need the new EIP4337? Why is Account Abstraction such a big deal? Well, that’s because of 2 key reasons:
i. Possible Features: Account Abstraction enables a ton of new use cases that were just not possible with our old 2771 approach. EOAs had certain constraints which could not enable such programmability. But with 4337 & smart contract wallets, we can enable new features such as session keys, multisig, arbitrary logic execution on your account etc. AA brings programmability to smart accounts that enable a plethora of custom UX improvements.
ii. Standardisation: The EIP also brings a standardised way for enabling these features and utilising smart contract wallets.
Conclusion
All the forms of abstraction that we mentioned above were not just tied to smart contract wallets and AA. We have been bringing these capabilities to the web3 ecosystem since 2019.
Having a Trusted Forwarder contract in between enabled us to bring these features to regular EOA users, a theme that EIP 3074 is trying to achieve. But we never restricted ourselves to just EOAs.
We enabled Gasless transactions for multiple apps that had users who had assets lying in smart contract wallets, such as Safe, and wanted Gasless transactions or gas fees paid in any ERC20 token transactions with smart contract wallets.
We started researching heavily into ERC-4337 a year ago (!) to leverage a new standard of Smart Contract Wallets and the Decentralised infrastructure needed to power these features. Building the entire stack end-to-end will enable us to provide the seamless and intuitive UX that web3 needs.
In the next post, we will explore how we transition to the new standard of Account Abstraction with ERC 4337 and how dApps can upgrade their infrastructure to become compatible with the new standards in the ERC.
.png)
.png)