Skip to main content

· 5 min read
Derek Chiang

Unless you check new ERCs everyday (in which case, good for you), you probably haven’t noticed this new ERC known as ERC-6492, innocuously named "Signature Validation for Predeploy Contracts.” As this post is going to argue, ERC-6492 is critical to the wide adoption of account abstraction and smart contract wallets in general.

We will now explain the issue that ERC-6492 addresses, briefly touch on the technicalities of how ERC-6492 solves the problem, and end by explaining why it’s critical for key ecosystem projects such as Ethers and SIWE to adopt this new standard.

Terminology

For brevity, I will be using the following pairs of terms interchangeably, even though it’s not technically accurate:

  • “AA” and “ERC-4337”
  • “AA wallets” and “smart contract wallets”
  • “Wallets” and “accounts”

The Context

As I explained in a previous post, AA wallets are mostly compatible with existing DApps since AA transactions look no different than normal transactions from the perspective of the DApps, except for some edge cases.

Signature validation is a different story, however. As you know, many DApps require some form of signing; OpenSea for instance requires the user to sign a message before they can “log into” the DApp.

Since smart contract wallets have the flexibility to support different signing schemes, there isn’t a universal way to validate signatures by a smart contract wallet. Instead, there’s a standard ERC-1271 which defines a standard function isValidSignature on a smart contract wallet so that the verifier (e.g. OpenSea) can call the function to validate the signature, without needing to know specifically what signing scheme the wallet uses.

This is all fine and good, and in fact ERC-1271 as a standard enjoys wide adoption. Most popular DApps today, including OpenSea, already support it.

The Issue

With the rise of ERC-4337, smart contract wallets are becoming increasingly commonplace. One key optimization that ERC-4337 implements is counterfactual deployment — namely, that we can compute the address of the account before the underlying smart contract is actually deployed. As a result, a user can “create” a ERC-4337 wallet without paying the deployment cost, so they can start receiving assets, signing into DApps, etc. Only when the user sends their first transaction that the contract is actually deployed.

While counterfactual deployment is normally very desirable, it becomes an issue when the user needs to sign messages. To understand why, recall that in order to validate a signature from a smart contract wallet, the verifier needs to call isValidSignature on the wallet contract. However, since the wallet contract is not actually deployed, it’s impossible to call that function! As a result, an attempt to validate that signature will fail.

Consequences

So what does this mean for the users? It means that it’s impossible to validate signatures from ERC-4337 wallets until they are deployed. Therefore, for a new ERC-4337 wallet that has not sent any transactions, it’s impossible to, say, sign into OpenSea or any DApp that uses SIWE.

This is very bad because users who are new to Web3 want to sign into DApps and look around before they spend any money on gas. Forcing a user to pay some gas to deploy their wallets before they can see a DApp would be a major step backwards comparing to the EOA experience today, where you can sign into DApps even from an empty account.

Solution

ZeroDev first encountered this problem when we were developing our WalletConnect integration and realized that we couldn’t sign into OpenSea until we deployed the wallet, which led to a lengthy discussion with many smart people in the 4337 ecosystem. Eventually, Ivo from Ambire came up with a great solution that turned into ERC-6492.

