Account Abstraction and SUAVE: How far are we from an Intent-Centric Ethereum?

“Intent” recently has become the center of Ethereum nerdy discussion, and dots are gradually being connected (Account Abstraction, SUAVE, order flow auction, etc.). This article will discuss how we can possibly complete the transition from “transaction-based interaction” to “intent-based interaction” and what unexpected outcomes could happen halfway that may thoroughly change the form of MEV.

Intents are already here

It’s unfair to talk about “intents” w/o mentioning Anoma. They have been building from ground up a blockchain architecture that’s natively intent-centric. So what are intents? This article is thankfully frontrun by Paradigm, so that I can borrow their definition:

“an intent is a signed set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party”

Let’s look at a real world example. Alice has 10,000 USDT on Ethereum, and with this money she wants to acquire as many GLP as possible, which is on Arbitrum. Today, Alice needs to first bridge her fund from Ethereum to Arbitrum, which requires optimally choosing a bridge. Luckily this can be done with a bridge aggregator like Bungee. After bridging USDT to Arbitrum, Alice now needs to decide which asset she uses to buy GLP — since GMX imposes dynamic fees to different assets when buying GLP to balance the pool, which means if the fees on USDT is too high, it may be profitable for Alice to swap USDT to another asset (i.e., ETH) and use ETH to buy GLP. To make the decision, Alice needs to compare the fee difference on GMX and transaction slippage between multiple assets. That’s a lot of work to do, and her calculation result may become obsolete when she signs the transaction — rates, prices and slippage change all the time.

With intents, the process would look totally different. Alice only needs to express her intent “I want to acquire as many GLPs as possible, at minimum 100,000, with 10,000 USDT on Ethereum” and an intent solver will do all the calculation and transaction for her, giving her only the end result: GLPs on Arbitrum.

In short, transaction = you specify HOW to do; intent = you specify WHAT you want, but don’t care how to achieve it.

Indeed, we are expressing intents right now on Ethereum already. Every swap using a DEX aggregator like 1inch is an intent: you only specify input amount and slippage tolerance, and let the routing contract find you the best routes. We call them “simple intents”. There’s also something I call “searcher intents”, as in searchers’ preferences on the ordering of transactions, in a Flashbots auction. This is important when we later dig into the implementation of intents. And then there’s “arbitrary intents”, as in users can express arbitrary intents and get them done.

A UX revolution

Blockchains have long been blamed for bad user experience, and many people deem UX as one of the major hurdles to the mass adoption of web3. Now that we have intents, an interaction paradigm that could make blockchain UX not only on par, but actually better than that of web2 today. Under current web2 setup, users with an end goal are still required to have knowledge of the paths, i.e., you need to know which app to use if you want to buy stocks/items/food… But intents enable to achieve end goals w/o knowledge of the paths. Native composability of blockchain dapps further makes this model scalable v.s. siloed web2 apps.

The Intent Layer

The vision sounds good, but we first need an intent layer where users express their intents and solvers compete to solve them. Anoma and SUAVE, Flashbots’ endgame for intents, are both trying to be THE intent layer for blockchains, while using quite different methodologies. It’s too early to compare them (nobody knows what an intent layer should look like yet), but one thing is for sure: building an intent layer is HARD. Many of its design principles actually contradict with each other, and it’s shown on SUAVE’s blueprint:

1. Credible commitment & Decentralization

A simple p2p network for intents (i.e., an “intent mempool”) is less likely to work, because it cannot guarantee both users and solvers’ commitment to the intent — for example, we need to make sure that a user will pay the amount she promises once her intent is solved, and a solver must follow the constraints set by users. A centralized solution could work, but of course we want a decentralized one, which leaves us only one option: a blockchain. Yes, that’s why SUAVE is itself a blockchain.

2. Privacy

We want solvers to provide the best execution for user intents, which requires as much information as possible; but at the same time don’t want malicious actors to exploit them, which entails at least some of the intents’ information to be concealed. Two problems are present: First, it is technically hard to make computable information private on a blockchain. Options are limited: TEE, ZKP, MPC. None of them is perfect, and Flashbots proposes to use SGX, Intel’s TEE, which has already drawn some critics on safety (and elegancy, compared to cryptographic solutions). Second, it’s unclear if there will ever exist a “right balance” of privacy. Flashbots’ latest product MEV-Share, or “ proto-SUAVE”, enables partial disclosure of transaction data from users to searchers. Whether that will actually make both users and searchers better off is yet to be seen: a backrun is only optimized if the searcher knows exactly the size and slippage of a swap, while zero information leakage makes it impossible to extract any value. Anything in between will reduce the maximum possible surplus.

3. Intent language/Protocol

Users also need a language to express intents. We want that language to be expressive enough for arbitrary intents, and that’s why SUAVE will use EVM/Solidity — it’s Turing Complete. But we also need a protocol that standardizes intents, and maybe limits the language, for two reasons: First, unlimitedly expressive intents are likely unsolvable, or unverifiable on-chain. Second, expressivity enables vague intents, vague intents generate more MEV, which we want to minimize. Another difficult balance to strike.

4. Cross-chain settlement & oracle

Since SUAVE is a standalone blockchain, for it to deal with intents from external domains (i.e., Ethereum), cross-chain settlement is involved. Ethereum users must deposit funds on SUAVE and commit to unlock them if their intents are solved. And for smart contracts on SUAVE to verify that, oracles are needed. Therefore, SUAVE will face every problem we have today with cross-chain bridges: security, speed, UX, trust assumptions, etc.

To recap: We want to use a blockchain to decentralize the intent layer, which introduces cross-chain settlement problem; we want to give more value back to users, which could also lead to more exploitation; we want users to express as they will, but also need to make sure what they expressed are solvable.

Intent Layer needs Account Abstraction

