Delphi Digital: Understanding "Intent-Centric" from the Perspective of Anoma Architecture

Author: Delphi Creative

Translator: Huo Huo, Blockchain in Plain Language

What is Anoma? Anoma is not a blockchain. Or, more accurately, it is not just a blockchain. Let's take a look at the pre-release Anoma white paper for some hints.

"The programmable settlement architecture fails to achieve counterparty discovery and resolution, both of which are essential for building most interactive multi-party applications. The limitations of the programmable settlement architecture lead contemporary application protocols to have at least one Web2 component, which becomes a centralized point. We introduce Anoma, a unified architecture for full-stack decentralized applications. Anoma's design follows the principles of intent-centric and homogeneous architecture / heterogeneous security, which together constitute 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 states and operations; and multi-chain atomic settlement, allowing users and applications with different security preferences to achieve atomicity."

If the highlighted terms above don't mean much to you right now, don't worry; that's why they are highlighted. We assure you that as we become familiar with the Anoma architecture and the unique problems it aims to solve, they will start to make more sense, which is the purpose of this report. Due to the broad scope of Anoma, we have divided this report into three parts, published as separate reports.

1) Intent, Counterparty Discovery, Solvers

2) Applications (Intent already exists, why do we need Anoma?)

3) Typhon, Chimera Chain, and Multi-Chain Atomic Settlement

1. Intent is More Than Just a Meme

Let's start with intent-centric.

While the intent-centric Anoma architecture has been developed for many years, the term intent is still new to many people. From our observations, intent does not yet have a standardized definition. Some people believe that intent is not much different from a trade, or even just a new term for a limit order. This is common in a crypto space where all words are composed.

The good news is that we have reached some rough consensus on what users can do with intent. Intent-centric execution is often understood as a paradigm where users express what they want and rely on third-party agents and intermediaries to achieve it. To clarify, users retain custody of their assets, but the complexity of interacting with the blockchain is abstracted away from the user and pushed onto these complex third-party agents. A major motivation here is to simplify the user experience.

Intent is considered declarative rather than imperative. In intent-centric execution, users can define what they want without specifying the intermediate steps required to achieve their goals. Intent only cares about "what," not "how."

While Anoma's intent fits this rough definition, Anoma has its own formal definition of intent.

Exceptional intent is defined as a binding commitment to a preference over a state space. In short, they are signed off-chain messages that authorize one or more future states. For example, the signer of the intent [-2000 USDC, +1 ETH] declares, "I authorize any future state where I have 1 more ETH and 2000 less USDC; I don't care how this happens."

The ETH requested by the user may come from a single party or multiple independent parties. The user is not interested in who their counterparties are or what their motivations might be.

In fact, there is no guarantee that the user will get what they want. Perhaps there will never be a counterparty who believes them. The user has signed a preference for a certain state, but that state does not yet exist. To realize it, the user's intent needs to be satisfied by other intents with compatible preferences and resolved. In the simplest case, we can imagine our intent [-2000 USDC, +1 ETH] matching with its exact mirror [+2000 USDC, -1 ETH].

In practice, intent matching does not require a direct overlap of demands. We really do not need another person to make the same-sized trade in the exact opposite direction. As we will explain later, intents with compatible preferences can be identified and matched in many different, complex ways involving many independent counterparties. This process is called counterparty discovery and resolution, executed by permissionless agents known as solvers running special algorithms.

From the user's perspective, all of this looks like a magic box. Users do not know or care about the intermediate steps of the resolution. If a successful match is found, the intent can be settled on-chain and verified by the user (settlement will be detailed later). Once verified, the user will "jump" directly to the future state they committed to, or they will remain in their current state.

Source: Anoma Documentation

2. Anoma Intent vs. Ethereum Transactions

Let's see how Anoma's intent-centric execution compares to the transaction-based execution we are used to in Ethereum. Note that we use EVM as an example, but the general description applies to all von Neumann VMs.

To recap, in the EVM, transactions do not mandate future states; they authorize execution paths. Traders send messages to smart contracts that hold a piece of code and storage. The contract takes the message as input and runs its code step by step. At the end of the execution, it may call other contracts to pass control of execution. The execution continues until it successfully terminates or runs out of gas.

