Why is my wallet address not on my AnomaPay payment?

AnomaPay's Transaction Service submits the settlement and pays the gas, so the sender on-chain is the service's account. AnomaPay's privacy page says that for shielded transfers an observer sees the Protocol Adapter interacting with that service, not your address. Your address is visible where you shield or unshield tokens, which your address page and External calls show.

What is the difference between a transaction hash and an Anoma id?

The hash names the EVM transaction. The Anoma id adds the chain id and the log index of the Protocol Adapter's TransactionExecuted event, so it names exactly one Anoma transaction even when one EVM transaction carried several. explorer.anoma.net uses the same id, so the two explorers can be compared directly.

How soon does a new transaction appear on Gnoma Explorer?

There is a short delay between a block and its settlement appearing, and it varies by network. /api/v2/status reports how recently each network was read and the measured delay from block to index. A transaction that is still missing after that may not have gone through the Protocol Adapter.

Can I see the amount or recipient of a private AnomaPay transfer?

Not on-chain. AnomaPay's privacy page says amounts are encrypted and the recipient is known only to the sender. What is public is the edge of the pool: shields and unshields with their address and amount, shown on External calls and Shielded pool.

Does the Executed badge prove the transaction succeeded?

Executed means the Protocol Adapter's events for the settlement are in the chain's logs, and an EVM transaction that fails leaves none. Where Etherscan gives a receipt status, a small shield-and-check icon appears in the badge once Etherscan confirms it, a second source independent of the index. If Etherscan reports a failure, the badge reads Reverted instead.

Guide · updated 2026-10-24

How to look up and verify an Anoma transaction

This guide shows how to find an Anoma or AnomaPay transaction on Gnoma Explorer, how to read what its page shows, and how to check the same transaction on the network's own block explorer and on explorer.anoma.net, the explorer Anoma's docs point to.

What you can search for

What you have	What Gnoma finds	How it looks
Transaction hash	The Anoma transactions that EVM transaction carried. One opens directly; several are listed so you can pick one.	`0x` and 64 hex characters
Anoma id	Exactly one settlement, under the same id explorer.anoma.net uses	`{chainId}_{txHash}_{logIndex}`
Address or ENS name	The settlements the address submitted, and its shields and unshields at the edge of the shielded pool	`0x` and 40 hex characters, or a name such as `name.eth`
Resource tag	The resource with that nullifier or commitment, and the settlement that published it	`0x` and 64 hex characters
Logic reference	The resource logic and the settlements that use it	`0x` and 64 hex characters

A settlement is one Anoma transaction completed on-chain through the Protocol Adapter, the contract that lets Anoma transactions settle on EVM networks. Its Anoma id has three parts: the network's chain id, the EVM transaction hash, and a log index. The log index points at the TransactionExecuted event, which the Protocol Adapter emits once at the end of each Anoma transaction it executes. When one EVM transaction executed more than one Anoma transaction, a bare hash matches several settlements and Gnoma lists them. On 2026-10-23 explorer.anoma.net used the same id in its transaction links, at /transactions/{id}, and that path also works on Gnoma, so changing the host is enough to compare. An ENS name is first resolved to its Ethereum address. The same lookups are JSON at /api/v2/search and /api/v2/txs/{id}, which accepts an id or a bare hash. [1] [2] [3]

Why an AnomaPay payment shows a service as the sender

AnomaPay is a privacy-preserving payments network built on Anoma. Its architecture docs describe the flow: the payer signs a payment intent in the AnomaPay frontend and sends it to a Transaction Service; a Proving Service creates the proofs; the Transaction Service then submits the finished transaction to the Protocol Adapter and pays the gas. So the Submitted by field on the settlement page shows the service's account, which Gnoma calls the submitter, and not the payer. For shielded transfers inside the app, AnomaPay's privacy page adds that amounts are encrypted and the recipient is known only to the sender. What stays public is the edge of the shielded pool. Putting tokens in is a shield, which AnomaPay's docs also call a deposit and Anoma's generic-call docs call a wrap; taking them out is an unshield, a withdrawal or unwrap. The address that makes a deposit or receives a withdrawal is visible on-chain. Searching your own wallet therefore finds your shields and unshields, while transfers inside the pool do not carry your address. [1] [2] [3] [4]

The on-chain observer sees the Protocol Adapter interacting with the Transaction Service, not your address.
docs.anoma.net

How to read a settlement

The page opens with Details: the transaction hash with a link to the network's block explorer, the network, the block and log index, the time, the submitter, the Protocol Adapter address and version, and the commitment tree root the adapter stored at the end of the settlement. At a glance counts actions, resources, payloads and external calls. Resource flow lists each action, and inside it one row per compliance unit: the consumed resource first, then the created one. The adapter's own code defines each compliance unit as one consumed and one created resource. Each resource card shows whether its tag is a nullifier or a commitment, its resource logic, its payloads by kind, and the raw payload bytes when opened. The adapter publishes only the payloads marked to be kept (deletion criterion Never), so those are the ones the page can show. External calls lists what the forwarder did: a shield shows the address the tokens came from, an unshield the address they went to, with the amount for known tokens and each step of a multi-step call. Raw data (JSON) at the bottom is the object /api/v2/txs/{id} returns. [1] [2]

