New endpoints, SDK releases, chain support, and spec changes. Updated as features ship.
account_code condition type to POST /v1/attest, 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.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.account dimension to POST /v1/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.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 records all three changes in its revision history. No new kid, no change to any signed preimage or to the trust object layout.POST /v1/trust/batch and its signed profiles are unchanged.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.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.--full prints the complete response.POST /v1/attest: the message for an unsupported chainId names where the supported chain IDs are listed, llms.txt.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./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.insumermodel.com/pass now redirects to 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.POST /v1/pass/verify. Nothing changes for a scanner or an integration that verifies passes.insumermodel.com/pass/connect, opened by sites that recognize the pass, stays where it is./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./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.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.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.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.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.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.insumer-discount in 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.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.wallet: a proof sent with solanaWallet or xrplWallet is refused (400). Responses and GET /v1/codes/{code} carry walletProven.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.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.walletProof at a store that has set nothing works exactly as before. The signed result is unchanged; walletProven and discountIfProven sit beside it.GET /v1/merchants/{id}/status returns the new settings and each token's alsoOn networks.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./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.rpc_failure, no credit used), never a total from the networks that answered.alsoOn is read on its own network only, exactly as before. A network listed twice, or already listed by another token, is a 400.rpc_failure means. In 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".wallet, solanaWallet and xrplWallet on verify, discount check, ACP and UCP.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.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.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.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.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.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.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.rpc_failure, never a signed met: false.rpc_failure: whether the issuer has frozen what it issued is part of the result, so the result is not signed without it.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.met: false with trustLineState.frozen: true, the same as a line with a freeze set on it, and earns no merchant tier.PUT /v1/merchants/{id}/nfts verifies an XRPL issuer's checksum and accepts a taxon from 0 to 4294967295; anything else is a 400.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.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.ok, data, meta, error).structuredContent: the same JSON the text content already held, parsed. The text content is unchanged, so clients that read it see no difference.api.insumermodel.com/mcp serves this version.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.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.INSUMER_PAYMENT_KEY set, 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.com.insumermodel/insumer, verified through the insumermodel.com domain (/.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.pip install insumer-verify (Python 3.9+). It is the Python counterpart of the npm package, built in the same repository, and it implements Section 12 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.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.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.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.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.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.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.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 Section 11.4 is restated to match. The published test vectors keep the prior value and verify unchanged.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.kid, no change to any signed preimage or to the trust object layout; every existing verifier reads the new profile unchanged.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.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.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.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.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.evaluatedCondition, same conditionHash, same preimage. No new kid, no change to any verifier.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.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 Section 5.4 states the rule.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.sub they got before. No new kid, no change to any preimage, no change to the claim set. Every verifier keeps working unchanged.kid selects. Specification 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 has always said.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.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.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.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.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.insumer-verify 1.8.8 and 1.8.7.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.contractAddress: "native" with 18 decimals. With proof: "merkle" it carries an account proof (subject: "account_balance"), which also proves a zero balance.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.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.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.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./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.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.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".kid, no change to any signed preimage.1284 and 1285 are retired.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.kid, no change to any signed preimage.format: "jwt", POST /v1/attest 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.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 Section 12, Check 6. Two new test vectors, 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.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.5042), which opened its public mainnet on September 16, is now a supported chain on POST /v1/attest. 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.eth_getBalance returns the 18-decimal view of the very same holding the 6-decimal ERC-20 reports, the two differing by exactly 1012. 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.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.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.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.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.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.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.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.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.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.kid selects, so no new canonicalization is introduced. The public key is published in the JWKS as RFC 9964 AKP entries (insumer-attest-pq1, insumer-trust-pq1), appended after the EC entries.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.dev.ucp.shopping.discount fragment matching Universal Commerce Protocol release 2026-08-25, and the version field reports that release.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.discounts.codes is empty. The verified discount still reaches the caller through the verification object, which always carries the code and signature.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.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.automatic is true and the applied entry carries no code field, which both protocols reserve for a submitted code.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}.kid. This release changes response formatting only.verifyTrustProfile, alongside the existing verifyAttestation. It independently checks the ECDSA P-256 signature, freshness, and expiry on a profile from POST /v1/trust and on each entry of POST /v1/trust/batch.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.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.failReason value on erc7710_delegation: delegator_not_deployed, returned when the principal address holds no contract code at the anchored block.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.failReason enum.erc7710_delegationproof: "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.subject: "delegation_revocation" (balance proofs carry no subject) and adds contractAddress alongside the usual mappingSlot, storageKey, accountProof, storageProof, and storageHash.terms). “Not revoked as of block N” was the one part you had to take on our word. Now the whole verdict is checkable.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.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.erc8004_agent still does not support proofs.erc8004_agent and erc7710_delegation on POST /v1/attest 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.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.$0.05 for both agent types, the standard rate. (Superseded in part: erc7710_delegation later gained Merkle revocation proofs. See the entry above.)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.erc8004_agent and erc7710_delegation condition types to POST /v1/attest: 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.8453) only at launch, 1 credit, no Merkle proofs. Gated per key at ship time; that flag was removed the same day.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.token_balance (including tokenized-stock holdings), nft_ownership, ratio_to_amount, and ratio_to_supply on POST /v1/attest. 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.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.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.insumer-attest-v1 and insumer-attest-v2 signatures and re-derives conditionHash locally.source provenance tag).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.ratio_to_amount and ratio_to_supply on /v1/attestratio_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.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.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.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.Authorization: Wallet is now accepted on POST /v1/attest, POST /v1/trust, POST /v1/trust/batch, GET /v1/credits, and POST /v1/credits/buy. Other endpoints continue to return 501 for this scheme. An SBT-holding agent can now run the full read-side lifecycle — attest against conditions, generate wallet trust profiles, batch-profile counterparties, check own balance, and top up credits — without ever handling an API key.updateWallet: true on POST /v1/credits/buy is ignored for wallet-auth callers. The SIWE signer is already bound to the registered wallet, and the soulbound Insumer Access pass cannot follow a rotation, so honouring the rewrite would silently lock the caller out on the next sign-in. To rotate the registered wallet, use X-API-Key auth.X-API-Key flows are unchanged on every endpoint. Blog post: Your Agent Doesn't Need an API Key.0x3E2a408cc6eceba04FF9d04A5B8B05aBa8DD50ce) — went live on May 18. POST /v1/keys/buy now mints a pass to the EVM sender wallet on every purchase. The pass is the wallet's lifetime membership token, never expires, and cannot follow a rotation.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.Authorization: Wallet <base64(JSON({message, signature}))> where message is a SIWE string with domain api.insumermodel.com and signature is an EIP-191 personal_sign. Existing X-API-Key auth on /v1/attest is unaffected.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.wallet field; xdc... addresses are auto-normalized to 0x... form.tronWallet is supplied; existing Solana, XRPL, and Bitcoin optional dimensions carry forward.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).ledgerIndex + ledgerHash (parallel to XRPL); Sui carries checkpointSequence + checkpointDigest.draft-borthwick-wallet-state-attestation-00 to the IETF Datatracker. Individual submission, Informational, 19 pages, expires November 14, 2026. Archived .txt at ietf.org/archive/id.environment.* constraint family Internet-Draft (May 12) and other public adoption artifacts informatively.draft-borthwick-msebenzi-environment-state-00 to the IETF Datatracker. Independent Submission stream, Informational, 43 pages, expires November 12, 2026. Archived .txt at ietf.org/archive/id.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.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.token_balance, nft_ownership, eas_attestation (Coinbase Verified, Gitcoin Passport templates), and farcaster_id. Mix any of them in a single call@insumermodel/mppx-condition-gate. The previous package is deprecated on npm with a redirect; Tempo’s MPP extensions page entry update is open/v1/attest returning a signed-boolean attestation against an ERC-8183 envelope. Also authored Skye Meta’s case.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.eth_getProof.eth_getProof. No backend change; the documentation states it.blockHeight (integer) and blockHash (64-character hex) inside the ECDSA-signed payload — the Bitcoin chain tip at the time of wallet state observation.blockNumber+blockTimestamp on EVM, slot on Solana, ledgerIndex+ledgerHash on XRPL, blockHeight+blockHash on Bitcoin.POST /v1/attest, POST /v1/trust, POST /v1/trust/batch.AttestationResult and TrustCheck schemas updated with the new blockHeight and blockHash fields.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.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.POST /v1/attest, POST /v1/trust, POST /v1/trust/batch.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.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.POST /v1/attest, POST /v1/trust, POST /v1/trust/batch.AttestationResult and TrustCheck schemas updated with the new slot field.insumer-skill — Wallet Auth for Claude Codejose. Verified end-to-end on April 13.smithery skill add douglasborthwick/insumer-skill.@insumermodel/plugin-eliza v2.0.0 — Scoped Package Renameeliza-plugin-insumer to @insumermodel/plugin-eliza to match the elizaOS registry format convention (all entries in index.json use @org/plugin-name).@insumermodel/plugin-eliza@2.0.0. Same 10 actions, same source code, zero functional changes.eliza-plugin-insumer deprecated on npm pointing to the new name.npm install @insumermodel/plugin-eliza.type, fetches each issuer’s public key via standard JWKS, and verifies signatures independently.multi-attest-verify.js) resolves the JWKS, fetches a live attestation, and returns a verified result with no issuer cooperation beyond the published endpoints.agent-governance-vocabulary — Co-author of vocabulary.yamlvocabulary.yaml and sole author of the insumerapi.yaml crosswalk in aeoess/agent-governance-vocabulary, merged via PR #1./v1/trust for Counterparty Risk ScoringPOST /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 responsebitcoinWallet parameter on POST /v1/attest and GET /v1/trust. Supports P2PKH (1...), P2SH (3...), bech32 (bc1q...), and Taproot (bc1p...) addressesbitcoinWallet to add a native BTC balance check alongside stablecoins, governance, NFTs, staking, Solana, and XRPLdev.ucp.shopping.eligibility/v1/attest with Skye Meta’s SkyeWoo.@insumermodel/mppx-token-gate listed as the first entry on Tempo’s new Extensions page. Wraps any MPP Method.Server to grant free access to token holders — one API call checks ownership across 37 chains and returns a signed receipt/v1/attest for Pre-Transaction VerificationPOST /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 outmulti-attest-verify.js shipped in insumer-examples. Zero dependencies, supports ES256 (P-256) and EdDSA (Ed25519), handles both raw P1363 signatures and JWT compact JWSPOST /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 sessionPOST /v1/keys/buy. 10 free attestation calls per agentchannel parameter added to POST /v1/keys/buy for partner revenue share trackingPOST /v1/attest. Restrict product visibility and purchases based on wallet conditions. Wallet-verified discounts apply automatically at checkout. No coupon codes to leakPOST /v1/attest. Gate any page, post, or block with a shortcode. Connects MetaMask, Phantom, and Coinbase Wallet simultaneouslyPOST /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.provider_jwks / kid / payload / sig) now in the spec. Suggestions for kid field and full signed payload accepted by spec author.POST /v1/attest output maps directly to the extension wire format.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.currency field to token config for XRPL trust line support; refines ACP/UCP discount display to read correct response fields.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.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).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.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.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).POST /v1/attest with 4 conditions (USDC balance, Coinbase KYC, country verification, Gitcoin Passport) in a single API callerror.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.failedConditions array identifying which source and chain failed.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.RpcFailureEnvelope schema on all 5 endpoints.format: "jwt" parameter on POST /v1/attest returns an ES256-signed JWT bearer token alongside the standard attestation response. No additional cost.pass, results, conditionHash, blockNumber, and blockTimestamp. 30-minute expiry. Verifiable via JWKS at /.well-known/jwks.json or GET /v1/jwks.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.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.tslangchain-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 listacp-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 flowsinsumer-examples repo: added XRPL verification to Python, Node.js, and bash examples, added XRPL curl examples to READMEmcp-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 settingslangchain-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)openapi-gpt.yaml) updated with XRPL parameters across all endpoints and legacy server removedrGm7WCVp9gb4jZHWTEtGUr4dd74z2XuWhE) as second check in the XRPL trust dimension. Wallet trust profiles now support up to 20 checks across 6 dimensionsPOST /v1/attest call: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana, and XRP Ledger"xrpl" to OnboardingChainId enum in OpenAPI spec, enabling merchants to configure XRPL tokens via PUT /v1/merchants/:id/tokensxrplWallet parameter documentation to commerce (/v1/acp/discount, /v1/ucp/discount), verification, and API reference developer pagesnft_ownership validation: the currency field is now only required for token_balance conditions on trust line tokens.chainId: "xrpl"). Native XRP balance checks, trust line token verification (RLUSD, any issued token), and NFT ownership verificationxrplWallet 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/discountcurrency (XRPL currency code, auto hex-encoded) and taxon (optional NFT filter)ledgerIndex and ledgerHash (XRPL equivalent of block number/hash) for freshness and snapshot verificationmet: false for frozen trust lines even if balance exceeds threshold, with trustLineState: { frozen: true } in the resultopenapi.yaml, llms.txt, llms-full.txt, and all marketing/blog pages to reflect 32-chain supportapi.insumermodel.comversion: 1.0.0 to llms.txt and llms-full.txt for agent cache invalidationeas_attestation condition type with 5 pre-configured compliance templates: coinbase_verified_account, coinbase_verified_country, coinbase_one, gitcoin_passport_score, gitcoin_passport_activeGET /v1/compliance/templates endpoint for listing available templatesPOST /v1/acp/discount and POST /v1/ucp/discount for OpenAI/Stripe ACP and Google UCP commerce protocol integrationfarcaster_id condition type for social identity verification via IdRegistry on Optimism/developers/ into hub + 6 focused vertical pages: verification, trust, compliance, commerce, onboarding, api-referencemcp-server-insumer v1.2.0 and langchain-insumer v0.5.0 with EAS + compliance toolsPOST /v1/trust for ECDSA-signed wallet trust fact profiles across 4 dimensions (stablecoins, governance, NFTs, staking), 17 checks, 7 chainsPOST /v1/trust/batch for profiling up to 10 wallets per request. Shared block fetches make batch 5-8x faster than sequential callsGET /v1/jwks endpoint for public key discovery. Static JWKS also at /.well-known/jwks.jsonkid field added to all signed responses for key rotation supportevaluatedCondition and conditionHash (SHA-256) in attestation results for tamper-evidenceblockNumber (hex) and blockTimestamp (ISO 8601) in RPC chain results for freshness verificationinsumer-verify v1.1.3 published on npm: client-side ECDSA signature verification, condition hash checking, block freshness, and expiry validation. Zero dependenciesproof: "merkle" parameter on POST /v1/attest and POST /v1/trust/v1/discount/check and /v1/verify responses. Booleans only by defaultunsafe-eval from CSP script-src across all pagesX-API-Key authentication (insr_live_ prefix)POST /v1/attest, GET /v1/credits, POST /v1/credits/buy, and 8 merchant onboarding endpointsllms.txt, llms-full.txt, openapi.yaml, ai-plugin.jsonmcp-server-insumer published on npm. Listed on Official MCP Registry, awesome-mcp-servers, mcp.so, mcpservers.orglangchain-insumer published on PyPIframe-src, XSS hardening, email validation, rate limitingunsafe-inline from CSP script-srcrobots.txttranslate="no" on brand names site-wide