On-Chain Attestation

POST /v1/attest

Boolean attestation. Returns an ECDSA-signed pass/fail for one or more conditions.

Agent conditions: standing to act

InsumerAPI is the neutral verifier: off-chain attestation of on-chain state. At settlement time three questions exist: can this wallet pay (payment rails), is the decision sound (reasoning verifiers), and does this party have standing to act. These two condition types answer the third, straight from chain state. Both are generally available, so every API key can send them with no flag to request. Base (chainId 8453) only at launch. 1 credit each. erc8004_agent does not support Merkle proofs; erc7710_delegation does: a revocation proof, covered below.

They also work with no API key at all, via x402 pay-per-call: send POST /v1/attest with no credential headers, take the 402 quote, sign an EIP-3009 USDC authorization on Base, and retry with the X-PAYMENT header. A standard call prices at the $0.05 rate. An agent can ask whether a counterparty has standing to act without ever opening an account.

The verdict and the declared limits are two different things

met is the verdict, and it is exactly the boolean above: the attested wallet is the delegate, the declared delegator matches expectedDelegator, the EIP-712 signature verifies, the delegation is unrevoked as of the anchored block, every caveat uses a recognized enforcer, and any time-window caveat is currently satisfied.

declaredLimits is not part of that boolean. It is a signed decode of the caveat terms the caller itself submitted, riding alongside the verdict inside the signed results: a sibling of evaluatedCondition, inside the signed payload but outside conditionHash. InsumerAPI returns signed booleans, never raw wallet data. On a delegation, the boolean is met, and the declared limits travel next to it, signed. They ride on passing and failing verdicts alike, once the signature and revocation checks pass: a delegation failing on unknown_caveat_enforcer or outside_time_window still carries the decode of its recognized caveats, while earlier failures (bad signature, revoked, mismatched parties) carry none. Worth knowing which is which before you build on either.

One decoded entry

{
  "kind": "erc20_transfer_amount",
  "enforcer": "0xf100b0819427117ecf76ed94b358b1a5b5c6d2fc",
  "terms": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913000000000000000000000000000000000000000000000000000000003b9aca00",
  "token": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "maxAmount": "1000000000"
}

All numeric values are decimal strings in base units: "1000000000" here is 1,000 USDC at 6 decimals.

Recognized kinds

Check the decode yourself

Every entry carries terms: the exact hex bytes it was decoded from. You supplied those bytes in your own request, so verification needs no external lookup and no second API call.

1. Re-run the enforcer contract’s public getTermsInfo byte layout against terms, and compare the result to the decoded values in the entry. In the example above, the first 20 bytes are the token and the next 32 are the amount.
2. Recompute delegationHash (the EIP-712 struct hash, carried in the signed evaluatedCondition, that commits to every caveat’s enforcer and terms) from the delegation object you already hold, and confirm it matches.

Together those two steps make the decode a checkable claim rather than a trust-us assertion: the hash pins which caveats were evaluated, and the byte layout pins what each one says.

Leaving the limits out: declaredLimits: "omit"

A delegation attestation in JWT form is portable, which means that by default the principal’s declared limits travel to anyone the token is forwarded to. Usually that is exactly right: a relying party needs the limits to act on them. Sometimes it is not.

Send the top-level declaredLimits modifier (a sibling of proof and format) to control it. Absent or "include" is the default: the limits are returned in the signed results, and therefore travel inside the JWT when format: "jwt" is used. Set it to "omit" and the decoded limits are left out; the result carries declaredLimitsOmitted: true instead.

{
  "wallet": "0x<agent wallet>",
  "format": "jwt",
  "declaredLimits": "omit",
  "conditions": [ { "type": "erc7710_delegation", ... } ]
}

You lose nothing by omitting: you submitted the caveats, so you already hold them. And the guarantee that makes this safe to forward: met, delegationHash, and conditionHash are byte-identical whether or not the limits are omitted. A forwarded token still commits to exactly which delegation was checked, and a holder can verify a limit shown to them out-of-band without ever learning one from the token.

The last part of the verdict is now provable too

A delegation verdict has three parts, and until now they were not equally checkable. The EIP-712 signature check you could always reproduce yourself: you hold the delegation object. The caveat decode you could always reproduce yourself: you submitted the raw terms bytes, and the steps above show how. But “not revoked as of block N” was ours to assert and yours to accept.

Send proof: "merkle" alongside a delegation condition and that gap closes. The result carries an EIP-1186 storage proof of disabledDelegations[delegationHash] in the DelegationManager’s storage, against the anchored block’s state root. Verify it against a block header and the whole verdict is checkable rather than partly trusted.

{
  "available": true,
  "type": "merkle",
  "subject": "delegation_revocation",
  "blockNumber": "0x12a05f200",
  "contractAddress": "0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3",
  "mappingSlot": 1,
  "storageKey": "0x<keccak256(abi.encode(delegationHash, mappingSlot))>",
  "accountProof": [ "0x...", ... ],
  "storageProof": [ { "key": "0x...", "value": "0x0", "proof": [ "0x...", ... ] } ],
  "storageHash": "0x..."
}

subject is what tells a delegation proof apart from a balance proof: balance proofs carry no subject field at all.

How to check it

1. Recompute storageKey = keccak256(abi.encode(delegationHash, mappingSlot)) using the delegationHash from the signed evaluatedCondition, and confirm it equals the returned storageKey. Do not skip this step: it is what binds the proof to this delegation. A proof of some other slot would verify against the header perfectly well.
2. Verify accountProof and storageProof against the state root of the block header for blockNumber.
3. Read the proven value: 1 means revoked, 0 means not revoked. Absence is proven here as firmly as presence: a proven 0 is positive evidence that no revocation exists, not a report that none was found.

Which managers

Proofs are returned only for DelegationManager deployments whose storage layout has been verified on-chain. Today that is the v1.3.0 manager on Base, 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3. The other recognized manager versions return proof.available: false with a reason saying the layout is unverified; the boolean verdict is computed and signed exactly as normal.

That restraint is the point. An inferred slot number would produce a proof of the wrong storage location that still verifies cleanly against the block header, a confident answer to a question nobody asked. Worse than no proof at all. So a slot gets proven only once it has been confirmed against the deployed contract.

Proof mode on a delegation condition costs 2 credits instead of 1, the same premium as any other proof-mode request. If a proof cannot be produced for a transient RPC reason, the premium is refunded and the call costs 1.