On-Chain Verification API: Verify Anything
On-Chain, Reveal Nothing

AI agents need to verify what wallets hold. But checking a balance means seeing a balance, and that creates a privacy problem. Today we are launching the On-Chain Verification API: a single endpoint that checks on-chain conditions across 32 blockchains and returns a cryptographically signed yes or no. No balances. No holdings data. Just proof.

The problem with exposing balances

When an AI agent needs to know whether a wallet holds a certain token, the standard approach is to call an RPC endpoint and read the raw balance. That works, but it exposes everything. The agent now knows the exact amount held, every token in the wallet, and potentially the full transaction history.

For many use cases, that is far more information than needed. A token-gated Discord bot does not need to know you hold 47,291 USDC. It just needs to know you hold more than zero. A lending protocol does not need your full portfolio breakdown. It just needs to know you meet a minimum threshold.

The question is binary. The answer should be too.

How the On-Chain Verification API works

The API accepts a list of conditions and a wallet address. Each condition specifies a token contract, a chain, and optionally a threshold. The API checks each condition on-chain and returns a signed verification with a simple met: true or met: false for each one.

Here is what a request looks like:

POST /v1/attest
{
  "wallet": "0x1234...abcd",
  "conditions": [
    {
      "type": "token_balance",
      "contractAddress": "0xA0b8...3E7a",
      "chainId": 1,
      "threshold": 1000,
      "decimals": 6,
      "label": "USDC >= 1000"
    },
    {
      "type": "nft_ownership",
      "contractAddress": "0xBC4C...a4f8",
      "chainId": 1,
      "label": "Bored Ape holder"
    }
  ]
}

And the response:

{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-A7C3E8F2D4A16790",
      "pass": true,
      "results": [
        { "condition": 0, "label": "USDC >= 1000",
          "type": "token_balance", "chainId": 1, "met": true,
          "evaluatedCondition": { "type": "token_balance", "chainId": 1, "contractAddress": "0xA0b8...3E7a", "operator": "gte", "threshold": 1000, "decimals": 6 },
          "conditionHash": "0x3a7f...", "blockNumber": "0x12f4a80", "blockTimestamp": "2026-02-22T15:30:00.000Z" },
        { "condition": 1, "label": "Bored Ape holder",
          "type": "nft_ownership", "chainId": 1, "met": false,
          "evaluatedCondition": { "type": "nft_ownership", "chainId": 1, "contractAddress": "0xBC4C...a4f8", "operator": "gt", "threshold": 0 },
          "conditionHash": "0x9b2e...", "blockNumber": "0x12f4a80", "blockTimestamp": "2026-02-22T15:30:00.000Z" }
      ],
      "passCount": 1,
      "failCount": 1,
      "attestedAt": "2026-02-22T15:30:00.000Z",
      "expiresAt": "2026-02-22T16:00:00.000Z"
    },
    "sig": "base64-ecdsa-signature",
    "kid": "insumer-attest-v1"
  },
  "meta": { "creditsRemaining": 42, "creditsCharged": 1, "version": "1.0", "timestamp": "2026-02-22T15:30:01.000Z" }
}

Notice what is absent from the response: no balance amounts, no token lists, no transaction data. The wallet's actual holdings never leave the server. Only the boolean results and a cryptographic signature are returned.

Cryptographically signed results

Every verification response includes an ECDSA signature over the result payload. This means any downstream system can independently verify that the verification was issued by The Insumer Model and has not been tampered with, without making another API call.

This is particularly important for agent-to-agent workflows. If Agent A requests a verification and passes the signed result to Agent B, Agent B can verify the signature locally. No trust required. No callback to the API. The verification is self-contained proof.

For a complete guide to AI agent verification — including attestation, trust profiles, and commerce endpoints — see the AI Agent Verification API overview. To go deeper on structured wallet trust data, explore wallet trust profiles.

33 chains, one call

The API supports conditions across all 32 blockchains in The Insumer Model network. You can mix chains in a single request. A verification that checks USDC on Ethereum, an NFT on Base, and a token on Solana is one API call, not three.

Supported chains include Ethereum, BNB Chain, Base, Polygon, Arbitrum, Optimism, Avalanche, Solana, and 24 more. The full list is in the verification docs.

Four condition types

The API currently supports four condition types:

• token_balance: checks whether a wallet holds at least a specified amount of a token. You provide the contract address, chain, threshold, and decimals. The API returns met: true if the wallet's holdings meet or exceed the threshold.
• nft_ownership: checks whether a wallet holds at least one NFT from a given contract. No threshold needed. If the wallet holds one or more, it passes.
• eas_attestation: checks whether a wallet has a valid EAS attestation matching a given schema on a supported chain.
• farcaster_id: checks whether a wallet is linked to a Farcaster account.

You can include up to 10 conditions per request. The overall pass field is true only when all conditions are met.

Built for agents

The API is designed for programmatic access. There is no dashboard to click through. You get an API key, you call the endpoint, you get a signed result. That is the entire workflow.

This is particularly important for AI agent integrations. Authentication is via API key in the X-API-Key header. Keys come in three tiers:

• Free: 10 verification credits included. No cost. Instant provisioning.
• Pro: 100 credits included. Higher rate limits.
• Enterprise: 500 credits included. Highest rate limits.

Each verification costs one credit. Additional credits can be purchased with USDC at 25 credits per USDC ($0.04 per verification). You can check your credit balance at any time with GET /v1/credits.

Use cases

Here are some of the ways agents can use the On-Chain Verification API:

• Token-gated access: Verify a user meets a minimum holding threshold before granting access to a channel, tool, or service. No balance data leaves the API.
• NFT membership: Check NFT ownership to unlock perks, content, or community features. Works with any collection on any supported chain.
• Creditworthiness signals: Confirm a wallet meets a stablecoin threshold without revealing the exact amount. Useful for DeFi agents evaluating counterparties.
• DAO eligibility: Verify governance token holdings for voting eligibility or proposal rights.
• Agent-to-agent trust: One agent verifies a wallet, passes the signed result to another agent. The second agent verifies the signature locally. Zero API calls needed on the receiving end.
• Compliance checks: Confirm a wallet meets certain asset thresholds for KYC or accreditation workflows, without exposing specific holdings.

Getting started

The fastest path from zero to a signed verification:

1. Get a free API key at /developers. No credit card required.
2. Call POST /v1/attest with your wallet address and conditions.
3. Receive a signed verification with boolean results.

The full API documentation, including request schemas, error codes, and code examples, is at /developers/verification. The /developers hub has links to all verticals including trust, compliance, and commerce.

Privacy is the point

Most blockchain APIs are designed to expose data. That is useful for block explorers and analytics platforms, but it is the wrong model for verification. When the goal is "does this wallet meet a condition," the answer should be yes or no, not a full financial profile.

The Insumer Model On-Chain Verification API does not store balances. It does not return balances. It checks conditions on-chain, records only the boolean results, signs them, and returns the signed verification. The wallet's actual holdings are never persisted or transmitted.

Verify anything on-chain. Reveal nothing.