Insumer Trust

InsumerAPI Wallet Trust Profile

A curated condition bundle for a single wallet. Same primitive as insumer-attest (read → evaluate → sign), but the conditions are pre-defined — 44 base checks across 5 dimensions, with optional cross-chain extensions. Boolean, not balance, on every check.

Pick this skill when the developer wants a snapshot. Pick insumer-attest when they want to specify their own conditions.

What you get

• 44 base checks across 5 dimensions:
  • Stablecoins — USDC and USDT balances on each major EVM chain
  • Governance — major governance token holdings
  • NFTs — collection holdings
  • Staking — staked balances on major staking protocols
  • Institutional stablecoins — EURCV, USDCV, USDC, and BENJI across Ethereum, Solana, XRPL, Stellar, and Sui
• Optional extensions (when extra wallet addresses are provided):
  • Solana USDC — pass solanaWallet
  • XRPL stablecoins — pass xrplWallet (RLUSD + USDC checks)
  • Bitcoin holdings — pass bitcoinWallet (native BTC balance)
  • Tron USDT — pass tronWallet (USDT-TRC20)
• Up to 49 total checks across 27 chains when all extensions are included
• Each check returns its own boolean; the response includes per-dimension and overall summaries
• 3 credits standard, 6 credits with proof: "merkle"

Architectural property to preserve

Each dimension's check is signed with its original issuer's signature. There is no orchestrator-layer wrap over the aggregated response. If you build a multi-issuer trust envelope using this output, preserve that property — combine the per-dimension attestations as separate signed objects, never re-sign or wrap them under a single envelope signature.

Setup

export INSUMER_API_KEY='insr_live_...'

Reference values

• Endpoint: POST https://api.insumermodel.com/v1/trust
• Cost: 3 credits standard, 6 credits with proof: "merkle"
• Wallet pattern: wallet is required (EVM, 0x + 40 hex chars). Solana / XRPL / Bitcoin wallets are optional add-ons.
• Trust profile ID format: TRST-XXXXX (returned in data.trust.id)

Usage

Example 1: EVM-only profile

curl -X POST https://api.insumermodel.com/v1/trust \
  -H "X-API-Key: $INSUMER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
  }'

Response shape (abbreviated):

{
  "ok": true,
  "data": {
    "trust": {
      "id": "TRST-A1B2C",
      "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
      "conditionSetVersion": "v1",
      "dimensions": {
        "stablecoins": { "summary": "...", "checks": [...] },
        "governance":  { "summary": "...", "checks": [...] },
        "nfts":        { "summary": "...", "checks": [...] },
        "staking":     { "summary": "...", "checks": [...] }
      }
    },
    "sig": "...",
    "kid": "insumer-trust-v2"
  },
  "meta": {
    "creditsRemaining": ...,
    "creditsCharged": 3
  }
}

Example 2: With Solana USDC

curl -X POST https://api.insumermodel.com/v1/trust \
  -H "X-API-Key: $INSUMER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "solanaWallet": "5xY...solanaAddress"
  }'

Example 3: Multi-chain profile (EVM + Solana + XRPL + Bitcoin)

curl -X POST https://api.insumermodel.com/v1/trust \
  -H "X-API-Key: $INSUMER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "solanaWallet": "5xY...solanaAddress",
    "xrplWallet": "rN7n3473SaZBCG4dFL83w7p1W9cgPJqKro",
    "bitcoinWallet": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq"
  }'

Each provided wallet adds its dimension to the response.

Example 4: Merkle proofs (advanced)

curl -X POST https://api.insumermodel.com/v1/trust \
  -H "X-API-Key: $INSUMER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "proof": "merkle"
  }'

EIP-1186 Merkle storage proofs on stablecoin and governance checks. Costs 6 credits instead of 3, and reveals raw on-chain balances. Only opt in if the consumer explicitly needs the raw balances.

When to use trust profile vs. custom attest

For multiple wallets in one call, use insumer-trust-batch.

Code emission rules

1. Read the API key from an env var. Never inline.
2. Verify the signature offline. Use insumer-jwks-verify. The signed boolean(s) is the product.
3. Don't re-sign or wrap the dimension attestations. Each dimension carries its own issuer signature; aggregating them under a new envelope sig defeats the verification chain.
4. Don't cache the verdict. Cache the JWKS, not the trust profile result. Wallet state changes.
5. Backend only. The API key is a backend credential.

Helper script

scripts/trust.py — Python helper that wraps POST /v1/trust. Reads INSUMER_API_KEY from env, accepts --wallet, --solana, --xrpl, --bitcoin, --proof merkle.

python scripts/trust.py --wallet 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

Error handling

Related skills

References

• InsumerAPI OpenAPI spec
• Public JWKS
• Developer docs — trust profile