Menu
How It Works
Use Cases
For Merchants For Token & NFT Holders For Foundations
Developers API Map FAQ Blog Pricing GitHub
Get Started

Developers > Changelog

What shipped

Changelog

New endpoints, SDK releases, chain support, and spec changes. Updated as features ship.

May 20, 2026

Wallet Auth Default — New Agents Skip the API Key, Scope Widens to Five Endpoints

Feature
  • POST /v1/keys/buy accepts a new optional keyDelivery body field ("wallet" | "apiKey" | "both", default "wallet"). On EVM purchases where the Insumer Access pass mints successfully, the default response omits the API key string entirely — the wallet + pass is the credential and there is nothing for the agent to store or leak. Callers that prefer a bearer key (legacy HTTP clients, cold-storage backup) opt in with keyDelivery: "apiKey". The key is always returned on non-EVM purchases (Solana, BTC, Tron) and on deferred mints so no buyer is ever left without a usable credential. The response now also carries authMethod ("wallet" | "apiKey" | "both") and, on the wallet path, a human-readable authHint.
  • Wallet Auth scope widened from one endpoint to five. Authorization: Wallet is now accepted on POST /v1/attest, POST /v1/trust, POST /v1/trust/batch, GET /v1/credits, and POST /v1/credits/buy. Other endpoints continue to return 501 for this scheme. An SBT-holding agent can now run the full read-side lifecycle — attest against conditions, generate wallet trust profiles, batch-profile counterparties, check own balance, and top up credits — without ever handling an API key.
  • updateWallet: true on POST /v1/credits/buy is ignored for wallet-auth callers. The SIWE signer is already bound to the registered wallet, and the soulbound Insumer Access pass cannot follow a rotation, so honouring the rewrite would silently lock the caller out on the next sign-in. To rotate the registered wallet, use X-API-Key auth.
  • All existing X-API-Key flows are unchanged on every endpoint. Blog post: Your Agent Doesn't Need an API Key.
May 19, 2026

Wallet Auth Goes Live on /v1/attest — Insumer Access Pass Dogfood

Feature
  • The Insumer Access pass collection — non-transferable ERC-721 on Base mainnet (0x3E2a408cc6eceba04FF9d04A5B8B05aBa8DD50ce) — went live on May 18. POST /v1/keys/buy now mints a pass to the EVM sender wallet on every purchase. The pass is the wallet's lifetime membership token, never expires, and cannot follow a rotation.
  • New auth method on POST /v1/attest: an Authorization: Wallet header carrying a SIWE (EIP-4361) envelope from a pass-holding wallet, in place of X-API-Key. The signing wallet must match the wallet that bought the key and must hold the pass on Base. Single-use nonce; Issued At must be within the last 5 minutes. We dogfooded the pattern on our own API first so we could speak from the experience of running it.
  • Wire format: Authorization: Wallet <base64(JSON({message, signature}))> where message is a SIWE string with domain api.insumermodel.com and signature is an EIP-191 personal_sign. Existing X-API-Key auth on /v1/attest is unaffected.
May 14, 2026

Tron, Stellar, Sui, and XDC — 37 Chains, Institutional Stablecoins Expanded

Feature
  • Three new non-EVM chains. POST /v1/attest now accepts tronWallet (T-prefixed base58, 34 chars) with chainId: "tron" for native TRX and TRC-20 tokens including USDT-TRC20; stellarWallet (G-prefixed StrKey, 56 chars) with chainId: "stellar" for native XLM and classic trustlines (use the new assetCode field for trustline assets); and suiWallet (0x + 64 hex) with chainId: "sui" for native SUI and Sui-native tokens via fully-qualified Move type strings.
  • XDC (chainId 50) added to the EVM family. Standard wallet field; xdc... addresses are auto-normalized to 0x... form.
  • New stablecoin coverage in the institutional_stablecoins base dimension on /v1/trust: USDC on Stellar, BENJI (Franklin OnChain U.S. Government Money Fund) on Stellar, and USDC on Sui. All three always run in the base profile.
  • Trust profile expanded to up to 49 checks across 27 chains in 9 dimensions (5 base + 4 optional). New optional dimension Tron (USDT-TRC20) activates when tronWallet is supplied; existing Solana, XRPL, and Bitcoin optional dimensions carry forward.
  • USDT-TRC20 added as a payment chain for /v1/keys/buy and /v1/credits/buy. Send to the Tron platform wallet, submit txHash with chainId: "tron". Stellar and Sui are read-only — not payment chains. Merchant token-tier configuration (/v1/merchants/{id}/tokens, /v1/merchants/{id}/nfts) still covers EVM + Solana + XRPL only (33 chains).
  • Per-chain freshness anchors preserved across all signed payloads. Stellar carries ledgerIndex + ledgerHash (parallel to XRPL); Sui carries checkpointSequence + checkpointDigest.
  • Total chain coverage: 31 EVM + Solana + XRPL + Bitcoin + Tron + Stellar + Sui = 37 chains. Blog post: Wallet Auth Now Reads Tron, Stellar, Sui, and XDC.
