Workflow Explainer

How one agent verifies another before work or money moves

Mercury Trust sits between payment and execution. It checks identity or authority, returns a signed receipt, and gives downstream services a reason to say yes, review, or no before they act.

See the 5-step flow Copy the live CLI flow Try free identity evidence

Payment is not trust

x402 proves a request was paid for. It does not prove the agent behind the request is who it claims to be, or that the service should execute a sensitive action.

Receipts matter only if enforced

The signed receipt becomes meaningful when the downstream service checks it and rejects missing or invalid trust evidence before execution.

Review is a real state

A review-grade receipt means the identity claim is meaningful enough for some routes, but not strong enough for every route.

Sequence

The live flow in five steps

This is the working pattern today for a trust-gated agent call: optional preflight, paid deep check, signed receipt, downstream request, then enforcement.

01
Optional free preflight

Call /api/trust/identity/evidence to confirm ERC-8004 coordinates and any ENSIP-25 corroboration before paying for the deeper trust decision.
02
Pay for deep identity attestation

Call POST /api/trust/identity/attest with the claimed agent identity. Mercury Trust evaluates the claim at execution time, not just as static metadata.
03
Receive a signed receipt

The response includes a signed trustReceipt with a normalized decision, guarantee code, canonical identity result, and expiry.
04
Attach the receipt downstream

The caller sends the next paid request with x-merc-trust-receipt attached. That lets the downstream service evaluate the trust context, not just the payment.
05
Enforce route policy

The downstream service decides whether this route accepts review-required or requires execution-allowed. That is where trust becomes operational.

Visual model

Receipt flow by participant

Caller Agent

collects claimed identity
requests trust decision
attaches signed receipt
pays downstream x402 route

Mercury Trust

checks ERC-8004 / identity evidence
returns allow, review, or deny
issues signed receipt
exposes receipt verification endpoint

Downstream Service

verifies receipt integrity
checks route policy
accepts or rejects execution
keeps the trust gate meaningful

Decision ladder

What each trust result means

Allow

Strong enough for routes that require execution-grade trust.

Review

Identity or authority is meaningful, but stronger proof is still recommended before higher-risk execution.

Deny

The downstream service should reject the request and stop the workflow.

Suggested downstream policy by route risk
Route class	Typical examples	Acceptable trust guarantee
Low-risk	business-day lookup, holiday lookup, read-only informational calls	`review-required` or `execution-allowed`
High-risk	funds movement, protected writes, business-critical automation	`execution-allowed` only

Live CLI flow

One command that gets trust and calls the downstream service

Trust input

{
  "wallet": "0xCALLER_WALLET",
  "targetAgentId": "agent-b",
  "mode": "identity",
  "identity": {
    "agentId": "agent-b",
    "deployerWallet": "0xDEPLOYER_WALLET",
    "model": "gpt-5-mini",
    "modelVersion": "2026-03-23",
    "deploymentHash": "sha256:YOUR_DEPLOYMENT_HASH"
  },
  "erc8004": {
    "agentId": "123",
    "registry": "eip155:8453:0xERC8004_REGISTRY_ADDRESS",
    "chain": "base",
    "signingWallet": "0xSIGNING_WALLET"
  }
}

Trust-aware paid call

node adapters/bin/merc-trust.cjs awal-pay ^
  "https://x402-data-bazaar.vercel.app/api/business-days/next/US/2026-03-23" ^
  --trust-file=trust-input.json ^
  --trust-max-amount=35000 ^
  --max-amount=10000 ^
  --pretty

This pays for the deep trust decision, extracts the signed receipt, attaches the trust header, and then pays the downstream x402 endpoint.

FAQ

What builders usually ask next

Why can a result be review instead of allow?

Because canonical identity can be strong enough to matter without being strong enough to authorize every action. ERC-8004 may prove who the agent is while signed manifest or wallet-proof evidence is still missing.

What does ERC-8004 prove well?

It proves canonical onchain identity binding. It does not, by itself, prove current runtime integrity or that the active software instance matches the claimed deployment.

Why do downstream services matter so much?

Because a signed receipt has teeth only when the downstream service enforces it. Without that, trust is advisory. With enforcement, trust changes whether execution happens.

Next step

Use the guide, or use the system

Inspect live offerings Back to product page