Frequently Asked Questions

The Insumer Model™ is condition-based access infrastructure. It reads blockchain state and returns verified, privacy-preserving yes/no answers across 37 chains, without exposing wallet balances. You can check offline that every result came from us, unaltered, and on EVM chains a Merkle proof lets you check the balance itself. Think of it as wallet auth: OAuth proves who you are, wallet auth proves what you hold. It is not a points program, not a reputation network, not an identity system, not a DeFi protocol, not a payments processor, and not an oracle network. Learn more on our How It Works page.

No. An oracle brings off-chain data onto a blockchain, usually as a feed that contracts read. InsumerAPI works the other way round. It reads wallet state, evaluates a condition the caller writes, and returns a signed yes or no that can be used anywhere: a web server, an AI agent, a point-of-sale terminal, or a smart contract. The caller decides the condition and what to do with the answer.

For a balance condition it returns the verdict, not the balance, unless you ask for a Merkle proof, which carries the proven value.

You do not have to take the answer on faith. The signature proves the attestation came from us, unaltered, and anyone can check it offline against our published keys. On EVM chains an optional Merkle proof lets you check the balance itself against the block header.

Smart contracts can use these attestations too. Our published contract adapters verify the signature on-chain and expose the result through standard interfaces, one of which (ERC-8183) is called a trust oracle. There the contract is the consumer, and InsumerAPI is still the source of the signed attestation.

OAuth proves identity: who you are. Wallet auth proves holdings: what you hold. The Insumer Model™ converts blockchain state into a signed attestation (a boolean or JWT) that any system can verify without touching a blockchain. Like OAuth, the downstream system never sees the underlying data. It just gets a trusted yes or no.

The API returns true or false: whether a wallet meets a condition or not. By default it never exposes the actual token balance, NFT inventory, or transaction history; the one opt-in exception is a Merkle proof, which carries the proven value so you can check it yourself. A system learns “this wallet qualifies” not “this wallet holds 47,000 USDC.” This is privacy by design at the protocol level.

No. The Insumer Model™ is read-only condition-based access infrastructure. It reads blockchain state and returns signed attestations. It never moves funds, processes payments, or interacts with wallets. It is a verification layer, not a transaction layer.

37 blockchains: 31 EVM chains (Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Sonic, zkSync Era, Linea, Gnosis, Mantle, Celo, and more), Solana (SPL tokens and NFTs), XRP Ledger (native XRP, trust line tokens like RLUSD and USDC, and NFTokens), Bitcoin (native BTC, all address formats including Taproot), Tron (native TRX and TRC-20 tokens), Stellar (native XLM and classic trustlines), and Sui (native SUI and Sui coin types). Moonbeam and Moonriver are not supported, and a request naming either returns 400; GLMR and MOVR live on Base as ERC-20s and are read with an ordinary token_balance condition. See the full list on our How It Works page.

Yes. The API works from any country. Wallet state is public chain state, so the same call returns the same signed answer everywhere. For commerce, discounts are percentage-based, so they work in any currency. Keys and credits can be bought by card or stablecoin from anywhere. Where a country appears in a compliance template, it is a condition you choose to check, not a restriction on where the service works.

Six primary use cases: AI Agents (trust profiles for autonomous agents: facts, not scores), API Access (gate endpoints by wallet conditions), Compliance (KYC and eligibility checks via Coinbase Verifications and EAS attestations), Commerce (condition-based discounts for physical and online stores), Governance (verify voting eligibility), and Tokenized Assets (verify ownership of real-world asset tokens).

Yes. InsumerAPI is a REST API with 46 endpoints for developers and AI agents. The flagship endpoint is POST /v1/attest, which checks wallet conditions and returns a boolean signed with ECDSA and a post-quantum ML-DSA-65 signature, or a standard JWT with a post-quantum twin beside it. Other endpoints include wallet trust profiles, batch trust, compliance checks, and credit management. See the developer documentation for details.

Enter your email on the homepage or call the self-serve key creation endpoint. You get an API key instantly, no credit card required. The free tier includes 10 free verifications plus 100 requests a day. AI agents can also buy a key with USDC, USDT, or BTC via POST /v1/keys/buy, no email needed, the sender wallet becomes the key identity. Or skip the key entirely: attest and trust support x402 pay-per-call. Send a request with no credentials, get a 402 quote, pay the quoted USDC amount on Base, Polygon, Arbitrum, Arc or Solana, retry. $0.05 per attestation, settled on-chain.

Free tier: 10 free verifications plus 100 requests a day, no credit card required. Pro: $29/month (1,000 credits). Enterprise: $99/month (5,000 credits). Pay per call from $0.04, with volume discounts up to 50%. See full pricing →