May 13, 2026

IETF Internet-Draft — Wallet State Attestation (Independent Submission)

Spec Ecosystem
  • Filed draft-borthwick-wallet-state-attestation-00 to the IETF Datatracker. Independent Submission stream, Informational, 19 pages, expires November 13, 2026. Archived .txt at ietf.org/archive/id.
  • Documents the wallet-state attestation primitive — an issuer reads canonical on-chain state for a specified wallet address, evaluates one or more operator-defined conditions, and returns a cryptographically signed boolean (or structured fact profile) that any verifier can check offline using a published JWKS endpoint. The primitive enables condition-based access without identity presentation, credential exchange, or trust in the issuer at runtime.
  • Profiles existing IETF building blocks (JWT, JWKS, JOSE) for the wallet-state-attestation use case. Defines request/response surface, ES256 signing-algorithm posture, JWKS discovery, JWT format, optional EIP-1186 Merkle proofs, and security and privacy considerations. Solo Informational draft; references the environment.* constraint family Internet-Draft (May 12) and other public adoption artifacts informatively.
May 12, 2026

IETF Internet-Draft — environment.* constraint family (Independent Submission)

Spec Ecosystem
  • Filed draft-borthwick-msebenzi-environment-state-00 to the IETF Datatracker. Independent Submission stream, Informational, 43 pages, expires November 12, 2026. Archived .txt at ietf.org/archive/id.
  • Defines the environment.* constraint family for autonomous-agent mandate vocabulary — membership criterion, family-wide fields, composition discipline, register discipline, security considerations, and IANA registry mechanics. Does not define any individual constraint type.
  • Co-drafted with Michael Msebenzi (Headless Oracle). Each author maintains their own type specification in parallel — InsumerAPI for environment.wallet_state, Headless Oracle for environment.market_state — with the family-definition Internet-Draft the converged parent document. Both type specifications are referenced informatively in Appendix A.
May 7, 2026

mppx adapter upgraded to condition-gate — four condition types (v2.0.0)

Ecosystem
April 24, 2026

ERC-8183 Envelope-in-Action Case Library — Co-maintainer

Spec Ecosystem
  • Publicly-named co-maintainer of the neutral erc-8183-cases GitHub org alongside Raul Jäger (ThoughtProof) and Pablo Lopez (RNWY).
  • Authored InsumerAPI’s case in the library: pre-commit wallet auth via /v1/attest returning a signed-boolean attestation against an ERC-8183 envelope. Also authored SkyeMeta’s case.
  • Charter scopes the library to compliance/regulatory how-to material, not spec governance. Announcement: Ethereum Magicians post.
April 21, 2026

Merkle proofs now available on Taiko

Feature
  • Taiko (167000) joins the list of chains where proof: "merkle" returns full EIP-1186 storage proofs. Verified live via a USDC condition against a holder wallet: mappingSlot: 9, 7-node accountProof, storageProof value matches the raw balance.
  • Total: 27 of 31 EVM chains now support Merkle proofs. The three remaining (Ronin, Moonriver, Viction) run public RPC endpoints that do not implement eth_getProof.
  • Prior docs claimed Merkle proofs were unavailable on Taiko; that was stale — Taiko's public RPC has long supported eth_getProof. No backend change; docs updated across openapi.yaml, llms-full.txt, the Merkle-proof blog, and the A2A/x402 specs.
  • As on any chain, slot discovery can still fail for tokens with non-standard proxy storage layouts (e.g. slot > 20). Standard ERC-20s resolve cleanly.
April 21, 2026

Bitcoin tip anchor in signed attestation results

Feature
  • Bitcoin condition results now include blockHeight (integer) and blockHash (64-character hex) inside the ECDSA-signed payload — the Bitcoin chain tip at the time of wallet state observation.
  • Semantically different from EVM and Solana anchors: Bitcoin’s UTXO model does not permit reproducible balance-at-block queries, so the anchor is evidence-of-freshness, not a bind to the specific block’s state. Verifiers can confirm the reading was no older than the reported tip.
  • If the tip lookup fails, the API returns 503 instead of signing a partial result — the same “refuse to sign what we can’t verify” invariant that already governs EVM, Solana, and XRPL paths.
  • With this change, every signed InsumerAPI attestation across all 37 chains carries a chain-specific point-in-time anchor: blockNumber+blockTimestamp on EVM, slot on Solana, ledgerIndex+ledgerHash on XRPL, blockHeight+blockHash on Bitcoin.
  • Affected endpoints: POST /v1/attest, POST /v1/trust, POST /v1/trust/batch.
  • No request-shape change. Fields are additive; existing consumers are unaffected.
  • OpenAPI AttestationResult and TrustCheck schemas updated with the new blockHeight and blockHash fields.
