Beyond Transactions
What intents mean for crypto, how they work with storage proofs, AA, & rollups, and interesting protocols in the intents space
Intents – and their effects on account abstraction, storage proofs, rollups, and more – are creating interesting new dynamics for crypto. As these critical components have emerged, they’re uniquely reshaping UX, tx efficiency and design, and the balance between centralization and decentralization.
Intents, unpacked
Transactions are highly specific actions that the user wants to execute, while intents specify a goal the user wants to achieve within certain parameters. Generally, intents outsource the task at hand from the user and are capable of accessing multiple environments so users don’t have to manually operate over fragmented protocols. By not codifying every aspect of a transaction, more transaction expressivity and efficiency are enabled, and UX is improved.
As Paradigm puts it, “By signing and sharing an intent, a user is effectively granting permission to recipients to choose a computational path on their behalf.”
Users just want to trade at the best possible price, and generally, they don’t care what platforms need to be involved (one reason for the success of 1inch and the launch of 1inch Fusion as an early example of intents). Further, intents can generally be satisfied through many different routes, whereas a tx has one highly specific execution route. This is described visually below:
In some designs of intent infrastructure, once a user specifies an intent, it’s broadcasted to gossip nodes within a p2p networking layer. We then delegate the computational responsibility to entities called solvers (aka searchers / matchmakers), which, in a fully intent-centric protocol, are also builders (PBS required). Solvers operate to execute a user’s intent specification and produce a valid transaction. They compete against each other to satisfy the intent in the most efficient way possible, which a relayer then verifies, and finally validators on the intent network commit to. The flow here is the following: user sends intent to intentpool → gossip nodes broadcast in intentpool → solvers compete to execute tx in the mempool.
Intents are an open problem space, and we’re still not exactly sure how the UX will look, but the general goal is to make crypto applications easier for the user and more computationally flexible and efficient. A recent Bankless episode with Dan Robinson highlighted how the new design would be structured from a high-level user flow perspective. The user would see a similar interface on the web app as usual, but instead of signing an eth tx they sign an offchain message that then is routed to the MEV “black box,” which eventually turns the intent into a full tx that is then included onchain. An intent is a more general format for the user than an eth tx since it only specifies a starting point and ending point, versus what we currently have with gas, slippage, using only one DEX/AMM, etc – leading to better UX. Once the intent is expressed, it’s offloaded to the system which finds the best price for it; users just broadcast a message but don’t create a tx themselves. From there, any solver is free to fulfill the intent provided they can prove that they solved it in the most competitive way (e.g. highest satisfaction gradient) and the user gets the best “price” for whatever they are trying to do. In this sense, intents are much more attractive and flexible for end users than a classic onchain tx since they can be solved in various ways, usually leading to a quicker and cheaper process with fewer manual steps.
One applied example of intents can be seen in UniswapX. In UniswapX, Dutch auctions are used for intents where the price is set high and comes down gradually, and the order is filled as soon as it becomes profitable for someone to fill it. The benefits of this in a competitive market, as Dan points out, are less slippage and a better foundation for order flow auctions.
Uma Roy of Succinct gave great specific examples of txs vs intents in her presentation on intents, SUAVE, AA, and cross-chain bridging:
Intents in practice, and what they mean for intersecting categories
Intents may have wide-reaching implications for the following categories:
Bridges & rollups: Dan covers this in more detail in a recent Bankless episode, but the way UniswapX will likely approach intents that require bridging is the following: users can just express an intent to, for example, have USDC on Arbitrum instead of ETH on Ethereum. Then the proof of the fulfillment of the intent can be passed via a message-passing bridge to the destination chain.
Another element Dan mentioned was that it might be plausible in the future that market makers may pay individuals on the other side of the trade more than the standard market price to get funds onto a rollup since it may be more profitable in fulfilling an intent (e.g. because the market maker is rebalancing someone who is trying to exit).
In many classic bridge designs, money sits in the bridge contract (e.g. bridges custody funds on top of a rollup) which is often super vulnerable to hacks. With UniswapX, as Dan explains, the only funds that are at risk are the “swaps currently in flight,” or active swaps; e.g. a swapper expresses an intent to bridge funds → a filler on chain makes a promise to fill the order [bridge risk] → filler fills the order on the destination chain. This is huge progress for the bridging landscape because the exposure time is just the time the swaps are in flight, dramatically lessening the amount of funds at risk in the event of an attack.
Intents can reduce bridging complications since users don’t have to manually bridge assets (a long and expensive process). Instead, they just specify which type of token they want to own and which rollup / chain they want to own it on. The rest is abstracted away and constitutes a huge UX improvement for swappers. And ultimately, if we’re using intents to ease crypto’s massive UX problem, then users need to be able to access cross-domain environments so that their intents can be satisfied more efficiently by leveraging more liquidity and different tech stacks.
Zero-knowledge (storage) proofs: Zero-knowledge storage proofs are a new mechanism to transmit blockchain state across L1s/L2s/L3s in a trustless way. As an ecosystem of L2s and L3s emerges, latency in transmitting state information is becoming a more pressing issue, and storage proofs work to solve this in a quick and lightweight way.
Storage proofs may be able to work with intents in interesting ways. As mentioned in the above point, when a user specifies an intent to get assets on a rollup, bridging occurs, and the state of the destination chain is sent back via a storage proof to verify that the intent was fulfilled correctly / the chain is in the expected state. In this way, storage proofs could be generated to trustlessly bridge assets on supporting infrastructure.
Maybe in the future we’ll see fulfilled intents aggregated into a verifiable storage proof, or the opposite – aggregated storage proofs of different states in a part of the computational flow to fulfill an intent.
At the EthCC Modular Summit, Vitalik talked about proof aggregation in the context of L2s. In the below design, the proofs at the end are just signatures / privacy protocols, the proofs in the middle are aggregation proofs, and then Layer 2 proofs aggregate the aggregation proofs, and finally there’s one overarching master proof which is transmitted to the L1. Through proof aggregation, we can hugely reduce costs and optimize the proving process.
Recursive proving has also been explored through zkTree, originally introduced by the Polymer Labs team, and may in the future help enable zkEVMs, zkRollups, zkBridges, and zk storage proofs.
Account abstraction: Essentially, account abstraction works to upgrade EOAs (externally owned accounts, the current standard for tx generation) so they can be managed by smart contract wallets, or alternatively enables functionality directly within smart contracts to initiate txs. For intents, this new paradigm means that the intent layer may move from dapps directly to a user’s smart contract wallet as intents become more mature and sophisticated. Stanley He makes that argument here, pointing out that for AA to work with intents there could be an intent → userOp → bundler process (with intents flowing through wallet frontends first):
Though AA greatly improves UX, users still have to actually manually discover the best / most efficient platforms to use for swapping / bridging / LP’ing / etc. Intents aim to extract even this discovery layer away, so that the only thing the user is responsible for doing is specifying a starting state and a desired end state.
ERC-4337 introduces some designs to maintain decentralization, like a unified ERC-4337 mempool. The piece highlights that fragmented / smaller pools (with bundlers that have different policies) are naturally more vulnerable to censorship and attacks. Reducing this surface area can be done by having one implementation standard on each bundler so they’re compatible.
Great projects such as Zerodev, Fun, Stackup, and Rhinestone are building in this space.
Some have expressed concerns around centralization when it comes to intents. From David Ma of Alliance: “The point is that intents are hard to decentralize and therefore are increasingly silo’ed in centralized servers with permissioned reads and writes.”
Efficiency vs decentralization is a classic problem in this space. With crypto adoption so hindered by poor UX, creating solutions that lean towards centralization is tempting. Further, because some elements of intents rely on offchain actors / infrastructure, computation costs are extremely low – notably lower than a regular tx. Computation cost originating from clearing orders doesn’t have to run onchain (which would manifest as gas costs), it can just run on a market maker’s server. Naturally, moving parts of the transaction flow offchain increases centralization, and there are also worries around concentration of solvers (which we use to coordinate the volume of intents).
Intents have also been explored in the context of compliance (cc: Nikhil), where users could opt into the most “compliant” route of satisfying an intent. The tradeoff here would be cost and speed / efficiency, but ultimately it shifts the regulatory burden more onto the user / LP versus the protocol.
Projects
Many interesting projects are leveraging intents with components of AA, bridging, and multichain infrastructure in unique ways in an effort to enable access to various rollups and ecosystems, tap into greater liquidity, and provide a more efficient and easier experience for the end user.
I’ve highlighted some interesting ones here:
Essential
Essential is building a holistic intent architecture. They have three main projects: a constraint-based programming language for intent expression (more on the DSL here), an EIP for account-abstraction-based intents on Ethereum, and an intent-based protocol that reimagines the tx lifecycle from first principles. Essential differs from SUAVE in the following ways:
Essential uses a DSL in Rust which is purpose-built for expressing intents. SUAVE uses mEVM (Solidity) which has built-in syntax for preference expression, block building, etc. Further, intents are never executed in Essential’s architecture. Rather, they’re solved and then an execution trace that solves the intent is generated, and that execution trace is what is executed onchain. This is in contrast to SUAVE, which generates EVM opcodes as a part of their intents.
SUAVE is dealing with the encrypted execution space, while Essential’s protocol does not utilize encrypted execution to accomplish intent privacy. Essential's intents are included on-chain before they are decrypted and executed.
Essential’s consensus mechanism forces solvers to compete on objective intent satisfaction (0-1 satisfaction gradient), competitively encouraging high satisfaction for end users. To start, Essential is working on intents in both the Ethereum ecosystem as well as building out their own intent-based protocol.
Anoma
Anoma is creating an “intent-centric architecture,” where anyone can implement a fractal instance of the protocol and those protocols come together to form the Anoma ecosystem. For intents themselves, Anoma creates a signed partial tx for users to express their desired end state. As Jon Charbonneau notes, with Anoma MMs can even periodically update their intents: “E.g., ‘I’m willing to buy X for Y, but this order is only good for block height Z.’”
Like Essential, Anoma also differs from SUAVE. SUAVE is chain-agnostic and acts as a separate middle layer in the stack to help service intents, while Anoma brands itself as “an architecture that can be deployed as an L1, L1.5 or L2,” rather than a feature / layer in the stack.
SUAVE
Flashbots’ SUAVE is itself a blockchain that “can act as a plug-and-play mempool and decentralized block builder for any blockchain.” It’s tailored to facilitate the expression and execution of preferences (high-level the same as intents). The SUAVE stack is the following: a mempool where users can specify preferences, an execution network where solvers compete to execute user preferences, and a block building environment where solvers actually create blocks – which can then be accepted by other networks.
PropellerHeads
PropellerHeads is honing into a specific element of the intent architecture – solvers. By using the PropellerSDK, specifically their Solver API and Private RPC, users are more protected from MEV and receive better prices on their trades. The Solver API returns the best route to get the best price on a swap, by plugging into many liquidity sources and running optimization algorithms to search for the optimal routes. An example of routing combinations originating from 4 orders into 1 route done by a solver on PropellerHeads:
OKcontract
OKcontract is focusing on the concept of “low-level intents” by creating a standard to specify smart contract interactions, generating a transactional interface from the specification, and then allowing devs to embed the automated interface into any web page. This architecture is similar to Uniswap widgets that can be embedded into other sites – OKcontract wants to do the same but for every contract and in an automated way.
CoW Swap
CoW Swap built an early example of intents, enabling p2p-settled orders on a trading interface built on top of CoW Protocol. Currently, CoW Swap can settle orders on Uniswap, Sushiswap, 1inch, and Paraswap, and enable users to transact via signed messages (a gasless process). CoW Swap plugs into existing on-chain liquidity, versus having LPs on their platforms, and can leverage liquidity from other AMMs when there aren’t enough CoWs (coincidence of wants) on the platform.
Skip
A protocol that isn’t often seen as fulfilling intents, but can be construed as such within the IBC ecosystem, is Skip Protocol. Skip operates across Cosmos and reserves blockspace futures in order to help stakeholders gain more revenue and protect users from harmful MEV. Skip’s API routing solution finds the most efficient path for cross-chain experiences for end users, ultimately creating an intent-based user flow.
What’s next from here
The future comes fast in crypto. Intents are still very much at the start of the discovery and implementation phase, but it’ll be exciting to see what types of new companies pop up and what the category evolves into. Technical iteration happens quickly in this space, so we’ll undoubtedly see interesting new designs and implementations of these types of architectures in the near future. Abstracting as much as we can away from the user while maintaining decentralization and driving tx efficiency and expressivity is top of mind for the intents space. Hopefully, it will ultimately drive crypto adoption and improve efficiency. Dynamics between intents, AA, storage proofs, and bridging are still being explored, and how these pieces will work together will be integral to the crypto ecosystem’s maturity.
Huge thank you to rain&coffee, Alex Hansen, Kydo, and Aryan for informing my thinking on this piece.