A huge thank you to apriori for the amazing insights, feedback and multiple reviews of this report. Additionally, thanks for the incredibly valuable discussions on all things Anoma - intents, counter party discovery, Typhon, Taiga and everything in between.

Introduction

Anoma is a framework for building intent-centric applications. It consists of two main components - Typhon and Taiga. Typhon consists of the P2P network, Mempool, Consensus, and Execution Engines. Taiga is the stateless execution environment that provides data and function privacy with recursive zero-knowledge proofs. Anoma is many things but it is not a blockchain.

It aims to provide the groundwork for decentralized counterparty discovery, privacy, and atomic multi-chain settlement. But what does this actually mean and more importantly, what are they doing that is novel? Anoma’s key innovation is that it provides efficient and private methods for counterparty discovery using an intent-centric system.

First, what is an intent?

Intent Centric Model

Anoma’s design is intent-centric because everyone who uses a blockchain has preferences when they interact with one another. Otherwise, they wouldn't need to interact at all over a blockchain in the first place. Given this, intents are the primary way for users to express their preferences in Anoma.

In Anoma’s architecture, an intent is a message sent by a user which expresses their preferences regarding the desired state of the system. The user defines the constraints of what the system can do instead of execution paths. Intents are realized through Anoma’s resource model. Unlike transactions, intents are partial. You can think of intents as partial transactions that require other direct or indirect parts as complements in order to form a final balanced transaction that satisfies all users’ constraints.

The preferred state may be carried out by the user (i.e transfer ETH to a friend) or it might require counterparty discovery and interaction with other users (i.e swapping ETH for an altcoin on a DEX). An intent simply states a user’s desired end state and is flexible on the path to get it. A clear example in DeFi today is a DEX aggregator - the user only cares about the best execution and does not care about the path to get it (which DEX is used, etc.). You may be wondering, this sounds similar to transactions so what is the difference between an intent and a transaction? Let’s look at the following example differentiating the two:

• Transaction: Alice lends stETH on Aave for an 8% yield.
• Intent: Alice has stETH and wants to earn the highest yield possible with trustworthy lending apps.

Transactions authorize how to get what you want, meaning the user had to find Aave themselves and authorize the transaction to get their desired outcome - yield on their stETH. This requires a lot of moving parts - a specific frontend, knowing which chain to use, keeping up with the markets, and much more.

However, with the use of intents on Anoma, Alice would only authorize what she wants/prefers. If you are a new user who only cares about yield on their stETH but doesn't keep up with the markets, authorizing what you want as an intent can find you the best opportunity (with desired risk preferences). In the above example, Alice can potentially find a better yield opportunity by authorizing what she wants as an intent, whereas the transaction model may be more limiting.

We have laid out some of the groundwork for intents but how does Anoma actually match intents with the desired counterparties?

This is solved through counter party discovery, which is built directly into Anoma’s architecture.

Counter Party Discovery and Settlement

Counterparty discovery is done today in the following ways:

1. Off-chain (centralized databases)
   • i.e. Binance, Instagram, etc
2. On-chain discovery
   • i.e. Uniswap (not Uniswap X) connects buyers and sellers

Focusing on the on-chain counterparty discovery, Anoma expands on this by allowing users to express what they want as intents to the network. In an oversimplified way, users can express what they want and Anoma will find the counterparty for them.

Anoma’s Approach

Similar to all blockchains, Anoma provides settlement. These transactions will be ordered and executed resulting in a new state. However, these intents need to find their counterparties to ultimately become a transaction.

This is where Anoma specializes, they directly optimize their protocol for counterparty discovery.

Below is the lifecycle of intents -> counterparty discovery -> consensus -> execution.

A more detailed view is shown below, showing the lifecycles of different intents - transparent, shielded, and private intents.

But how exactly do intents find their counterparties?

Intent Gossip Layer and Solvers

Users authorize intents and they are broadcasted to intent gossip nodes. Similar to the mempool, this will be a P2P networking layer with a bunch of users’ intents (not transactions). These intents then go through counterparty discovery, which is enabled through nodes called ‘solvers’. These solvers take intents, find their matches and create transactions resulting in a new state. Solvers span across all fractal instances, meaning solvers can match intents across many different chains. This brings forward a very open design space for interoperability; more importantly, the end user does not need to worry about which chain she is on.

