Anoma and Intent Centric Design
Anoma is taking a radical new approach to how blockchains function. Today, users submit transactions to platforms like Ethereum. These transactions must be specific, defining the exact parameters of the transaction.
Anoma’s vision is that in the future, users will not submit transactions, but will instead submit “intents”; a user will state the outcome that they would like and a network of automated solvers will determine the transactions to get there. Intent centric design, pioneered by Anoma, is gaining traction. This month we are going to dig into what intents are, how they work and the direction that intent centric protocol design is moving towards.
In mid-2021 we detailed our investment case for Anoma. In this investment case, we discussed Anoma’s novel matchmaking system that allows users to “gossip” (broadcast) their trading intents. But what does it mean to have an “intent”? Blockchains today are transaction centric; every action is a transaction. Users of blockchains must have a base understanding of how blockchains work to correctly specify their transactions.
For example, let’s assume that I want to trade USDT into ETH on Ethereum. There are several steps that must be completed in the transaction process including:
1. Defining the application / contract that I am interacting with. For example, do I want to use a decentralized exchange like Uniswap or Sushiswap, or an aggregator like 1inch or CowSwap?
2. Defining the parameters of the transaction:
- The amount of USDT I want to sell.
- The level of slippage I am comfortable incurring and therefore the minimum ETH I will receive back.
- The gas fees I am willing to pay in this transaction.
3. Signing the transaction to submit it to the network.
The specificity required to make a single transaction makes using blockchains a user experience nightmare, even for more sophisticated users. Users must know about the different applications that they can use, and it is challenging to understand the subtle differences between applications, including fee models and how the applications work. Defining a transaction then requires a master’s degree in protocol design, with familiarity with gas limits, gas prices, slippage, approval limits and wrapped tokens all expected.
This is where intents come in. Instead of going through the transaction process, in an intent driven system the process reduces to:
1. Define how much of asset x I wish to spend and the minimum amount of asset y that I wish to receive back.
2. Sign the intent.
All other decisions are left to the protocol and “solvers”. So how does this work?
With transactions, the user defines the exact computational path for a transaction to take. With intents, the user allows economic agents using the protocol to determine the computational path on behalf of the user. These agents are referred to as “solvers” or “matchmakers” and it is their job to calculate the optimum route of transactions that an intent can take to be satisfied. Importantly, multiple intents can be satisfied in a single transaction. If I am looking to swap asset x for asset y, and you are looking to swap asset y for asset x, then we can settle two separate intents in a single transaction between the two of us. It is possible to solve multiple intents in a single transaction.
For matchmaking to work, it is necessary for all intents to be known to the solvers. In the transactional model, most blockchains have what is known as a “mempool”. This is a blockchain node’s waiting room for queued transactions, those that have been received but not validated, and pending transactions, those that have been validated by a node but not yet included in a block. When you sign a transaction on Bitcoin, your transaction enters the Bitcoin mempool where it waits to be included in an upcoming block. The higher the gas fee that you pay, the higher priority your transaction becomes in the mempool. Importantly, the mempool is public, meaning that it is visible to everyone, and in the case of Bitcoin and Ethereum it is permissionless, meaning that anyone can run a full node and participate in consensus.
In the intent model, there is a step before the transactional mempool, which we can term the “intent pool”. This is where intents first land. Solvers review the intent pool, trying to determine computational routes that would allow intents to be satisfied. When a route is discovered, the solver can execute transactions on behalf of the user to satisfy their intents. There are a variety of potential designs for such an intent pool.
- Transparent or private:
- There are two types of transparency that can be assessed. Firstly, there is transparency of the intents being submitted. Secondly, there is transparency of the matchmaking process.
- Allowing transparent intents to be submitted may result in MEV (maximal extractable value) opportunities for traders. This is a common problem on smart contract platforms today that have transparent transaction mempools. Traders can review intents entering the pool and take advantage of the knowledge of unsettled transactions.
- In terms of the matchmaking process, transparency is beneficial. It proves that solvers are acting honestly, that the quality of matchmaking is high, and it allows for auditing of the process.
- Permissioned or permissionless:
- A permissionless pool is one that can be accessed by anyone running up a node. This is censorship resistant and maximizes decentralization. However, there is a risk that the pool could be used for MEV. The solvers could abuse their ability to execute transactions by trading against users whose intents have not yet been settled.
- A permissioned pool helps prevent MEV as all the solvers are known and this should guarantee some level of quality assurance. They will have a reputation to uphold and could be removed from the solver set for malicious behaviour. However, the trust assumptions of permissioned pools run counter to the ethos of decentralization.
The ideal solution is something that combines privacy of intent submissions, with transparency of the matchmaking process and a permissionless system that anyone can take part in. This combination is technically challenging to implement and is what Anoma is working towards. More specifically, Anoma defines itself as:
“An intent-centric protocol for composable privacy, decentralized counterparty discovery, solving, and atomic multi-chain settlement.”
To break this down:
- Intent-centric protocol: a protocol that is generalized and focused on users stating their intents rather than their transactions.
- Composable privacy: allowing users to define how private they want their transactions to be.
- Decentralized counterparty discovery and solving: creating a system where matchmaking can take place efficiently and in a decentralized manner.
- Atomic multi-chain settlement: while the intents are stated on Anoma, the transaction settlement can occur on other chains.
At CMCC Global, we are excited by an intent centric design future. It is a future where users can focus on their preferences and can leave networks of solvers to matchmake on their behalf. In this model, users have a higher degree of assurance as they only need to specify the end state that they are comfortable with and do not need to concern themselves with challenges of transaction execution. This will result in a drastically improved user experience and will help onboard millions more users into a user-friendly digital asset ecosystem. Anoma is pioneering the research and development going into intent centric design and we look forward to supporting the team as they roll out Namada this year, their first instantiation of Anoma, and the Anoma mainnet in 2024.
Last month it was announced that CMCC Global was the lead investor in the latest round of fundraising for Anoma. Other Anoma investors include Coinbase Ventures, Polychain Capital, Delphi Digital, Electric Capital, and Maven 11. This investment was made from both our Digital Asset Fund 4 and Fund 3B.