In contrast to Anoma intents, which can only lead to binary state changes, Ethereum transactions can arbitrarily transform states based on the execution path. The execution path is determined by the order of transaction execution. The order of execution matters!

Let's take a moment to reflect on our findings. Below, we compare the properties of Ethereum transactions with Anoma intents.

Ethereum Transactions | Exceptional Intent: --- | --- Sequential, imperative execution | Commitment-based declarative execution Authorize execution paths | Authorize future states Final state depends on execution order | Execution order does not matter On-chain execution only (execution and verification interleaved) | Off-chain execution, on-chain verification Settlement guaranteed | No guarantee of settlement * Known counterparties | Unknown counterparties State changes are arbitrary | State changes are binary No other transactions needed for settlement | Other intents needed for resolution Settled by users | Settled by third-party agents

* Without compatible counterparties, it may not be possible to find an on-chain execution path. Users can specify an expiration date for their intents to ensure they expire in such cases.

So far, we have a good foundation for understanding how Anoma intents differ from Ethereum transactions. To truly appreciate their powerful capabilities, let's look at some of the most use cases they can enable.

3. Intent is More Than Just a Limit Order

Our example intent [-2000 USDC, +1 ETH] is a limit order; it only commits to the exchange price of the trade. While limit orders are an important use case for intents, they are just one of many. Intents can express any form of generalized commitment. For example, intents can feasibly simulate AMM orders by committing to trade along an xy = k curve. In fact, intents can be programs or even entire algorithms encoding quite complex commitments. These can be conditional or unconditional. They may also rely on other commitments (so-called higher-order commitments), paving the way for powerful applications that would otherwise be impossible.

Below, we look at some example use cases that intents can enable.

1) Combinatorial Auctions:

Market makers or advanced users can use intents to make various expressive bids based on their unique needs:

• Economic complements: Buy two items A and B for $10, where each item costs only $4 because they are complementary goods.
• Economic substitutes: Use some ETH to buy as much USDC or USDT as possible.
• Counterparty discrimination: Sell up to two units of A, with pricing for counterparty C1 at $10, C2 at $9, and C3 at $8.

Expressive bidding better captures the motivations of advanced users in the market. It can be used in any type of market (financial trading, grids, logistics, carbon credits, etc.) to improve efficiency. Historically, a significant challenge for expressive bidding venues has been the inability to match multidimensional bids due to computational complexity. With advancements in deep technology and artificial intelligence, we may see this no longer be an issue in the coming years.

2) Crowdfunding: Crowdfunding is an interesting intent use case because it involves many independent agents. Intents can enable many cool use cases:

• Risk-reducing investments: Commit to fund a project only if commitments exceed X dollars.
• Users pre-commit to donate to winning projects but do not know which project it will be.
• Peer pressure: Commit to fund an event only if your favorite influencer also commits to fund it.

3) P2P Lending: Lenders specify acceptable collateral, LTV, interest rates, and quoted assets, and match with borrowers. When borrowers repay the collateral, lenders may still be willing to lend, in which case the solver can find another counterparty on their behalf. Lenders can bring their own oracles, and bad debts can be isolated to certain parties. In this model, there is no distinction between DeFi lending protocols, NFT lending protocols, or others; any asset can be lent/borrowed.

4) OTC NFT Trading: OTC trading of NFTs often revolves around exchanges between NFTs and involves characteristics. 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 they have certain characteristics. This is not a preference you can easily put on-chain, so counterparty discovery often involves Discord DMs, exposing users to phishing/scam risks during execution.

5) Automated Operations:

• Good After Time (GOAT) orders: For example, buy Token at a specific future time only if the price is within a specified range.
• Subscriptions: Pay-as-you-go model, where users commit to pay a fixed amount for each unit of time over a predefined period.
• MTCS, also known as debt clearing, is a unique and powerful technique that can save liquidity in the economy.

The idea behind MTCS is simple. If Alice owes Bob 1 ETH, Bob owes Greg 1 ETH, and Greg owes Alice 1 ETH, then in reality, no one needs any "money" to fulfill their obligations. All we need to do is recognize that the total obligations form a closed loop; all debts can offset and clear each other.