Action: A part of a transaction. Anoma's specs say actions partition a transaction's state change and limit what resource logics get to see: proofs made in an action can access only that action's resources. Gnoma shows each action's tree root at the top of its box. [1]
Compliance unit: A data structure used to verify a compliance proof. The compliance units of an action never share a resource tag, and together they cover every resource in the action. [1]
Resource tag: A resource's tag is its nullifier when the resource is consumed and its commitment when it is created. Gnoma's Resources page lists every tag. [1]
Nullifier and commitment: Consuming a resource adds its nullifier to the adapter's nullifier set, and the adapter reverts the transaction if that nullifier is already in the set. Creating a resource adds its commitment to the commitment tree, and a consumed resource must refer to a commitment tree root the adapter already holds among its past roots. [1]
Resource logic: The resource logic function a resource names, identified by its verifying key (the hash of that function), which Gnoma calls the logic reference. For each resource, the adapter receives its tag, its verifying key and a logic proof. Gnoma's Resource logics page profiles each one. [1]
Payload kinds: Data a resource carries, in four kinds: resource payloads for plain information about the resource, discovery payloads for data encoded with public keys for discovery, external payloads for data connected with external calls, and application payloads for application-specific purposes. The page labels them Res, Disc, Ext and App. [1]
External call: A call from Anoma to an ordinary EVM contract, which Anoma's docs call a generic call. It is carried by an ephemeral resource and run through a forwarder contract that only the Protocol Adapter can invoke. The adapter checks the bytes the call returns against the output committed in the transaction. Gnoma's External calls page lists them all. [1]

Checking it on the chain and on explorer.anoma.net

Read the badge next to the network name. Executed means the Protocol Adapter's events for this settlement are in the chain's logs, and an EVM transaction that fails leaves no events. A small shield-and-check icon inside the badge means Etherscan, a second source the index does not rely on, also confirmed the receipt status. Reverted means Etherscan reports a failure. Where Etherscan gives no receipt status, the badge rests on the events alone.
If a hash you expect is missing, check /api/v2/status first. It says whether every network is being followed on time (fresh), how long ago each one was last read, and the measured delay from a block to its settlement appearing. A hash that never appears may not be a Protocol Adapter transaction at all.
Follow the hash link in Details to the network's block explorer. In the transaction's event logs, look for ActionExecuted and TransactionExecuted coming from the Protocol Adapter address listed on Networks; the adapter's source code shows where each is emitted.
Open the same id on explorer.anoma.net at /transactions/{id}. The tags, their kinds and the action tree root should match.
For a script, /api/v2/txs/{id} returns the whole settlement as JSON. For the index as a whole, Proof compares the explorer's totals with each Protocol Adapter's own counters on a schedule.

Anoma's docs describe explorer.anoma.net as a view of all Anoma protocol activity, with a GraphQL playground for running queries against its indexer. On 2026-10-23 its transaction page showed the hash, the sender, the contract, the log index, the network, block and time, each tag with its kind, logic and payload counts, and each action with its tree root and tag count; its search box asked for a hash. It does some things better: it is the explorer Anoma itself points to, its transaction page links each action to a page of its own, and the GraphQL playground lets you write your own queries. Gnoma's transaction page adds the pairing by compliance unit, decoded external calls with amounts, the commitment tree root and the receipt check. [1] [2]

Questions

Why is my wallet address not on my AnomaPay payment?: AnomaPay's Transaction Service submits the settlement and pays the gas, so the sender on-chain is the service's account. AnomaPay's privacy page says that for shielded transfers an observer sees the Protocol Adapter interacting with that service, not your address. Your address is visible where you shield or unshield tokens, which your address page and External calls show.
What is the difference between a transaction hash and an Anoma id?: The hash names the EVM transaction. The Anoma id adds the chain id and the log index of the Protocol Adapter's TransactionExecuted event, so it names exactly one Anoma transaction even when one EVM transaction carried several. explorer.anoma.net uses the same id, so the two explorers can be compared directly.
How soon does a new transaction appear on Gnoma Explorer?: There is a short delay between a block and its settlement appearing, and it varies by network. /api/v2/status reports how recently each network was read and the measured delay from block to index. A transaction that is still missing after that may not have gone through the Protocol Adapter.
Can I see the amount or recipient of a private AnomaPay transfer?: Not on-chain. AnomaPay's privacy page says amounts are encrypted and the recipient is known only to the sender. What is public is the edge of the pool: shields and unshields with their address and amount, shown on External calls and Shielded pool.
Does the Executed badge prove the transaction succeeded?: Executed means the Protocol Adapter's events for the settlement are in the chain's logs, and an EVM transaction that fails leaves none. Where Etherscan gives a receipt status, a small shield-and-check icon appears in the badge once Etherscan confirms it, a second source independent of the index. If Etherscan reports a failure, the badge reads Reverted instead.

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.