Given solvers address a very large space for matchmaking intents, how might this actually work in practice? It is likely that each solver will take on specialized roles. For instance, someone might have a solver specifically dedicated to matching DEX trades or another may strictly focus on NFTs. A generalized approach to solving may not scale due to complexity, so specialization amongst solvers is likely. These solvers may sound very similar to builders in the Ethereum PBS design. Given it's still very early, much is still unknown about the reputation of solvers and how this plays out.

Current Approaches to Intents

Outside of Anoma, there are two main ways users can express their intents and have them implemented on-chain today:

• Account Abstraction (AA)
• Applications

Let's unpack AA and the applications below. Understanding the current approaches to intents will highlight why Anoma is tackling a generalized approach.

Account Abstraction

Account abstraction is a key example of a protocol that takes some preferences and implements it on behalf of a user to create better UX. Things such as specifying which tokens to use for gas, rate limiting the maximum amount withdrawn from a wallet, or being able to make whitelists and blacklists of contracts, can all be done using AA. Hence, AA can be thought of as a protocol that solves a few UX issues through curated intents. However, these AA smart contract wallets are not generalized systems - they are limited to a few curated intents, the chains they support, and can only enforce intents on a user account but not incorporate other on-chain information such as finding the best route to make a swap for the best execution. Enter ‘intent-specific’ apps.

Applications

‘Intent-specific’ apps are apps that allow users to express their intents for specific actions and enforce them on-chain. For example, DEXs such as CowSwap allow users to find the best swap for their needs without having to individually go through the 100s of DEXs to see which execution is better. Other examples may include yield aggregators or NFT aggregators. However, these intent-specific apps such as CowSwap rely on centralized off-chain orderbooks that are trusted for fair ordering and execution. Additionally, intent-specific apps may not mold well with a multi-chain world (multi-rollup, multi-chain, or a hybrid). For instance, even though DEX aggregators can deploy on many rollups and chains, how can a user find the best pricing for swapping from asset A to B? With this setup, the user would still have to individually search into each rollup/chain to see which has the most liquidity or lowest fees to see which one to use.

This leads us to why Anoma is aiming for a generalized system to intents. Rather than having to identify the specific chain and application to use, a user can specify something as simple as “I want to sell as much ETH as possible”. Then a solver will find a solution that is optimal and execute atomic transactions between the counterparties, without sacrificing privacy guarentees and centralization risk.

Given that an intent is a user preference, generalizing them to have better counterparty discovery can create a superior UX and unlock new use cases. There is a large addressable market to build an infrastructure for intents in a cross-chain world and Anoma’s architecture aims to do so in a highly scalable and privacy-centric way.

But first, lets talk about what Anoma actually is, some of its benefits, and what is going on under the hood.

Anoma Overview

Anoma is an architecture for building blockchains. It aims to become home to many blockchains, called ‘fractal instances’, through a scaling strategy called ‘fractal scaling’. In simpler terms, Anoma will serve as the base architecture for many blockchains with varying security assumptions. These blockchains have the ability to define their validator sets, sybil resistance mechanisms, (choose between PoS, PoA, etc.), governance, and execution pricing (network fees). Overall, this type of scaling unlocked by Anoma allows for many benefits for each blockchain:

• Dynamic security
  • Allows users to pay fees proportional to their security needs
  • Chains do not need to overpay for security
• Higher Throughput and Scalability
  • Multiple chains = more throughput
• Lower Latency
  • Subset of validators
• Validator Alignment
  • The reputation of the validators at stake for each chain
  • Can also ask more from your validators (i.e dYdX validators running in memory orderbooks)
• Faster Upgrades
  • Every chain allows upgrades to happen in production in parallel with the canonical chain
• Interoperability
  • Every chain is interoperable with Inter-Blockchain Communication (IBC)

Every chain gets all of the above benefits, while simultaneously being composable with one another over IBC. This means users can use assets across multiple Anoma-blockchains depending on the functionality or security they need for a given use case. Additionally, assets will be composable with all other IBC-enabled chains such as Osmosis, Cosmos Hub, Injective and many other chains that are live or planning to launch.

Another added benefit is that each instance has a unique way of doing upgrades. For those familiar with Polkadot and Kusama, Kusama was supposed to be an iterative “testnet” for chains to experiment with before deploying to Polkadot. Although it allows rapid experimentation, it actually forked entirely separate communities and liquidity - creating a fragmented UX. Anoma provides an intuitive solution to this. It's ‘fractal scaling’ allows each chain to test its upgrades in production. This is achieved by having the original chain as the “canonical” chain and allowing the upgraded chain to live in parallel with one another. Over time, users can move assets between the two of them to test things out. After sufficient testing or demand, it is ultimately the stakers that vote on making the upgraded chain the ‘canonical’ chain - this significantly reduces a lot of issues with governance on upgrades.