April 21, 2026

Block anchor guaranteed on every signed EVM attestation

Feature
  • blockNumber and blockTimestamp are now present on every signed result across all 31 EVM chains. Previously, if the RPC helper silently failed on the block-lookup step, an attestation could sign with the anchor fields absent.
  • If either eth_blockNumber or eth_getBlockByNumber fails, the API now returns 503 with a retryable error payload (no credits charged) instead of signing a partial result.
  • Affected endpoints: POST /v1/attest, POST /v1/trust, POST /v1/trust/batch.
  • OpenAPI AttestationResult and TrustCheck schema descriptions updated; the prior “26 of 31” carve-out for Taiko, Ronin, Moonriver, and Viction was stale — those chains have always returned the same anchor fields via direct public RPC.
April 21, 2026

Solana slot anchors in signed attestation results

Feature
  • Solana condition results now include a slot field (integer) identifying the Solana ledger slot at which the wallet state was read. Parallel to blockNumber on EVM chains and ledgerIndex on XRPL.
  • The slot is inside the ECDSA-signed payload, so verifiers can independently reproduce the read by querying wallet state at the signed slot or later.
  • Affected endpoints: POST /v1/attest, POST /v1/trust, POST /v1/trust/batch.
  • No request-shape change. Field is additive; existing consumers are unaffected.
  • OpenAPI AttestationResult and TrustCheck schemas updated with the new slot field.
April 13, 2026

insumer-skill — Wallet Auth for Claude Code

SDK
  • New Claude Code skill that helps developers add wallet auth to their projects from inside Claude Code. Activates on phrases like "add wallet verification", "gate by token holdings", "token gating", "on-chain eligibility", "condition-based access", or "wallet_state".
  • Emits signature-verifying integration code on the first try. Hard-stop guardrails on inline keys, unverified responses, raw balance leaks, and incorrect USDC decimals (defaults to 18, must be 6).
  • Reference example included: an Express middleware that gates an endpoint by USDC balance on Base, with offline JWKS verification via jose. Verified end-to-end on April 13.
  • Install: smithery skill add douglasborthwick/insumer-skill.
  • Published on Smithery. Source on GitHub.
  • Different surface from the MCP server: this is for writing wallet auth into your own projects at build time; the MCP server is for calling the API at runtime from an agent. Same API underneath.
April 12, 2026

@insumermodel/plugin-eliza v2.0.0 — Scoped Package Rename

SDK
  • ElizaOS plugin renamed from eliza-plugin-insumer to @insumermodel/plugin-eliza to match the elizaOS registry format convention (all entries in index.json use @org/plugin-name).
  • Published to npm: @insumermodel/plugin-eliza@2.0.0. Same 10 actions, same source code, zero functional changes.
  • Old unscoped package eliza-plugin-insumer deprecated on npm pointing to the new name.
  • Install: npm install @insumermodel/plugin-eliza.
April 10, 2026

Multi-Attestation Payload Format v1.1 — Nine issuers, ten signed dimensions

Spec Ecosystem
  • The Multi-Attestation Payload Format defines a composable envelope for nine independent issuers contributing ten signed dimensions: InsumerAPI (wallet state, 37 chains), Revettr (compliance risk), ThoughtProof (reasoning integrity), RNWY (behavioral trust + wallet intelligence — two dimensions), Maiat (job performance), APS (passport grade), AgentID (trust verification), AgentGraph (security posture), and SAR (settlement witness).
  • SkyeMeta’s SkyeProfile is the multi-issuer orchestrator product built on this format; InsumerAPI contributes the wallet-state dimension and publishes the spec.
  • Each attestation is self-describing — carries its own algorithm, key identifier, and JWKS discovery endpoint. No shared registry or coordination between issuers required. A relying party selects attestations by type, fetches each issuer’s public key via standard JWKS, and verifies signatures independently.
  • Reference verifier (multi-attest-verify.js) resolves the JWKS, fetches a live attestation, and returns a verified result with no issuer cooperation beyond the published endpoints.
  • Blog post: Would You Trust Your Agent? KYA Is Real.
April 10, 2026

agent-governance-vocabulary — Co-author of vocabulary.yaml

