The Notary of Everywhere

At 4:52 on a Friday afternoon, an instruction lands at a corporate treasury service: pay this invoice. $48,000 in USDC to a vendor's wallet, on behalf of a client called Meridian Labs. The sender is not Meridian's CFO. It is Meridian's procurement agent, a piece of software carrying a signed permission slip. There is no human to call, the payment is irreversible the second it settles, and the one thing everyone has learned about AI agents is that some of them are compromised, confused, or running on authority that was revoked twenty minutes ago.

The service has about four seconds to decide before the payment becomes irreversible. This post is about the eight questions it asks in those four seconds, and about the thing almost nobody plans for: still being able to prove the answers fourteen months later, when Meridian's auditor asks why a bot could move $48,000.

At the counter, money talks

First, the honest part. If this were a checkout counter, none of these questions would matter. A one-shot sale, paid in full, upfront, in crypto: the buyer risks their own money, the seller gets paid, everyone goes home.

Delegation breaks that symmetry. The actor and the owner are different parties. The agent is spending, but the money is Meridian's, and the treasury service sits in the middle carrying the liability if those two facts ever disagree. The moment a machine asks you to do something irreversible on someone else's behalf, "the money arrived" stops being the end of your risk. It might be the beginning of it.

So before the payment executes, the service needs answers about two different parties:

• About the agent: Are you a registered, identifiable agent, or an anonymous script? And does Meridian's treasury authorize you to spend, right now, as of this block, not as of whenever you were set up? Up to what amount?
• About Meridian: Is there a KYC-attested entity behind this instruction? Does the operating account actually cover a $48,000 payment, with margin? And are the treasury reserves where policy says they should be, on every chain the treasury lives on?

Two parties, two wallets. Which is why this is two calls to POST /v1/attest: an attestation evaluates one wallet, and here there are two that matter. One receipt for the actor. One receipt for the owner.

Call one: may this agent act?

The first call attests the agent's wallet. Two conditions, both answered from chain state on Base:

Request · the agent's wallet

{
  "wallet": "0xA9b3…the agent's wallet…",
  "conditions": [
    {
      "type": "erc8004_agent",
      "chainId": 8453,
      "agentId": "412",
      "label": "Registered ERC-8004 agent"
    },
    {
      "type": "erc7710_delegation",
      "chainId": 8453,
      "delegationManager": "0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3",
      "expectedDelegator": "0x51fA…Meridian's treasury…",
      "delegation": { …the signed ERC-7710 delegation the agent carries… },
      "label": "Currently authorized by Meridian's treasury"
    }
  ]
}

Response · abridged

{
  "pass": true,
  "results": [
    { "label": "Registered ERC-8004 agent",
      "met": true, "matchedVia": "owner" },
    { "label": "Currently authorized by Meridian's treasury",
      "met": true,
      "declaredLimits": [
        { "kind": "erc20_transfer_amount",
          "token": "0x8335…USDC on Base…",
          "maxAmount": "75000000000" }
      ] }
  ],
  "attestedAt": "2026-07-31T20:52:14.000Z",
  "expiresAt": "2026-07-31T20:57:14.000Z",
  "sig": "MEUCIQDrT…", "kid": "insumer-attest-v2"
}

Read the second result closely, because it is doing a lot of work. met: true means the whole chain of facts held at the anchored block: the agent is the delegate, the declared principal is Meridian's treasury, the signature verifies, the delegation is unrevoked as of that block, and every restriction the principal attached uses a recognized enforcer. The declaredLimits block decodes what Meridian actually signed: a USDC spending cap of 75,000, comfortably above this $48,000 invoice. Cap and invoice, side by side, in the same signed object.

Notice also that this attestation expires in five minutes, not the standard thirty. That is deliberate. Revocation is one transaction away, so a verdict about delegation is only fresh while it is fresh. The short window is the honest window.

Call two: the owner, wherever the money lives

