> What shipped and when. New endpoints, SDK releases, chain support, and spec changes for InsumerAPI. > > Page: https://insumermodel.com/developers/changelog/ · API: https://api.insumermodel.com · OpenAPI: https://insumermodel.com/openapi.json · Index for agents: https://insumermodel.com/llms.txt [Developers](https://insumermodel.com/developers/) > Changelog # Changelog New endpoints, SDK releases, chain support, and spec changes. Updated as features ship. October 7, 2026 ## Account Code: Plain Key, EIP-7702 Delegation or Contract, as a Signed Boolean Endpoint Feature Spec - **Adds the `account_code` condition type to [POST /v1/attest](https://insumermodel.com/developers/verification/), the tenth.** It asks what code sits at the wallet address itself at the anchored block: `expect: "none"` (no code, a plain key account), `"eip7702"` (the EIP-7702 delegation designator, a key that has delegated execution to a contract) or `"contract"` (any other code: a smart-contract wallet, a protocol, a token). The three are exclusive on a chain. With `"eip7702"`, an optional `delegate` names the address the designator must point at. Any of the 31 EVM chains; a non-EVM chain is a 400. The answer is the boolean: the code and the delegation target are never returned, in any format or mode. 1 credit, 2 in proof mode, the standard 30-minute expiry, JWT format and x402 pay-per-call at the standard rate. The signed `evaluatedCondition` is `{type, chainId, expect, operator: "code_state"}`, plus `delegate` when supplied, and echoes nothing read from the chain. - **Adds an account proof for the type.** With `proof: "merkle"` the result carries an EIP-1186 account proof, `subject: "account_code"`, whose `codeHash` is the proven value: keccak256 of empty code means no code, keccak256 of `0xef0100` followed by the 20-byte target means an EIP-7702 delegation to that target, anything else means contract code. Proof subjects are now three: `account_balance`, `account_code` and `delegation_revocation`, beside the subject-less ERC-20 slot proof. - **Adds the `account` dimension to [POST /v1/trust](https://insumermodel.com/developers/trust/) and `POST /v1/trust/batch`.** Ten rows, two per chain on Ethereum, Base, Arbitrum, Optimism and Polygon: "Contract code on X" and "EIP-7702 delegation on X", exclusive per chain, a plain key reading false on both. Which contract is never named; that question belongs to `account_code` with `delegate`. Each row's `evaluatedCondition` has the attest layout, so its `conditionHash` equals the equivalent attest condition's. The profile is now **155 base checks across 27 chains in 10 dimensions**, up to **176 checks across 29 chains in 14 dimensions** with the optional Solana, XRPL, Bitcoin and Tron wallets. `conditionSetVersion` is `"2026-10-08"`; readers log it and never reject on it. Account rows carry `available: false` in proof mode. Pricing is unchanged: 3 credits, 6 with proofs. - **Dimensions come in a fixed order.** The ten base dimensions in the published order, then any of `solana`, `xrpl`, `bitcoin` and `tron` that were switched on, in that order; the same order for every wallet, in a batch as in a single profile. Readers may still look dimensions up by name. The [specification](https://insumermodel.com/state-attestation-spec/) records all three changes in its revision history. No new `kid`, no change to any signed preimage or to the trust object layout. October 7, 2026 ## Batch Trust Profiles Arrive as a Summary a Model Can Read SDK Endpoint - **A model reads a summary per wallet.** A trust profile lists every check, tens of thousands of characters per wallet, so ten profiles in one tool result were more than a model can read. The batch tools now hand the model a summary per wallet: the profile ID, check set, expiry, the key IDs it names, the held / not held / not evaluated counts, and the checks held in each dimension. The counts are facts about the wallet, not a score. `POST /v1/trust/batch` and its signed profiles are unchanged. - **mcp-server-insumer 1.19.0:** the text of `insumer_batch_wallet_trust` is the summary, and the complete signed profiles are in `structuredContent`, unchanged. `detail: "full"` puts them in the text as well. The hosted endpoint serves the same version. `insumer_list_tokens` describes the registry as a directory: an attestation can check any token on a supported chain, and NFTs on EVM chains, Solana and XRPL, whether listed or not. - **langchain-insumer 0.14.0:** `InsumerBatchWalletTrustTool` returns content and an artifact. The model reads the summary, and the complete response is the tool message's `artifact`. Called with plain arguments, the tool now returns the summary where it used to return the complete JSON; pass `detail="full"` for the same output as before. Requires langchain-core 0.2.17 or later. - **insumer-trust-batch skill 0.3.0:** the helper script prints the summary and saves the complete signed response to a JSON file; `--full` prints the complete response. - **Choose the full form on the call that needs it.** A profile cannot be fetched again, so a second call signs fresh profiles and is charged again. - **`POST /v1/attest`:** the message for an unsupported `chainId` names where the supported chain IDs are listed, [llms.txt](https://insumermodel.com/llms.txt). October 7, 2026 ## A Store's Owner Can Pause Its Recognition Endpoint - **`paused` in `PUT /v1/merchants/{id}/settings`**: `true` pauses a store’s recognition, `false` resumes it. `GET /v1/merchants/{id}/status` shows `paused` and `pausedAt`. - **While a store is paused**, `/v1/verify`, `/v1/acp/discount`, `/v1/ucp/discount` and `/v1/discount/check` return **409** “This store’s recognition is paused.” with no credit used and no code created. `/v1/pass/verify` answers `recognized: false` with `paused: true`. The store is left out of `GET /v1/merchants`, and `GET /v1/merchants/{id}` returns 404. - **Resuming** restores everything as it was. October 7, 2026 ## The Member Pass Is Skye Meta's Bothy Pass Ecosystem - **`insumermodel.com/pass` now redirects to [skyemeta.com/pass/](https://skyemeta.com/pass/)**, the Bothy Pass, which Skye Meta builds on InsumerAPI. Links keep their query string, so existing invite and tap links still work. - **Pass codes are still signed by InsumerAPI** and checked with `POST /v1/pass/verify`. Nothing changes for a scanner or an integration that verifies passes. - **The connect window at `insumermodel.com/pass/connect`**, opened by sites that recognize the pass, stays where it is. October 6, 2026 ## One Credit Balance: The Key That Owns a Store Pays for Its Codes Endpoint - **There is one kind of credit: your API key's.** A store has no balance of its own. A discount code from `/v1/verify`, `/v1/acp/discount` or `/v1/ucp/discount`, or an NFC tap, that carries a discount uses one credit from the API key that owns the store, the key that created it. A 0% result is free. Every in-store scan uses one credit from that key. A caller using another key is not charged; if you call with the owner key, your key pays. - **Stores run through a licensed platform** such as Skye Meta are covered by that platform's license and are not charged per use. - **New errors on the code endpoints.** 402 when the owner key is out of credits: "The API key that owns this store has no credits remaining. Its owner can buy more via POST /v1/credits/buy." Returned only when the result carries a discount. 403 when the store has no active owner key: "This store has no active owner API key, so it cannot issue codes or record scans and taps." No credit is used and no code is created in either case. - **Hourly limit on paid discount codes.** Codes that carry a discount, issued through `/v1/verify`, `/v1/acp/discount` or `/v1/ucp/discount`, with a key other than the store's owner, are subject to an hourly limit (429; the message says when to try again): "The hourly limit on discount codes has been reached. Try again in N minutes." No credit is used and no code is created. - **Top up with `POST /v1/credits/buy`**, which carries the volume tiers. `POST /v1/merchants/{id}/credits` is kept for compatibility: same payment flow and flat rate (25 credits per $1), and the credits go to the owner key's regular balance. - **A new store from `POST /v1/merchants` starts with no balance of its own.** Its `credits` field, and the one in `GET /v1/merchants/{id}/status`, is the owner key's current balance. - **ACP and UCP `meta` describe the caller's key**, and never another key's balance. When the caller owns the store and the code carries a discount, `creditsCharged` is `1` and `creditsRemaining` is the caller key's credits after the charge; otherwise `creditsCharged` is `0` and `creditsRemaining` is the caller key's credits. Field names and types are unchanged. - **mcp-server-insumer 1.18.0** describes the one credit balance in its discount tools and lists the core tools (attest, compliance templates and the trust profiles) first. The hosted endpoint serves the same version. October 6, 2026 ## Stores Can Recognize a Chain's Own Coin Feature - **`contractAddress: "native"` on EVM chains** in `PUT /v1/merchants/{id}/tokens`: a store can recognize the chain's own coin, such as ETH on Ethereum or Base, as Solana (SOL) and the XRP Ledger (XRP) already allowed. Use `decimals: 18`. October 5, 2026 ## MCP Server 1.17.1 and an Agent Skill for Discounts Feature - **The MCP tools cover the discount changes below.** `insumer_verify`, `insumer_acp_discount` and `insumer_ucp_discount` take `walletProof`, with the exact message to sign in the field's description; `insumer_configure_settings` takes the store's terms; `insumer_configure_tokens` takes `alsoOn`. The hosted endpoint at `https://api.insumermodel.com/mcp` runs 1.17.1. - **New agent skill `insumer-discount`** in [insumer-agent-skills](https://github.com/insumerapi/insumer-agent-skills): read the store's terms, check for free, prove the wallet if it pays, create the code. Its helper prints the message to sign and never handles a private key. October 5, 2026 ## Discounts: Prove the Wallet, or Take the Store's Terms Without Proof Feature - **New optional field `walletProof`** on `/v1/verify`, `/v1/acp/discount` and `/v1/ucp/discount`: an EIP-4361 (Sign-In with Ethereum) message signed by the EVM wallet in `wallet`, with URI `https://api.insumermodel.com/v1/merchants/{merchantId}`. A proof that fails is a 401 and uses no credit. - **A proven wallet gets the full discount its holdings earn**, under the store's tiers and cap, without the store's daily limit. Proof never lowers a holdings requirement. It covers the one address in `wallet`: a proof sent with `solanaWallet` or `xrplWallet` is refused (400). Responses and `GET /v1/codes/{code}` carry `walletProven`. - **The store sets the terms for a wallet without proof**, in `PUT /v1/merchants/{id}/settings`: `maxUnprovenDiscount` (the same discount, the default; a lower one; or `0` for none) and `maxDiscountsPerWalletPerDay` (1 to 100 discount codes per UTC day, or `null` for no limit). Over the limit is a 429 with no credit used and no code created; only codes that carry a discount count. Only a daily count is kept for the limit, and it is deleted after the day. - **Agents can read the terms before calling.** `GET /v1/merchants`, `GET /v1/merchants/{id}` and `GET /v1/discount/check` return `walletTerms`. The check previews what a wallet gets without proof, and `discountIfProven` when proof would get more. - **Nothing changes for existing callers.** A request without `walletProof` at a store that has set nothing works exactly as before. The signed result is unchanged; `walletProven` and `discountIfProven` sit beside it. - **Also:** `GET /v1/merchants/{id}/status` returns the new settings and each token's `alsoOn` networks. October 5, 2026 ## Merchant Tokens Can Count on Every Network They Are On Feature - **New optional field `alsoOn`** on a token in `PUT /v1/merchants/{id}/tokens`: the same token on other networks, each as `{ chainId, contractAddress }`, up to 9, on EVM chains and Solana. - **One tier per token.** The discount check and verification (`/v1/verify`, ACP, UCP) read every network listed plus the token's own, add the balances exactly, and award the token's tier once. A holder with 400 on Ethereum and 600 on Arbitrum reaches a 1,000 threshold. The token appears once in the breakdown and uses one of the 8 token slots. - **The store decides what counts as the same token.** Only the deployments the store lists are added together. Each network's balance is read in that token's own decimals there, and the balances are added exactly. - **All or nothing.** A read that fails on any listed network refuses the whole check (503, `rpc_failure`, no credit used), never a total from the networks that answered. - **Nothing changes without it.** A token saved without `alsoOn` is read on its own network only, exactly as before. A network listed twice, or already listed by another token, is a 400. October 5, 2026 ## MCP Server 1.16.2: Tool Descriptions and Merchant Tools Match the API SDK - **Tool descriptions say what `rpc_failure` means.** In [mcp-server-insumer](https://www.npmjs.com/package/mcp-server-insumer) 1.16.2, the attest, trust, verify, discount check, ACP and UCP tools each state that a 503 `rpc_failure` means a read did not complete, nothing was signed, and the call can be retried. It is never a "no". - **The merchant tools take the wallets the API reads:** `wallet`, `solanaWallet` and `xrplWallet` on verify, discount check, ACP and UCP. - **The configure tools carry more of the stored configuration.** `insumer_configure_nfts` takes `enabled` and `benefitType`, so a collection that was switched off stays off when its configuration is saved again. `insumer_configure_tokens` takes `name` and `logo`, and `enabled` for the own token. - An XRPL `taxon` is an integer from 0 to 4294967295, and a Sui coin type with type parameters is accepted. The hosted endpoint at `api.insumermodel.com/mcp` serves this version. October 5, 2026 ## Merchant Verification Is Signed Before Any Credit Is Taken; Discounts Are Whole Numbers Security Endpoint - **`POST /v1/verify` signs the result first.** The credit is taken and the code is stored together after the signature exists, and a coupon is created only once the code exists. A result that cannot be signed, or a code that cannot be stored, answers 503 in the standard error envelope: no credit used, no code created, safe to retry. A retry after a timeout on the caller's side is a new verification: if the first request completed, it used a credit and created a code, and the retry does both again. `/v1/acp/discount` and `/v1/ucp/discount` run the same verification and follow the same order. - **An own token's `enabled` is a boolean.** On `PUT /v1/merchants/{id}/tokens`, `"ownToken": {"enabled": false}` switches the own token off, as `null` does. `true`, or leaving it out, saves the token switched on. Any other value is a 400. - **Discounts are whole numbers.** A tier discount and an NFT discount are whole numbers from 1 to 50, and `discountCap` is a whole number from 1 to 100. A value with a fraction, such as 10.5, is a 400 on the token, NFT and settings saves. Digits such as `"10.0"` are accepted as 10. The spec already typed these fields as integers. October 4, 2026 ## Merchant Token Saves Validated; Two More Refusals on an Incomplete Read Security Endpoint - **Merchant token saves are validated.** `PUT /v1/merchants/{id}/tokens` checks a Solana mint address (`"native"` or base58, 32 to 44 characters), verifies an XRPL issuer's checksum, and checks an XRPL `currency` by the same rule as an attest condition. The currency is stored as entered, in the letter case given. Anything that fails is a 400. - **A merchant token's `decimals` is not used at evaluation.** The field is still required on save, from 0 to 18. When a discount is evaluated the token's own decimals are read from the chain. - **A balance that cannot be stated exactly is a refusal.** When a balance was read but has no exact decimal form, the answer is 503 `rpc_failure`, never a signed `met: false`. - **An XRPL trust line whose issuer account cannot be read is a refusal.** The answer is 503 `rpc_failure`: whether the issuer has frozen what it issued is part of the result, so the result is not signed without it. October 4, 2026 ## XRPL Currency Codes Are Matched Exactly as Issued Feature Chains - **XRPL currency codes are matched exactly as issued.** Currency codes are case-sensitive on the XRP Ledger: send `USD`, not `usd`, and send a token name in the letter case its issuer used. Trust-line conditions are evaluated the same way for a wallet of any size. October 4, 2026 ## XRPL Verification Strengthened: Issuer-Wide Freezes Security Chains - **XRPL verification strengthened.** A trust line whose issuer has frozen everything it issued is `met: false` with `trustLineState.frozen: true`, the same as a line with a freeze set on it, and earns no merchant tier. - **Merchant NFT configuration extended.** `PUT /v1/merchants/{id}/nfts` verifies an XRPL issuer's checksum and accepts a `taxon` from 0 to 4294967295; anything else is a 400. October 4, 2026 ## MCP Server 1.16.1: XRPL Currency Codes in Every Accepted Form SDK - **XRPL currency codes are accepted in every form the API accepts.** In [mcp-server-insumer](https://www.npmjs.com/package/mcp-server-insumer) 1.16.1, `currency` takes a 3-character code, a token name of 1 to 20 printable ASCII characters, or a 40-character hex code, and its description states that codes are case-sensitive and sent exactly as issued. The hosted endpoint at `api.insumermodel.com/mcp` serves this version, and the `insumer-attest` agent skill carries the same note. October 4, 2026 ## Input Validation Extended; Discount Check Refuses on an Incomplete Read Security Endpoint - **Input validation extended.** On XRPL and Solana, `nft_ownership` with `contractAddress: "native"` is a 400, as on the EVM chains. `XRP` given as an issued currency is a 400: use `contractAddress: "native"`. A decimal string (`threshold`, `multiple`, `amount`, `minFraction`) is at most 400 characters. - **`GET /v1/discount/check` refuses when a read does not complete.** It answers 503 `rpc_failure`, the same refusal as `/v1/attest`, so a discount answer always rests on completed reads. A frozen XRPL trust line earns no tier on the merchant endpoints. October 4, 2026 ## Non-EVM Verification Strengthened Security Chains - **Non-EVM verification strengthened.** Balances on Solana and Tron are compared digit for digit at any size. XRPL conditions extend to wallets holding many more NFTs. Messages in a 503 refusal use a fixed vocabulary. October 3, 2026 ## MCP Server 1.16: Output Schemas and Structured Results SDK - **Every tool declares an output schema.** In [mcp-server-insumer](https://www.npmjs.com/package/mcp-server-insumer) 1.16.0, the 27 tools share one schema describing the response envelope (`ok`, `data`, `meta`, `error`). - **Successful results carry `structuredContent`:** the same JSON the text content already held, parsed. The text content is unchanged, so clients that read it see no difference. - The HTTP runner answers any non-POST request with 405. The hosted endpoint at `api.insumermodel.com/mcp` serves this version. October 2, 2026 ## Hosted MCP Endpoint; MCP Server 1.15 Endpoint SDK - **The MCP server is hosted.** `https://api.insumermodel.com/mcp` serves ten of the 27 tools over MCP streamable HTTP: connect by URL, no install and no key, on a shared daily allowance. The ten are the signing keys, attest, compliance templates, wallet trust and batch trust, the merchant and token directories, the discount check and code validation. Run the package locally with your own key for the full set. - **[mcp-server-insumer](https://www.npmjs.com/package/mcp-server-insumer) 1.15.0 can be hosted.** `createInsumerServer(options)` is exported from the package root and builds a configured server for any transport, and `HOSTED_TOOLS` names the ten-tool subset. The stdio binary is unchanged: `npx -y mcp-server-insumer` behaves as before. October 2, 2026 ## MCP Server 1.14: Every Payment Quote Checked Before Signing SDK Security - **Pay-per-call checks the quote before the wallet signs.** With `INSUMER_PAYMENT_KEY` set, [mcp-server-insumer](https://www.npmjs.com/package/mcp-server-insumer) 1.14 signs a payment only when the x402 quote pays InsumerAPI's own receiving address, in USDC on Base, under the `exact` scheme, for no more than a cap: $3.00 per call by default, the price of the largest call today, adjustable with `INSUMER_MAX_PAYMENT_USDC`. Any other quote is refused and nothing is signed. Proven live: a $0.05 attestation paid and returned signed; the same quote under a lower cap was refused before signing. - **Every tool says what it does.** All 27 tools declare MCP annotations, so an agent host can tell the nine tools that only read from the ones that spend credits, create records, or replace a merchant's configuration. Every free-text input carries a format and a length limit (wallet addresses per chain, contract addresses and coin types, transaction hashes, merchant IDs, domains), so malformed input is refused before any request is sent. Tool descriptions point to [llms.txt](https://insumermodel.com/llms.txt) and [pricing](https://insumermodel.com/pricing/) for figures that change. - **The MCP Registry entry is now `com.insumermodel/insumer`**, verified through the insumermodel.com domain ([/.well-known/mcp-registry-auth](https://insumermodel.com/.well-known/mcp-registry-auth)). The npm package name is unchanged, so existing `npx -y mcp-server-insumer` configurations keep working. The previous registry name is deprecated with a pointer to the new one. - **insumer-verify 1.9.3 on npm** carries the README already on GitHub, including the pointer to the [Python package](https://pypi.org/project/insumer-verify/). The built code is byte-identical to 1.9.2, so the Python package stays at 1.9.2.1 and the test vectors' reference version still holds. **wdk-protocol-wallet-auth 0.2.9** is likewise documentation only. October 1, 2026 ## insumer-verify for Python Ecosystem Feature - The attestation and trust-profile verifier is on PyPI: `pip install insumer-verify` (Python 3.9+). It is the Python counterpart of the [npm package](https://www.npmjs.com/package/insumer-verify), built in the same [repository](https://github.com/insumerapi/insumer-verify), and it implements [Section 12](https://insumermodel.com/state-attestation-spec/) check for check: the ECDSA P-256 signature over the preimage the `kid` selects, condition hashes per scheme, block freshness, expiry bound to the signed `attestedAt`, the ML-DSA-65 companion (`pqSig`, and `pqJwt` bound to `jwt` by the full claim set), the tokens beside a `format: "jwt"` response, and trust profiles. - Both packages pass all 27 published [test vectors](https://insumermodel.com/.well-known/state-attestation-test-vectors.json), so a verdict from one can be reproduced with the other. The specification, not either implementation, is the source of truth. The Python package reproduces the issuer's `JSON.stringify` serialization exactly rather than approximating it with `json.dumps`: ECMAScript number formatting, property order, UTF-16 key sorting, and the v1 condition-hash replacer semantics, each cross-checked against Node. - One required dependency (`cryptography`); install `insumer-verify[pq]` for the post-quantum companion, which is otherwise reported `unverifiable`. A saved copy of the JWKS verifies with no network, exactly as in the npm package. Verified against production on a v1 key and a v2 key: raw, JWT format with the companion, and a trust profile. - **1.9.2.1 strengthens parity with the npm package beyond the published vectors.** An adversarial review ran crafted inputs through both verifiers and compared every verdict. The Python package now reads base64 exactly as the JavaScript runtime reads it, reads timestamps exactly as `Date` reads them (out-of-range fields invalid, day-of-month rollover, numeric and boolean coercion), refuses hostile shapes inside the signed payload as failed checks rather than passing over them, and accepts the same signature encodings on the JWT path. A parity suite built from those inputs ships with the tests, and the two packages agree on every verdict in that suite. One deliberate strengthening over the npm package, documented in the README: a caller option the verifier cannot read, such as a key set that is not an object or a cutoff date in an unknown form, is an error in the call rather than a silently weaker policy. - Nothing signed changes. No new `kid`, no change to any preimage; the API is untouched. The Python package is one more independent verifier of the signatures, and it goes on the list every key rotation has to clear before it ships. October 1, 2026 ## The Trust Profile Expands to Nine Dimensions: 145 Checks Across 27 Chains Endpoint Feature Spec - [POST /v1/trust](https://insumermodel.com/developers/trust/) and `POST /v1/trust/batch` now run **145 base checks across 27 chains in 9 dimensions**, up to **166 checks across 29 chains in 13 dimensions** with the optional Solana, XRPL, Bitcoin and Tron wallets. The profile was 45 base checks across 26 chains in 5 dimensions, up to 50 across 28 in 9. - Four new base dimensions: `tokenized_treasuries` (16: BUIDL, USYC, OUSG, USTB, USDY), `stablecoin_deposits` (39: Aave v3 aUSDC and aUSDT receipts, sUSDS, sDAI, listed Morpho USDC vaults), `wrapped_bitcoin` (12: cbBTC, WBTC, tBTC) and `names` (2: ENS .eth names and Basenames). The existing dimensions grow too: `stablecoins` to 52 (adding OUSD, PYUSD, USDG, USD1, RLUSD, USDS, DAI and EURC on their main chains), `governance` to 8 (adding ENS, LDO, SKY, COMP), `staking` to 5 (adding wstETH, weETH). The optional `solana` dimension is now 14 checks, `xrpl` adds OUSG, and `tron` adds USD1 and WBTC. Robinhood Chain joins the base chain set. - Every row is a presence check: a token balance above zero, or an NFT held. A row is admitted on an official issuer deployment and at least $1M live supply, and each was verified live on its chain by two independent readers before it entered the table. Stellar and Sui still add no dimension: their rows sit inside the base dimensions and carry `evaluated: false` when the wallet is absent, as before, now including USDY on Sui. - `conditionSetVersion` is now a dated identifier of the check list that was run: `"2026-10"`, the same on every key version, v1 and v2 alike, inside the signed payload. It is bumped whenever a row is added or removed. Readers may log it. Signature verification must not reject a result solely because the condition-set version is unfamiliar; the `kid`, not this field, selects the signing preimage. An application may still require a particular set for its own policy. The [specification](https://insumermodel.com/state-attestation-spec/) Section 11.4 is restated to match. The published test vectors keep the prior value and verify unchanged. - With `proof: "merkle"`, EVM token rows carry a storage proof when the token's balance slot can be discovered. Rows whose balance is computed rather than stored (Aave aTokens, BUIDL) and tokens with non-standard storage layouts are declined with `available: false` and a stated reason, rather than attempting a proof that cannot exist. NFT and non-EVM rows are declined as before; a check that was not evaluated carries no `proof` key at all; the premium is refunded whenever no proof is delivered. - Pricing is unchanged: 3 credits, 6 with proofs; $0.15 and $0.30 per call via x402. No new `kid`, no change to any signed preimage or to the trust object layout; every existing verifier reads the new profile unchanged. September 27, 2026 ## Wallet State Attestation Internet-Draft, Revision 01 Spec Ecosystem - Revision 01 of [`draft-borthwick-wallet-state-attestation`](https://datatracker.ietf.org/doc/draft-borthwick-wallet-state-attestation/) is on the IETF Datatracker: individual submission, Informational, 31 pages, expires March 31, 2027. Archived .txt at [ietf.org/archive/id](https://www.ietf.org/archive/id/draft-borthwick-wallet-state-attestation-01.txt). - The document states both signing schemes and how the `kid` selects them: the bare scheme, and the domain-separated scheme whose canonical form is RFC 8785. It defines the post-quantum companion (ML-DSA-65, carried as `pqSig` and `pqKid`, and in the JWT format as `pqJwt` bound to the token by its full claim set) with a four-verdict decision list, and a numbered verification procedure that names the verdict at every branch, including what a verifier reports when the signing key cannot be selected. - Written for every implementer, not only ours: the [specification](https://insumermodel.com/state-attestation-spec/), the [test vectors](https://insumermodel.com/.well-known/state-attestation-test-vectors.json) and `insumer-verify` follow the same rules, and a verifier built from the draft text alone reproduces the published attestation vectors. Nothing an issuer signs changes; every attestation ever issued verifies as before. September 27, 2026 ## Every Identifier in the Signed Condition Has an Alphabet Security Spec - On [POST /v1/attest](https://insumermodel.com/developers/verification/), the caller-supplied identifiers that are carried inside the signed `evaluatedCondition` are now checked against their alphabets before any credit is charged. XRPL `currency` is a 3-character standard code, a token name of 1 to 20 printable ASCII characters, or a 40-character hex code; Stellar `assetCode` is 1 to 12 characters from a-z, A-Z, 0-9; XRPL `taxon` is an integer from 0 to 4294967295; a Solana `contractAddress` is `"native"` or a base58 mint of 32 to 44 characters; an XRPL or Stellar issuer in `contractAddress` must pass its address checksum. Anything else is a 400 that names the field. - Why: the v2 preimage is RFC 8785 canonical JSON, and RFC 8785 refuses a string that is not well-formed Unicode. Since September 20 a condition `label` is always well-formed; these identifiers now carry the same guarantee, so no signed bytes can ever hold a value a verifier outside JavaScript cannot rebuild. The canonical serializer itself now refuses such a string as well. - Every request that was accepted with a well-formed identifier signs byte-identical output: same `evaluatedCondition`, same `conditionHash`, same preimage. No new `kid`, no change to any verifier. September 27, 2026 ## Each Verdict Stands on Its Own When the Key Cannot Be Selected SDK Spec - `insumer-verify` **1.9.2**: each check now reports its own result when the signing key cannot be selected. A `kid` that is missing, that the key set does not hold, or that cannot be fetched fails the signature verdict alone, with the reason. Condition hashes, freshness and expiry need no key and are computed and reported as before, and the post-quantum companion is *absent* when none was transmitted and *unverifiable* when one was, since that `kid` selects no preimage to rebuild it over. Nothing is checked against a key the response did not name, and `valid` stays false. Earlier releases reported every check failed and the companion unverifiable once the key failed to resolve, on the attestation, JWT and trust-profile paths alike. - [Specification](https://insumermodel.com/state-attestation-spec/) Section 12, Check 1 now states the rule for every verifier. [Test vectors](https://insumermodel.com/.well-known/state-attestation-test-vectors.json) 11 and 19 are restated to match: their condition hashes reproduce and are published as such, and vector 11, which carries no companion, reports it *absent*, as vector 23 always has for the same artifact. The set is still 27, and every other vector publishes exactly what it published before. - Nothing signed changes, and no accept-or-reject outcome changes anywhere: an artifact whose key cannot be selected was refused before and is refused now. What changes is the report a reader is handed about it. September 24, 2026 ## The Token Subject Names the Wallet That Was Evaluated Security Spec - With `format: "jwt"`, the token’s `sub` is now always a wallet a condition in the request evaluated, in both the ES256 token and its post-quantum companion. A wallet field that no condition reads is ignored and never named. When conditions span chain families, `sub` names the first evaluated family in the order EVM, Solana, XRPL, Bitcoin, Tron, Stellar, Sui. [Specification](https://insumermodel.com/state-attestation-spec/) Section 5.4 states the rule. - A `solanaWallet` a condition reads must be a base58 address of 32 to 44 characters. A request for `format: "jwt"` needs at least one condition that evaluates a wallet. - Requests whose conditions read every wallet they supply get the same `sub` they got before. No new `kid`, no change to any preimage, no change to the claim set. Every verifier keeps working unchanged. September 22, 2026 ## Rotation Tolerance for the Post-Quantum Companion Security SDK Spec - The companion signs the exact classical preimage the classical `kid` selects. [Specification](https://insumermodel.com/state-attestation-spec/) Section 12, Check 6 now states how a verifier treats a `kid` it does not recognise: that `kid` selects no preimage, so the companion is *unverifiable* rather than *refuted*, and a verifier MUST NOT fall back to another era’s preimage. A recognised `kid` naming the other artifact type is a relabelled artifact and stays refuted, as [test vector 21](https://insumermodel.com/.well-known/state-attestation-test-vectors.json) has always said. - This strengthens the verifier side of a key rotation. Rotations are two-sided: every verifier has to tolerate a signing `kid` it has not met before the issuer flips to it, and the specification now says what tolerating one means for the companion verdict. The rule is written for every verifier, not only ours. - `insumer-verify` **1.8.10** enforces it on both the attestation and the trust path. Two further strengthenings ship with it. An *absent* companion now distinguishes a call that did not supply one from an artifact that does not carry one, since a bare JWT string carries its companion in `options.pqJwt` rather than in the token. And `checks.jwt.pq` is reported once the token parses and names the response `kid`, so the companion verdict stands beside every later outcome instead of only the passing one. - Nothing signed changes. No new `kid`, no change to any preimage, no change to any response. All 27 published test vectors report exactly what they published, vector 21 included. Verifier-side throughout. September 21, 2026 ## Gitcoin Passport Verdicts Now Say Which Test They Passed Security Spec - The two Gitcoin Passport templates test different things: `gitcoin_passport_score` is met when the decoder’s `isHuman` is true (a score of at least 20), `gitcoin_passport_active` when `getScore` returns any score above zero. The signed `evaluatedCondition` of a decoder-based `eas_attestation` now carries `decoderMethod` (`"isHuman"` or `"getScore"`), so a verifier can tell from the signed bytes which test a verdict passed. - The two templates are distinguished in the signed `evaluatedCondition`, and therefore in `conditionHash`. The result’s `label` is set by the caller, so a relying party gating on either Gitcoin template matches `decoderMethod` as well as the decoder address to pin the test it means. - Additive: no field removed, no new `kid`, no change to how any preimage is built. A verifier recomputes `conditionHash` over whatever `evaluatedCondition` carries, so existing verifiers accept the new responses unchanged. The `conditionHash` of the two Gitcoin templates changes, which is the point; every other condition type is unchanged. A contract that pinned a Gitcoin `conditionHash` should re-pin. - Verified against production with a v1 key and a v2 key, both templates: signature, condition hashes and the post-quantum companion all verify under `insumer-verify` 1.8.8 and 1.8.7. September 21, 2026 ## USDC on Arc: in the Trust Profile, and a Fifth Way to Pay Per Call Endpoint Chain - [POST /v1/trust](https://insumermodel.com/developers/trust/) gains one stablecoin check, **USDC on Arc** (chain ID `5042`). The profile is now **45 base checks across 26 chains in 5 dimensions**, up to 50 across 28 chains in 9 with the optional wallets. The check is additive: every existing check, label and `conditionHash` is unchanged, and `conditionSetVersion` does not move. - Arc’s USDC is the chain’s own asset, so the check reads it as `contractAddress: "native"` with 18 decimals. With `proof: "merkle"` it carries an **account proof** (`subject: "account_balance"`), which also proves a zero balance. - The x402 quote on [POST /v1/attest](https://insumermodel.com/developers/verification/), [POST /v1/trust](https://insumermodel.com/developers/trust/) and `POST /v1/trust/batch` carries a fifth `accepts[]` entry: **USDC on Arc** (`eip155:5042`), listed last so every earlier entry keeps its position. Same price, same `exact` scheme, same EIP-3009 authorization, gasless for the payer. - **Sign under the domain the quote gives you.** Each EVM entry’s `extra` carries its token’s EIP-712 `name` and `version`, and they differ by network: `USD Coin` on Base, Polygon and Arbitrum, `USDC` on Arc. A client that hardcodes the name produces a signature Arc will not accept. As on every EVM network, the server re-derives that domain from the contract and asserts it before verifying a payment. - Arc payments settle through Circle’s hosted facilitator; the other four networks settle as before. A settlement that has not confirmed by our deadline is held as unresolved, never reported as uncharged: present the same payment header again and it resolves to the same payment. - Nothing signed changes. No new `kid`, no change to any signed preimage. Verified against production: the 45-check profile, in both modes, checked whole by `insumer-verify` 1.8.7 including the post-quantum companion; the Arc payment path exercised end to end on Arc’s test network, from quote to on-chain receipt. September 20, 2026 ## Merkle Proofs on Ronin, and the Scale Is Always the Token’s Own Feature Chains - **Ronin (`2020`) now carries Merkle proofs**: storage proofs for token balances and account proofs for the native coin. Proofs now cover 27 of the 31 EVM chains; the four outside that set are ZKsync Era, Sei, Viction and XDC Network. - **The token’s own decimals are always the scale.** On `/v1/attest` the scale is read from the chain for every `token_balance` and `ratio_to_amount` condition, and a `decimals` value in the request is a cross-check. Equal to the token’s own value, nothing changes; different, or not an integer from 0 to 100, the API returns `400`, and a mismatch message names the token’s own value. A threshold is in display units, so the verdict depends on the scale, and the relying party must be able to trust that the scale is the token’s own. A scale that cannot be read is still the `503` `rpc_failure`, never a `400`. - **Sui coin types are validated at the door.** On Sui, `contractAddress` must be a coin type (`address::module::Name`, optionally with type parameters). The short form (`0x2::sui::SUI`) and the 64-hex long form of an address name the same coin; anything that is not a coin type is a `400`. - **A contract address that is not an address is a 400.** On EVM chains and on Tron, a `contractAddress` that is neither `"native"` nor a well-formed address is refused at the door with a message that says what to send. `nft_ownership` requires the NFT contract: `"native"` names a coin, so to check the native coin use `token_balance` with `"native"`. - **Several chain families in one request are read together.** A request naming Solana, XRPL, Bitcoin, Tron, Stellar and Sui waits for the slowest of them, not for their sum. - Nothing signed changes: no new `kid`, no change to any signed preimage. September 20, 2026 ## Moonbeam and Moonriver Retired — 37 Chains Chains - Both networks stopped producing blocks in August 2026 (the final blocks are dated 2026-08-10) after the Moonbeam Foundation moved GLMR and MOVR to Base as ERC-20s. A signature over state that can never change again is not current state, so chain IDs `1284` and `1285` are retired. - A request naming either chain returns `400` with a message that says so and gives the token’s address on Base: GLMR `0xb3846fd356c2149ee8d30b0449088dc74e265459`, MOVR `0x43fEB74608334DDa8c1a6500D185cFC3Ea962B83`. Both are read with an ordinary `token_balance` condition on `chainId` `8453`. - The engine is now **37 chains**: 31 EVM plus Solana, XRPL, Bitcoin, Tron, Stellar and Sui. NFT ownership covers 33; Merkle proofs cover 26 of the 31 EVM chains. - EAS attestation conditions are supported on five chains: Ethereum, Optimism, Polygon, Base and Arbitrum. - Nothing signed changes: no new `kid`, no change to any signed preimage. September 20, 2026 ## The Post-Quantum Companion Binds the Full Claim Set Feature SDK Spec - With `format: "jwt"`, [POST /v1/attest](https://insumermodel.com/developers/verification/) returns `pqJwt` beside `jwt`: a second compact JWS (ML-DSA-65) carrying the same claims. A verifier now binds the two by the **whole claim set** — the same member names, and for every member a deeply equal value — where the check previously named `jti`, `exp` and `pass`. The companion therefore vouches for every claim a relying party reads from the `jwt`: `sub`, `results`, `conditionHash` and the block anchor included. - Any difference — a changed value, a missing member, an extra one on either side — reports the companion as `refuted`, and the reason names the first differing claim. Comparison is by parsed value, never by bytes, so member order is free to differ between the two tokens. - `insumer-verify` **1.8.6** on npm implements it; the rule is [specification](https://insumermodel.com/state-attestation-spec/) Section 12, Check 6. Two new [test vectors](https://insumermodel.com/.well-known/state-attestation-test-vectors.json), 24 and 25, are the refused cases: the genuine pair of vector 17 with one claim edited inside `jwt` and the `pqJwt` left untouched. Vectors 26 and 27 are a whole `format: "jwt"` response, as issued and with a token edited. The set is now 27 vectors. - `insumer-verify` **1.8.7**, the same day, verifies a `format: "jwt"` response whole. The API returns the tokens beside the attestation, and given that whole object the verifier now checks the tokens as well and reports them as a sixth verdict, `checks.jwt`: the ES256 signature of `jwt`, its condition hashes, that it is the token of this attestation (`jti`, `pass`, `results` and `exp` equal the attestation's), and its `pqJwt` companion. The verdict appears only when the response carries tokens; every other input reports the same five verdicts as before. - Nothing signed changes. No new `kid`, no change to any signed preimage or to any response, and every attestation ever issued verifies as before — both tokens have carried one identical claim set since the companion shipped. Verified against fresh production responses under a v1 key and a v2 key, by 1.8.6 and by the previous release. The raw format is unaffected: there `pqSig` already covers the exact classical preimage. September 17, 2026 ## Arc Joins the Engine — 39 Chains, and Native Balances Become Provable Chain Feature - Arc (chain ID `5042`), which opened its public mainnet on September 16, is now a supported chain on [POST /v1/attest](https://insumermodel.com/developers/verification/). Every EVM condition type works from day one: `token_balance`, `nft_ownership`, `evm_view_call`, and the ratio rules. That brings the engine to **39 chains, 33 of them EVM**. USDC on Arc sits at the predeploy `0x3600000000000000000000000000000000000000`, EURC at `0xbEf5f6d51CB62b58e6A8f77868681825C6fe21c1`. - **Arc's native gas asset is USDC itself** — one balance exposed through two interfaces, not two assets. `eth_getBalance` returns the 18-decimal view of the very same holding the 6-decimal ERC-20 reports, the two differing by exactly 10^12. A request pairing `contractAddress: "native"` with the predeploy on Arc would therefore read one balance twice, and the rule its author believed they wrote would require half of what it says. Such a request is refused with a 400 that names both conditions, before any credit is charged. - The same rule applies wherever a chain's gas asset is also an ERC-20. On Celo, Moonbeam and Moonriver the mirror is the chain's own gas token, so pairing the native asset with it reads one balance twice there as well, and is rejected the same way. Use either the native asset or the token address on these chains, never both. - **Native balances now carry a proof, on every proof-capable chain.** A Merkle proof here meant a *storage* proof, which needs a balance mapping to point at — so a condition with `contractAddress: "native"` could never carry one, on any chain. Arc made that conspicuous, since its native asset is USDC. Such a condition now returns an **account** proof (`subject: "account_balance"`): the account’s own Merkle branch, whose `balance` field is the value evaluated, against the same block state root used to verify a storage proof. Simpler than the storage path — no slot to discover, and no mapping-slot assumption for a verifier to trust — and it proves a *zero* balance, which the storage path cannot. Additive throughout: proofs sit outside every signed preimage, so nothing a verifier reads has changed, and ERC-20 storage proofs are untouched. - **Merkle proofs cover 27 of the 33 EVM chains, Arc among them.** Whether a chain can carry a proof is a property of the node read, not of the chain. The six outside that set are ZKsync Era, Sei, Ronin, Moonriver, Viction and XDC Network, whose RPCs decline `eth_getProof`. A `proof: "merkle"` request on any of them returns the signed attestation with the proof marked unavailable, and the premium is refunded — as it is now whenever no proof is delivered, whatever the reason. - Nothing signed changes. No new `kid`, no change to any signed preimage, and the post-quantum companion applies on Arc as everywhere else. Verified live against production with both a v1 and a v2 key — pass and fail, block-anchored — and both responses checked end to end by `insumer-verify` 1.8.4, including the companion. September 3, 2026 ## Pay-Per-Call Settles on Base, Polygon, Arbitrum, and Solana Endpoint Chain - The x402 quote on [POST /v1/attest](https://insumermodel.com/developers/verification/), [POST /v1/trust](https://insumermodel.com/developers/trust/), and `POST /v1/trust/batch` now carries one `accepts[]` entry per settlement network: USDC on Base (`eip155:8453`, listed first as before), Polygon (`eip155:137`), Arbitrum (`eip155:42161`), and Solana (`solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp`). Same price on every network; a client that takes the first entry sees exactly what it saw before. x402 moves the money. InsumerAPI checks the conditions. - EVM entries advertise each USDC contract's own EIP-712 name and version in `extra`, and the server re-derives and asserts that domain against the contract on-chain before verifying a payment. The Solana entry advertises the facilitator's fee payer in `extra.feePayer`; the payer builds a partially signed USDC transfer around it and settlement is gasless there too. - The payment header is read under both names: `PAYMENT-SIGNATURE` (the x402 v2 name) and `X-PAYMENT`. The settlement receipt is returned as `PAYMENT-RESPONSE` and `X-PAYMENT-RESPONSE`. A client sending either name alone is answered the same way. - Additive throughout: nothing signed changes. The attestation bytes never contain payment data, and the same `kid`, JWKS, and post-quantum companion apply regardless of which network paid. Verified live on all four networks with the reference `@x402` client and `insumer-verify` 1.8.4. September 1, 2026 ## Post-Quantum Companion Signatures Spec Endpoint - Every [POST /v1/attest](https://insumermodel.com/developers/verification/) and [POST /v1/trust](https://insumermodel.com/developers/trust/) response now carries a second, post-quantum signature beside the ECDSA one: `pqSig` and `pqKid` (ML-DSA-65, FIPS 204) as siblings of `sig` and `kid`. With `format: "jwt"` a sibling `pqJwt` (a compact JWS with `alg: "ML-DSA-65"`, same claims as `jwt`) is returned as well. Applies to v1 and v2 keys alike. - Additive by design. `sig`, `kid`, `jwt`, every preimage, and every existing JWKS entry are byte-for-byte unchanged. A verifier that does not read the new fields behaves exactly as before; this was checked against the unmodified previous release of `insumer-verify` before shipping. - The companion signs the post-quantum domain tag plus the same classical preimage the response's `kid` selects, so no new canonicalization is introduced. The public key is published in the [JWKS](https://insumermodel.com/.well-known/jwks.json) as RFC 9964 `AKP` entries (`insumer-attest-pq1`, `insumer-trust-pq1`), appended after the EC entries. - The key binding, signed by both the classical and the post-quantum key and anchored on Base (block 50758053), is published at [/.well-known/pq-key-binding.json](https://insumermodel.com/.well-known/pq-key-binding.json). Its block time is the public record of when the companion came into existence. - The [spec](https://insumermodel.com/state-attestation-spec/) gains Check 6: the companion is reported as a fifth, independent verdict (verified, refuted, absent, unverifiable). A refuted companion fails the artifact. An absent one affects a live access decision only under the verifier's own cutoff date, judged by its own clock; an artifact read as evidence after the fact is never refused for lacking a companion. - `insumer-verify` 1.8.0 reports the fifth verdict and takes `mode`, `pqRequiredFrom`, and `pqActivatedAt` options. Published test vectors 12 through 17 exercise the companion on both key eras, a tampered companion, an unresolvable `pqKid`, a pre-companion artifact under a cutoff, and the JWT envelope. August 28, 2026 ## Commerce Discount Responses Track Their Current Releases Spec Endpoint - [POST /v1/ucp/discount](https://insumermodel.com/developers/commerce/) now returns a `dev.ucp.shopping.discount` fragment matching Universal Commerce Protocol release `2026-08-25`, and the `version` field reports that release. - New optional `subtotal` request field, an order-level base in minor units for callers that do not send line items. UCP's applied discount carries an absolute amount and has no percentage field, so an applied entry needs either `items` or `subtotal`. `subtotal` is ignored when `items` is supplied. - With neither supplied, the response carries no applied entry and `discounts.codes` is empty. The verified discount still reaches the caller through the `verification` object, which always carries the code and signature. - Per-item `allocations` now use largest-remainder distribution, so they sum exactly to the discount `amount` as the UCP discount extension requires. Allocation order follows the order of the submitted items. - [POST /v1/acp/discount](https://insumermodel.com/developers/commerce/) tracks Agentic Commerce Protocol release `2026-04-17` and takes the same treatment. It also accepts `subtotal`: ACP's applied discount requires an integer amount in minor units, and `coupon.percent_off` does not stand in for it. - Both responses now describe the discount as what it is: an **automatic** discount. It follows from what the wallet holds, not from a code anyone entered, so `automatic` is `true` and the applied entry carries no `code` field, which both protocols reserve for a submitted code. - Following from that, `discounts.codes` is always empty — it echoes codes the caller submitted, and this endpoint accepts none — and the ACP `rejected` array is always empty, since it lists submitted codes that could not be applied. An ineligible wallet is simply an automatic discount that did not apply. The `INSR-XXXXX` redemption code is returned in `verification.code`, and on `applied[].id` on the ACP path; validate it at [GET /v1/codes/{code}](https://insumermodel.com/developers/api-reference/). - Unchanged on both paths: the verification performed, the signed payload, the signature scheme, and the `kid`. This release changes response formatting only. August 5, 2026 ## Client-Side Verification for Trust Profiles Feature - [insumer-verify](https://www.npmjs.com/package/insumer-verify) v1.6.0 adds `verifyTrustProfile`, alongside the existing `verifyAttestation`. It independently checks the ECDSA P-256 signature, freshness, and expiry on a profile from [POST /v1/trust](https://insumermodel.com/developers/trust/) and on each entry of POST /v1/trust/batch. - The `kid` on the response selects the scheme: `insumer-trust-v2` (domain-separated canonical preimage) or the legacy `insumer-attest-v1` (bare JSON). The public key resolves from [GET /v1/jwks](https://insumermodel.com/developers/api-reference/#jwks). - Why it matters: a trust profile carries no score and no opinion, only cryptographically verifiable evidence organized by dimension. A third party can now confirm that evidence came from InsumerAPI and has not been altered, without trusting the caller. - For batch, call `verifyTrustProfile` once per `data.results[i]`. The function returns the verified profile so a consumer renders the object that was checked. Zero dependencies, the same as the attestation path. July 28, 2026 ## Delegation Failures Name the Undeployed Principal Spec - New `failReason` value on `erc7710_delegation`: `delegator_not_deployed`, returned when the principal address holds no contract code at the anchored block. - That is the normal state of a smart-contract wallet until its first transaction. Signing a delegation is an off-chain EIP-712 signature, so a principal can grant authority without ever deploying, and the ERC-1271 path treats a counterfactual principal as an undeployed wallet rather than a signature failure. - Why it matters: your code can now tell “this principal rejected the signature” from “this principal is not on chain yet.” The first is final; the second is worth retrying once the wallet deploys. - The verdict is unchanged and still a signed false. Redemption calls `executeFromExecutor` on the delegator account, so an undeployed principal cannot exercise the delegation regardless of what it signed. No other `failReason` changes meaning, and no signed bytes change for any case that was already reported correctly. - Documented in the [state attestation specification](https://insumermodel.com/state-attestation-spec/#evaluated-conditions) and the OpenAPI `failReason` enum. July 27, 2026 ## Revocation Proofs for `erc7710_delegation` Feature - `proof: "merkle"` now works on an `erc7710_delegation` condition. The result carries an EIP-1186 storage proof of `disabledDelegations[delegationHash]` in the DelegationManager, against the anchored block's state root. - The proof object is tagged `subject: "delegation_revocation"` (balance proofs carry no `subject`) and adds `contractAddress` alongside the usual `mappingSlot`, `storageKey`, `accountProof`, `storageProof`, and `storageHash`. - Why it matters: a delegation verdict has three parts. Two of them you could already reproduce yourself: the EIP-712 signature check (you hold the delegation) and the caveat decode (you submitted the raw `terms`). “Not revoked as of block N” was the one part you had to take on our word. Now the whole verdict is checkable. - To verify: recompute `storageKey = keccak256(abi.encode(delegationHash, mappingSlot))` from the `delegationHash` in the signed `evaluatedCondition` and confirm it matches, verify the account and storage proofs against the block header's state root, then read the value: `1` is revoked, `0` is not. A proven `0` is positive proof that no revocation exists, not a report that none was found. - Returned only for DelegationManagers whose storage layout has been verified on-chain, which today means the v1.3.0 manager on Base. Other recognized managers return `proof.available: false` with a reason, and the verdict is signed as normal. An inferred slot would prove the wrong location while still verifying against the header, which is worse than no proof. - Costs 2 credits like any proof-mode request, refunded to 1 if a proof cannot be produced for a transient RPC reason. `erc8004_agent` still does not support proofs. July 27, 2026 ## Agent Conditions: Generally Available and on x402 Pay-Per-Call Feature - `erc8004_agent` and `erc7710_delegation` on [POST /v1/attest](https://insumermodel.com/developers/verification/) are now generally available. The per-key enablement flag is gone from production: every API key can send both types, with no request to make and no gating `403`. - Both types also work with **no API key at all**, via x402 pay-per-call: send the request with no credential headers, take the `402` priced quote, sign an EIP-3009 USDC authorization on Base, and retry with the `X-PAYMENT` header. The facilitator settles gasless (the wallet needs USDC, no ETH) and the signed attestation returns in the same round trip. - Price on pay-per-call is `$0.05` for both agent types, the standard rate. (Superseded in part: `erc7710_delegation` later gained Merkle revocation proofs. See the entry above.) - Everything else is unchanged: Base (chainId `8453`) only at launch, 1 credit when paid with credits, `agentId` required for `erc8004_agent`, `expectedDelegator` required for `erc7710_delegation`, an unknown caveat enforcer fails the condition, declared limits are reported rather than simulated, and attestations containing a delegation condition expire in 5 minutes. July 27, 2026 ## Agent Conditions: erc8004_agent and erc7710_delegation Feature - Added `erc8004_agent` and `erc7710_delegation` condition types to [POST /v1/attest](https://insumermodel.com/developers/verification/): off-chain attestation of ERC-8004 agent registration and ERC-7710 delegation validity on Base. Both shipped gated to enabled keys and were opened to everyone the same day. See the general-availability entry above. - `erc8004_agent`: met when the attested wallet owns the agent NFT or is the Identity Registry’s on-chain signature-verified `agentWallet` binding for the supplied `agentId`. The signed statement is exactly “registered at agentId N, owned by / bound to this wallet”. Registration is permissionless, so it implies no vetting, no reputation, no endorsement. - `erc7710_delegation`: met when the delegation’s delegate is the attested wallet, the delegator is the caller-asserted `expectedDelegator`, the EIP-712 signature verifies (EOA or ERC-1271), the delegation is not revoked as of the anchored block, and every caveat uses a recognized enforcer. Declared spend and target limits are reported in `declaredLimits`; attestations containing a delegation condition expire in 5 minutes. - Both types: Base (chainId `8453`) only at launch, 1 credit, no Merkle proofs. Gated per key at ship time; that flag was removed the same day. July 20, 2026 ## Robinhood Chain — 38 Chains Feature - Robinhood Chain (chainId `4663`) added to the EVM family — the Ethereum Layer-2 built on Arbitrum’s stack that Robinhood took to public mainnet on July 1, 2026, home of tokenized equities (Tesla, NVIDIA, Apple, SPY, and more as ERC-20 stock tokens) and the USDG stablecoin. Standard `wallet` field, standard EVM semantics. - Every EVM condition type works on day one: `token_balance` (including tokenized-stock holdings), `nft_ownership`, `ratio_to_amount`, and `ratio_to_supply` on [POST /v1/attest](https://insumermodel.com/developers/verification/). A wallet can now prove “holds at least N tokenized shares” the same way it proves any other balance condition — signed boolean out, raw balance never exposed. - Merkle storage proofs (EIP-1186) supported — Robinhood Chain joins the proof-capable set, now **28 of 32 EVM chains**. - Total chain coverage: **32 EVM + Solana + XRPL + Bitcoin + Tron + Stellar + Sui = 38 chains**. June 10, 2026 ## Wallet Auth v2 — Domain-Separated Signing, Decimal-String Thresholds, Ratio Conditions on v2 Security Feature - Every newly created API key now signs with a **versioned, domain-separated scheme (v2)** on [POST /v1/attest](https://insumermodel.com/developers/verification/) and [POST /v1/trust](https://insumermodel.com/developers/trust/). Same ECDSA P-256 key, stronger binding: each signature is tagged to its message type, so an attestation signature and a trust-profile signature can’t be replayed across contexts. v1 stays byte-frozen for existing keys — nothing changes for a key issued before today. - On v2 keys, agent-supplied quantities are **decimal strings, not JSON numbers**: `token_balance.threshold` and the ratio fields `multiple` / `amount` / `minFraction` (e.g. `"100"`, `"0.005"`). This carries an exact, full-precision value that a JSON float would silently round — the thresholds an agent composes stay lossless. A JSON number returns `400` with a self-correcting message. v1 keys still accept either, and a string is valid on both. - [GET /v1/jwks](https://insumermodel.com/developers/api-reference/#jwks) now publishes **three key IDs** — `insumer-attest-v1`, `insumer-attest-v2`, and `insumer-trust-v2` — all the same public key. The `kid` on every response tells a verifier which scheme and domain to check against. The signature proves we issued it; the blockchain proves we were correct. - **`ratio_to_amount` and `ratio_to_supply` now sign under v2.** On a v2 key their quantities are decimal strings, and `ratio_to_supply` uses an exact-rational share-of-supply comparison with no float in the signed bytes. Same 1-credit cost, same signed boolean output. - Offline verification is unchanged in shape: [insumer-verify](https://www.npmjs.com/package/insumer-verify) (npm) checks both `insumer-attest-v1` and `insumer-attest-v2` signatures and re-derives `conditionHash` locally. June 5, 2026 ## White-Label Scanner — Partner-Run Point-of-Sale on the Merchant API Endpoint Security - New X-API-Key endpoints let a partner run its own branded scanner against merchants it manages — no account of its own. The partner builds only UI; InsumerAPI does all the cryptographic verification. - **[POST/GET /v1/merchants/{id}/scanners](https://insumermodel.com/developers/api-reference/#scanners)** — add, remove, and list a merchant's in-person scanner PINs (4–8 digits, a limited number per merchant, never returned). Owner key only. - **[POST /v1/scanner/session](https://insumermodel.com/developers/api-reference/#scanner-session)** — validate a scanner PIN and return the merchant config for a login-less branded scanner. 5 failed attempts / 15 min lockout. - **[POST /v1/pass/verify](https://insumermodel.com/developers/api-reference/#pass-verify)** — verify a scanned pass: checks the InsumerAPI ECDSA signature on the QR, enforces 65-second freshness, then computes the discount against the merchant config. A bad signature is rejected with no discount. - **[POST /v1/registry/submit](https://insumermodel.com/developers/api-reference/#submit-registry)** — submit a token/NFT to the public registry as pending for review (free, no credits; idempotent per chain + address; records a `source` provenance tag). - Merchant API deltas: `POST /v1/merchants` accepts an optional `externalId` for idempotent upsert; `PUT /v1/merchants/{id}/tokens` accepts per-token `name`/`logo` for the directory listing; `POST /v1/merchants/{id}/directory` accepts `{ "listed": false }` to unpublish, and partner-provisioned merchants must pass domain verification before publishing. - **[PUT /v1/merchants/{id}/verification](https://insumermodel.com/developers/api-reference/#partner-verify)** — a designated white-label partner can record that it verified an org's domain in its own branded flow (so the operator never sees an Insumer-branded challenge). Restricted to partner-enabled keys; self-serve merchants keep the DNS/meta/file challenge flow. - **No pass “sign” endpoint.** Signing is the InsumerAPI primitive — it only signs wallet state it computed itself, and signing is never exposed as a public API call. A white-label wrapper scans and verifies passes that InsumerAPI issued; it never mints signatures. June 1, 2026 ## Dimensionless Conditions — `ratio_to_amount` and `ratio_to_supply` on /v1/attest Feature - Two new condition types on [POST /v1/attest](https://insumermodel.com/developers/verification/) express access rules as **relationships, not fixed numbers**, so a single rule means the same thing on every chain and over time with no re-tuning. Purely additive: the five existing condition types and the ECDSA-signed boolean output are unchanged. - **`ratio_to_amount`** — met iff `balance >= multiple × amount`. A self-scaling check for agent spending: “hold at least 10× the size of the transaction the agent intends to make,” which adjusts itself to every payment instead of a flat cap. `amount` is in token/display units (e.g. `100` for 100 USDC, not base units). RPC EVM chains. The `evaluatedCondition` carries `multiple`, `amount`, and the derived `threshold`. - **`ratio_to_supply`** — met iff `balance / totalSupply() >= minFraction`, a fraction in `(0, 1]` (e.g. `0.005` for 0.5% of supply). Share-of-supply gating for project and governance tokens, where your slice of supply represents your stake. RPC EVM chains, ERC-20 contracts only. Operator `gte_fraction`. - Reproducible by design. For `ratio_to_supply`, the result carries the raw `totalSupply` read and the computed `fraction` as siblings — inside the ECDSA-signed payload but outside `conditionHash`, which stays a pure fingerprint of the rule. A verifier re-reads balance and `totalSupply` at the pinned `blockNumber` and re-derives the boolean. Decimals cancel in the ratio, so the comparison is exact. - No change to the signing path, `kid`, the `conditionHash` algorithm, or credit cost (1 credit, same as any attest condition). OpenAPI `Condition`, `EvaluatedCondition`, and `AttestationResult` schemas updated with the new type values and the `multiple` / `amount` / `minFraction` fields plus the `totalSupply` / `fraction` result fields. May 20, 2026 ## Wallet Auth Default — New Agents Skip the API Key, Scope Widens to Five Endpoints Feature - [POST /v1/keys/buy](https://insumermodel.com/developers/onboarding/) 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](https://insumermodel.com/developers/verification/), [POST /v1/trust](https://insumermodel.com/developers/trust/), [POST /v1/trust/batch](https://insumermodel.com/developers/trust/), [GET /v1/credits](https://insumermodel.com/developers/account/), and [POST /v1/credits/buy](https://insumermodel.com/developers/account/). 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](https://insumermodel.com/developers/account/) 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](https://insumermodel.com/blog/your-agent-doesnt-need-an-api-key.html). 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](https://insumermodel.com/developers/onboarding/) 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](https://insumermodel.com/developers/verification/): 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 ` 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](https://insumermodel.com/developers/verification/) 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](https://insumermodel.com/developers/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](https://insumermodel.com/developers/onboarding/) and [/v1/credits/buy](https://insumermodel.com/developers/account/). 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](https://insumermodel.com/blog/wallet-auth-tron-stellar-sui-xdc.html). May 13, 2026 ## IETF Internet-Draft — Wallet State Attestation (Individual Submission) Spec Ecosystem - Filed [`draft-borthwick-wallet-state-attestation-00`](https://datatracker.ietf.org/doc/draft-borthwick-wallet-state-attestation/) to the IETF Datatracker. Individual submission, Informational, 19 pages, expires November 14, 2026. Archived .txt at [ietf.org/archive/id](https://www.ietf.org/archive/id/draft-borthwick-wallet-state-attestation-00.txt). - 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`](https://datatracker.ietf.org/doc/draft-borthwick-msebenzi-environment-state/) to the IETF Datatracker. Independent Submission stream, Informational, 43 pages, expires November 12, 2026. Archived .txt at [ietf.org/archive/id](https://www.ietf.org/archive/id/draft-borthwick-msebenzi-environment-state-00.txt). - 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 - v2.0.0 expands the mppx adapter from two condition types to four: `token_balance`, `nft_ownership`, `eas_attestation` (Coinbase Verified, Gitcoin Passport templates), and `farcaster_id`. Mix any of them in a single call - The category expansion drove a rename to [`@insumermodel/mppx-condition-gate`](https://www.npmjs.com/package/@insumermodel/mppx-condition-gate). The previous package is deprecated on npm with a redirect; Tempo’s MPP [extensions page entry](https://github.com/tempoxyz/mpp/pull/630) update is open - Blog post: [Condition-Based Access for Machine Payments Protocol](https://insumermodel.com/blog/mppx-condition-gate-machine-payments-protocol.html) April 24, 2026 ## ERC-8183 Envelope-in-Action Case Library — Co-maintainer Spec Ecosystem - Publicly-named co-maintainer of the neutral [erc-8183-cases](https://github.com/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 Skye Meta’s case. - Charter scopes the library to compliance/regulatory how-to material, not spec governance. Announcement: [Ethereum Magicians post](https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902/195). 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) do not expose `eth_getProof`. - Merkle proofs are available on Taiko, which supports `eth_getProof`. No backend change; the documentation states it. - Storage proofs may be unavailable for tokens with non-standard storage layouts. 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. A verifier can rely on the anchor fields being present on every signed result. - 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 “26 of 31” carve-out for Taiko, Ronin, Moonriver, and Viction no longer applies: those chains return the same anchor fields as every other EVM chain. 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](https://smithery.ai/skills/douglasborthwick/insumer-skill). Source on [GitHub](https://github.com/insumerapi/insumer-skill). - 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`](https://www.npmjs.com/package/@insumermodel/plugin-eliza). 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](https://github.com/insumerapi/insumer-examples/blob/main/MULTI-ATTESTATION-SPEC.md) 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). - Skye Meta’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.](https://insumermodel.com/blog/multi-attestation-spec-five-shipped-wallet-binding.html) 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](https://github.com/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](https://revettr.com) 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 checks via `bitcoinWallet` parameter on [POST /v1/attest](https://insumermodel.com/developers/verification/) and [GET /v1/trust](https://insumermodel.com/developers/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 Skye Meta’s SkyeWoo. March 23, 2026 ## MPP Extensions Directory — First Community Package Listed Ecosystem - [`@insumermodel/mppx-token-gate`](https://www.npmjs.com/package/@insumermodel/mppx-token-gate) listed as the first entry on [Tempo’s new Extensions page](https://github.com/tempoxyz/mpp/pull/445). 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](https://defaultverifier.com) 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](https://github.com/insumerapi/insumer-examples/blob/main/MULTI-ATTESTATION-SPEC.md) spec. Four independent issuers (InsumerAPI, ThoughtProof, RNWY, Maiat) sign attestations across four trust dimensions. One envelope, one verification pass, any combination of issuers. - Skye Meta’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](https://github.com/insumerapi/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](https://insumermodel.com/blog/multi-attestation-four-issuers-one-verification-pass.html) March 16, 2026 ## AgentTalk by Skye Meta — Condition-Gated Agent Communication Feature - [AgentTalk](https://skyemeta.com/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](https://skyemeta.com/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](https://insumermodel.com/blog/token-gate-woocommerce-products-skyewoo-plugin.html) March 14, 2026 ## SkyeGate WordPress Plugin — No-Code Condition-Based Access Feature - [SkyeGate](https://skyemeta.com) 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](https://insumermodel.com/blog/token-gate-wordpress-skyegate-plugin.html) 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. - 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](https://github.com/Universal-Commerce-Protocol/ucp) (UCP), the open commerce standard backed by Shopify. - [#203 — Signals for authorization & abuse](https://github.com/Universal-Commerce-Protocol/ucp/pull/203): 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](https://github.com/Universal-Commerce-Protocol/ucp/pull/250): 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](https://github.com/Universal-Commerce-Protocol/ucp/pull/264) (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`). - InsumerChat knowledge base updated with XRPL response field documentation. 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](https://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 checks, 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 - Large wallets with many trust lines and NFTs are read in full - 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](https://insumermodel.com/state-attestation-spec/) 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](https://insumermodel.com/developers/verification/), [trust](https://insumermodel.com/developers/trust/), [compliance](https://insumermodel.com/developers/compliance/), [commerce](https://insumermodel.com/developers/commerce/), [onboarding](https://insumermodel.com/developers/onboarding/), [api-reference](https://insumermodel.com/developers/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, 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](https://insumermodel.com/developers/) [API Reference →](https://insumermodel.com/developers/api-reference/)