What is the difference between a nullifier and a commitment?

A commitment is added to the commitment tree when a resource is created; a nullifier is published when a resource is consumed and goes into the nullifier set, and a resource can be consumed only once. Anoma's specification uses the commitment as a created resource's tag and the nullifier as a consumed resource's tag, so a resource can be identified without referring to its contents. Resources lists both, and each transaction page pairs them in its resource flow.

Is a shield the same as a deposit?

Yes. Anoma's Transfers docs call moving tokens into the shielded pool a mint (deposit) and taking them out a burn (withdrawal). This site says shield and unshield, and its API marks them wrap and unwrap, the names of the ERC20 forwarder calls in Anoma's specification.

Why does a transaction page show actions and compliance units?

Anoma's specification groups a transaction's resources into actions and partitions each action into compliance units, which set the scope of each compliance proof. On this site's transaction pages, each unit shows one consumed resource beside one created resource, and the heading counts both actions and units.

What does this site mean by a settlement?

A settlement is one Anoma transaction completed on-chain through a Protocol Adapter. One EVM transaction can carry more than one, so ids take the form {chainId}_{txHash}_{logIndex}. The live list is on Transactions and in /api/v2/txs.

What is an intent, and can I see intents here?

An intent states the outcome a user wants and the constraints on it, rather than the steps, as Anoma's ARM announcement describes it. This explorer records transactions once they settle, so intents appear only as a clearly marked simulation on Labs.

Are these definitions official?

No. Gnoma Explorer is independent and not affiliated with the Anoma Foundation or Heliax; each definition follows the Anoma page it cites. Anoma's docs describe its own Anoma Explorer, at explorer.anoma.net, which displays indexed transactions, tags, resource logics and external calls across existing Protocol Adapters.

Guide · updated 2026-10-24

Anoma glossary: the terms in plain words

The words Anoma uses for its resource machine, its contracts on EVM networks, the shielded pool, AnomaPay, XAN and governance, each explained in plain words from Anoma's own docs and specification, with the page of this explorer where it shows up.

Each entry below pairs an Anoma term with the plain word this explorer uses for it and links the page where you can see it. Where Anoma's docs or specification define a term, the entry follows them and cites the page. Where a word belongs only to this site, such as settlement or submitter, the entry says how the site uses it. Gnoma Explorer is independent and not affiliated with the Anoma Foundation or Heliax. More guides are on Learn.

The resource model in brief

Anoma's state model is neither account based nor built on unspent outputs: it is a resource model. The Anoma Resource Machine keeps state as resources, records that are immutable and can be created once and consumed once. Each resource is paired with a resource logic, which encodes the rules for how it can be used. A transaction groups resources into actions, splits each action into compliance units, and is checked with proofs. Anoma says the model was inspired by the commitment and nullifier system first used by Zcash. [1] [2] [3]

Anoma Resource Machine (ARM): The part of the Anoma protocol that defines and enforces the rules for valid state updates, a role Anoma's specification compares to that of the EVM in Ethereum. The state it works on is the set of active resources: those that were created and not yet consumed. On this site, each entry on Transactions is one ARM transaction applied on an EVM network. [1]
Resource: An immutable on-chain record of state; in AnomaPay, each one stands for an amount of a token owned by a user. Anoma's App SDK docs list its fields, among them a logic reference (which identifies the program that governs its validity rules), a label reference (which token it is), a quantity, and a value reference that binds it to its owner's keys. This site calls a resource Anoma's private unit of value and state. Resources lists every resource by its tag, with its logic, payloads and calls. [1]
Resource logic: The program that a resource's logic reference identifies, and so the rules that resource must follow. Anoma's specification defines the logic reference as the resource logic's verifying key. Resource logics lists every logic and profiles it from what it does on-chain, since most have no public name. [1]
Nullifier: A value computed from a resource and a nullifier key. Publishing it marks the resource as consumed, and it is stored in a public, append-only nullifier set. A resource can be consumed only once. On this site a resource whose nullifier was published is a consumed resource, shown by its nullifier on Resources and in each transaction's resource flow. [1]
Commitment: A unique identifier of a resource, computed from it with a hash and used to prove that the resource exists. To establish that it exists, its commitment is added to a global commitment tree. On this site a resource whose commitment was added is a created resource, and Proof compares the resources indexed with each Protocol Adapter's own counters. [1]
Tag: How a resource is identified when constraints are checked, without referring to its contents directly. For a created resource the tag is its commitment; for a consumed resource it is its nullifier. Every resource on this site is found by its tag: Resources lists them and the search box accepts one. [1]
Action: A part of a transaction whose proofs can see only the resources in that action. Every resource consumed or created in an action needs its own proof that its resource logic holds, and each resource's application data can carry four kinds of payload: resource, discovery, external and application. Each transaction page on this site draws its actions as separate boxes in the resource flow and counts payloads by kind. [1]
Compliance unit: A part of an action with its own compliance proof, which must show, among other things, that the unit's delta (its balance) was computed correctly. An action can have several units; they do not overlap and together cover all of its resources, and how many resources one unit holds is left to each implementation of the resource machine. On this site's transaction pages each unit appears as one consumed resource beside the one created with it. [1]
Transaction and settlement: Anoma's specification defines a transaction as the fields that are necessary and sufficient to validate and apply a state update: a set of actions and a single delta proof, a balance proof that the transaction's delta is correctly derived from its actions' deltas. Settlement is this site's word for one such transaction completed on-chain through a Protocol Adapter. Transactions lists every settlement by an id of the form {chainId}_{txHash}_{logIndex}, because one EVM transaction can carry more than one. [1]