Similarly, in the real economy, companies often incur trading obligations. MTCS recognizes that one company's accounts payable are another company's accounts receivable. Theoretically, as long as these loops in the trade graph can be identified, companies can clear their obligations through mutual offsetting. This reduces their cash flow concerns and increases productivity in the economy. MTCS has been deployed in certain economies, and research shows it can save significant liquidity. It is also worth noting that MTCS is part of the broader movement of collaborative finance (CoFi).

In the future, intents and solvers can enable MTCS or similar technologies to allow companies to clear their obligations and settle on-chain without relying on centralized clearinghouses.

6) Any Multi-Domain and/or Privacy-Preserving Applications:

• Multi-domain: An Ethereum user wants to buy Bad Kids NFT on Stargaze. This path has many steps, wallets, research overhead, operational (i.e., bridging and wrapping assets) risks, and involves 4 blockchains across two ecosystems. We will delve into this in the Typhon and Chimera chain sections.
• Privacy-preserving applications: Intents are suitable for broad privacy-preserving computations. Through intents, we can build private multi-party barter, private DAOs, etc. We will discuss the privacy aspects of intents later in this section.

4. Counterparty Discovery and Resolution

Anoma intents consume and create some "resources." A bit oversimplified, in our intent example [+1 ETH, -2000 USDC], we can view the created resource as 1 ETH and the consumed resource as 2000 USDC. When the same type of resources created and consumed by the intent do not offset each other, the intent is considered unbalanced. To check for balance, the total sum of created resources must equal the total sum of consumed resources for all involved resource types.

Technically, this balance check is the only factor that distinguishes Anoma intents from Anoma tx (do not confuse with Ethereum tx). In short, in the Anoma world, balanced intents are called, you guessed it… transactions. By the same logic, Anoma intents are merely partial Anoma transactions.

Intents are combined by solvers in the p2p intent gossip network. When two Anoma intents combine, they produce a composite intent, which is another intent whose resources are the aggregation of its constituent intents' resources. As long as the solvers are willing, intents can combine with each other. Ultimately, solvers form a transaction through "balance checks," at which point they can choose to settle on-chain.

Below, we see some unique ways to match intents to form fully balanced transactions.

• Solvers bring their own liquidity: Solvers become counterparties to the transaction by acting as receivers.
• Partial fills: The tokens sold are collectively purchased by many independent parties.
• Direct mirroring: Two intents are directly opposite to each other.
• Circular trades: Intents can be resolved even without direct pairs existing. For example, 3 intents can yield a balanced transaction even if no pair of intents satisfies each other's preferences.

5. Solver Incentives, Censorship Resistance, and DoS Resistance

Achieving a network that is both DoS-resistant and censorship-resistant is very challenging. To this end, Anoma's intent gossip layer is designed to perform path verification by default; all gossip messages are signed by the sender node, forming a chain of signatures that can be traced back to its originator. Path verification plays a crucial role in both DoS and censorship resistance. First, we expand the resistance to censorship.

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 contain fees that solvers can only collect when they settle on-chain. This creates a competitive environment where solvers compete to be the first to resolve intents. Solver competition is beneficial and desirable as it improves the quality of execution for users (speed, price, etc.).

On the other hand, if incentives are mishandled, competition can spiral out of control, leading to greedy corrupt behavior within the network. First, nodes may start to "hoard" intents to gain a competitive edge in resolving intents, which would hinder user censorship resistance. Path verification can elegantly address this issue by laying the groundwork for incentive mechanisms that encourage the broad dissemination of intents.

Consider the following example:

A solver observes two intents, [+2 ETH, -4 NFT] and [-1 ETH, +2 NFT], which, while compatible, do not form a fully balanced transaction. To form a complete solution, the solver needs to find other compatible intents. To propose a complete solution, the solver can take time to observe new incoming intents. However, this is risky, as there may be other solvers handling the same intents. If the solution is resolved by another solver, they may lose the opportunity to collect any fees.