This setup favors safety while allowing chains to move fast, ultimately empowering the users and stakers of each chain to decide on their future.

What is Behind These Anoma Chains?

In short, a lot of innovations were made at the consensus, execution, and mempool layers to enable this design. There are many moving parts to Anoma, but they can be grouped into two major components: Typhon and Taiga. The system responsible for consensus, gossip, parallel execution, and mempool is called Typhon, which is supposed to be an alternative to Tendermint. Typhon stores, orders and executes transactions on all Anoma instances. Whereas Taiga provides the tooling for privacy-preserving applications, including intents, solvers, and transactions.

Typhon

Consensus

They created a new consensus mechanism based on Heterogeneous Paxos. It allows for atomic cross-chain transactions between multiple fractal instances. This is very important for particular use cases. For example, when booking a vacation, a traveler may only want to book a hotel reservation if they can only get the flight that fits within their budget. Either all of their conditions are filled or none of them. In the same regard, if the cheapest flight and hotel reservation are on separate chains, you will want either all of the conditions filled or none. Given Anoma will have many chains with many intents that want to compose with one another, this consensus allows a way for cross-chain intents to execute simultaneously.

There are a few pieces that make this vision come together, but we will focus on two large components involved: base chains and chimera chains. Base chains are simply sovereign blockchains that are built using Anoma, otherwise called fractal instances - while chimera chains are chains that carry out atomic transactions between base chains. Basically, multiple base chains can connect to a Chimera chain which settles transactions between them. The chimera chain acts as the glue that ties together atomic cross-chain transactions between the base chains. Note that chimera chains introduce an additional consensus mechanism that is dependent on the consensus of the base chains.

With this consensus, any unique chain built on Anoma will be able to enjoy atomicity with one another (so long as they settle to the same chimera chain), which is currently a feature mainly enjoyed on single chains - bringing this cross-chain is very powerful, contributing to a much better UX and new use cases. Things such as cross-chain flash loans or atomic cross-chain swaps and much more are now possible. The above is a very brief overview but for those more interested in the specifics, head to Anoma’s specifications.

Execution

After consensus has been reached on the transaction order, Typhon’s execution engine processes all of the independent transactions in parallel through parallel execution. It updates and stores the most up-to-date state of the VM.

Mempool

The mempool is based on Narwhal, which references batches of transactions through hashes and proves those transactions are available for execution. The headers Narwhal produces are what the consensus ultimately decides on for transaction ordering.

Taiga

The second main component is Taiga, which is responsible for providing generalized shielded state transitions. It allows for privacy account abstraction, where end users can specify their privacy preferences. The Taiga protocol allows applications to build on top of it to take advantage of fully shielded state transitions. For those interested in the inner workings of Taiga, GitHub, and this talk are great resources. Below are some of the unique features unlocked by Taiga:

• Compatible with transparent Anoma
  • assets can flow between shielded and transparent pools. Applications are private by default but still have the option to be public given they can support both types of state transitions as well (optionality for the applications/users)
• Data and function privacy
  • all transactions look the same to a third-party observer, regardless of the applications being used
• Atomic multiparty-state transitions
• Performance benefits through new and improved zero-knowledge systems

Now that we have discussed the inner workings of Anoma, let's dive into the exciting applications that can be built with it.

Anoma Applications

Apps building with Anoma can immediately plug into the intent gossip layer mentioned above. This enables applications to be inherently cross-chain. As for the applications themselves, they would only need to define the specific state transition rules, and the rest is taken care of by Anoma - counterparty discovery, solving, and a settlement network.

Applications on Anoma will have the ability to be public or privacy-preserving. This is key as it enables the developers/users to cater to their privacy preferences. Having the optionality for privacy may also help in light of compliance, which is similar to what Aztec is doing.

Anoma’s aim is to provide the infrastructure for traditional apps to be built while also bringing about novel use cases. App developers will be writing the applications in Juvix, a language that provides many features for developers as shown here.

Traditional Apps That Can Be Built on Anoma

Most of the top applications in crypto today revolve around DeFi, particularly DEXs. The most popular being Uniswap, which uses the blockchain itself to facilitate counterparty discovery. Others such as CoWSwap use single-operator orderbooks to ensure fair ordering and the best execution. On Anoma, a DEX can be implemented over its network - users give their trades as intents to Anoma and solvers can match the counterparties of a given trade.