Spec Ecosystem
  • Co-author of vocabulary.yaml and sole author of the insumerapi.yaml crosswalk in aeoess/agent-governance-vocabulary, merged via PR #1.
  • The vocabulary names wallet-auth and condition-based-access primitives unambiguously, so signed attestations from one issuer can be referenced cleanly by another across the agentic-commerce ecosystem.
March 28, 2026

Revettr Integrates /v1/trust for Counterparty Risk Scoring

Ecosystem
  • Revettr integrates POST /v1/trust as the wallet analysis signal in their counterparty risk scoring API. Trust profile dimensions surface at signal_scores.wallet.details.insumer_trust in every Revettr score response
  • Revettr scores wallets, domains, IPs, and company names for x402 agent commerce — “should this agent send money to this counterparty?” Wallet auth provides the on-chain verification layer alongside domain intelligence, IP intelligence, and sanctions screening
March 25, 2026

Native Bitcoin Support (33 Chains)

Feature
  • Native BTC balance verification via bitcoinWallet parameter on POST /v1/attest and GET /v1/trust. Supports P2PKH (1...), P2SH (3...), bech32 (bc1q...), and Taproot (bc1p...) addresses
  • New Bitcoin Holdings dimension in trust profiles — pass bitcoinWallet to add a native BTC balance check alongside stablecoins, governance, NFTs, staking, Solana, and XRPL
  • Confirmed-only balance (no unconfirmed transactions), consistent with XRPL’s validated-ledger pattern. Same ECDSA-signed boolean output — no balances exposed
  • Total chain coverage: 30 EVM + Solana + XRPL + Bitcoin = 33 chains
March 24, 2026

UCP Capability Proposal — dev.ucp.shopping.eligibility

Spec Ecosystem
  • Co-authored Universal Commerce Protocol Discussion #297 with zologic (UCPReady, WooCommerce).
  • Capability adds condition-based access at merchant checkout: wallet state evaluated against merchant-defined conditions, returned as a signed-boolean attestation. Reference implementation pairs InsumerAPI /v1/attest with SkyeMeta’s SkyeWoo.
March 23, 2026

MPP Extensions Directory — First Community Package Listed

Ecosystem
  • @insumermodel/mppx-token-gate listed as the first entry on Tempo’s new Extensions page. Wraps any MPP Method.Server to grant free access to token holders — one API call checks ownership across 37 chains and returns a signed receipt
  • Tempo maintainers created the extensions directory specifically to house community-built integrations. MPP is the payment protocol behind Stripe’s crypto payments infrastructure
March 23, 2026

SettlementWitness Integrates /v1/attest for Pre-Transaction Verification

Ecosystem
  • SettlementWitness integrates POST /v1/attest as the pre-transaction verification layer in their Settlement Attestation Record (SAR) flow. Wallet auth qualifies agents going in, SAR verifies delivery coming out
  • Pre/post pattern for x402 agent commerce: InsumerAPI attestation confirms the counterparty holds what they claim before payment, SettlementWitness confirms the deliverable after settlement
March 23, 2026

Multi-Attestation Payload Format — Composable Verification Across Independent Issuers

Feature
  • Published the Multi-Attestation Payload Format spec. Four independent issuers (InsumerAPI, ThoughtProof, RNWY, Maiat) sign attestations across four trust dimensions. One envelope, one verification pass, any combination of issuers.
  • SkyeMeta’s SkyeProfile is the multi-issuer orchestrator product built on this format; InsumerAPI contributes the wallet-state dimension and publishes the spec.
  • Reference verifier multi-attest-verify.js shipped in insumer-examples. Zero dependencies, supports ES256 (P-256) and EdDSA (Ed25519), handles both raw P1363 signatures and JWT compact JWS
  • Blog post: Four Issuers, One Verification Pass
March 16, 2026

AgentTalk by Skye Meta — Condition-Gated Agent Communication

Feature
  • AgentTalk by Skye Meta: condition-gated communication layer for AI agents using POST /v1/attest. Agents declare wallet conditions, join channels, and receive per-agent ECDSA-signed attestation JWTs. Sessions re-verify on demand. Sell the token, lose the session
  • Supports composable conditions (up to 10 per channel) across 31 chains. Agents buy their own InsumerAPI keys with USDC via POST /v1/keys/buy. 10 free attestation calls per agent
  • channel parameter added to POST /v1/keys/buy for partner revenue share tracking
March 15, 2026

SkyeWoo WooCommerce Plugin — Token-Gated Products & Wallet-Verified Discounts

