Verification is not a chain-specific problem. It is a condition evaluated against state, returned as a signed result. No node. No indexer. No UTXO parsing. Just a signed boolean.

The problem: every chain stores data differently

Blockchains do not agree on how data is stored.

EVM chains use accounts. Solana uses program state. XRPL uses trust lines. Bitcoin uses UTXOs.

Four fundamentally different data models. Four different query patterns. Four different ways to answer the same question: "Does this wallet meet a condition?"

If you are building verification into your system, you should not need to care about any of this. The question is the same everywhere. The answer should be too.

The primitive

Wallet auth reduces every chain to the same operation: condition in, signed boolean out.

Send a wallet and a condition. Get a signed boolean. No balances exposed. No chain-specific code. The same privacy-by-design model as every other chain.

Every system that interacts with wallets eventually needs to answer this question. The interface should not change when the underlying architecture does. Wallet auth reduces this to a single primitive across all chain architectures.

Bitcoin is the worst-case scenario for verification

No accounts. No balance calls. No standard query pattern. The concept of "balance" does not exist natively in Bitcoin. It is derived by aggregating unspent transaction outputs across the entire chain history.

If the same interface works here, it works everywhere.

And it does. The request is identical:

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{
    "bitcoinWallet": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq",
    "conditions": [{
      "type": "token_balance",
      "contractAddress": "native",
      "chainId": "bitcoin",
      "threshold": 0.01
    }]
  }'

Same structure as Ethereum. Same structure as Solana. Same structure as XRPL. The same endpoint used to verify token holdings on any chain. The response is ECDSA-signed with conditionHash for tamper detection. Add "format": "jwt" for a standard JWT bearer token verifiable by Kong, Nginx, Cloudflare Access, or AWS API Gateway via the JWKS endpoint.

All four Bitcoin address formats are supported: P2PKH (1...), P2SH (3...), bech32/SegWit (bc1q...), and Taproot/bech32m (bc1p...). Taproot is the default in Phantom, Coinbase Wallet, and MetaMask.

Why this matters now

Three things converged:

  1. Wallets shipped Bitcoin support. Phantom, Coinbase Wallet, and MetaMask all added native BTC. Users already have Bitcoin addresses in the same wallets they use for EVM and Solana.
  2. Agents are settling in BTC. AI agents increasingly use bitcoin for autonomous payments. Verifying that an agent holds BTC before it transacts is the same problem wallet auth already solves for ERC-20 tokens.
  3. Bitcoin is the chain people recognize. "Prove you hold 0.1 BTC" is the single most intuitive example of wallet auth you can give to someone who has never heard of ERC-20 or SPL tokens.

Trust profiles

The wallet trust endpoint now includes a Bitcoin Holdings dimension. Pass bitcoinWallet alongside your EVM wallet, and the trust profile adds a native BTC presence check to its existing stablecoins, governance, NFTs, and staking dimensions.

For AI agent trust scoring, this adds a meaningful signal: an agent that holds BTC alongside stablecoins and governance tokens presents a different risk profile than one with an empty wallet.

Scope

This release covers native BTC balance. Confirmed transactions only, consistent with XRPL's validated-ledger pattern. We intentionally excluded BRC-20, Ordinals, Runes (evolving standards, no stable indexing), Lightning Network (off-chain, not queryable), and Merkle/SPV proofs (structurally different from EIP-1186).

The primary use case is covered: "does this wallet hold bitcoin?" That question now has a cryptographically signed answer.

Available everywhere

Bitcoin support is live across the full stack:

30 EVM chains + Solana + XRP Ledger + Bitcoin = 33 chains. Four chain architectures. One interface. One signature format.

Verification is not a chain-specific problem.

Blockchains made writing permanent. Wallet auth makes reading them verifiable.

Try it now

InsumerAPI is free to start. Get an API key with 10 verification credits and test Bitcoin wallet auth in under a minute.

View API Docs