Contracts on each EVM network

Anoma reaches existing blockchains through the Protocol Adapter, a contract that implements Anoma on an existing chain, whether an L1 or an L2, and gives access to the Anoma Resource Machine without changes to that chain. AnomaPay's docs describe it as a smart contract deployed on every supported EVM chain that acts as the anchor of the system: Anoma transactions settle through its execute function, and it controls shielded funds through forwarder contracts. The deployments this site reads, with their addresses and versions, are on Networks. [1] [2] [3] [4]

Protocol Adapter: The contract that settles Anoma transactions on an EVM network. Its execute function checks every compliance proof and resource logic proof with a trusted RISC Zero verifier, runs the external calls, and only if all of it succeeds adds the new commitments to its commitment tree and the nullifiers to its nullifier set. Networks lists each deployment this site reads, with its address, version and live status. [1]
Forwarder contract: A contract that the Protocol Adapter calls while it executes a transaction. In Anoma's specification, the ERC20 forwarder lets users lock ERC20 tokens in it and first checks that its caller is the Protocol Adapter, so that no other agent can interact with its state: a Wrap locks a user's tokens in it with a Permit2 signature, and an Unwrap sends them to a chosen address. Not every forwarder is restricted this way; the specification's block time forwarder is open to anyone. On this site every external call names its forwarder, and Proof checks the token balance each network's forwarder holds against every shield minus every unshield. [1]
External call: A call the Protocol Adapter makes to a forwarder contract while it executes a transaction. A resource's external payload names the forwarder, the input to pass it and the exact output expected back; any other output makes the transaction revert, and each call emits a ForwarderCallExecuted event. External calls decodes each one it recognises as a shield, an unshield or DeFi from the pool. [1]
Generic call: Anoma's way to combine a shielded state change with ordinary EVM calls in one atomic transaction: value leaves the pool, a list of contract calls fixed in advance runs, and the proceeds go back in. The user's signature covers the whole list, and the Generic Call Forwarder only passes funds through within that one transaction. This site labels these calls DeFi from the pool on External calls and lists the contracts they reach on Shielded pool. [1]
Shield and unshield: A shield moves tokens from an EVM wallet into the shielded pool; an unshield moves them out to a wallet address. Anoma's App SDK docs call these a mint (deposit) and a burn (withdrawal). Every shield and unshield is listed on External calls, and the daily flows in and out are on Shielded pool. [1]
Submitter: This site's word for the account that sent a settlement to the Protocol Adapter on-chain. AnomaPay's docs say its proving service operator generates the zero-knowledge proofs and relays the transaction on the user's behalf, so the submitter can be that service rather than the person whose tokens move. Address pages list what an account submitted, and Analytics charts active and new submitters over time. [1]

Privacy, payments, the token and governance