Feature
  • SkyeWoo by Skye Meta: WooCommerce plugin for condition-based products using POST /v1/attest. Restrict product visibility and purchases based on wallet conditions. Wallet-verified discounts apply automatically at checkout. No coupon codes to leak
  • Connects MetaMask, Phantom, and Coinbase Wallet simultaneously. 31 chains (30 EVM + Solana). Up to 10 conditions per product. Server-side enforcement
  • Added to homepage Use Cases, For Businesses page, and blog tutorial
March 14, 2026

SkyeGate WordPress Plugin — No-Code Condition-Based Access

Feature
  • SkyeGate by Skye Meta: WordPress plugin for condition-based content access using POST /v1/attest. Gate any page, post, or block with a shortcode. Connects MetaMask, Phantom, and Coinbase Wallet simultaneously
  • No Web3 code required — plugin handles multi-wallet connection, verification via InsumerAPI, and server-side condition-based access. 31 chains supported (30 EVM + Solana). Up to 10 conditions per gate
  • Added to homepage Use Cases, For Businesses page, and blog tutorial
March 14, 2026

Native gas token balance verdicts across 31 EVM chains

Feature
  • POST /v1/attest returns native gas token balance verdicts (ETH, POL, BNB, AVAX, etc.) accurately on all 31 EVM chains when contractAddress: "native" is set. Native balances flow through eth_getBalance lookups, distinct from ERC-20 balanceOf calls used for token balance evaluation.
  • Native SOL balance checks on Solana flow through a dedicated native-balance branch in the upstream call path.
  • Applies to both standard and Merkle proof attestation paths on EVM. XRPL native XRP balance checks operate on a separate code path.
March 13, 2026

UCP Spec Contributions — Signals, Eligibility & Attestation Extension

Feature Docs
  • Contributed to two merged specs in the Universal Commerce Protocol (UCP), the open commerce standard backed by Shopify.
  • #203 — Signals for authorization & abuse: shaped the cryptographic attestation signal pattern (provider_jwks / kid / payload / sig) now in the spec. Suggestions for kid field and full signed payload accepted by spec author.
  • #250 — Eligibility claims & verification contract: contributed the attestation-as-proof model for non-instrument eligibility claims (token holdings, on-chain attestations). Spec author invited a companion attestation extension.
  • #264 — Attestation extension (proposed): submitted capability extension adding cryptographic attestation proofs to eligibility claims. Follows the discount extension pattern. Enables offline verification of claims via JWKS — no callback to the platform or attestation provider required.
  • InsumerAPI is the first production implementation of the UCP attestation pattern — POST /v1/attest output maps directly to the extension wire format.
March 11, 2026

eliza-plugin-insumer v1.2.1 — Full Autonomous Agent Lifecycle (10 Actions)

SDK Feature
  • eliza-plugin-insumer expanded from 4 to 10 actions covering the complete autonomous agent lifecycle — no human required at any step: BUY_API_KEY, CREATE_MERCHANT, CONFIGURE_TOKENS, ADD_CREDITS, VERIFY_WALLET, CHECK_TRUST, CHECK_TRUST_BATCH, ACP_DISCOUNT, UCP_DISCOUNT, CONFIRM_PAYMENT.
  • 6 new actions: merchant onboarding (create, configure tokens, add credits), ACP/UCP commerce protocol integration, and payment confirmation.
  • Adds currency field to token config for XRPL trust line support; refines ACP/UCP discount display to read correct response fields.
March 11, 2026

POST /v1/keys/buy — Agent-Friendly Key Purchase with USDC

Feature SDK Docs
  • New public endpoint POST /v1/keys/buy — buy an API key with USDC, no email or prior authentication required. The sender wallet from the on-chain transaction becomes the key’s identity. One key per wallet.
  • Designed for autonomous AI agents: send USDC to the platform wallet, submit the tx hash, receive an API key with credits. Volume discounts apply ($0.04–$0.02/call).
  • Existing email-based key creation (POST /v1/keys/create) remains unchanged for human developers.
  • mcp-server-insumer v1.8.0: new insumer_buy_key tool.
  • langchain-insumer v0.10.0: new InsumerBuyKeyTool (26 tools total).
  • eliza-plugin-insumer v1.1.0: new BUY_API_KEY action (4 actions total).
  • OpenAPI spec, API reference (26 endpoints), and all SDK READMEs updated.
March 10, 2026

Sender Wallet Verification on USDC Credit Purchases

Feature SDK
  • POST /v1/credits/buy and POST /v1/merchants/{id}/credits now verify the on-chain sender. First purchase registers the sender wallet to the API key. Subsequent purchases must come from the same sender.
  • New optional updateWallet parameter (boolean): set to true to change the registered wallet. The verified USDC transfer from the new address proves ownership.
  • mcp-server-insumer v1.7.14 published to npm with updateWallet on both buy credits tools.
  • langchain-insumer tools updated with update_wallet parameter.
  • OpenAPI spec, GPT specs, LLM specs, API reference, Postman collection, and workbench schema updated.
