Anoma

• Name: Anoma
• URL: https://docs.anoma.net/
• Category: intent-centric operating system / resource-machine architecture / solver-and-settlement middleware / heterogeneous-security coordination layer
• Summary: Anoma is not just another cross-chain intents product. The useful read is broader and less flattering to the usual category labels: it is an attempt to turn intents, resource-state transitions, discovery, solving, and settlement into one operating system-shaped architecture. The interesting part is not the slogan. It is that Anoma makes several usually-hidden layers explicit: the Anoma Resource Machine, protocol adapters, solver and discovery infrastructure, and the claim that one architecture can sit across different security domains.
• What it does:
  • Frames application behavior around signed intents and resource transformations rather than only imperative transaction execution
  • Uses the Anoma Resource Machine (ARM) as a resource-based state and execution model instead of a standard account-model stack
  • Exposes protocol adapters that surface Anoma-style functionality on existing chains such as Ethereum, Arbitrum, Base, and Optimism
  • Treats solving, matching, discovery, and related service layers as first-class parts of the system rather than as backend glue the architecture ignores
  • Positions developers to target one intent-centric architecture while settling across different underlying chains and trust domains
• Key claims:
  • The whitepaper and current docs both make the same core complaint: programmable settlement alone does not solve counterparty discovery, matching, or solving, so supposedly decentralized apps still lean on hidden middleware.
  • ARM is the main reason this note matters. Anoma is changing the unit of state, not just standardizing a better cross-chain order envelope.
  • The protocol-adapter strategy matters almost as much. Anoma is trying to project its architecture onto existing chains instead of waiting for a fresh sovereign chain to win distribution.
  • The homogeneous architecture, heterogeneous security line is worth keeping because it is a sharper analytical claim than generic interoperability rhetoric, even if production reality may end up messier.
  • In practice, authority can still pool around whoever runs discovery, indexing, solver infrastructure, and adapter operations at scale.
• Whitepaper: A canonical Anoma whitepaper does exist and still matters for the project’s framing, but the current docs and specs have evolved the presentation. For this pass, the strongest primary sources were the official docs, the protocol specs entrypoint, the main repo README, the protocol-adapter page, the ARM page, and the 2022 whitepaper draft; see ../whitepapers/anoma-primary-sources-2026-05-12.md.
• Sources:
  • https://docs.anoma.net/
  • https://specs.anoma.net/latest/
  • https://docs.anoma.net/anoma-resource-machine
  • https://docs.anoma.net/anoma-protocol-adapter
  • https://anoma.net/
  • https://raw.githubusercontent.com/anoma/anoma/main/README.md
  • https://raw.githubusercontent.com/anoma/whitepaper/main/whitepaper.md
  • https://github.com/anoma/whitepaper

Internal linkages

• Keep this one tight: erc-7683, open-intents-framework, and namada.

Control surface

• Onchain surface: ARM-style validity rules, protocol-adapter logic, and whatever settlement chains ultimately enforce state transitions.

• Offchain/operator surface: discovery, matching, solver infrastructure, indexing, proof services, and adapter operations.

• The clean user-facing intent story can hide a lot of operational power. That is the real reason to keep the note.

• Last reviewed: 2026-06-03 UTC