The agent lives on one chain. The money lives everywhere. That is not a slogan, it is just what corporate crypto treasuries look like: BTC sitting in cold reserve, USDT on Tron because that is where payment liquidity is, RLUSD on the XRP Ledger, operating USDC on Base and Ethereum. So the second call attests Meridian's treasury wallet, and this is where one request fans out across chains:

Request · Meridian's treasury, six conditions, five chains

{
  "wallet": "0x51fA…Meridian's treasury…",
  "xrplWallet": "rN7n…",
  "bitcoinWallet": "bc1q…",
  "tronWallet": "TWdc…",
  "conditions": [
    { "type": "eas_attestation", "template": "coinbase_verified_account",
      "label": "KYC-attested entity" },
    { "type": "ratio_to_amount", "chainId": 8453,
      "contractAddress": "0x8335…USDC on Base…",
      "multiple": "1.5", "amount": "48000",
      "label": "Operating account covers 1.5x this payment" },
    { "type": "token_balance", "chainId": 1,
      "contractAddress": "0xA0b8…USDC on Ethereum…",
      "threshold": "250000",
      "label": "Mainnet float above policy floor" },
    { "type": "token_balance", "chainId": "xrpl",
      "contractAddress": "rMxC…RLUSD issuer…", "currency": "RLUSD",
      "threshold": "100000",
      "label": "RLUSD reserve above floor" },
    { "type": "token_balance", "chainId": "bitcoin",
      "contractAddress": "native", "threshold": "5",
      "label": "BTC cold reserve intact" },
    { "type": "token_balance", "chainId": "tron",
      "contractAddress": "TR7N…USDT on Tron…", "threshold": "150000",
      "label": "USDT payment float above floor" }
  ]
}

Response · abridged

{
  "pass": true,
  "passCount": 6, "failCount": 0,
  "results": [
    { "label": "KYC-attested entity",                    "met": true },
    { "label": "Operating account covers 1.5x this payment", "met": true },
    { "label": "Mainnet float above policy floor",        "met": true },
    { "label": "RLUSD reserve above floor",               "met": true },
    { "label": "BTC cold reserve intact",                "met": true },
    { "label": "USDT payment float above floor",          "met": true }
  ],
  "attestedAt": "2026-07-31T20:52:15.000Z",
  "expiresAt": "2026-07-31T21:22:15.000Z",
  "sig": "MEQCIB4w…", "kid": "insumer-attest-v2"
}

Six signed booleans across five chains, one call, one signature. A bank checking loan covenants before a disbursement would recognize every line of it. And look at what the treasury service never learns: not one balance. It knows the operating account holds at least 1.5 times this payment. It does not know if that is $72,001 or $40 million. Meridian answers the questions precisely because answering reveals nothing else. That is the trade the whole model runs on: conditions in, signed booleans out.

The ratio_to_amount condition deserves a special mention because it was built for exactly this moment. A flat threshold goes stale: the floor that made sense for $48,000 invoices is wrong for $480,000 invoices. A ratio never needs re-tuning. Pass the payment amount, pass your risk multiple, and the signed answer is always scaled to the transaction in front of you.

The payment executes at 4:52:19. Both attestations go into the case file next to the instruction and the transaction hash. Total verification cost: two credits.

Fourteen months later

Now the part nobody plans for. It is fourteen months later and one of three people is asking questions. Meridian's new CFO, who says the company never authorized that payment. Meridian's auditor, who wants to know why a bot could move $48,000 of client money. Or a regulator, who wants to see the treasury service's controls for agent-initiated instructions.

Here is the uncomfortable truth about that conversation: the blockchain alone cannot answer that question now. It proves the payment happened, permanently and to anyone. What it does not preserve is the state you evaluated at the moment you decided to act. The delegation may have been revoked since. The balances have moved. The facts that justified your decision were perishable, and the person questioning you showed up after they perished.

Unless someone recorded them. That is what the two receipts are. Signed, block-anchored statements that on July 31 at 4:52 p.m., at a specific block, the delegation was valid and unrevoked, the signed spending cap exceeded the invoice, the principal was KYC-attested, and every reserve covenant held. The signatures verify against our published key with any standard library, so "trust me, we checked" becomes "here is a verifiable object, check it yourself."

