Anoma is an intent-centric L1 blockchain designed from the ground up around the intent abstraction. Where ERC-7683 retrofits intents onto the EVM and treats solvers as off-chain agents, Anoma's architecture treats intents as the primary unit of state transition. Users emit intents to a public mempool; counterparty discovery, matching, and settlement all happen within the protocol. The mainnet is targeted for 2026 release per the Anoma Foundation.
Anoma matters as a research direction because it answers the question: what does a chain look like if intents are first-class instead of bolted on? The architecture has three innovations: a counterparty-discovery layer, a unified settlement engine, and a homogeneous-architecture / heterogeneous-security model that allows Anoma to host multiple consensus instances. Eco watches the Anoma design space because the orchestration-layer thesis applies regardless of whether the underlying primitive is a solver network or an intent-native chain.
What Is Anoma?
Anoma is a blockchain protocol that treats user intents as the primary input to state transitions. Where Ethereum users sign transactions (specific instructions to be executed), Anoma users sign intents (desired outcomes). The protocol's job is to find counterparties, match intents, and settle the resulting state changes. Users never specify "swap X for Y on this DEX"; they specify "I will accept any path that delivers Y in exchange for X."
The protocol was designed by Christopher Goes, Adrian Brink, and Awa Sun Yin, who previously built the Cosmos-based Namada chain. Anoma extends the Namada research into a more general intent-matching engine. Anoma's whitepaper series includes the foundational paper on intent-centric architecture and supporting papers on the resource model, the heterogeneous paxos consensus, and the Juvix programming language used to write intents.
The Anoma testnet launched in Q1 2025, and the Anoma Foundation has staged mainnet for 2026 with periodic milestone testnets through 2025-2026 per Anoma's blog.
How Does Anoma Work?
An intent in Anoma is a partial transaction: a constraint on the state change the user will accept, expressed in the resource model. The user signs the intent and submits it to the Anoma mempool. Solvers (called "solvers" or "matchmakers" in Anoma terminology) read intents from the mempool and search for combinations that satisfy multiple intents simultaneously — finding two users whose intents are mirror images and matching them, or finding chains of three or more intents whose combined state change cleanly resolves.
This is fundamentally different from the auction model used in ERC-7683 where one solver fills one user's intent. Anoma's solvers find coincidence-of-wants matches across multiple intents. If user A wants to trade USDC for ETH and user B wants to trade ETH for USDC, the solver matches them directly without using a DEX. This compresses execution costs to near zero for matched flows. Anoma's research portal publishes ongoing papers on matchmaking algorithms.
Settlement in Anoma uses the resource model: each intent describes resources to be consumed and resources to be produced. A valid match is one where the produced resources of one intent satisfy the consumed resources of another, and vice versa. The protocol verifies the match and atomically applies the resulting state change. The user's input resource and the counterparty's input resource swap simultaneously, with no sequential ordering risk.
The Resource Model
Anoma's resource model is the data structure that makes intent matching tractable. A resource is a typed token with associated logic: ownership rules, transferability, and validity predicates. Resources are linear (consumed exactly once) and balanced (the sum of resources before a transaction equals the sum after).
This model derives from the linear-logic foundations of Anoma's design. The Anoma whitepaper formalizes the resource calculus and proves that valid intent matches preserve resource balance. The practical effect is that Anoma can verify any intent match in constant time without simulating the underlying DEX swap or bridge transfer — the validity is a function of the resource bookkeeping alone.
The resource model also supports privacy. Users can submit shielded intents where the resource details are hidden from the public mempool but visible to a trusted matchmaker via zero-knowledge proofs. This is one of the design points distinguishing Anoma from public-mempool intent networks like Across or UniswapX.
Solvers and Matchmakers
Anoma's solvers serve a different function from Across or UniswapX solvers. They are matchmakers, not fillers. They do not hold cross-chain inventory or front their own capital. They search the intent mempool for satisfiable combinations and submit the matches to the protocol for atomic settlement.
This changes the solver economics. Anoma solvers earn fees for finding matches, not spreads on capital deployment. The cost of running a solver is computational (search algorithms over the intent mempool) rather than financial (inventory). Anoma's research on intent matching as search covers the algorithmic complexity and proposes optimizations.
The matchmaker market is expected to be more open than solver markets in capital-front-loaded networks. Without the inventory requirement, anyone with sufficient compute can participate, which the Anoma Foundation expects will distribute matchmaking across many small actors rather than concentrating it among large capital providers.
Heterogeneous Paxos and Multi-Consensus Hosting
Anoma's consensus layer uses a variant of Paxos called Heterogeneous Paxos, which allows different parts of the network to run with different validator sets and different fault assumptions. This is what enables Anoma to host multiple "fractal" instances of itself — sub-chains with their own validators that interoperate via the resource model.
The architectural goal is to let applications choose their own security and validator preferences without forking to a separate chain. A high-value DeFi application might run on a maximum-security instance with a large validator set; a high-throughput consumer application might run on a smaller, faster instance. Both are "Anoma chains" and both can settle resource transfers between themselves natively.
Anoma's research repository contains the Heterogeneous Paxos paper, which formalizes the trust assumptions and proves safety properties under various validator-overlap conditions.
Use Cases
The clearest use case for Anoma's design is private intent matching at scale. A market maker submitting price quotes wants the quotes visible to counterparties but not to MEV searchers. Anoma's shielded intent path allows this natively — the quote is visible to authorized matchmakers via ZK proofs but invisible in the public mempool.
The second use case is multi-party settlement. A three-way trade among three counterparties is impractical to express as a single transaction in EVM-style chains; it requires either a sequential set of transactions (with re-order risk) or a custom batch contract. In Anoma, a matchmaker finds the three-way match and submits it as one resource-balanced state change. The protocol verifies and settles atomically.
The third use case is cross-domain coordination. Anoma's resource model is chain-agnostic in its abstract form; resources can represent assets on Anoma's own consensus or on connected external chains via bridge integrations. This positions Anoma as a coordination layer for cross-chain intent matching, not just intra-chain.
Adoption Status and Open Questions
As of April 2026, Anoma's mainnet Phase 1 is live (launched September 29, 2025), with XAN and governance activated; some protocol adapters and applications remain in test phase pending audit. The first applications building on Anoma include Vamp-IR (a programmable-gadget framework for ZK circuits), Namada (Anoma's privacy-focused sister chain, already on mainnet), and a small number of intent-matching DEX prototypes. Namada's mainnet is the closest production-readiness data point for Anoma's underlying technology stack.
The open questions are: matchmaker liveness (will enough matchmakers run to clear the intent mempool reliably), intent expression complexity (can users specify rich intents without writing Juvix code), and cross-chain integration (how does Anoma's resource model bridge to non-Anoma chains). The Anoma Foundation's testnet phase is designed to surface answers before mainnet launch.
The Juvix Programming Language
Anoma intents are expressed in Juvix, a functional programming language designed by Heliax (one of Anoma's contributing organizations) specifically for the resource-model context. Juvix compiles to ZK circuits, which is what allows shielded intents to be verified without revealing their contents. The Juvix project site covers the language design and compiler architecture.
For end users, Juvix is invisible — wallets generate Juvix-compiled intent code from user actions in standard wallet UIs. For application developers building intent-emitting apps, Juvix is the language of choice. The functional, total-language design is meant to make intent logic auditable: a Juvix function describing an intent's validity predicate is provably terminating and side-effect-free, which simplifies security review.
The maturity of Juvix tooling is one of the open questions for Anoma's mainnet readiness. Compared to Solidity's mature toolchain (Hardhat, Foundry, Slither, multiple audit firms), Juvix is at an earlier stage. The Anoma Foundation has invested in Juvix tooling alongside protocol development, and the first wave of Anoma applications will demonstrate how usable the developer experience is.
Anoma vs ERC-7683 vs Eco's Orchestration Approach
The three approaches sit at different layers. ERC-7683 standardizes cross-chain intent orders within the EVM ecosystem; solvers fill them with their own inventory. Anoma rebuilds the chain around intent matching as a primary operation. Eco operates above both as an orchestration layer for stablecoin movement, picking the right underlying primitive (a Hyperlane-secured solver fill, a CCTP burn-and-mint, or potentially an Anoma-routed match in the future) for each route.
The orchestration thesis is independent of the underlying primitive. Whether the best path for a given USDC transfer is an Across-style relayer fill, a CCTP native burn-and-mint, or an Anoma intent match, the team integrating Eco Routes sees the same SDK call. The orchestration layer evaluates the options and routes accordingly. As Anoma matures, it adds a new option to that decision space without changing the integration surface.
Practical Implications for Application Developers
For application developers watching Anoma, the practical implications depend on the application's shape. Multi-party trade settlement (three or more parties whose preferences resolve via matchmaking) is hard to express in EVM-style chains and natural in Anoma. Privacy-preserving order flow (where order details should be hidden from public mempools but visible to authorized matchmakers) is also natural in Anoma via shielded intents.
For single-party cross-chain flows that already work via ERC-7683 networks, Anoma offers no immediate advantage. The user signs an outcome; a solver fills it; the user receives the output. Whether that flow runs on Across with optimistic settlement, on Eco's orchestration layer across multiple primitives, or on Anoma is a choice about latency, cost, and protocol-specific features rather than a fundamental capability difference.
The interesting design space for Anoma is at the boundary of intent matching and cross-chain orchestration. As Anoma's mainnet launches and bridge integrations mature, orchestration layers like Eco can route appropriate flows through Anoma alongside the existing primitives. The application sees one integration; the orchestration layer picks Anoma when the matching benefits exceed the integration overhead.
FAQ
When does Anoma launch on mainnet?
The Anoma Foundation targets late 2026 for mainnet. Testnet phases throughout 2025-2026 are expected to surface remaining technical questions before launch. Namada, Anoma's sister chain using related technology, is already on mainnet.
Is Anoma a Layer 1 or a Layer 2?
Anoma is a Layer 1 with a unique architecture: it can host multiple "fractal" instances under the same protocol via Heterogeneous Paxos. Each instance has its own validator set and consensus parameters, and instances interoperate natively via the resource model.
How does Anoma's intent model differ from ERC-7683?
ERC-7683 defines an order format for cross-chain intent execution; one solver fills one order with capital. Anoma intents are partial transactions matched against other intents; matchmakers find satisfiable combinations rather than fronting inventory. The two models target different problem shapes.
Can Anoma intents move stablecoins cross-chain?
In its mature form, yes — Anoma's resource model supports cross-chain assets via bridge integrations. The current testnet focuses on intra-Anoma intent matching; cross-chain bridge integration is on the roadmap and will likely connect via existing message-passing protocols.
Who runs solvers (matchmakers) on Anoma?
Anyone with the compute to search the intent mempool. The matchmaker role does not require inventory, only computation, which is expected to distribute participation more broadly than the capital-front-loaded solver markets in EVM intent networks. The Anoma Foundation expects the long-tail of small matchmakers to provide redundancy against any single matchmaker exit, while specialized matchmakers compete on algorithmic sophistication for complex multi-party matches that simpler solvers cannot find profitably.