On a high level, ERC-6492 works by using a [UniversalSigValidator contract](https://eips.ethereum.org/EIPS/eip-6492#reference-implementation) that validates a signature as such:

  • Check if the signature ends with a sequence of magic bytes, which indicate that the signature is for a not-yet-deployed contract.
    • If so, the signature itself contains all the data necessary for deploying the contract, which comes down to an account factory address and the calldata for the factory.
    • UniversalSigValidator would then proceed to deploy the contract and calls isValidSignature on it to validate the signature.
  • If the magic bytes are not detected, then proceed as normal, which means:
    • Check if there’s contract code at the address. If so, proceed with ERC-1271.
    • Otherwise, assume that the account is an EOA and perform a ecrecover.

But wait! You might say. The signature verifier has to deploy the contract if it doesn’t exist? Isn’t that incurring a lot of cost for the verifier?

The answer is no because the verifier will be using eth_call, which essentially simulates the transaction without actually executing it on-chain.

Next Steps

So who needs to implement ERC-6492? In short, it’s whoever that needs to verify signatures, which is mostly DApps.

However, DApps don’t write everything from scratch. In fact, there are a few libraries that most DApps use for handling signatures, so if these libraries adopt ERC-6492, DApps would get to support ERC-6492 “for free.” Some of these key libraries are:

If you want to see the space move towards AA and smart contract wallets, there are a few things you can do:

  • Upvote these PRs
  • Make your own PRs to libraries that validate signatures
  • And of course, if you are building a DApp, make sure that it can handle SCW signatures! DApps that work seamlessly with SCW will have an inherent advantage comparing to those that don’t, since more and more traffic are moving to SCW everyday.

· 8 min read
Derek Chiang

At ZeroDev, it’s our job to help devs learn and adopt AA, so naturally we have come across a lot of questions, concerns, and objections.

In this post, I’d like to summarize some common pushbacks against ERC-4337 and AA in general, and I will group them into three categories:

  • Misconceptions: things that are just not true.
  • Yes and no: somewhat true, but the reality is nuanced.
  • Valid concerns: real issues that need to be addressed.

Let’s dive in!

Misconceptions

AA is no big deal because SCW has been around for years

Without AA, smart contract wallets like Safe/Argent are not “first class citizens” on the blockchain, meaning that you cannot initiate transactions directly from them. Rather, you have to do one of the following:

  • Call the SCW from a EOA, so you STILL have to own a dumb wallet before you can own a smart one.
  • Rely on a centralized relaying service to relay your transactions, which exposes you to risks like censorship, downtime, etc.

With AA however, you can directly send transactions from a SCW, the same way you can directly send transactions from MetaMask. This makes it possible to use a SCW as your only wallet, which is precisely what the next billion Web3 users will do.

You still need a EOA to own an AA wallet

This common point of confusion stems from the fact that most AA wallets today are owned by a private key (just like EOA wallets), but it’s misguided because:

  • Private key ≠ EOA. While it’s true that each private key has a corresponding EOA, the key itself is just that — a key that can sign things. A typical AA wallet will store and safeguard a private key just like MetaMask does, and use the key to sign transactions for the smart contract account. The corresponding EOA, to the extent that it exists, is only used as a public key for validating signatures.
  • Since AA enables transactions to be validated with a smart contract, the validation logic can be arbitrary, so you don’t technically even need a private key. Here’s a proof of concept using fingerprints instead of private keys.

We don’t need AA if we have MPC

The best way to think about MPC vs AA is:

  • MPC improves the key management experience.
  • AA improves the transaction experience.

With MPC, you effectively have a “virtual private key” without ever having to store it somewhere, which is a huge improvement over the status quo of having to write down a 12-word seed phrase.

AA is about what happens when you send a transaction — who pays gas? What tokens are used to pay for gas? Who signs the transaction? All of these can be abstracted away with AA.

As you can see, MPC and AA actually complement each other nicely — MPC saves the user from having to deal with keys, while AA makes transactions smooth. In fact, it’s precisely by combining MPC with AA that we are able to offer social AA wallets.

Yes and No

AA transactions are more expensive

Since AA uses smart contract wallets, each transaction necessarily has some overheads comparing to the equivalent EOA transaction. There’s also the cost of deploying the smart contract wallet on-chain.

However, multiple factors lower the transaction cost in AA’s favor:

  • SCW has the ability to batch transactions, so what normally takes multiple transactions with EOA, may only take one transaction with a SCW. A classic example is when you interact with a DeFi protocol, where each action typically involves multiple transactions (e.g. approve → swap → deposit). In AA, all these can be done in one atomic transaction, thus saving gas.
  • ERC-4337 supports signature aggregation, so that multiple AA transactions can effectively “share” a signature, thus lowering the cost for each transaction. Here are some numbers from Vitalik.
  • ERC-4337 does not deploy the smart contract account until the user’s first transaction. Before then, the account exists “counterfactually” — it has an address even though it’s not really deployed. So your users can receive assets even without paying any deployment cost.

As a result, whether AA transactions or normal transactions cost more gas actually depend on the workload. For some applications (notably DeFi), AA transactions might wound up being cheaper!

AA is not ready for production

There’s no doubt that anyone building something on AA/ERC-4337 today is a trailblazer — there are not many prior examples to look to or patterns to borrow from. In that sense, building something on AA certainly involves more technical risks than building a classic DApp.

However, everything you need to build a full AA application, notably ERC-4337 itself, is already running in production/mainnet. We are at an inflection point where you are either building one of the last non-AA applications, or one of the first AA applications. The choice is yours.

AA is not compatible with existing DApps

Before AA, there was “meta transactions” that could remove gas (or pay gas in ERC20s) by using relayers that submit transactions on users’ behalf. The main problem, however, was that DApp contracts had to use a helper function like _msgSender() instead of the more intuitive msg.sender to get the address of the transaction sender. Needless to say, most DApps did not do that, so the compatibility of meta transactions were severely limited.

AA does not have this problem, however, which makes it compatible with the vast majority of DApps. Where the compatibility breaks down, however, is when the DApp asks the wallet to sign a message. It turns out that EOA signatures and smart contract wallet signatures cannot be verified the same way, so there’s a standard ERC-1271 that DApps are supposed to implement to be compatible with smart contract wallets. Here’s an incomplete and likely outdated list of DApps grouped by whether they support ERC-1271.

If a DApp requires message signing but doesn’t support ERC-1271, then AA indeed won’t work with the DApp. Fortunately, the space is completely aligned that ERC-1271 needs to be supported, and new DApps being written today typically support ERC-1271 by default if they use libraries like OpenZeppelin.

ERC-4337 is not real AA. We should wait for real AA

When someone says that ERC-4337 is not “real” AA, they are typically referring to the fact that ERC-4337 is NOT integrated into the blockchain protocol itself. In contrast, new networks like zksync and StarkNet have “enshrined” AA as a part of their protocols.

The reason why Ethereum and most other EVM chains have not enshrined AA is two-fold:

  • Enshrining AA will be protocol-breaking, and therefore require a hard fork.
  • There’s no consensus over the best approach to implement AA, so it’s not even clear what we should be enshrining.

Enshrining AA into the protocol itself also means that every EVM chain has to implement this breaking change, which can take a very very long time. In contrast, since ERC-4337 is implemented as smart contracts, deploying to a new chain is literally a matter of deploying a few smart contracts. That’s why ERC-4337 is already running on all EVM chains today.

In any case, the distinction between “real AA” and “ERC-4337 AA” matters little to the end users. From their perspective, their transactions “just work” either way. Therefore, given the level of community buy-in for ERC-4337, it’s our best hope for achieving AA on EVM blockchains in the near term.

Valid Concerns

ERC-4337 is fairly centralized right now

In theory, ERC-4337 is designed such that anyone can spin up relayers (aka “bundlers”), unlike previous relayer networks that are typically run by a single entity.

In practice, however, most bundler implementations except for StackUp are not production-ready, so most ERC-4337 traffic is going through StackUp today. This is not unlike how most Ethereum traffic is going through Geth. Hopefully, this will change as other bundlers go into production.

ERC-4337 may still change

While ERC-4337 has been deployed on mainnet, it’s not technically finalized. The EIP is still in draft status, and the core team has acknowledged that the EIP and the smart contracts could still change.

Fortunately, it’s expected that any changes to the EIP and core smart contracts won’t affect the core account interface, so wallets that are compatible with ERC-4337 today will most likely still be compatible with ERC-4337 in the future.

ERC-4337 has not been formally verified

While ERC-4337 has been audited, it has NOT been formally verified, so one cannot completely rule out the possibility that there are some critical security issues.

Fortunately, there are teams working on the formal verification of ERC-4337 (with our very own taek being a major contributor). When ERC-4337 has been formally verified, that’s when we expect to see it finalized.

The Bottom Line

Anyone building on AA today is a trailblazer taking on technical risks, no doubt about it. But with risk comes reward — if properly executed, your project will dwarf your competition in terms of usability.

At ZeroDev, we’ve developed an AA framework that dramatically shortens the time — and reduces the risks — for devs to build wallets and DApps on AA. Check out ZeroDev and start building the future of Web3 today!

· 8 min read
Derek Chiang

As the saying goes, the only constant in Web3 is change. If you are building a Web3 product, you need to stay on top of technological trends, in order to identify new opportunities to grow and improve your product.

One emerging trend that you might have noticed is “account abstraction” (AA). While there have been many great technical write-ups on account abstraction, I would like to explain in this blog post the practical benefits of account abstraction, or in other words, how you can leverage account abstraction to improve your app.

Account abstraction in simple terms

First thing first: what does account abstraction actually mean?

On most blockchains today, transactions can only be sent from an "externally owned account" (EOA), which is a fancy term to refer to wallets like MetaMask that are created from a seed phrase. In other words, EOAs are the wallets everyone has been using so far.

Account abstraction describes the ability for smart contracts to send and verify transactions. The difference between a smart contract and an EOA is like the difference between a computer and an abacus. Whereas an abacus can only be used in a specific way, a computer can be programmed to perform arbitrary functions. Similarly, whereas EOAs work in a pre-defined way, smart contract wallets (SCW) can be programmed. This opens up exciting opportunities for you as a developer to improve user experience (UX) and implement new product features, which we will detail below.

Side note on smart contract wallets

Some of you might be wondering: how is this different than smart contract wallets like Gnosis Safe? Hasn't that been around for a while?

Yes, but the key breakthrough with account abstraction is that SCWs can finally originate transactions. With Gnosis Safe, for example, the user still has to use an EOA like MetaMask to issue transactions, which are then "routed through" Gnosis Safe. Think controlling a computer with an abacus. This introduces a significant barrier to using SCWs, which is why to this date SCWs like Gnosis Safe are only used in high-security enterprise settings, and not in day-to-day Web3 usage.

Gas sucks; AA fixes it

One of the biggest UX issues with EOA wallets is that users have to pay gas in ETH (or whatever the native token is). This can be a significant hurdle, especially for new users who are not familiar with cryptocurrencies and may not even own any ETH.

As a classic example, let's say you are doing a "free mint" and you would like your users to mint an NFT. While minting is free, gas is not. Someone new to crypto would have to first acquire some ETH, which probably involves a KYC process. More likely than not, they will simply give up, instead of engaging with your app.

Another example is NFT games, where a user may have won or received some NFTs, but can't do anything with them (such as trading or transferring the NFTs) since they don't have the ETH to pay for gas.

Account abstraction addresses these issues by allowing users to skip gas entirely, if a third party is willing to sponsor gas for them. In these examples, you (the developer) can enable gas-less experiences for your users by sponsoring their gas.

Account abstraction-enabled wallets can also pay gas in any ERC-20 tokens. For DeFi applications, it's very common for a user to primarily be investing in ERC-20 tokens such as UNI or USDC. With an EOA, the user would still have to own a little bit of ETH (which they have to top up every now and then) in order to pay gas for transactions. With account abstraction, the user can pay gas in the tokens they already own!

Seed phrases are a nightmare

One of the biggest UX issues with EOA wallets is the need to safe-keep a seed phrase. This is an incredibly difficult task for most people: seed phrases are difficult to remember, and can be easily lost or stolen.

With smart contract wallets, there are many ways to solve this problem. One idea is social recovery: a user can authorize a list of their friends or family members to recover their account if they lose access. It's much easier to remember who your best friends are than to remember 12 random words!

The flexibility of smart contract wallets also means that it can work with MPC, so your users can simply login with a social account (e.g. Google) or email/password.

Batch transactions for fewer confirmations

Another issue with EOA wallets is that each transaction is verified and executed separately, which means long wait times and high gas fees. We have all had the terrible experience of trying to do something simple, say swapping one token for another, and yet having to confirm and wait for multiple transactions (e.g. an "approve" into a "swap").

With account abstraction, however, multiple transactions can be batched together into a single transaction. This significantly reduces the cost and wait time associated with interacting with your app — your users can get things done in one click.

Batching also makes your app safer by ensuring “atomicity” — that a multi-step process either finishes or completely reverts, instead of getting stuck in a “half-completed” state, e.g. “approve” succeeding but “swap” failing. The lack of atomicity can lead to very tricky bugs in DApps, but it won’t be an issue with AA.

Build interactive apps with session keys

What if you are building a highly interactive application such as a game, where prompting the user for confirmation would really disrupt their flow? Enter session keys, which are temporary keys that can be used to send transactions for a limited amount of time, with a limited scope of permissions.

Combining session keys with batching, your app can be sending far fewer transactions, while skipping most approvals, making your UX approach that of traditional Web2 applications.

Transaction Guards

Sometimes you want to protect your wallets against misuse. With an AA wallet, you can set up "transaction guards" – smart contracts that check transactions that go through your wallet.

One example is spending limits. You might want to limit your daily spending to $100, and for anything more than that you require a second signer (e.g. ledger). This not only helps you rein in your NFT impulse buys, but also is a good way to defend against hackers. With AA, spending limits can be easily implemented as a transaction guard.

Delegate assets

When you put crypto into a centralized product, you typically have no visibility into what they are doing with your funds, which can result in disastrous consequences (cough FTX cough). When you hold crypto in a self-custody wallet, there's perfect visibility, but you need to personally initiate and sign every transaction, which limits the potential of your crypto.

What if there's a third way? What if you can self-custody your funds, while authorizing a third party to perform limited actions on your behalf?

A great example is collateralized loans like Compound and Aave. When you put down collateral and take out a loan from these protocols, you need to continuously monitor your loan and top up your collateral if necessary, in case the price of your collateral token drops and your collateral gets liquidated. This is a lot of work and stress.

With account abstraction, you can build applications such that your users can delegate certain transactions for you to perform. If you were building a lending app with account abstraction, for instance, your app could automatically close your user's position when their collateral is in danger — all without them having to give away custody of their assets. This works because the permissions are enforced by smart contract wallets — the third party (e.g. your app) can only perform the delegated transactions, and nothing else (such as stealing user assets).

Subscriptions

As a particular use case of delegating assets, it's worth mentioning subscriptions. With AA, your users can easily authorize you (the app) to pull money from their accounts, but only up to a certain amount, at a given frequency.

State of account abstraction today

By now, hopefully I have convinced you that account abstraction can vastly improve the UX and functionality of your app. But is it ready today? Can you actually build real products on account abstraction right now?

The answer is a resounding yes. New rollups such as StarkNet and zksync natively support account abstraction, while ERC-4337 has brought account abstraction to all EVM blockchains, including Ethereum, Polygon, Arbitrum, Optimism, Avalanche, and more.

In a future blog post, I will dive deeper into ERC-4337 and explain how account abstraction actually works. For now, my team at ZeroDev has created an SDK that you can use today to enable account abstraction in your app. Give it a try now, or join our new Discord and say hi!