WTF Is Anoma? Part 1: WTF Are Intents?

Part 1 – Intents

Introduction

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. 

• Intents, Counterparty Discovery, Solvers
• Applications (intents are already here so why do we need Anoma?)
• Typhon, Chimera Chains, and Multi-Chain Atomic Settlement

Intents Are More Than a Meme

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

Anoma Intents vs. Ethereum Txs

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. 

*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. 

Intents Aren’t (Just) Limit Orders

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.

• • Combinatorial Auctions: Market makers or power users can use intents to place all sorts of expressive bids based on their unique needs:
    • • Economic Complements: Buy two goods A and B at $10 for the package, but only $4 for each individually since they’re complements.

• • • • Economic Substitutes: Buy as much USDC or USDT as possible with some ETH.

• • • • Counterparty Discrimination: Sell at most two units of A, pricing it at $10 for counterparty C1, $9 for C2, or $8 for C3.

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.

• Crowdfunding: Crowdfunding is an interesting use case for intents as it involves many independent agents. Intents can enable many cool use cases:

• • • Risk-Reduced Investments: Commit to fund a project only if it receives commitments for more than X dollars. 

• • • GitCoin Matching Funds: Users pre-commit to donate to the winning projects, without knowing which they will be.
• • • Peer Pressure: Commit to fund a campaign only if your favorite influencer also commits to fund it. 
• P2P Lending: Lenders choose specifications like accepted collateral, LTVs, rates and quote assets and are matched with borrowers. When a borrower pays off collateral, the lender may still be willing to lend, in which case a solver can find another counterparty on their behalf. Lenders can bring their own oracles and bad debt can be isolated to certain parties. Under this model, there is no distinction between what is a DeFi lending protocol, NFT lending protocol, or another sector; any asset can be lent/borrowed against.
• OTC NFT Trading: OTC trading in NFTs usually revolves around swapping NFTs for NFTs and involves traits. For example, a user may be willing to sell a rare (and illiquid) NFT for “x” ETH but would also accept 2 of the same collection if it has certain traits. This is not a preference you can trivially put on-chain and so counterparty discovery usually involves Discord DMs and exposes users to phishing/scam risk during execution.
• Automated Actions: 
  • • Good After Time (GOAT) Orders: e.g., buy a token at a specific point in time in the future only if the price is within a specified range.
    • Subscriptions: pay-as-you-go models where users commit to pay a fixed amount per unit time for a predefined period.

• Multilateral Trade Credit Set-Off (MTCS): MTCS, also known as obligation clearing, is a unique and powerful technique to save liquidity in an economy.

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. 

• Any Multi-Domain and/or Privacy Preserving Application:
  • • Multi-Domain: An Ethereum user wants to buy a Bad Kids NFT on Stargaze. This path has numerous steps, wallets, research overhead, operational (i.e., bridging and wrapped assets) risks, and touches 4 blockchains spanning two ecosystems. We’ll talk about this one in-depth in the Typhon & Chimera Chain section.
    • Privacy-Preserving Apps: Intents are amenable to generalized privacy-preserving compute. With intents, we can build private multiparty bartering, private DAOs, etc. We cover the privacy aspect of intents later in this part.

Many other example use cases can be found in this excellent post by Propeller Heads, which we took inspiration from.

Counterparty Discovery & Solving

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.

• Solvers Bringing Their Own Liquidity: Solvers become the counterparty to the trade by acting as a taker.
• Partial Fills: A token being sold is bought by many independent parties collectively.
• Direct CoWs: Two intents are direct inverses of each other. 
• Ring Trades: Intent can be solved even without the presence of direct CoWs. For example, 3 intents produce a balanced tx, even though no pairs of intents satisfy each other’s preferences. 

Solver Incentivization, Censorship and DoS Resistance

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 Flow Control

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.

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.

Intent Settlement

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.

• Whitelists/Blacklists: Only send funds to X, Y, Z accounts, only perform ETH transfers, etc.
• Rate Limits: Do no more than X volume per day.
• Access Control: 2 out of X, Y, Z accounts must sign a transfer.

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 vs. Smart Contracts

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. 

Open Research Areas

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.

• Resource Pricing: As we saw, settlement-conditional fees can make it hard for nodes to properly account for the resources they consume. In addition to token gating and fees, we can see new web-of-trust type Sybil resistance techniques to emerge in the future. A user’s on-chain history, identity, and reputation will play a significant role here. 
• User-Interface Security: As execution moves off-chain, front-ends and wallets will have more responsibility in making sure users sign their intents accurately, as they intended. User interfaces will thus be playing a more involved role in security. How they will adapt remains to be seen. Can blind-signing hardware wallets become a thing of the past?
• Solver DAOs: There are reasons why solvers may want to coordinate with each other in the solving process. They can find value in aggregating their own liquidity to offer better guarantees in solving and reduce wasteful failed attempts to settle txs. In certain cases, solvers may want to coordinate with each other by forming a consensus protocol and/or running MPC among each other. The topology of the solver network will be taking shape accordingly.

Conclusion

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.