Create on-chain verification

EVM wallet address (0x...)

Solana wallet address (base58, 32-44 chars). Required if any condition uses chainId "solana".

XRPL wallet address (classic r-address). The base58 checksum is verified; an address that fails it returns 400 rather than a signed not-met result.

Bitcoin address (P2PKH, P2SH, bech32, or Taproot). Required if any condition uses chainId "bitcoin".

Tron address (T-prefix, base58, 34 chars). Required if any condition uses chainId "tron". Tron supports TRC-20 (e.g. USDT) and native TRX via contractAddress "native".

Stellar address (G-prefix StrKey, 56 chars; the checksum is verified). Required if any condition uses chainId "stellar". Stellar checks measure classic-account balances (trustlines + native XLM); Soroban contract-held balances are out of scope. Trustline conditions require both contractAddress (G-issuer) and assetCode.

Sui address (0x + 64 hex chars, 32-byte). Required if any condition uses chainId "sui". Coin type goes in contractAddress (e.g., "0x2::sui::SUI" for native, or "<package>::<module>::<TYPE>" for any other coin). Response envelope surfaces checkpointSequence as the temporal anchor.

Set to "merkle" to include EIP-1186 Merkle storage proofs in results. Proofs are attempted for token_balance and ratio_to_amount conditions on all 31 EVM chains (a ratio_to_amount proof proves the same ERC-20 balance slot), and returned for erc7710_delegation conditions on DelegationManagers whose storage layout has been verified on-chain (currently the v1.3.0 manager on Base). A delegation proof carries subject: "delegation_revocation" and proves the value of disabledDelegations[delegationHash] against the anchored block's state root — so "not revoked as of block N" becomes checkable rather than taken on the API's word. Where a chain cannot serve a proof, or the token's storage slot cannot be discovered (a zero ERC-20 balance whose slot is not yet known, or a non-standard storage layout), the result carries proof.available: false with a reason instead. In practice 27 of the 31 EVM chains serve proofs today; ZKsync Era (324), Sei (1329), Viction (88) and XDC Network (50) do not. Always unavailable: nft_ownership, eas_attestation, farcaster_id, ratio_to_supply, and erc8004_agent conditions; conditions on Solana, XRPL, Bitcoin, Tron, Stellar, and Sui; and delegations against a manager whose layout has not been verified (an inferred slot would yield a proof of the wrong location that still verifies against the header, which is worse than no proof). Costs 2 credits instead of 1; whenever no proof is delivered the premium is refunded and the request costs 1, whatever the reason: a read that did not complete, a chain or token that cannot carry a proof, or a condition type that has none. A condition with contractAddress "native" carries an ACCOUNT proof (subject "account_balance") instead of a storage proof. An account_code condition carries an account proof too (subject "account_code"): its codeHash field is the proven value, which a verifier compares with the hash the expected state implies (keccak256 of empty code for "none", keccak256 of 0xef0100 followed by the delegate the verifier supplies for "eip7702", anything else for "contract"); an account absent from the state trie may report codeHash as all zeros, which also means no code. Note: in proof mode the account record's fields (balance, nonce, storageHash, codeHash) reach the caller; on a token_balance condition that is the raw on-chain balance (standard mode never returns it).

Set to "jwt" to include a Wallet Auth by InsumerAPI token (ES256-signed JWT) in the response. The JWT contains the attestation data as standard claims (iss, sub, jti, iat, exp) plus pass, results, conditionHash, blockNumber, and blockTimestamp. sub is the wallet a condition in the request evaluated. 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; the other families' wallets are evaluated but not named by sub. format "jwt" needs at least one condition that evaluates a wallet. The exp claim matches the attestation's expiresAt: iat + 1800 (30 minutes), or iat + 300 (5 minutes) when the request contains an erc7710_delegation condition, so a JWT never outlives the attestation it carries. Verifiable by any standard JWT library using the JWKS at https://insumermodel.com/.well-known/jwks.json. No additional cost.

Controls whether decoded caveat limits ride along with erc7710_delegation results. Default (field absent, or "include"): declaredLimits are returned inside the signed results, and therefore also travel inside the portable JWT when format: "jwt" is used. Set to "omit" and the decoded limits are left out; the result carries declaredLimitsOmitted: true instead. Use "omit" when the attestation will be FORWARDED to third parties and the principal's spending ceiling should not travel with it — a delegation attestation in JWT form is portable, so by default the declared limits reach anyone it is passed to. That is usually what you want (a relying party needs the limits to act), but not always. The caller loses nothing by omitting: it submitted the caveats and already holds them. Critically, met, delegationHash, and conditionHash are byte-identical either way — a forwarded token still commits to exactly which delegation was checked, and a holder can verify a limit shown to them out-of-band without ever learning one from the token. No effect on any other condition type. No additional cost.