Note: This blog was updated on September 2, 2025 to reflect the latest plans for Anoma’s mainnet rollout

What is Anoma?

The word “Anoma” can mean many things. Here we will talk about two: the Anoma protocol and the Anoma network. The Anoma protocol is a distributed operating system for intent-centric applications, and the Anoma network is the interlinked graph of computers running this protocol.

An operating system:

1. Abstracts diverse hardware behind a universal interface, and
2. Provides an environment in which applications can run.

Three classes of operating systems are predominant today:

1. Desktop operating systems such as Windows, Linux, and Mac OS.
2. Mobile operating systems such as iOS and Android.
3. Web browsers such as Chrome and Safari.

These three classes of operating systems all fit this definition, but differ in what hardware they seek to abstract and what kind of environment they seek to provide. Desktop and mobile operating systems are concerned with abstracting physical hardware, while web browsers already run on an existing OS and can make use of the hardware abstractions provided by that OS. While all three classes of OSs are interested in providing an environment in which multiple applications can run safely, mobile OSs and web browsers are typically more concerned with limiting application permissions and cleanly sandboxing application code.

Similar to web browsers, Anoma is an operating system that runs on top of an existing “base-level” operating system which abstracts differences in physical hardware. Similar to mobile operating systems, Anoma provides a very clean sandbox for applications, up to the point of making it safe and incentive-compatible for nodes to run code they receive over the network. Rather than seeking to abstract the hardware of one computer, a distributed operating system such as Anoma aims to abstract the hardware of many networked computers so that applications can treat this network as if it were a single abstract machine: specifically, an intent machine.

What does Anoma mainnet mean?

By mainnet, we mean a version of Anoma which allows developers to build and deploy real applications that can integrate with existing tokens such as ETH, BTC, DAI, USDC. This stage of mainnet does not yet come with any native Anoma token. The most important interface (really, the only external interface) in all of the Anoma protocol is the application development interface, and our first priority is to allow developers to start building applications using it.

The basic architectural concept for the initial mainnet version – nicknamed "Resource Plasma" after the concept first described in this post – is to primarily leverage existing service providers for ordering, compute, and storage services (often bundled together as “blockchains”, and some “solvers” or “searchers”) and knit these service providers together using the Anoma node and P2P system into a distributed network capable of supporting intent-centric applications built using the resource machine.

With the Minimum Viable Resource Plasma (MVRP) architecture, Anoma provides three things:

1. A framework to write native intent-centric applications, and
2. A network allowing those applications to instantly leverage existing services and liquidity, and
3. A clear interface for service providers to easily support new classes of applications.

In a diagram, the intent flow in MVRP looks like this:

With the Anoma mainnet:

• Operators will be able to run Anoma nodes and participate in the intent gossip network, solving, and settlement per their preferences.
• Solvers will be able to combine Anoma intent liquidity and EVM intent liquidity and settle atomically in a single transaction.
• Developers will be able to write intent-centric applications using the resource machine and Juvix, with transparent, succinct, and zero-knowledge proof options.
• Users will be able to define their own security model, choosing service providers for network relay, compute, storage, and ordering in their intents, which the Anoma network will then coordinate and the application logic will then enforce.

How will Anoma be deployed?

For the past few years, Anoma ecosystem teams have been conducting (and publishing) research and developing early prototypes. This has led to the overall system architecture and current plan to deploy Anoma in a series of phases designed to facilitate the collection and incorporation of developer and ecosystem feedback with rapid iterations, and to start building real applications. The following plan is an initial proposal and is subject to change at any time in the future. Please follow Anoma on X and other communication channels to be up to date.

The Anoma roadmap to mainnet consists of three basic phases:

1. Devnets, the first phase, are focused on allowing developers to start building Anoma applications, getting a feel for the system, and providing feedback which will be incorporated into design or ergonomic changes as necessary. Devnets are aimed exclusively at developers – beware, here be dragons! – and will iterate until there is a stable application development API and a handful of solid apps.
2. Testnets, the second phase, are focused on allowing users to start playing with (testnet) Anoma applications built by the early developers, and providing feedback on UX and functionality which will be incorporated into design or application changes as necessary. Testnets are aimed at both developers and users, and should be more stable than devnets, but changes will still happen on a periodic cadence.
3. Mainnet, the third phase, includes a stable application development interface and full support for the Resource Plasma architecture. Mainnet will not include an Anoma-specific consensus at the beginning – but thanks to the Plasma architecture, this is not necessary for developers and users to build and use real applications with real value. In this stage, the focus will be on making Anoma applications valuable for users, and coordinating further protocol iteration and efficiency improvements as necessary to achieve that. The mainnet version will first include deployments of the protocol adapter (allowing intent settlement) to the Ethereum mainnet and Ethereum L2s, followed by other chains and ecosystems. Successive versions after launch will bring additional options to applications including private solving, FHE, MPC, threshold encryption, on-demand consensus, and Chimera chains.

Thanks for reading! Please leave any feedback and questions on the forums.