Create
Data Widget
Data Dashboard
Part 1 – Intents
What is Anoma? This is a surprisingly hard question to answer. Anoma is not a blockchain. Or, more accurately, not just a blockchain. Anoma is an architecture. Let’s check the pre-release Anoma whitepaper for some hints.
“Programmable settlement architectures do not enable counterparty discovery and solving, both of which are necessary to build the majority of interactive multiparty applications. The architectural constraints of programmable settlement result in contemporary application protocols that have at least one Web2 component, which becomes the centralization point. We present Anoma, a unified architecture for full-stack decentralized applications. Anoma is designed following the principles of intent-centricity and homogeneous architecture / heterogeneous security, together constituting a declarative paradigm for building decentralized applications.
…
Anoma’s architecture also exposes novel primitives, such as composable privacy, which enables applications to handle transparent, shielded, and private state and operations; and multi-chain atomic settlement, which allows users and applications with different security preferences to obtain atomicity.”
If the highlighted terms above don’t mean much to you for now, don’t worry; that’s why they are highlighted. We assure you they will start to make more sense as we become familiar with the Anoma architecture and the unique problems it aims to address, which is the purpose of this report.
Due to Anoma’s vast scope, we’ve broken up this report into three sections, to be released as separate reports.
Let’s start off with intent-centricity.
While the intent-centric Anoma architecture has been under development for many years, intents are a new term for many. From what we can observe, there is not yet a canonical definition for intents. Some consider intents to be not that different from txs or even just a new term for limit orders. This is pretty common in cryptospace where all the words are made up.
The good news is that we do have some rough consensus on what users can do with intents. Intent-centric execution is generally understood as a paradigm where users express what they want and rely on third-party agents and intermediaries to make it happen. For the sake of clarity, users retain custody of their assets, but the complexity of interacting with blockchains is abstracted away from users and pushed towards these sophisticated third-party agents. A major motivation here is simplifying UX.
Intents are said to be declarative, as opposed to imperative. In intent-centric execution, users can define what they want without being prescriptive of the intermediate steps needed to get there. Intents only care about the “what” and don’t care about the “how.”
While Anoma intents conform to this rough definition, Anoma has its own formalized definition for what constitutes an intent.
Anoma intents are defined as binding commitments of preferences over state space. Put simply, they are signed off-chain messages that authorize one or more future states. For example, the signer of [-2000 USDC, +1 ETH] intent declares “I authorize any future state where I have 1 more ETH and 2000 less USDC and I don’t really care how that may happen.”
The ETH that the user is asking for may be sourced from a single party or many independent parties. The user isn’t interested in who their counterparties will be or what motivations they might have.
Indeed, there are no guarantees that the user will get what they want. Perhaps there will never be a counterparty to credit them. The user has signed a preference over a state but that state doesn’t exist yet. For it to be actualized, the user’s intent needs to meet other intent(s) with compatible preferences and get settled. In the simplest case, we can imagine our intent [-2000 USDC, +1 ETH] getting matched with an exact mirror image of it [+2000 USDC, -1 ETH].
In practice, intent matching doesn’t require a direct coincidence of wants. We don’t really need another person doing a same-size trade in our exact inverse direction. As we explain later, intents with compatible preferences can be identified and matched in many different, complex ways involving many independent counterparties. This process is referred to as counterparty discovery and solving and it’s performed by permissionless agents known as solvers running special algorithms.
From the user’s perspective, it all looks like a magic box. Users don’t know or care about the intermediate steps of solving. If a successful match is found, intents can settle on-chain and be verified by the user (more on settlement later). Once verified, the user will directly “jump” to the future state they had committed to, or else they will stay in their current state.
Source: Anoma Docs
Let’s see how Anoma’s intent-centric execution compares to the tx-based execution we are used to in Ethereum. Note that we use EVM as an example but the general remarks apply to all Von-Neumann VMs.
As a refresher, in EVM, txs don’t mandate a future state; they authorize an execution path. Txs pass a message to a smart contract holding a piece of code and storage. The contract takes the message as input and runs its code in a step-by-step fashion. At the end of execution, it potentially calls some other contract to pass over the execution control. The execution continues until it successfully terminates or runs out of gas.
Contrary to Anoma intents, which can only result in a binary state change, Ethereum txs may transition the state arbitrarily depending on the execution path. The execution path is determined by the order in which txs get executed. The execution ordering matters!
We take a moment to reflect on our findings. Below, we compare the properties of Ethereum txs to Anoma intents.
Ethereum Tx | Anoma Intent |
Step-By-Step, Imperative Execution | Commitment Based, Declarative Execution |
Authorizes An Execution Path | Authorizes A Future State |
End State Depends on The Order Of Execution | The Order Of Execution Doesn’t Matter |
On-Chain Execution Only (Execution & Verification Are Interleaved) | Execution Off-Chain, Verification On-Chain |
Settlement Is Guaranteed | Settlement Isn’t Guaranteed* |
Counterparty Is Known | Counterparty Is Unknown |
State Change Is Arbitrary | State Change Is Binary |
Doesn’t Need Other Txs To Settle | Needs Other Intents To Settle |
Settled By The User | Settled By Third Party Agents |
*An on-chain execution path may not be found in the absence of compatible counterparties. Users may specify an expiration date on their intents to make sure their intents get invalidated in such cases.
By now, we have a good foundation on how Anoma intents differ from Ethereum txs. To truly appreciate their power, let’s see most use cases they can enable.
Our example [-2000 USDC, +1 ETH] intent is a limit order; it only commits to an exchange price for a trade. While limit orders are an important use case for intents, they’re only one of the use cases. Intents can express any form of generalized commitment. For example, it’s entirely possible for intents to emulate an AMM order by committing to trade against a xy = k curve. Indeed, intents can be programs or even entire algorithms encoding fairly complex commitments. These can be conditional or unconditional. They may also depend on other commitments (so-called higher-order commitments) paving the way for powerful applications that would otherwise not be possible.
Below, we take a look at some example use cases that intents can enable.
Expressive bidding better approximates the motivations of power users in a marketplace. It can be used in any type of marketplace (financial trading, power grids, logistics, carbon credits, etc.) to increase efficiency. Historically, a notable challenge of expressive bidding venues has been the infeasibility of matching multi-dimensional bids due to computational complexity. With the progress in deep tech and AI, we might see this becoming a non-issue over the next few years.
The idea in MTCS is simple. If Alice owes Bob 1 ETH, Bob owes Greg 1 ETH, and Greg owes Alice 1 ETH, no one actually needs any “money” to fulfill their obligations. All we need is to recognize that the total obligations form a closed loop; all debts can offset each other and be cleared.
Similarly, in the real economy, companies frequently commit to trading obligations. MTCS acknowledges that an account payable of one company is an account receivable of another. In theory, as long as these loops in the trade graph can be identified, companies can clear their obligations by netting them out against each other. This reduces their cash flow concerns and increases productivity in the economy. MTCS is already deployed in certain economies and studies show substantial liquidity savings. It’s also worth noting that MTCS is part of a broader movement known as collaborative finance, or in short, CoFi.
In the future, intents and solvers can enable MTCS or similar techniques for companies to clear their obligations and settle them on-chain without relying on centralized clearing houses.
Many other example use cases can be found in this excellent post by Propeller Heads, which we took inspiration from.
Anoma intents consume & create some “resources.” Somewhat grossly oversimplifying, in our intent example [+1 ETH, -2000 USDC], we can think of the resource being created as 1 ETH and the resource being consumed as 2000 USDC. Intents are deemed unbalanced when the resources they consume & create of the same type don’t cancel each other out. To pass a balance check, the sum of created resources must equal to the sum of consumed resources, for all types of involved resources.
Technically speaking, this balance check is the only thing that separates an Anoma intent from an Anoma tx (not to be confused with an Ethereum tx). Put simply, in the Anoma world, a balanced intent is called, you guessed it… a tx. By the same logic, Anoma intents are just partial Anoma txs.
Intents are combined by solvers in the p2p intent gossip network. When two Anoma intents are combined, they produce a composite intent which is yet another intent whose resources are an aggregation of those of its constituent intents. Intents can be combined with each other for as long as the solver(s) want. Eventually, solvers form a tx that passes the “balance check,” at which point they may choose to settle it on-chain.
Below, we see some unique ways intents can be matched to form fully balanced txs.
A network that’s *both DoS and censorship-resistant* is very challenging to achieve. For this, Anoma’s intent gossip layer is designed to be path-authenticated by default; all gossipped messages are signed by the sender node, forming a chain of signatures traceable all the way back to their originator. Path authentication plays a crucial role in DoS and censorship resistance. First, we expand on censorship resistance.
In most cases, solvers are likely to be profit-seeking agents. They execute and settle intents in exchange for fees, which are conditional on settlement; intents carry fees that can only be collected by solvers if and when they get settled on-chain. This creates a competitive environment where solvers compete against each other to be the first to settle intents. Solver competition is beneficial and desired as it improves the execution quality (speed, price, etc.) for users.
On the other hand, if incentives aren’t properly handled, competition can get out of hand, incentivizing greedy behavior in the network. Primarily, nodes can start to “hoard” intents to gain a competitive advantage in settling intents which would hinder censorship resistance for users. Path authentication can elegantly address this by laying the foundation for incentive mechanisms that encourage wide propagation of intents.
Consider the example below.
A solver observes 2 intents, [+2 ETH, -4 NFT] and [-1 ETH, +2 NFT], which, although compatible, don’t form a fully balanced tx. To form a full solution, the solver needs to find additional compatible intent(s). To come up with a full solution, the solver could take their time to observe new incoming intents. However, this is risky as there may be other solvers dealing with the same intents. If the solution is settled by another solver, they could lose the opportunity to collect any fees.
Path authentication offers an alternative by allowing nodes to prove their efforts to the network. Nodes can instead put a partial claim on fees and pass their partial solution [+1 ETH, -2 NFT] to other nodes for them to continue the solving process. Upon eventual settlement, they can each earn their fair share for their contribution in gossip and solving. In this manner, the intent gossip layer can be imagined as an incentivized data availability layer. One can imagine that even in the presence of giant solvers with deep liquidity and closed-sourced algos, smaller solvers can do their part and earn fees, continuing to contribute to the censorship resistance of the network.
Path authentication will also be crucial for DoS resistance. With settlement-conditional fees, solvers spend computational resources without any guarantees of getting paid. Reflecting back on the history of account abstraction (AA) in Ethereum, we know that this opens the door for cheap DoS vectors. Path authentication can play an important role here in protecting nodes against malicious actors. Namely, nodes can keep track of their peers’ (as well as users’) behaviors. Over time, they can establish their own local trust graphs to decide who to trust in the network and to what degree.
Information control in crypto mostly remains an unaddressed problem. Generally speaking, users lack the ability to control what information gets disclosed to whom. In most cases, all user activity information is exposed to all on-chain observers. This fundamentally limits the use cases that decentralized applications can promise to businesses and retail users.
For those interested in a complete overview of the privacy landscape, we recommend our Everybody Needs Privacy report.
The Anoma architecture paves the way for novel privacy-preserving apps through its unified execution environment (EE) known as Taiga. To appreciate Taiga, we must first understand what is meant by information flow control.
Privacy is a meaningless notion in the absence of an observer. When we talk about privacy, we must first define who the observer is. In our context, observers fall into two camps. We might be dealing with observers of the on-chain activity (which can be pretty much anyone in the world) or off-chain agents such as solvers and gossip nodes. Additionally, the information we’re concerned with might be about “the who,” i.e., the identity of the intent signer, or “the what,” the function and/or data expressed in the intent.
Based on this framework, Taiga defines three types of intents: transparent, shielded, and private. Shielded intents hide “the who” from everyone but expose “the what” to off-chain ZK-provers. Private intents take it a step further and make use of a variety of privacy-preserving solving methods (TEEs, MPC, Threshold FHE, etc.) to also hide certain information about “the what” from solvers.
Transparent Intent | Shielded Intent | Private Intent | |
“The Who” | Exposed | Hidden | Hidden |
“The What” | Exposed | Exposed | (Partly) Hidden |
The Observer | Everyone | “The what” is hidden from on-chain observers but exposed to off-chain prover(s) | Everyone |
Taiga is unique and powerful in two main ways.
Taiga is a unified execution environment that offers composable privacy. Composable privacy means developers can ship applications and have users interact with each other within the same application via transparent, shielded, or private intents. This makes privacy a user choice and stands in stark contrast to the current status quo where privacy is always an application/infrastructure choice (a DEX is either built to be private or transparent).
As the intuition goes, there is a fundamental tradeoff between counterparty discovery and privacy. An intent that hides information about “the what” can be processed more fairly but may have a harder time finding compatible counterparties. Consequently, the market can price transparent, shielded, or private intent-solving differently based on the quality of execution.
It’s also worthwhile to know that there exist some research challenges. Particularly, while solvers can match shielded intents with transparent intents and vice versa, the feasibility of composing them with private intents remains to be an open research problem.
Most, if not all, privacy projects today only focus on information control at the settlement layer. This is understandable as it’s urgently needed. We first and foremost want users to be able to hide certain information from the observers watching on-chain activity. However, in doing so, projects often sacrifice information control at the counterparty discovery layer. Contrarily, Taiga focuses on both information control at the settlement and counterparty discovery layer.
Privacy at the settlement layer is commonly done via ZKPs shielding on-chain data. However, ZKPs are very restrictive when it comes to privacy. They are typically only useful in special cases where users prove properties of some state that they exclusively own. This is suitable for payments or identity-related apps but not suitable for applications where there are multiple users interacting with each other.
Commonly, multi-user apps get around this limitation by introducing a shared ZK-prover that collects all private user data, performs some computation over it, and posts ZK-proofs of computation on-chain on behalf of the users. This, at best, offers Web2-style privacy. While the user activity is hidden from on-chain observers, it gets fully exposed to a single, shared, centralized solver; i.e., ZK-prover. It might also add new challenges for permissionlessness and censorship resistance.
Taiga offers something unique in this respect. As intents don’t assume immediate settlement, they can be executed over many partial steps by independent solvers. A solver can match some shielded intents with some other shielded/transparent ones and pass ZK-proofs of this matching to other solvers for them to continue the solving process. Proofs generated on the edges of the network by independent parties can be composed with each other.
We end up with an architecture where no single observer gets to have a complete picture of the partial executions that lead up to the settlement of a tx. This is shown in the diagram below, where three solvers each have local visibility on some intents but no one has full visibility.
Last but not least, Anoma is also focused on information control at the settlement layer. Indeed, the very first application to launch in the Anoma ecosystem will be Namada; a privacy-preserving settlement layer. Namada’s unique offering is a one-of-a-kind multi-asset shielded pool (MASP) where all fungible as well as non-fungible assets can share one anonymity set. This, in turn, allows owners of these assets to form one big anonymity set contributing to each other’s privacy. Namada will soon launch as a Cosmos & IBC-compatible app-chain with the purpose to become the multichain privacy layer with an initial focus on Ethereum and Cosmos ecosystems.
An Anoma tx lifecycle looks as follows: users sign intents → intents are gossiped in the p2p layer → solvers match compatible intents and form txs (counterparty discovery & solving) → txs are settled on-chain. In this section, we’ll take a closer look at settlement.
For txs to settle, they need to be verified on-chain. The verification is done by on-chain functions known as predicates. Each account in Anoma (users as well as tokens) has an associated predicate, which constrains the set of possible future states authorized by that account. The easiest way to conceptualize predicates is to think of them as restrictions one may put on their bank account or smart contract wallet.
Intents and predicates are similar in functionality; they both commit to some preferences over the state space. The main difference is that intents live off-chain as ephemeral expressions of preferences whereas predicates live on-chain as persistent expressions of preferences (although they can be updated at any time). Together, they form a two-layered authorization scheme. A tx must satisfy both to successfully settle on-chain.
The main role of predicates is to ensure atomic (all or nothing) settlement. In order for a tx to settle and advance the on-chain state, the tx must satisfy predicates of all accounts it touches.
For example, an ETH<>USDC swap between Alice and Bob can successfully settle if and only if predicates for Alice, Bob, ETH, and USDC are all satisfied. If the state transition doesn’t satisfy any single one of these involved accounts’ VPs, it will fail and the on-chain state won’t change for any of them. Put simply, state transitions succeed if all involved parties give a thumbs up, or else they fail.
Predicates and smart contracts are similar in some ways and dissimilar in others. While both are on-chain, code predicates are only concerned with verification and not execution. They don’t perform step-by-step imperative execution. Given a tx, they simply check if they are happy with it and return a boolean; either authorize it or not.
In this respect, intents & predicates potentially promise a much more secure way for users to interact with applications. Users no longer have to give unrestricted access to smart contracts and reason about the op-codes in their execution path.
Another notable difference between the two is that the functions run by predicates don’t own any state. As they are pure functions, the verification can always be fully parallelized.
Smart Contract | Predicate |
Lives On-Chain | Lives On-Chain |
Code and Storage | Pure Function |
Can Return Any Data Type | Returns A Boolean |
Main Role: Execution (Step-By-Step) | Main Role: Verification (Atomic) |
Consumes On-Chain Fees | Consumes On-Chain Fees |
Declarative execution has a number of open research areas that deserve further exploration. As we finalize the first part of our series, we leave you with some of our departing thoughts here.
With this, we conclude Part 1 of our Anoma series. Our focus in Part 2 will be on the application layer. We will highlight a growing trend among prominent dApps to move towards intent-based architectures. We will also analyze the unique value-adds of the Anoma architecture for these existing dApps and new ones to come.
Special thanks to Cheryl Ho for designing the cover image for this report and to Brian McRae for editing.
Delphi Pro is our institutional-grade crypto research and analysis offering, providing full market coverage across deep-dive reports, analysis, data and community.
Starting at $499 a month**
Create a free account* Team features available on multi-seat purchase.
** Based on purchase of annual subscription.
Readers also enjoyed