Five runtime agent SDKs: MCP server (npx -y mcp-server-insumer, runtime agent access for Claude Desktop, Cursor, Windsurf), LangChain (pip install langchain-insumer), ElizaOS plugin (@insumermodel/plugin-eliza), LlamaIndex tool spec (pip install llama-index-tools-insumer), and OpenAI GPT (GPT Store). Plus a Claude Code skill (smithery skill add douglasborthwick/insumer-skill) that helps Claude Code write wallet auth into your project. Plus two framework adapters that package the wallet auth primitive into host-shaped surfaces: WDK protocol module (@insumermodel/wdk-protocol-wallet-auth) for Tether's Wallet Development Kit, and mppx condition-gate (@insumermodel/mppx-condition-gate) for Machine Payments Protocol routes. Attestations are independently verifiable with insumer-verify (npm install insumer-verify). OpenAPI 3.1 spec available at /openapi.yaml.

Yes. AI agents can create their own API keys, verify wallets, and purchase additional credits by sending USDC, USDT, or BTC on-chain, all programmatically with no human intervention. Agents can also skip keys entirely and pay per call over x402 (USDC on Base, Polygon, Arbitrum, Arc, or Solana, $0.05 per attestation). Two condition types exist specifically for agents: erc8004_agent verifies ERC-8004 agent registration, and erc7710_delegation verifies a principal really delegated authority to an agent, checked against live chain state. The MCP server and LangChain SDK make integration straightforward for agent frameworks.

Yes, on five endpoints: POST /v1/attest, POST /v1/trust, POST /v1/trust/batch, GET /v1/credits, and POST /v1/credits/buy. Agents that buy a key via POST /v1/keys/buy with USDC or USDT on an EVM chain receive an Insumer Access pass (soulbound ERC-721) minted to their wallet on Base; x402 payers become eligible after $1 of spend and claim it on their first wallet-signed request. The same wallet can then sign requests with its private key and present them in an Authorization: Wallet header instead of X-API-Key. The signed message is SIWE (EIP-4361) scoped to api.insumermodel.com; the signature is EIP-191 personal_sign; single-use nonce; Issued At within the last 5 minutes. Other endpoints return 501 for this scheme. The five-endpoint coverage lets an SBT-holding agent run the full read-side lifecycle (attest, generate trust profiles, check balance, top up credits) without ever handling an API key. For your own API, Skye Meta’s @skyemeta/access middleware on npm accepts wallet-signed requests beside API keys. See the full Authentication reference.

Every attestation includes two signatures, each with a key ID: ECDSA P-256 (sig, kid) and post-quantum ML-DSA-65 (pqSig, pqKid). Fetch our public keys from /.well-known/jwks.json or GET /v1/jwks, then verify with insumer-verify (npm or PyPI), which reports each signature as its own verdict, or check the ECDSA signature with any standard crypto library. JWT-format results can be verified by standard JWT libraries. No callback to the API is required.

Developers build it with POST /v1/attest or the merchant endpoints. Stores, clubs and communities that want it run for them use Skye Meta, a separate company that licenses InsumerAPI.

No. InsumerAPI is read-only: it checks a wallet and signs the answer, and never processes payments. Your integration keeps its existing payment flow, in whatever currency it already accepts.

API responses typically return in 1–3 seconds, even when checking multiple conditions across multiple chains.

Yes. Developers can integrate InsumerAPI directly into any online checkout.

Yes. InsumerAPI supports on-chain identity checks including Coinbase Verifications (KYC, country of residence, Coinbase One membership) and EAS attestations on Base. Pre-configured compliance templates let developers gate access to verified users without handling personal data. See the compliance docs.

Send a wallet address and one or more conditions (token balance thresholds, NFT ownership, on-chain identity records). The API checks state across 37 chains and returns a yes or no for each condition, signed twice: ECDSA and post-quantum ML-DSA-65. Optionally request format: "jwt" for a standard JWT, or proof: "merkle" for a blockchain-anchored storage proof. See How It Works for the full flow.

Adding format: "jwt" to an attestation request returns a standard ES256-signed JWT alongside the normal response. The JWT contains claims for pass/fail, condition results, and block context. It can be verified by any standard JWT library via the JWKS endpoint, making it compatible with Kong, Nginx, Cloudflare Access, AWS API Gateway, and similar systems. A post-quantum twin, pqJwt, comes beside it.

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

By default the API returns only booleans: true or false for each condition. By default it never exposes wallet balances, token inventories, or transaction history; if you ask for a Merkle proof, the proof carries the proven value. In commerce contexts, merchants see only the outcome (e.g. tier qualification), never the wallet address or holdings. Privacy is built in at the protocol level. Read our Privacy Policy for full details.

No. Verification is performed server-side against live blockchain data. Every attestation is signed twice, with ECDSA and a post-quantum ML-DSA-65 signature. You can verify any attestation yourself using our public signing keys. Forged or tampered results are rejected by any system that checks the signature.