This is very old technology in new clothes. A notary does not vouch for your character. A notary witnesses that a specific fact was true at a specific moment and signs, so the record outlives the moment. That is exactly what attest is: a notary for wallet state, with one difference no notary ever had. This one witnesses on every chain at once.

And for the one clause that could change a block later, you do not even have to trust us. Ask for the delegation check with proof: "merkle" and the response carries an EIP-1186 storage proof of the revocation slot itself, verifiable against the block header from any source you like. "Unrevoked as of block N" stops being our word and becomes arithmetic. The state attestation spec walks through the whole procedure.

Not a score. State.

One more distinction, and for anyone who has sat across from an auditor it may be the one that matters most. Nothing in either call is a trust score.

A score is an opinion. Somebody's model weighed some signals and produced an 87, and when the auditor asks why you paid out on an 87, you are defending a number you did not compute, from inputs you cannot see, produced by a model that has probably changed since. You cannot re-derive it. Neither can they. An opinion in your audit file is a liability wearing a badge.

What these calls return is wallet state, checked against conditions you wrote. Balance at least 1.5x the payment at block N: true. Delegation unrevoked as of block N: true. KYC attestation present: true. No weights, no model, no judgment. The API never says "this wallet is trustworthy." It reads state, applies your condition, and signs the answer. The policy stays yours: the 1.5x multiple, the reserve floors, which attestation counts as KYC. Those are your risk decisions, sitting in plain sight in your own request. What you outsource is only the reading of chain state and the signature over the result.

So the audit conversation becomes the best version of itself: here was our written policy, and here are the signed facts showing the policy was satisfied at the moment we acted. Policy plus facts. Nothing in between for anyone to second-guess.

This was one checklist. Yours will be different.

Everything above is one composition, not the product. Meridian's eight questions are what a treasury service happens to care about. The caller writes the checklist, and the menu it draws from is long: nine condition types, any thresholds, any mix of 38 chains, up to ten conditions per call.

A different caller asks different questions of the same endpoint:

• Does this wallet hold a tokenized security? A tokenized treasury fund share or a tokenized equity is, on-chain, a token. "Holds at least 100 shares" is a token_balance condition like any other, answered without revealing the position size.
• Does it own the NFT? A collection on Ethereum, a Solana mint, an XRP Ledger issuer. Ownership yes or no, never the contents of the wallet.
• Does it carry the membership pass? A community token or membership pass is a condition, so "is this person one of ours" becomes a signed boolean any door, store, or site can check.
• Is it a meaningful holder? "Holds at least half a percent of supply" via ratio_to_supply, for governance and communities where share matters more than amount.
• Has someone attested to it? KYC, credentials, compliance claims: any EAS attestation, by template or raw schema.
• Does your own contract say yes? Any view function that answers yes or no about an address, like hasAccess(address), becomes attestable with evm_view_call. Your rules, our signature.

Swap the amounts, swap the chains, stack them however your risk policy reads. The shape of the answer never changes: signed booleans about wallet state, checked at a block, verifiable later. One note for precision: token and balance checks span all 38 chains, while NFT ownership spans the 34 chains where NFTs live.

Eight answers, six chains, two receipts

Count what the two calls actually delivered. Eight signed booleans. Six chains touched: Base for the agent, the delegation, the KYC attestation, and the operating account; then Ethereum, the XRP Ledger, Bitcoin, and Tron for the covenants. Two receipts that will outlive the state they describe. Zero balances revealed. And the same endpoint answers nine condition types across 38 chains, so when Meridian's treasury adds Solana or Stellar or Sui next quarter, that is one more condition in the array, not a new integration.

The next time a machine shows up asking you to move a human's money, there are only two things you need that the payment rails will not give you: signed answers before you act, and the same signed answers still in your hands when the human asks what happened. Both are one POST away.