March 8, 2026

langchain-insumer v0.9.13 — XRPL ledgerHash & trustLineState docs

SDK Docs
  • langchain-insumer v0.9.13 published to PyPI: added XRPL response field documentation to attest() docstring and README — ledgerHash, trustLineState: { frozen }, and frozen trust line behavior (met: false).
  • Firestore knowledge base updated with XRPL response field documentation for InsumerChat.
March 10, 2026

AsterPay KYA Integration — ERC-8183 Agent Trust Scoring

Feature
  • AsterPay KYA case study published: Know Your Agent trust scoring for ERC-8183 agentic commerce using POST /v1/attest with 4 conditions (USDC balance, Coinbase KYC, country verification, Gitcoin Passport) in a single API call
  • Contracts deployed on Base Sepolia. Open source at github.com/AsterPay/erc8183-kya-hook
March 5, 2026

RPC Failure Handling — “If we can’t verify, we don’t sign”

Feature SDK
  • 5 signing endpoints now return HTTP 503 with error.code: "rpc_failure" when an upstream data source is unavailable after retries. No attestation signed, no JWT issued, no credits charged. Retryable after 2–5 seconds.
  • Response includes failedConditions array identifying which source and chain failed.
  • Affected endpoints: POST /v1/attest, POST /v1/trust, POST /v1/verify, POST /v1/acp/discount, POST /v1/ucp/discount. (POST /v1/trust/batch handles failures per-wallet and always returns 200.)
  • insumer-verify v1.3.0, mcp-server-insumer v1.7.5, langchain-insumer v0.9.7, eliza-plugin-insumer v1.0.4 published with rpc_failure documentation.
  • OpenAPI spec updated with RpcFailureEnvelope schema on all 5 endpoints.
March 4, 2026

Wallet Auth by InsumerAPI

Feature SDK
  • New format: "jwt" parameter on POST /v1/attest returns an ES256-signed JWT bearer token alongside the standard attestation response. No additional cost.
  • JWT claims include pass, results, conditionHash, blockNumber, and blockTimestamp. 30-minute expiry. Verifiable via JWKS at /.well-known/jwks.json or GET /v1/jwks.
  • Compatible with any JWKS-aware API gateway (Kong, Nginx, Cloudflare Access, AWS API Gateway, Azure APIM, Traefik, Envoy).
  • insumer-verify v1.2.0 published to npm: auto-detects JWT string vs attestation object.
  • mcp-server-insumer v1.7.3, langchain-insumer v0.9.5, eliza-plugin-insumer v1.0.2 updated with Wallet Auth support.
March 1, 2026

mcp-server-insumer v1.6.2

SDK
  • mcp-server-insumer v1.6.2 published to npm: updated README with langchain-community PR #549 cross-reference, wallet trust tool descriptions now reflect optional Solana + XRPL dimensions (up to 20 checks), batch wallet trust mentions xrplWallet parameter, aligned version strings in server.json and src/index.ts
March 1, 2026

langchain-insumer v0.9.1, langchain-community PR Updated to 25 Tools, Example Repos XRPL

SDK Feature
  • langchain-insumer v0.9.1 published to PyPI: adds XRPL usage examples to README (native XRP, RLUSD trust line, wallet trust with XRPL dimensions); wallet trust tool description now reflects optional Solana + XRPL dimensions (up to 20 checks)
  • langchain-community PR #549 updated to 25 tools: adds xrpl_wallet to 5 existing tools (attest, wallet_trust, batch_wallet_trust, check_discount, verify), adds 5 new tools (acp_discount, ucp_discount, request_domain_verification, verify_domain, validate_code), exports InsumerComplianceTemplates in __all__, adds World Chain (480) to Merkle proof chain list
  • acp-ucp-onchain-eligibility-example repo: adds XRPL examples across all flows (attest, trust, merchant onboarding, ACP, UCP, credits); full_agent_flow.py now carries auth headers across all flows
  • insumer-examples repo: added XRPL verification to Python, Node.js, and bash examples, added XRPL curl examples to README
March 1, 2026

XRPL Across All SDKs, GPT Upgraded to 25 Actions

