<!-- Markdown copy of https://insumermodel.com/ai-agent-verification-api/ for agents. -->

> Give an AI agent wallet auth: one call checks a wallet on any of 37 chains and returns a signed yes or no. Hosted MCP server, x402 pay per call, LangChain.
>
> Page: https://insumermodel.com/ai-agent-verification-api/ · API: https://api.insumermodel.com · OpenAPI: https://insumermodel.com/openapi.json · Index for agents: https://insumermodel.com/llms.txt

# AI Agent Wallet Auth API

One API call reads token balances, NFT ownership, on-chain attestations, Farcaster identity, arbitrary boolean view calls, ratio rules, or agent standing across 37 blockchains. Returns an attestation signed twice, ECDSA and post-quantum. No RPC management. No ABI encoding. No Web3 libraries.

[Quickstart](https://insumermodel.com/developers/quickstart/) [View OpenAPI Spec](https://insumermodel.com/openapi.yaml)

### On this page

1. Why AI Agents Need On-Chain Verification
2. How the Attestation API Works
3. Verification Capabilities
4. Agent-Native Conditions
5. Cross-Chain Coverage (37 Blockchains)
6. Two Signatures and Merkle Proofs
7. Wallet Trust Profiles for Agent Decisions
8. Token-Gated Commerce Protocols
9. Use Cases
10. Agent SDK Integrations
11. Production Case Study
12. Independent Signature Verification
13. Frequently Asked Questions

## Why AI agents need on-chain verification

AI agents that interact with wallets need to answer simple questions. Does this wallet hold a specific token? Does it own a particular NFT? Has it completed a compliance attestation? These are boolean questions, but getting answers today requires managing RPC connections, ABI encoding, and chain-specific quirks across dozens of networks.

Raw balance APIs also expose too much. If a commerce agent only needs to know whether a customer holds 100 USDC, it shouldn't learn they hold 47,000. [Privacy-preserving verification](https://insumermodel.com/developers/verification/) returns a signed yes or no, nothing more.

Then there's the infrastructure. 37 blockchains means 37 different sets of RPC endpoints, rate limits, and failure modes. EVM chains share libraries but every chain has its own provider quirks. Solana, XRPL, Bitcoin, Tron, Stellar, and Sui each use a completely different protocol. Nobody building an AI agent wants to maintain all of that.

## How the on-chain attestation API works

### Send conditions

POST to /v1/attest with a wallet address and one or more conditions (token balance, NFT, EAS, Farcaster).

### We check on-chain

The API reads the relevant blockchain state. Every signed result carries a chain anchor and an expiry: verifiable, and dated by the chain itself.

### Receive signed result

Get a boolean result signed twice, ECDSA P-256 and post-quantum ML-DSA-65. Verify both with our JWKS endpoint.

### Keep the record

Good for access until it expires (30 minutes, or 5 with a delegation). Good as evidence for as long as you keep it: an audit trail of what your agent was shown, re-checkable offline against a saved copy of our public keys. We cannot reproduce it later, so keep it.

curl: POST /v1/attest:

```bash
curl -X POST https://api.insumermodel.com/v1/attest \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "conditions": [{
      "type": "token_balance",
      "contractAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
      "chainId": 1,
      "threshold": "1000"
    }]
  }'
```

```json
{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-7F2A9E3B1C8D4056",
      "pass": true,
      "results": [{
        "type": "token_balance",
        "met": true,
        "chainId": 1
      }]
    },
    "sig": "<88-char base64, P1363 r||s>",
    "kid": "insumer-attest-v2",
    "pqSig": "...base64...",
    "pqKid": "insumer-attest-pq1"
  }
}
```

## Token balances, NFTs, EAS, Farcaster, and World Chain

### Token Balances

ERC-20, SPL, and XRPL trust line tokens. Check if a wallet meets a threshold without revealing the actual balance.

### NFT Ownership

ERC-721, Solana NFTs, and XRPL NFTokens. Verify that a wallet holds an NFT from a specific collection.

### EAS Attestations

Ethereum Attestation Service attestations on Ethereum, Base, Arbitrum, Optimism, and Polygon. Check schema-based attestations.

### Farcaster Identity

Verify whether a wallet has a registered Farcaster ID using the IdRegistry contract on Optimism. Returns a boolean for social identity gating.

### Self-Scaling Conditions

Rules that scale to the transaction instead of a fixed number. Gate an agent on holding 10x the amount it is about to pay, or a fraction of a token's supply. One condition holds on every payment size with no re-tuning. EVM chains.

### World Chain

Verify WLD token holdings on World Chain (chainId 480). Identity-adjacent verification for the proof-of-personhood ecosystem.

All verification types return the same signed boolean format. [Full documentation →](https://insumermodel.com/developers/verification/)

## Agent-native conditions: standing to act

InsumerAPI attests to on-chain state and takes no side in the transaction. 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. Two condition types on `POST /v1/attest` answer the third, straight from chain state. Both work on any API key. Base only, 1 credit each.

An agent does not even need a key. Send `POST /v1/attest` with no credential headers, take the `402` quote, pay the quoted amount in USDC on Base, Polygon, Arbitrum, Arc, or Solana, and retry with the `PAYMENT-SIGNATURE` header. The facilitator settles gasless (the wallet needs USDC, no gas token) and the signed attestation comes back in the same round trip. erc8004_agent does not support Merkle proofs, so it is always the `$0.05` standard rate. erc7710_delegation does: proof "merkle" returns a storage proof of the revocation slot at `$0.10`. Discover, pay, get a signed answer: no account, no credits, no dashboard.

### `erc8004_agent`

Is this wallet a registered ERC-8004 agent? Met when the attested wallet owns the agent NFT or is the Identity Registry's on-chain signature-verified `agentWallet` binding. Requires `agentId` (uint256 decimal string). The signed statement is exactly “registered at agentId N, owned by / bound to this wallet”. ERC-8004 registration is permissionless, so it implies no vetting, no reputation, no endorsement.

### `erc7710_delegation`

Is this signed delegation from principal P to this agent wallet currently valid, and what limits does it declare? Checks delegate, principal, EIP-712 signature (EOA or ERC-1271), on-chain revocation at the anchored block, and recognized caveats; declared spend and target limits are reported in `declaredLimits`. Attestations containing a delegation condition expire in 5 minutes: revocation is one transaction away, so the verdict window stays tight.

Request shapes, semantics, and result fields: [condition-type docs →](https://insumermodel.com/developers/verification/)

## Cross-chain verification across 37 blockchains

Every chain uses the same POST /v1/attest interface. Pass a `chainId` and the same request works on every chain.

#### EVM: 31 chains

Ethereum, BNB Chain, Base, Avalanche, Polygon, Arbitrum, Optimism, XDC, Chiliz, Soneium, Plume, World Chain, Sonic, Gnosis, Mantle, Scroll, Linea, ZKsync, Blast, Taiko, Ronin, Celo, Viction, opBNB, Unichain, Ink, Sei, Berachain, ApeChain, Robinhood Chain, Arc. Full block anchor on every signed result, on every chain.

#### Solana: 1 chain

SPL token balances, Metaplex NFTs, and compressed NFTs. Native integration, not bridged.

#### XRPL: 1 chain

Native XRP, trustline tokens (RLUSD, USDC), and NFTokens. [Try the live XRPL demo →](https://insumermodel.com/demos/xrpl/)

#### Bitcoin: 1 chain

Native BTC balance across all address formats (P2PKH, P2SH, bech32, Taproot). Responses include `blockHeight` + `blockHash` as chain-tip evidence-of-freshness.

#### Tron: 1 chain

Native TRX and TRC-20 tokens, including USDT-TRC20. Pass `tronWallet` (T-prefixed base58) and `chainId: "tron"`.

#### Stellar: 1 chain

Native XLM and classic trustlines (USDC, BENJI) via `assetCode`. Pass `stellarWallet` (G-prefixed StrKey) and `chainId: "stellar"`.

#### Sui: 1 chain

Native SUI and Sui-native tokens via fully-qualified Move type strings (e.g. USDC). Pass `suiWallet` (0x + 64 hex) and `chainId: "sui"`.

## Signed twice: ECDSA and post-quantum

Every attestation and trust profile carries two signatures over the same answer. ECDSA P-256 (`sig`, `kid`) is the one standard JWT and ECDSA libraries check today. ML-DSA-65 (`pqSig`, `pqKid`), the post-quantum signature standardised in FIPS 204, is there for the record: an agent's signed results stay checkable even if ECDSA can one day be forged. Both public keys are published at [/.well-known/jwks.json](https://insumermodel.com/.well-known/jwks.json) and via the `GET /v1/jwks` endpoint (24-hour cache), and the binding between them is anchored on Base. The [insumer-verify](https://www.npmjs.com/package/insumer-verify) package reports each signature as its own verdict (the post-quantum check needs its optional ML-DSA package); any ECDSA library checks the first.

For higher assurance, add `proof: "merkle"` to your attestation request. This returns an EIP-1186 Merkle storage proof anchored to a specific block hash, making the attestation independently verifiable against the blockchain state trie. Merkle proofs are available on 27 of 31 EVM chains. [Verification docs →](https://insumermodel.com/developers/verification/)

The attestation format aligns with emerging standards including [KCP RFC-0004](https://insumermodel.com/blog/kcp-rfc-0004-attestation-url-standard.html) (attestation_url) and the ERC-8004 proposed standard for on-chain attestation URLs, ensuring forward compatibility as the ecosystem formalizes attestation exchange between AI agents.

## Wallet trust profiles for agent decisions

A single attestation answers one question. A trust profile answers many. `POST /v1/trust` runs 155 checks across 27 chains in 10 dimensions, up to 176 across 29 chains in 14 dimensions with optional Solana, XRPL, Bitcoin, and Tron wallets, to produce a multi-dimensional wallet trust fact profile. Each dimension is reported independently with per-check booleans, and the entire profile is signed twice, with ECDSA and post-quantum ML-DSA-65. No score, no opinion, just cryptographically verifiable evidence organized by dimension.

Ten base dimensions always run: stablecoins (USDC across 17 chains and USDT across 10, plus OUSD, PYUSD, USDG, USD1, RLUSD, USDS, DAI and EURC on their main chains), governance, nfts, staking, institutional_stablecoins, tokenized_treasuries, stablecoin_deposits, wrapped_bitcoin, names, and account (contract code present and EIP-7702 delegation present, on Ethereum, Base, Arbitrum, Optimism and Polygon). That is 155 presence checks across 27 chains. Four optional dimensions activate when the matching wallet is supplied: solana (USDC, EURC, OUSD, PYUSD, USD1, USDG, USDS, BUIDL, USDY, WBTC, cbBTC, tBTC, JitoSOL and mSOL), xrpl (RLUSD, USDC and OUSG), bitcoin (native BTC), and tron (USDT, USD1 and WBTC), for up to 176 checks across 29 chains in 14 dimensions. Dimensions come back in a fixed order, the same for every wallet. Stellar and Sui wallets add no dimension; their rows sit inside the base dimensions. Batch up to 10 wallets in a single call with `POST /v1/trust/batch`.

Trust profiles are the input layer for agent-to-agent trust decisions, credit scoring, and compliance workflows. [Trust profile documentation →](https://insumermodel.com/developers/trust/)

## Condition-based commerce via ACP & UCP

Attestations alone prove facts. Commerce endpoints turn those facts into actions. `POST /v1/acp/discount` answers in the format of the Agentic Commerce Protocol (ACP) from OpenAI and Stripe; `POST /v1/ucp/discount` answers as a discount fragment of Google's Universal Commerce Protocol (UCP).

An agent sends a wallet and a merchant ID. The API checks the wallet against the merchant's tiers and returns a signed code and the discount it carries (0 when no tier applies). The merchant never sees the wallet balance, only that the condition was met.

This is condition-based commerce without the merchant needing any blockchain infrastructure. [Commerce documentation →](https://insumermodel.com/developers/commerce/)

## On-chain verification use cases

Every use case below runs through the same `POST /v1/attest` endpoint. The API handles the chain-specific logic.

#### AI Agent Counterparty Checks

Before an AI agent transacts with another agent or wallet, it calls `POST /v1/trust` to evaluate stablecoin holdings, governance token holdings, staking positions, tokenized treasuries, deposit receipts, wrapped bitcoin, names, and account code. The trust profile becomes the decision input for whether to proceed.

#### Token-Gated Commerce

A merchant configures token tiers. When a customer (or their AI agent) presents a wallet, the API checks holdings and returns a discount code. The merchant never sees the wallet balance, only the tier the customer qualifies for.

#### XRPL Trust Line Verification

Verify RLUSD or USDC trust lines, or native XRP balances, on the XRP Ledger. [Try the live demo →](https://insumermodel.com/demos/xrpl/)

#### Multi-Chain Attestation

Check conditions across multiple chains in a single API call. A verification that checks USDC on Ethereum, an NFT on Base, and a token on Solana is one request, not three. Results are signed together.

#### Attestation Gating

Use EAS attestations on Ethereum, Base, Arbitrum, Optimism, or Polygon to gate access to services. Verify that a wallet holds a specific schema-based attestation without querying the attestation service directly.

#### World Chain Identity Signals

Verify WLD token holdings on World Chain to add proof-of-personhood-adjacent signals to agent trust decisions. An agent holding WLD on chainId 480 has likely interacted with the Worldcoin identity ecosystem.

#### Developer Platform Onboarding

AI agents buy their own API key by sending USDC to the platform wallet and calling `POST /v1/keys/buy` with the transaction hash, and no email or prior authentication is needed. The sender wallet becomes the key’s identity. Alternatively, agents can use the free key creation endpoint for 10 starter credits. Or skip keys entirely: `attest` and `trust` support [x402 pay-per-call](https://insumermodel.com/pricing/#x402). A request with no credentials returns a 402 quote; pay the quoted amount in USDC on Base, Polygon, Arbitrum, Arc, or Solana, and retry. $0.05 per attestation, including the agent standing types. [Onboarding docs →](https://insumermodel.com/developers/onboarding/)

#### Self-Sustaining Loop

When credits run low, the agent calls `POST /v1/credits/buy` with a USDC transaction hash. Credits are added instantly. No human approval, no subscription renewal, no dashboard. The agent discovers, acquires access, operates, refuels, and continues indefinitely. That closed loop is what makes it autonomous infrastructure, not just an API. [Full lifecycle →](https://insumermodel.com/blog/ai-agent-autonomous-api-lifecycle.html)

## Claude Code, MCP, LangChain, GPT, and REST

#### Claude Code Skill

Claude writes the integration. One install, one prompt.

[Smithery →](https://smithery.ai/skills/douglasborthwick/insumer-skill)

#### MCP Server

Claude Desktop, Cursor, Windsurf. Install via npx, or connect by URL at api.insumermodel.com/mcp (no key, ten tools).

[npm →](https://www.npmjs.com/package/mcp-server-insumer)

#### LangChain

Python toolkit for LangChain agents. pip install.

[PyPI →](https://pypi.org/project/langchain-insumer/)

#### OpenAI GPT

Custom GPT with 28 actions. Import the spec.

[Setup guide →](https://insumermodel.com/developers/)

#### ElizaOS Plugin

10 actions for the autonomous agent lifecycle. npm install.

[npm →](https://www.npmjs.com/package/@insumermodel/plugin-eliza)

#### LlamaIndex Tools

InsumerToolSpec with six agent methods. pip install.

[PyPI →](https://pypi.org/project/llama-index-tools-insumer/)

#### WDK Protocol Module

Packages the wallet auth primitive as a WDK protocol module, alongside Swap, Bridge, Lending, Fiat.

[npm →](https://www.npmjs.com/package/@insumermodel/wdk-protocol-wallet-auth)

#### mppx condition-gate

Method.Server adapter for MPP. Six condition types: token, NFT, EAS, Farcaster, and self-scaling amount/supply ratios.

[npm →](https://www.npmjs.com/package/@insumermodel/mppx-condition-gate)

#### REST API

46 endpoints. Any language, any framework.

[OpenAPI spec →](https://insumermodel.com/openapi.yaml)

Explore how the core endpoints connect in the [API Topology →](https://insumermodel.com/workbench/)

## Case study

ERC-8183 Agentic Commerce

### AsterPay KYA: Know Your Agent trust scoring

AsterPay wired InsumerAPI into their KYA Hook for ERC-8183 agentic commerce. One `POST /v1/attest` call evaluates 4 conditions (USDC balance, Coinbase KYC, country verification, and Gitcoin Passport score), feeding into AsterPay's KYA trust score without manual review.

JWT responses are verified via ES256 signatures and JWKS. Contracts deployed on Base Sepolia.

[Read the full case study →](https://insumermodel.com/blog/asterpay-kya-erc8183-attestation-integration.html)

## Independent attestation signature verification

Every attestation and trust profile includes two signatures, each with a key identifier: `sig` and `kid` (ECDSA P-256), and `pqSig` and `pqKid` (post-quantum ML-DSA-65). To verify an attestation independently:

1. Fetch the public keys from [/.well-known/jwks.json](https://insumermodel.com/.well-known/jwks.json) or the `GET /v1/jwks` endpoint
2. Match the `kid` in the response to the key in the JWKS
3. Verify the ECDSA signature over the attestation payload using any ECDSA library
4. Resolve `pqKid` to its `AKP` entry in the same JWKS and verify the post-quantum signature `pqSig` (ML-DSA-65), reported as its own verdict

The [insumer-verify](https://www.npmjs.com/package/insumer-verify) package, on npm and [PyPI](https://pypi.org/project/insumer-verify/) ([source on GitHub](https://github.com/insumerapi/insumer-verify)) wraps this in a single function call. No callback to the API is needed. The verification is self-contained and works offline.

## Frequently asked questions

### What does the AI Agent Verification API return?

The API returns a boolean signed twice, with ECDSA P-256 and post-quantum ML-DSA-65. It checks whether a wallet meets one or more conditions (for example a token balance threshold, NFT ownership, an EAS attestation, Farcaster identity, or agent standing) and returns true or false without exposing the actual balance or holdings.

### How many blockchains does InsumerAPI support?

InsumerAPI supports 37 blockchains: 31 EVM chains (including Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, XDC, Robinhood Chain, and 22 more), Solana (SPL tokens and NFTs), XRPL (native XRP, trust line tokens like RLUSD and USDC, and NFTokens), Bitcoin (native BTC), Tron (native TRX, TRC-20 tokens including USDT-TRC20), Stellar (native XLM, classic trustline assets including USDC and BENJI), and Sui (native SUI, Sui-native tokens including USDC).

### How do I verify an attestation signature?

Every attestation includes two signatures, each with a key ID: ECDSA P-256 (`sig`, `kid`) and post-quantum ML-DSA-65 (`pqSig`, `pqKid`). Fetch the public keys from [/.well-known/jwks.json](https://insumermodel.com/.well-known/jwks.json) or `GET /v1/jwks`, then verify with the [insumer-verify](https://www.npmjs.com/package/insumer-verify) package, which reports each signature as its own verdict, or check the ECDSA signature with any ECDSA library. No callback to the API is required.

### What is a Merkle storage proof?

Adding `proof: "merkle"` to an attestation request returns an EIP-1186 Merkle storage proof anchored to a specific block hash. This makes the attestation independently verifiable against the blockchain state trie without trusting the API. Merkle proofs are available on 27 of 31 EVM chains and cost 2 credits instead of 1.

### Why use signed attestations instead of raw RPC calls?

Raw RPC calls expose the full balance, require chain-specific ABI encoding, and produce no verifiable proof that the check was performed correctly. A signed attestation returns only a boolean (privacy-preserving), works identically across 37 chains (no per-chain code), and includes a cryptographic signature that any downstream system can verify independently.

### Is the API privacy-preserving?

Yes. The API returns true or false: whether the condition was met or not. By default it never exposes the actual token balance, NFT inventory, or transaction history; an optional Merkle proof carries the proven balance. A commerce agent learns "this wallet qualifies for 15% off," not "this wallet holds 47,000 USDC." This is privacy by design at the protocol level.

### Can AI agents create their own API keys?

Yes. An AI agent can buy its own API key autonomously by sending USDC to the platform wallet and calling `POST /v1/keys/buy` with the transaction hash. No email or prior authentication needed. The sender wallet becomes the key’s identity. Alternatively, agents can call `POST /v1/keys/create` with an email for a free key with 10 credits. The entire lifecycle (key purchase, verification, and credit top-up) is programmatic with no human intervention required. Or skip keys entirely: [x402 pay-per-call](https://insumermodel.com/pricing/#x402) serves attest and trust with no key at all, $0.05 per attestation, settled in USDC on Base, Polygon, Arbitrum, Arc, or Solana.

Still forming the mental model? Our founder co-hosts Old Men, New Money. See the plain-English explainer on [agent commerce infrastructure](https://oldmennewmoney.com/agent-commerce-infrastructure).

## Start verifying

Free tier includes 10 free verifications plus 100 requests a day. One attestation costs 1 credit. Get your API key and make your first call in under a minute.

[Quickstart](https://insumermodel.com/developers/quickstart/) [Read the Docs](https://insumermodel.com/developers/)