AMMs

AMMs such as concentrated liquidity can be implemented by a user who authors her intent to swap within a sub-range of price for a given asset. This is not on-chain, so the user would not be sending transactions or locking funds in an LP. Additionally, other features such as limit orders can be built into the user's stated intents.

Orderbooks

Orderbooks can also be implemented in Anoma. An entire orderbook can potentially live in the intent gossip layer as a series of intents that indicate users' preferences as bid/ask orders. Market makers can continuously update their orders every block, which provides an orderbook full of intents that users can authorize. Other CLOB designs today have been done as fully on-chain orderbooks (Injective, Sei, etc.). On-chain orderbooks have been hard to scale, as bids/asks are done on-chain which gets quite expensive.

Another approach is dYdX, which is notably moving to its own app-chain for scalability and decentralization (among other things). They take the approach of off-chain orderbooks and on-chain settlement - this provides scalability and decentralizes the off-chain orderbook they are running across the validator set. Another main factor in their decision for v4 is combatting MEV. Given their orderbook will be off-chain, it introduces trust in the validators regarding MEV. Although they have their reputation on the line, validators can see orders and can potentially give worse execution or censor transactions in this model.

Anoma’s architecture provides a potential 3rd option to implement a fully off-chain orderbook that is private by default. Transactions sent to validators can be encrypted, which reduces MEV captured by validators. However, one can imagine MEV is not fully removed in this kind of system - if I am vague in my intents I authorize to the network (i.e. I want to sell ETH for USDC without specifying additional conditions such as slippage), I may get worse execution.

Rollup Sequencers

Many rollups today operate using centralized sequencers that are responsible for ordering transactions and sending the updated state to Ethereum. The sequencer is a single point of failure given that sequencers can censor transactions and play a key role in MEV on the given L2. Alternatively, these rollups can spin up their own blockchain on Anoma, using Typhon consensus to form a decentralized sequencer, and then send the proofs to Ethereum as they do today.

New Use Cases

We covered some of the existing applications that can be built on Anoma but there are also some exciting and novel use cases.

Multiparty Bartering

Multiparty bartering is a way of coordinating among many parties in an efficient and private manner. For example, imagine a scenario where you and your two friends want to go on vacation, but only if the following conditions are met:

• Flight under $500
• Specific hotel availability for the weekend
• Snorkeling tour under $50

To do this currently, you would have to go to many frontends that do not ‘communicate with one another’ meaning you can satisfy one of the conditions by buying the flights but the snorkeling tour may be fully booked. This becomes a coordination issue, even amongst just 3 individuals. With Anoma, all of our intents would be expressed and either all of the conditions would be satisfied or none of them at all (atomicity). This means that Anoma’s architecture would be a large improvement on its web2 counterparts such as companies like Expedia that aggregate things such as flights and hotels. This is just one such example for travel, but one can imagine creating intent-based applications that create the ultimate UX for many of the applications that are fragmented in today’s web2 world. All of this is hypothetical but the world of generalized intents can produce a lot of interesting applications in a privacy-preserving way.

Anoma’s Modularity in a Multichain World

Anoma is many things, as shown by this report. However, one of the most important parts about it is understanding how it functions in a multichain world given it is an architecture and not a specific blockchain. Similar to things such as the Cosmos SDK or IBC, Anoma’s architecture is modular and open sourced for anyone to use. Meaning developers can use Anoma however they like to spin up novel applications. For instance, developers can use all parts of the stack or they can just use Ferveo (which is what Osmosis is doing), or Taiga and get counterparty discovery and solving. Anoma is a public good that anyone can use to build out anything they want - any layer 1 chain, layer 2, rollup sequencers, and even SUAVE can build on Anoma’s architecture.

A looming question is what this all looks like in the end for the end user. There are all these intents, but how does the end user interact with Anoma that provides them with the best possible UX, ultimately leading to adoption? We have laid out examples of orderbooks being built with Anoma to traveling coordination and much more, but these do not address how users can easily get what they want. A user who wants to coordinate a vacation does not care about DEX trades and vice versa.

Given the addressable market of generalized intents, the landscape is quite large and it will need a way to present this to the end user so they do not need to care about chimera chains or require a technical understanding. Given the success of LLMs as evidenced by Chatgpt and its incredible growth to 100m users, there is a lot of promise in how LLMs can obfuscate the complexity of Anoma for end users, while providing a unified way for users to do whatever they'd like. This is speculation of course with the use of LLMs, but certainly an open question that has yet to be answered.