Skip to main content
Anyone can verify a Mnemom agent’s reputation without trusting Mnemom’s infrastructure. Scores and Merkle roots are published to Base L2 contracts by Mnemom on a cron schedule; you read them back either through the Mnemom API or directly via any Ethereum-compatible client. For the conceptual overview — why on-chain anchoring exists, how the Merkle tree maps to integrity checkpoints, and what ERC-8004 means for interop — see On-Chain Verification.
Anchoring and score publishing are not customer-callable endpoints. Mnemom’s backend runs them on a 6-hour cron under an internal service key. Customers consume on-chain data through the three read endpoints below, or by querying the contracts directly.

Prerequisites

Before using on-chain verification features, ensure you have:
  1. A Mnemom API key — created in your dashboard or via POST /v1/api-keys. Read-only access is enough.
  2. Agents with published reputation scores — agents need at least 50 analyzed integrity checkpoints and a public Mnemom Trust Rating before they appear on-chain.
API key authentication: pass your key in the X-Mnemom-Api-Key header:
(Bearer JWTs from /v1/auth/login work too.)

Verifying a score against the chain

Confirm that the score Mnemom reports off-chain matches what’s published on-chain, and that the underlying Merkle root has been anchored. Endpoint: GET /v1/on-chain/verify-proof/{agent_id} — public, no auth required.
Response: 200 OK
verified: true means the off-chain Merkle root matches the anchored root and the off-chain score matches the ScoreRecord in the registry. Any false is a tamper signal — open a support ticket.

Checking on-chain status

Lightweight “does this agent have any on-chain data?” check — useful before calling verify-proof in workflows where the agent may be new or pre-eligible. Endpoint: GET /v1/on-chain/status/{agent_id} — public.
Response: 200 OK

Viewing history

Retrieve the full history of anchoring and publishing events across all agents in your org — useful for compliance audits and trend dashboards. Endpoint: GET /v1/on-chain/history — auth required. Query parameters:
Response: 200 OK

How anchoring + publishing actually happen

Mnemom’s backend runs a 6-hour cron that:
  1. Computes agent-level Merkle trees from the latest integrity checkpoints.
  2. Aggregates agent-level roots into a global root.
  3. Calls MnemoMerkleAnchor.anchorRoot(root, leafCount, treeDepth) on Base.
  4. Publishes eligible agents’ reputation scores in a batch to MnemoReputationRegistry.publishBatch(records) (up to 200 agents per tx per contract limit).
This runs under an internal service key — customers never call the underlying anchor or publish endpoints themselves; those are gated behind X-Service-Key and reject any other auth. Gas is paid from the Mnemom operational wallet; there is no customer-facing billing line for on-chain operations. You do not need to hold ETH on Base to use any part of this system. If you need an off-cycle anchor or publish (e.g., for a time-critical compliance filing), contact support — the backend team can run the cron manually.

Verifying directly against Base L2

Everything above goes through the Mnemom API. If you prefer a fully trust-minimized path, read the contracts directly. Deployed addresses (Base mainnet, chain ID 8453): Agent ID encoding: human-readable IDs like mnm-550e8400-... are stored on-chain as keccak256(abi.encodePacked(agentId)). Compute the hash client-side before querying:
Query the registry:
Query the Merkle anchor:
Both getScore and isRootAnchored are view calls — zero gas, no wallet required. Any public Base RPC endpoint works.
Use the API path when possible — it’s cached and doesn’t hit the RPC on every request. Drop to direct RPC when you need trust-minimized verification or are composing with other smart contracts.

See also