Account Abstraction is often reduced to “gasless transaction”, “seedless recovery”, and maybe “rate limit”. Yes, those are cool, but not cool enough. The coolest thing about AA lies in its architecture, making wallets the entry of intent.

Short recap on AA:

There are two types of addresses on Ethereum: smart contracts and external-owned accounts (EOA). EOAs can initiate transactions, but smart contracts can’t. Therefore most Ethereum wallets we use today are EOAs. There are smart contract wallets (SCW) like Gnosis Safe, but since a smart contract can’t initiate transactions, you need EOA(s) to prompt the SCW. SCW is good: as a smart contract, a wallet can execute arbitrary logics, opening up countless new applications to wallets, while EOAs can only sign transactions.

To enable users to use SCWs w/o needing a separate EOA, EIP-4337 introduces a new transaction type called User Operation, and a new role called Bundlers. After EIP-4337, users flow of SCWs becomes:

Users send UserOps (indicating actions they want wallets to do) to the UserOp mempool — → Bundlers validate and “bundle” UserOps together, execute them (sign, pay gas fee), send the transaction to the EntryPoint contract — → the EntryPoint contract pass transactions to SCWs, prompting the SCWs to do what users asked — → Bundlers get gas fee refund from EntryPoint contract (we will skip PayMaster for simplicity).

So why would an intent layer need AA? We still use SUAVE as an example. There are two scenarios:

1. SUAVE directly addresses user intents

In this case, as we mentioned, users would need to deposit funds and check note write smart contracts on SUAVE. This would be a huge downgradation in UX. And it’s very counterintuitive — why do I need to move funds to and interact with a different chain just to do something on Ethereum? Here, AA and SCW come into play: you can wrap all interaction logics with SUAVE into an Ethereum wallet. Fund deposit, verification of execution, everything. This doesn’t solve any fundamental challenges to SUAVE — we still need a trustless bridge, an intent protocol, etc. But at least UX per se can be largely saved by SCW. An EOA simply cannot do that.

2. SUAVE only addresses searcher intents

It’s clear that Flashbots will iteratively build SUAVE on top of its current offerings, namely MEV-Boost and MEV-Share. Considering the difficulty of building a feasible protocol for arbitrary intents, it’s very likely that SUAVE will NOT touch user intents in a long time. Instead, it will look more similar to the current Flashbots, who mainly work with preferences on transaction ordering, or what I call “searcher intents”. In this case, there has to be someone who turn users intents to transactions first, then submit transactions to SUAVE, meaning the intent solving will happen prior to SUAVE.

So who’s going to be the intent layer in this case? Today it’s dapps, just like DEX aggregators solving simple intents. With AA matures over time, SCWs will likely become the de facto intent layer and take the lunch away from both dapps and SUAVE. And here’s why:

Exclusive Intent Flow redefines MEV

Currently, MEV is about reordering existing transactions. However, with intents, most of the value will be extracted already BEFORE transactions are even created, and MEV (if we still call it by this name) will be about creating transactions from intents. Solvers, after receiving intents, can tweak the execution freely as they want (as long as constraints are met) and insert their own transactions into intent-generated transactions, bundle them together as ONE atomic transaction.

The most straightforward example will be a sandwich attack: Right now, sandwich attackers need inventory to move prices against user transactions, and have to trust relays, builders and proposers NOT to unbundle their sandwich bundle (otherwise they get absolutely nuked). But an intent solver would be able sandwich a user intent risk-free & capital-free: He only needs to take a flashloan and sway the price before user’s swap, and swap back after user’s swap, repay flashloan and take profit, all in one transaction because all steps involved are technically HIS.

Wait, doesn’t this sound familiar? Let’s take a look at this wonderful drawing again:

Yes. Bundlers are very much like intent solvers. They receive UserOps, turn them into transactions, and take advantage of them at will because technically those transactions belong to them.

So you are saying bundlers will become the next searchers. What does it have to do with wallets? The key point is, UserOps AREN’T intents. UserOps are pseudo-Ethereum-transaction whose nonce and signature fields usage is not defined by the protocol but instead by each account implementation. Thus there has to be a “intent-to-UserOp” process. And that’s exactly what an intent layer does.

If we believe that SCWs will dominate, then there’s only one logical outcome: Wallet(s) become the intent layer. Intents and order flow that previously go to dapps will be intercepted by wallet frontends. The users flow will become something like this:

Notice that intent solvers on SCW frontends are very likely to simultaneously act as bundlers, who may also be block builders. Such vertical integration gives rise to the so called “Exclusive Intent Flow (EIF)”, just like EOF (Exclusive Order Flow) that has been widely discussed in the MEV community. In my previous article I argued that EOF is less of a problem because users can easily switch executors if they find themselves being squeezed. But intents will make it different this time: Users don’t own their transactions anymore. Of course they can switch intent layers too, but the cost will be much higher than switching RPCs like today.

So (un)surprisingly, intents will further centralize MEV. The good news is, building a fully functional intent layer is difficult for both Flashbots and any wallets, so we won’t see EIF in its full form for a long time. The bad news is, wallets can iterate too. Remember, dapps are intent solvers today, and SCWs can have plugins, or in-wallet dapps. Installing a wallet plugin to your wallet will be as normal as installing an app to your Android phone from Google Play. Those wallets plugins will act as the earliest intent solvers, and all intents they attract will be first funneled to the wallet. An intent layer built from the bottom up.

Now we can answer the question in the topic: We are still far far away from an intent-centric Ethereum, but intents will start playing a bigger role in user flow, which will inevitably change MEV landscape permanently, with smart contract wallets becoming a strong value extractor. Users sacrifice ownership over their transactions for better UX, hoping for an ingeniously designed intent layer to equitably return them the value their intents generated.