SDK Feature Spec
  • mcp-server-insumer v1.6.0 published to npm (updated to v1.6.2 same day): xrplWallet parameter on all 7 wallet-accepting tools, XRPL added to ChainId, OnboardingChainId, and UsdcChainId schemas, new currency field for trust line tokens, taxon field for NFT collections, xrplAddress in USDC payment settings
  • langchain-insumer v0.9.0 published to PyPI: xrpl_wallet parameter on attest, wallet_trust, check_discount, verify, acp_discount, and ucp_discount tools and wrapper methods (updated to v0.9.1 same day)
  • InsumerAPI Verify GPT upgraded from 13 to 25 actions, matching full SDK parity. New actions: merchant onboarding (create, status, tokens, NFTs, settings, directory, domain verification), credit purchases, JWKS, and payment confirmation
  • GPT system instructions updated with guardrails: prompt extraction protection, anti-reverse-engineering, and IP protection while keeping all 25 actions fully usable
  • GPT OpenAPI spec (openapi-gpt.yaml) updated with XRPL parameters across all endpoints and legacy server removed
March 1, 2026

USDC on XRP Ledger; XRPL NFT validation refined

Feature
  • Adds native USDC on XRPL (Circle issuer rGm7WCVp9gb4jZHWTEtGUr4dd74z2XuWhE) as second check in the XRPL trust dimension. Wallet trust profiles now support up to 20 checks across 6 dimensions
  • USDC can now be verified across 9 chains in a single POST /v1/attest call: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana, and XRP Ledger
  • Adds "xrpl" to OnboardingChainId enum in OpenAPI spec, enabling merchants to configure XRPL tokens via PUT /v1/merchants/:id/tokens
  • Adds xrplWallet parameter documentation to commerce (/v1/acp/discount, /v1/ucp/discount), verification, and API reference developer pages
  • Refines XRPL nft_ownership validation: the currency field is now only required for token_balance conditions on trust line tokens.
March 1, 2026

XRP Ledger Integration (32 Chains)

Chains Endpoint Feature
  • XRP Ledger added as 32nd supported chain (chainId: "xrpl"). Native XRP balance verification, trust line token verification (RLUSD, any issued token), and NFT ownership verification
  • xrplWallet field on all 7 wallet-accepting endpoints: POST /v1/attest, POST /v1/trust, POST /v1/trust/batch, GET /v1/discount/check, POST /v1/verify, POST /v1/acp/discount, POST /v1/ucp/discount
  • New condition fields: currency (XRPL currency code, auto hex-encoded) and taxon (optional NFT filter)
  • XRPL dimension added to wallet trust profiles: RLUSD + USDC checks (up to 20 total checks with Solana + XRPL)
  • Dual RPC with automatic failover across XRPL nodes
  • Trust line pagination (max 10 pages) and NFT pagination (max 5 pages) for large wallets
  • Response includes ledgerIndex and ledgerHash (XRPL equivalent of block number/hash) for freshness and snapshot verification
  • Frozen trust line detection: attestation returns met: false for frozen trust lines even if balance exceeds threshold, with trustLineState: { frozen: true } in the result
  • Updated openapi.yaml, llms.txt, llms-full.txt, and all marketing/blog pages to reflect 32-chain support
February 28, 2026

State Attestation Spec, Custom API Domain, Security Hardening

Spec Feature Security
  • Published State Attestation Specification v1 for integrators
  • Custom API domain live: api.insumermodel.com
  • SRI hashes on all external scripts, redirect validation, admin auth hardening
  • Two-pool credit system documented: API credits (per key) and merchant credits (per merchant)
  • Added version: 1.0.0 to llms.txt and llms-full.txt for agent cache invalidation
  • Developer vertical pages: primitive cohesion notes, onboarding checklist, commerce failure responses
February 27, 2026

EAS Attestations, Compliance Templates, ACP/UCP, Farcaster, Developer Verticals

Endpoint SDK Feature
  • eas_attestation condition type with 5 pre-configured compliance templates: coinbase_verified_account, coinbase_verified_country, coinbase_one, gitcoin_passport_score, gitcoin_passport_active
  • GET /v1/compliance/templates endpoint for listing available templates
  • POST /v1/acp/discount and POST /v1/ucp/discount for OpenAI/Stripe ACP and Google UCP commerce protocol integration
  • farcaster_id condition type for social identity verification via IdRegistry on Optimism
  • Staking dimension added to trust profiles: stETH, rETH, cbETH positions
  • Restructured /developers/ into hub + 6 focused vertical pages: verification, trust, compliance, commerce, onboarding, api-reference
  • mcp-server-insumer v1.2.0 and langchain-insumer v0.5.0 with EAS + compliance tools
  • 26 API endpoints, 26 SDK tools (full parity)
February 26, 2026

Trust Profiles, Batch Trust, /v1/jwks Discovery Endpoint, Condition Hashing, insumer-verify

