A Counterpoint to Account Abstraction
Did you mint your POAPs at this year’s EthCC? I sure did. I couldn’t wait to mint those bad boys at the largest Ethereum France event of the year (held in Belgium, of course). While my opinion of NFTs is generally… unfavorable (I’ve written about this before), this whole non-fungus-among-us thing may finally have an application: conference swag.
I kid.
I went to a bunch of talks. Loads of ’em. I know you’ve been waiting for it, so here’s the big announcement: the 2024 Award Winner for the Most Refreshing Crypto Talk was Kris Decoodt’s “Unmasking Crypto’s Moloch”, which I highly recommend.
But I digress.
Most of the conference was dominated by ERC-4337, better known as Account Abstraction (AA). There were about 48 booths that wanted me to use their new AA tech, and probably four out of three talks were about how this new wonder was apparently going to bring crypto to the masses.
I took copious notes, which was difficult to do while gorging myself on stoofvles poutine.
What is Account Abstraction?
In short, Account Abstraction is an attempt to add properties to Smart Contract Accounts (SCAs) so that they behave more similarly to Externally Owned Accounts (EOAs), like your Metamask wallet. At the core of the issue is that EOAs can’t execute code, so developers can’t add any sort of logic to them, and SCAs can’t initiate transactions, so you can’t directly use them like EOAs.
This leads us to what has been the biggest issue with crypto adoption since Nakamoto first put quill to parchment in his mildly-impactful PDF: User eXperience (UX). Honestly, and bear with me for a moment, EOAs and SCAs are simply “implementation details”.
Let’s talk about what a user sees.
Say an end user wants to send some USDC to a business to purchase a thing or provide a service. The user needs both the USDC and some ETH to pay for gas fees. This is annoying, to say the least, in a UX sense. It’s bad enough for us Web3 aboriginals, but try convincing a Web2 user that they need to get a-hold of not just one token (USDC) but then a second one called ETH (which is not a “normal token” like USDC but a “special construction”), and the sole purpose of that second token is so that they can do stuff with that first token —
We are droning on, drawing detailed diagrams on the blackboard with loads of arrows, but as we finish our mind-numbing explanation and look back at our Web2 pupil; well — here I ask you to imagine the moment Bugs Bunny zips away and all that’s left in his place is the smoke outline of an anthropomorphized rabbit. The Web2 user left long ago.
To restate this whole thing in UX terms: ERC-4337 is an attempt to fix a broken User Experience.
Follow our adventure on X.
Play our newest game: Hangman Clash.
Chat with us on Discord.
Sounds Perfect for Spyre
This fits almost 1:1 with many of our use cases here at Spyre.
Our goal is to turn casual-competitive Web2 users into Web3 participants — but gas fees coalesce into the coarse outline of an elephant in the corner. We want Web2 users to be able to buy into the ecosystem with nothing but USDC. We want them to be able to move that USDC around, stake their buy-ins, join matches, earn payouts and rewards, and perform unknown future actions with their USDC (after all, it’s theirs). But all of these things require gas, which is why Spyre seems like the perfect use case for AA.
But here’s the thing: at Spyre, we have decided not to use Account Abstraction at all. Unfortunately, for the time being, there are significant drawbacks to AA.
GASP
The current generation of AA is sorta like ChatGPT trying to draw hands: it’s just not quite right.
Let’s backup and evaluate ERC-4337 through a holistic lens. It exists after many, many failed attempts to unite EOAs and SCAs into some sort of Smart Account To Rule Them All. The reason this ERC has made it so far is not because it is the best solution to the problem, but because it is the most pragmatic. Specifically, because it doesn’t change the protocol.
ERC-4337 has some wins for UX, but it also introduces new issues of its own. With this ERC comes the added complexity of userOps, the “Alt-Mempool” (sounds like someone who knew about mempools before they were cool), an entirely new network of Bundlers, a new economy for that network to operate under — eek. That’s a lot of stuff.
At the end of the day, this means a few things:
- Either you need to pay for a managed solution for your bundlers and paymasters, or you need to pay for the added burden of running additional infrastructure yourself.
- You will likely need to do some code-tweaking to operate around the concept of userOps rather than whatever you had been doing.
- In its present form, Account Abstraction makes pretty much everything more expensive than it was with plain old EOAs. There is more on-chain overhead, so gas fees go up across the board.
At Spyre, we are laser focused on the unit economics of skill-based games. We have to have a predictable and consistent model for how much it costs to process on-chain matches. This is so that we can optimize costs and give users the highest possible payouts. Higher gas fees mean that we have to take a larger rake from players to fix some UX problems.
In an ideal world, we want to pay for gas fees for users, but we want to pay the least amount possible, and without being beholden to additional managed bundler services.
Enter EIP-712 x Sharded Keys
EIP-712 has been around for some time. It’s actually already on stage but perhaps you didn’t see it because it was hiding behind that fern, stage-left. EIP-712 is simply a way to sign a payload such that you get a nice, clear message from Metamask or whatever EOA the user is using.
With EIP-712 we can take all the data we’d like for a user to submit in a transaction, let them sign it themselves, but then we can submit it for them and pay for gas ourselves.
Gas fees stay low, users see exactly what they are signing, and everyone stays in control of their own accounts: bingpot.
The remaining UX issue revolves around EOA management. Obviously, a Web2 user is never going to download Metamask but nor do we need them to. This is also a solved problem. For account management, we can use existing in-app wallet solutions like ThirdWeb’s In-App Wallet. In-app wallets give us access to non-custodial social/text/email login through sharded keys. This solution has been around for some time and it most closely mimics a Web2 user’s expectations already.
The combo of EIP712 plus in-app wallets gives us great, gas-free UX, and the benefits of low-cost EOAs.
The Future
Who knows what the future will bring, but it’s difficult to see a future in which the existing Account Abstraction solution can match EOAs on price point and simplicity. My personal guess (don’t quote me, unless I’m right) is that ERC-4337 is a temporary band-aid. That the time will come when we need a protocol level change to enable “true” smart accounts.
In the short-to-mid term, however, Spyre is able to provide a gas-free experience to users with minimal hidden overhead, paired with the excellent UX of in-app wallets.
Or, heck, maybe we’re completely wrong and we end up transitioning to AA. Regardless, we’ll always pick what most benefits the user and isn’t just a shiny new thing.
Follow our adventure on X.
Play our newest game: Hangman Clash.
Chat with us on Discord.