Shielded pool: Where tokens are held so they can be used privately through Anoma. AnomaPay's docs say that once assets are shielded, transfers between AnomaPay users are visible only to the users involved; the pool's total balance is public, but who owns which tokens inside it is private. Shielded pool measures the public part: how much is inside, what crosses the boundary and how large a crowd an unshield can hide in. [1]
AnomaPay: A privacy-preserving payments network built on Anoma that enables shielded transfers of ERC20 tokens on EVM-compatible chains. Its docs list the tokens and networks it supports and place the Protocol Adapter at its heart, so AnomaPay's transfers settle like any other Anoma transaction. This site does not label settlements by app: it profiles each resource logic from what it does on-chain on Resource logics and decodes each call on External calls. [1]
XAN: Anoma's native token. Anoma's tokenomics page says it can be used for payments, transaction fees and network governance, and gives its supply as 10,000,000,000 XAN, fixed. XAN adds up every transfer the token contract has recorded to show supply, holders and daily activity, and Proof checks that ledger's supply against the contract's own totalSupply(). [1]
Governor and timelock: The contracts XAN holders use to govern Anoma since Governance V2. The Governor, built on OpenZeppelin's Governor framework, takes proposals and counts For, Against and Abstain votes; voting power counts only once it is delegated, including to yourself. A proposal that passes waits in the timelock, the only thing capable of changing the XAN token, for fourteen days as announced, and then any address may execute it. Governance reads the rules, proposals and votes from the contracts. [1]
Intent: What a user wants to happen, stated as an outcome and its constraints rather than the exact steps. Anoma designed its resource machine to process intents: the user states the end state and does not need to work out the steps to reach it. This site records transactions after they settle, so intents appear only as a clearly marked simulation on Labs. [1]

One step, several names

Anoma's pages give the same steps different names. In the specification's ERC20 forwarder example, moving tokens in is a Wrap and moving them out is an Unwrap. AnomaPay's docs speak of a deposit and a withdrawal, and the App SDK docs build them as a mint and a burn. Running a list of contract calls from the pool is a generic call. This site says shield, unshield and DeFi from the pool, and its API uses wrap and unwrap, the specification's words, as the table shows. [1] [2] [3] [4]

On this site	In the API	In Anoma's pages	Where to see it
Settlement	`id` of the form `{chainId}_{txHash}_{logIndex}`	Transaction, settled by the Protocol Adapter	Transactions, /api/v2/txs
Shield	`direction` is `wrap`	Wrap; deposit; mint	External calls, /api/v2/calls
Unshield	`direction` is `unwrap`	Unwrap; withdrawal; burn	External calls
DeFi from the pool	`direction` is `multicall`	Generic call	External calls, Shielded pool
Consumed resource	`kind` is `nullifier`	Nullifier	Resources, /api/v2/tags
Created resource	`kind` is `commitment`	Commitment	Resources
Resource logic	`logic`	Logic reference (verifying key)	Resource logics, /api/v2/logics
Submitter	`sender`	This site's word	Analytics, /api/v2/submitters/top

Questions

What is the difference between a nullifier and a commitment?: A commitment is added to the commitment tree when a resource is created; a nullifier is published when a resource is consumed and goes into the nullifier set, and a resource can be consumed only once. Anoma's specification uses the commitment as a created resource's tag and the nullifier as a consumed resource's tag, so a resource can be identified without referring to its contents. Resources lists both, and each transaction page pairs them in its resource flow.
Is a shield the same as a deposit?: Yes. Anoma's Transfers docs call moving tokens into the shielded pool a mint (deposit) and taking them out a burn (withdrawal). This site says shield and unshield, and its API marks them wrap and unwrap, the names of the ERC20 forwarder calls in Anoma's specification.
Why does a transaction page show actions and compliance units?: Anoma's specification groups a transaction's resources into actions and partitions each action into compliance units, which set the scope of each compliance proof. On this site's transaction pages, each unit shows one consumed resource beside one created resource, and the heading counts both actions and units.
What does this site mean by a settlement?: A settlement is one Anoma transaction completed on-chain through a Protocol Adapter. One EVM transaction can carry more than one, so ids take the form {chainId}_{txHash}_{logIndex}. The live list is on Transactions and in /api/v2/txs.
What is an intent, and can I see intents here?: An intent states the outcome a user wants and the constraints on it, rather than the steps, as Anoma's ARM announcement describes it. This explorer records transactions once they settle, so intents appear only as a clearly marked simulation on Labs.
Are these definitions official?: No. Gnoma Explorer is independent and not affiliated with the Anoma Foundation or Heliax; each definition follows the Anoma page it cites. Anoma's docs describe its own Anoma Explorer, at explorer.anoma.net, which displays indexed transactions, tags, resource logics and external calls across existing Protocol Adapters.

Sources

Gnoma Explorer is independent and not affiliated with the Anoma Foundation or Heliax. Statements about Anoma are Anoma's own, from the sources above; figures are this explorer's, from the pages linked in the text.