Endpoint SDK Feature
  • POST /v1/trust for ECDSA-signed wallet trust fact profiles across 4 dimensions (stablecoins, governance, NFTs, staking), 17 checks, 7 chains
  • POST /v1/trust/batch for profiling up to 10 wallets per request. Shared block fetches make batch 5-8x faster than sequential calls
  • GET /v1/jwks endpoint for public key discovery. Static JWKS also at /.well-known/jwks.json
  • kid field added to all signed responses for key rotation support
  • evaluatedCondition and conditionHash (SHA-256) in attestation results for tamper-evidence
  • blockNumber (hex) and blockTimestamp (ISO 8601) in RPC chain results for freshness verification
  • insumer-verify v1.1.3 published on npm: client-side ECDSA signature verification, condition hash checking, block freshness, and expiry validation. Zero dependencies
  • DJD Agent Score architecture pattern published: agent trust scoring in the Coinbase x402 ecosystem
February 25, 2026

Merkle Storage Proofs

Feature Spec
  • Optional proof: "merkle" parameter on POST /v1/attest and POST /v1/trust
  • Returns EIP-1186 Merkle storage proofs anchored to block headers for fully trustless verification without re-querying a chain
  • Available on 26 of 31 EVM chains (not available on Taiko, Ronin, Moonriver, Viction, Solana, or XRPL). 2 credits per attestation (double standard)
  • Privacy policy and terms updated for opt-in balance disclosure
February 24, 2026

Privacy Enforcement, CSP Hardening

Security Spec
  • Removed raw balance amounts from /v1/discount/check and /v1/verify responses. Booleans only by default
  • Removed unsafe-eval from CSP script-src across all pages
  • Added explicit privacy guarantees to Privacy Policy
  • Privacy-by-design language enforced across all docs and discovery files
February 22-23, 2026

Public API Launch, Self-Serve Keys, Agent SDKs, AI Discovery

Feature SDK Endpoint
  • Public API launched with X-API-Key authentication (insr_live_ prefix)
  • Self-serve API key provisioning: Free (10 credits), Pro ($29/mo, 1,000 credits), Enterprise ($99/mo, 5,000 credits)
  • POST /v1/attest, GET /v1/credits, POST /v1/credits/buy, and 8 merchant onboarding endpoints
  • AI agent discovery: llms.txt, llms-full.txt, openapi.yaml, ai-plugin.json
  • mcp-server-insumer published on npm. Listed on Official MCP Registry, awesome-mcp-servers, mcp.so, mcpservers.org
  • langchain-insumer published on PyPI
  • InsumerAPI Verify GPT live in GPT Store
  • GPT-optimized OpenAPI spec and system instructions for Actions
February 21, 2026

Clover POS Integration

Feature
  • Clover POS integration in dashboard: OAuth connect, automatic discount application at point of sale
  • Scanner shows Clover discount names from individual tier breakdown
  • Stripe and Clover positioned as complementary payment channels
February 20, 2026

31-Chain Expansion, Security Hardening

Chains Security
  • Expanded from 8 to 32 supported chains (30 EVM + Solana + XRPL)
  • New chains include Sonic, Gnosis, Mantle, Scroll, Linea, zkSync Era, Blast, Taiko, Ronin, Celo, Moonbeam, Moonriver, Viction, opBNB, World Chain, Unichain, Ink, Sei, Berachain, ApeChain
  • HSTS headers, CSP frame-src, XSS hardening, email validation, rate limiting
  • Removed unsafe-inline from CSP script-src
February 19, 2026

ECDSA Signing, For Foundations Page

Feature Security
  • ECDSA P-256 signatures on QR payloads and scanner verification
  • For Foundations page with chain request form and admin approval pipeline
  • AI crawlers explicitly allowed in robots.txt
  • translate="no" on brand names site-wide
February 15-16, 2026

NFC Tap-to-Verify, FAQ Page, Mailchimp Integration

Feature
  • NFC tap-to-verify flow: merchant programs NFC tag, customer taps, InsumerPass opens and verifies server-side
  • Dedicated FAQ page with 22 questions, JSON-LD schema, accordion expand/collapse
  • Mailchimp subscribe form on book page with customer journey welcome email
  • Organization JSON-LD with contact and social links for Knowledge Panel
February 11-14, 2026

Site Launch

Feature
  • Static site launched on Vercel (migrated from WordPress)
  • 13 marketing pages, 6 app pages (Firebase/OAuth), 12 blog articles
  • SEO: OG tags, Twitter Cards, canonical URLs, JSON-LD, sitemap
  • Google Analytics (GA4) across all pages
  • 301 redirects for old WordPress URLs
  • Mobile-responsive breakpoints at 768px and 480px on all pages
← Back to Developers Hub API Reference →