> Answers on how wallet auth works, what it costs, what the API sees and how to verify a signed result. For developers and AI agent builders. > > Page: https://insumermodel.com/faq/ · API: https://api.insumermodel.com · OpenAPI: https://insumermodel.com/openapi.json · Index for agents: https://insumermodel.com/llms.txt # Frequently Asked Questions Everything you need to know about wallet auth, from getting started to technical details. ## General Questions ### What is The Insumer Model™? 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](https://insumermodel.com/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](https://insumermodel.com/how-it-works/) page. ### Is InsumerAPI an oracle? 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. ### How is wallet auth different from OAuth? OAuth proves identity: who you are. [Wallet auth](https://insumermodel.com/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. ### What does “boolean, not balance” mean? 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. ### Is this a payment system? 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. ### What blockchains are supported? 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](https://insumermodel.com/how-it-works/). ### Does it work internationally? 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. ### What are the use cases? 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). ## For Developers ### Is there an API? 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](https://insumermodel.com/developers/) for details. ### How do I get an API key? Enter your email on the [homepage](https://insumermodel.com/) 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](https://insumermodel.com/pricing/#x402). 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. ### What does it cost? 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 →](https://insumermodel.com/pricing/) ### What SDKs and integrations are available? 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](https://insumermodel.com/openapi.yaml). ### Can AI agents use the API? 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](https://insumermodel.com/pricing/#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. ### Can my AI agent authenticate with a wallet signature instead of an API key? 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)](https://eips.ethereum.org/EIPS/eip-4361) scoped to `api.insumermodel.com`; the signature is [EIP-191](https://eips.ethereum.org/EIPS/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`](https://www.npmjs.com/package/@skyemeta/access) middleware on npm accepts wallet-signed requests beside API keys. See the full [Authentication reference](https://insumermodel.com/developers/api-reference/#auth). ### How do I verify an attestation independently? 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](https://insumermodel.com/.well-known/jwks.json) or `GET /v1/jwks`, then verify with [insumer-verify](https://www.npmjs.com/package/insumer-verify) (npm or [PyPI](https://pypi.org/project/insumer-verify/)), 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. ## For Businesses ### How do I use wallet auth for commerce? Developers build it with `POST /v1/attest` or the [merchant endpoints](https://insumermodel.com/developers/commerce/). Stores, clubs and communities that want it run for them use [Skye Meta](https://skyemeta.com/recognition/), a separate company that licenses InsumerAPI. ### Do businesses need to accept cryptocurrency? 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. ### How fast is verification? API responses typically return in 1–3 seconds, even when checking multiple conditions across multiple chains. ### Does it work for online stores? Yes. Developers can integrate InsumerAPI directly into any online checkout. ### Can I verify KYC or compliance status? 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](https://insumermodel.com/developers/compliance/). ## Technical Details ### How does POST /v1/attest work? 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](https://insumermodel.com/how-it-works/) for the full flow. ### What is a JWT bearer token? 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. ### What is a Merkle storage proof? 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. ### What data is collected and how is privacy protected? 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](https://insumermodel.com/privacy-policy/) for full details. ### Can verification be faked? 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](https://insumermodel.com/.well-known/jwks.json). Forged or tampered results are rejected by any system that checks the signature. ## Still Have Questions? Ask **InsumerChat** in the bottom right corner, reach out to our team. [Contact Us](https://insumermodel.com/contact/) [View API Docs](https://insumermodel.com/developers/)