Path verification provides an alternative that allows nodes to prove their efforts to the network. Instead, nodes can propose partial fee claims and pass their partial solution [+1 ETH, -2 NFT] to other nodes so they can continue the resolution process. Once the final solution is reached, each of them can receive a fair share for their contributions to the gossip and resolution process. In this way, the intent gossip layer can be imagined as an incentive data availability layer. One can envision that even in the presence of giant solvers with deep liquidity and closed-source algorithms, smaller solvers can still do their part and earn fees, continuing to contribute to the network's censorship resistance.

Path verification is also crucial for resisting DoS attacks. In cases where conditional fees are settled, solvers expend computational resources without any guarantee of reward. Looking back at the history of account abstraction (AA) in Ethereum, we know this opens the door to cheap DoS vectors. Path verification can play an important role in protecting nodes from malicious actors. That is, nodes can track the behavior of their peers (and users). Over time, they can build their own local trust graph to decide whom to trust in the network and to what extent.

6. Information Flow Control

Information control in the crypto space remains an unresolved issue. Generally, users lack the ability to control what information they disclose 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 enterprises and retail users.

For those interested in a comprehensive understanding of privacy, we recommend our report "Everyone Needs Privacy."

The Anoma architecture paves the way for novel privacy-preserving applications through its unified execution environment (EE) called Taiga. To understand Taiga, we must first understand what information flow control means.

Without observers, privacy is a meaningless concept. When we talk about privacy, we first need to define who the observers are. In our context, observers fall into two camps. We may be dealing with on-chain activity observers (who could be anyone in the world) or off-chain agents (such as solvers and gossip nodes). Additionally, the information we care about may be about "who," i.e., the identity of the intent signer, or "what," i.e., the functions and/or data expressed in the intent.

Based on this framework, Taiga defines three types of intents: transparent, shielded, and private. Shielded intents hide "who" from everyone but expose "what" to off-chain ZK provers. Private intents go further, utilizing various privacy-preserving solutions (TEE, MPC, threshold FHE, etc.) to hide certain information about "content" from solvers.

Taiga is a unified execution environment that provides composable privacy. Composable privacy means developers can publish applications and allow users to interact with each other through transparent, shielded, or private intents within the same application. This makes privacy a choice for users, contrasting sharply with the current state where privacy is always an application/infrastructure choice (DEXs are either private or transparent).

Intuitively, there is a fundamental trade-off between counterparty discovery and privacy. Hiding information about "content" can lead to fairer treatment, but it may make it harder to find compatible counterparties. Therefore, the market can price transparent, shielded, or private intent resolutions differently based on execution quality.

It is also worth noting that there are some research challenges. In particular, while solvers can match shielded intents with transparent intents and vice versa, the feasibility of combining them with private intents remains an open research question.

Today, most (if not all) privacy projects focus solely on information control at the settlement layer. This is understandable, as it is urgently needed. We first want users to be able to hide certain information from on-chain observers of their activities. However, in doing so, projects often sacrifice information control at the counterparty discovery layer. In contrast, Taiga emphasizes information control at both the settlement layer and the counterparty discovery layer.

Privacy at the settlement layer is typically achieved by shielding on-chain data through ZKPs. However, ZKPs have significant limitations regarding privacy. They are usually only useful in special cases where users prove certain properties of states they exclusively own. This applies to payment or identity-related applications but not to applications where multiple users interact with each other.

Typically, multi-user applications address this limitation by introducing a shared ZK prover that collects all private user data, performs some computations on it, and publishes ZK proofs of the computations on-chain on behalf of the users. This can at best provide Web2-style privacy. While user activities are hidden from on-chain observers, they are fully exposed to a single, shared, centralized solver; i.e., the ZK prover. It may also introduce new challenges for permissionless and censorship-resistant systems.

Taiga offers something unique in this regard. Since intents do not assume immediate resolution, they can be executed by independent solvers through many partial steps. Solvers can match some shielded intents with other shielded/transparent intents and pass the ZK proof of this match to other solvers so they can continue the resolution process. The proofs generated by independent parties at the network edge can be combined.

In the architecture we ultimately arrive at, no single observer can have a comprehensive understanding of the partial execution leading to transaction settlement. As shown in the diagram below, three solvers each have local visibility on certain intents, but none have complete visibility.

