anoma-primary-sources-2026-05-12

Anoma primary sources

Reviewed: 2026-05-12 UTC

Core protocol framing

• https://docs.anoma.net/
  • Main current docs entrypoint.
  • Used to confirm Anoma’s present self-description as a Distributed Operating System for intent-centric applications, plus the emphasis on a unified developer and user interface across many underlying chains.
• https://specs.anoma.net/latest/
  • Current protocol-specs entrypoint.
  • Used to confirm the formal framing of Anoma as a protocol architecture for state-, network-, and application-level interoperability without restricting intent types or solving methods.

Canonical whitepaper and original architectural thesis

• https://raw.githubusercontent.com/anoma/whitepaper/main/whitepaper.md
  • Canonical raw source for the Anoma whitepaper draft reviewed in this pass.
  • Used to confirm the project’s original argument that programmable settlement does not natively provide counterparty discovery or solving, the intent-centric design thesis, the role of validity predicates, and the homogeneous architecture / heterogeneous security framework.
• https://github.com/anoma/whitepaper
  • Repository page used to confirm that the whitepaper is still maintained as a working draft and that a whitepaper.pdf artifact exists in the repo.

Implementation and live deployment surfaces

• https://raw.githubusercontent.com/anoma/anoma/main/README.md
  • Canonical implementation-repo README.
  • Used to confirm the main protocol implementation, linkage to the live specification, and the continuing importance of research forums and architecture posts for following design evolution.
• https://docs.anoma.net/anoma-protocol-adapter
  • Best source in this pass for the deployment strategy.
  • Used to confirm that the Protocol Adapter exposes Anoma functionality on existing chains, and that live deployments now exist on Ethereum, Arbitrum, Base, and Optimism.

Resource-machine model

• https://docs.anoma.net/anoma-resource-machine
  • Best short official source for ARM’s current framing.
  • Used to confirm the Resource Machine as the state and execution model of the Anoma DOS and as distinct from both UTXO and account models.
• https://docs.anoma.net/resources
  • More application-facing than protocol-facing, but still useful.
  • Used to confirm how resources appear in practice as immutable objects with logic references, quantity, ownership/value references, nullifier commitments, and encrypted storage, plus the operational role of an indexer in fetching user resources.

Main takeaways from this pass

• Anoma’s most important contribution to the corpus is not intents in the abstract, but an explicit decomposition of decentralized applications into user intents, resource-state semantics, solving / counterparty discovery, protocol adapters, and heterogeneous settlement domains.
• The whitepaper remains valuable because it spells out the architectural critique many later intents systems only imply: settlement alone is insufficient, and hidden Web2 solver / sequencer layers become the real centralization point.
• The current docs show Anoma trying to operationalize that architecture through ARM and Protocol Adapters rather than only through a future sovereign chain.
• The main control surfaces to keep mentally hot are solver and indexer operation, protocol-adapter deployment, validity / verification semantics around resources, and the practical gap between homogeneous architecture rhetoric and whatever security / service dependencies real deployments inherit.
• Anoma is therefore a useful comparison class not only for Open Intents Framework and other ERC-7683-adjacent systems, but also for resource-oriented state models, validity-predicate architectures, and any chain-abstraction stack that claims to unify many chains under one application interface.