Last but not least, Anoma also focuses on information control at the settlement layer. In fact, the first application launched in the Anoma ecosystem will be Namada: a privacy-preserving settlement layer. Namada's unique product is a one-of-a-kind multi-asset shielded pool (MASP), where all fungible and non-fungible assets can share an anonymous set. In turn, this allows the owners of these assets to form a large anonymous set to protect each other's privacy. Namada will soon launch as an application chain compatible with Cosmos and IBC, aiming to become a multi-chain privacy layer, initially focusing on the Ethereum and Cosmos ecosystems.

7. Intent Settlement

The lifecycle of an Anoma tx is as follows:

User signs intent → Intent propagates in the p2p layer → Solvers match compatible intents and form tx (counterparty discovery and resolution) → Tx settles on-chain. In this section, we will take a closer look at settlement.

To settle a transaction, verification must occur on-chain. Verification is accomplished through on-chain functions called predicates. Each account in Anoma (users and tokens) has an associated predicate that restricts the possible future state set authorized by that account. The simplest way to conceptualize predicates is to think of them as restrictions that could be imposed on a bank account or smart contract wallet.

• Whitelists/Blacklists: Send funds only to accounts X, Y, Z, only perform ETH transfers, etc.
• Rate limits: Cannot exceed X amount per day.
• Access control: 2 out of X, Y, Z accounts must sign the transfer.

Intents and predicates are functionally similar; they both commit to some preference over the state space. The main difference is that intents exist as transient expressions of preference off-chain, while predicates exist as persistent expressions of preference on-chain (although they can be updated at any time). Together, they form a two-layer authorization scheme. Transactions must satisfy both to successfully settle on-chain.

The primary role of predicates is to ensure atomic (all-or-nothing) settlement. For a transaction to resolve and advance the on-chain state, it must satisfy the predicates of all accounts involved.

For example, an ETH\<>USDC swap between Alice and Bob can only successfully settle if the predicates of Alice, Bob, ETH, and USDC are all satisfied. If the state transition cannot satisfy any of the predicates of the involved accounts, the state transition will fail, and the on-chain state of any of those accounts will not change. In short, if all relevant parties give a thumbs up, the state transition succeeds; otherwise, it fails.

8. Predicates vs. Smart Contracts

Predicates and smart contracts are similar in some ways and different in others. While both are on-chain, code predicates only care about verification and not execution. They do not perform step-by-step imperative execution. Given a transaction, they simply check if it is satisfied and return a boolean value; either authorized or not authorized.

In this regard, intents and predicates may provide a safer way for users to interact with applications. Users no longer need unrestricted access to smart contracts and infer the opcodes in their execution paths.

Another notable distinction between the two is that the functions running predicates do not own any state. Since they are pure functions, verification can always be fully parallelized.

9. Open Research Areas

Declarative execution has many open research areas worth further exploration. As we conclude the first part of the series, we leave you with some thoughts as we prepare to depart.

• Resource Pricing: As we have seen, conditional fees for settlement may make it difficult for nodes to accurately account for the resources they consume. Beyond token gating and fees, we can expect new trust network-type witch resistance technologies to emerge in the future. Users' on-chain histories, identities, and reputations will play an important role here.
• User Interface Security: As execution shifts off-chain, frontends and wallets will bear more responsibility for ensuring users accurately sign their intents as expected. Therefore, user interfaces will play a more significant role in security. How they will adapt remains to be seen. Will blind signature hardware wallets become a thing of the past?
• Solver DAOs: There are reasons why solvers may want to coordinate with each other during the resolution process. They can find value in aggregating their liquidity, providing better guarantees for resolving issues, and reducing wasteful failed attempts to resolve transactions. In some cases, solvers may want to coordinate with each other by forming consensus protocols and/or running MPC among themselves. The topology of the solver network will form accordingly.

10. Conclusion

Thus concludes Part 1 of our Anoma series. In Part 2, we will focus on the application layer. We will highlight the growing trend of well-known dApps transitioning to intent-based architectures. We will also analyze the unique value added by the Anoma architecture for these existing dApps and upcoming new dApps.