Update to InsumerAPI

{
  "description": "InsumerAPI wallet trust profile: a curated multi-dimensional condition-based access bundle for a single wallet. 155 base checks across 27 chains in 10 dimensions (stablecoins, governance, NFTs, staking, institutional stablecoins, tokenized treasuries, stablecoin deposits, wrapped bitcoin, names, account), plus optional Solana, XRPL, Bitcoin and Tron dimensions (up to 176 checks across 29 chains in 14 dimensions). Use when the user wants an InsumerAPI trust profile, a pre-built signed wallet snapshot rather than conditions specified one by one (for example an InsumerAPI pre-transaction trust check). The profile is signed once, as a whole. Carry it unchanged: never re-sign or wrap it.\n",
  "included_files": [
    {
      "relative_path": "scripts/trust.py",
      "size_in_bytes": 2861
    }
  ],
  "name": "insumer-trust",
  "skill_md_contents": "---\nname: insumer-trust\ndescription: >\n  InsumerAPI wallet trust profile: a curated multi-dimensional condition-based\n  access bundle for a single wallet. 155 base checks across 27 chains in 10\n  dimensions (stablecoins, governance, NFTs, staking, institutional\n  stablecoins, tokenized treasuries, stablecoin deposits, wrapped bitcoin,\n  names, account), plus optional Solana, XRPL, Bitcoin and Tron dimensions (up\n  to 176 checks across 29 chains in 14 dimensions). Use when the user wants an InsumerAPI\n  trust profile, a pre-built signed wallet snapshot rather than conditions\n  specified one by one (for example an InsumerAPI pre-transaction trust check). The profile is signed once, as a whole. Carry it unchanged:\n  never re-sign or wrap it.\nmetadata:\n  version: \"0.3.1\"\n  author: InsumerAPI\n---\n\n# InsumerAPI Wallet Trust Profile\n\nA curated condition bundle for a single wallet. Same primitive as `insumer-attest` (read → evaluate → sign), but the conditions are pre-defined: 155 base checks across 27 chains in 10 dimensions, with optional cross-chain extensions. **Boolean, not balance, on every check.** Every row is a presence check.\n\nPick this skill when the developer wants a snapshot. Pick `insumer-attest` when they want to specify their own conditions.\n\n## What you get\n\n- **155 base checks** across **27 chains** in **10 dimensions** (23 EVM chains plus the Solana, XRPL, Stellar and Sui rows inside the base dimensions):\n  - **Stablecoins** (52): USDC, USDT, OUSD, PYUSD, USDG, USD1, RLUSD, USDS, DAI and EURC across 23 EVM chains, including USDC on Arc and USDG on Robinhood Chain\n  - **Governance** (8): UNI, AAVE, ENS, LDO, SKY and COMP on Ethereum, ARB on Arbitrum, OP on Optimism\n  - **NFTs** (3): BAYC, Pudgy Penguins, Wrapped CryptoPunks\n  - **Staking** (5): stETH, rETH, cbETH, wstETH, weETH\n  - **Institutional stablecoins** (8): EURCV, USDCV, USDC, and BENJI across Ethereum, Solana, XRPL, Stellar, and Sui. Always present; the Solana, XRPL, Stellar and Sui entries are evaluated only when the matching wallet is supplied, and are otherwise marked `evaluated: false`\n  - **Tokenized treasuries** (16): BUIDL, USYC, OUSG, USTB, USDY (the USDY on Sui row needs `suiWallet`, otherwise `evaluated: false`)\n  - **Stablecoin deposits** (39): Aave v3 aUSDC/aUSDT, sUSDS, sDAI, listed Morpho USDC vaults\n  - **Wrapped bitcoin** (12): cbBTC, WBTC, tBTC\n  - **Names** (2): ENS .eth, Basenames\n  - **Account** (10): two rows per chain on Ethereum, Base, Arbitrum, Optimism and Polygon. \"Contract code on X\" is met when bytecode other than the EIP-7702 delegation designator is at the wallet address; \"EIP-7702 delegation on X\" is met when the designator is there. The two are exclusive per chain; a plain key account reads false on both. Which contract is never named; to require a specific delegation target, send `delegate` with an `account_code` condition in `insumer-attest` (the answer is still yes or no). Each row's `evaluatedCondition` is `{type: \"account_code\", chainId, expect, operator: \"code_state\"}`, hashed exactly like the equivalent attest condition\n- **Optional extensions** (when extra wallet addresses are provided):\n  - **Solana** (14): pass `solanaWallet` (USDC, EURC, OUSD, PYUSD, USD1, USDG, USDS, BUIDL, USDY, WBTC, cbBTC, tBTC, JitoSOL, mSOL on Solana)\n  - **XRPL** (3): pass `xrplWallet` (RLUSD, USDC, OUSG)\n  - **Bitcoin** (1): pass `bitcoinWallet` (native BTC)\n  - **Tron** (3): pass `tronWallet` (USDT, USD1, WBTC)\n  - **Stellar / Sui**: pass `stellarWallet` / `suiWallet`. These add no checks and no dimension; they let the Stellar and Sui rows inside the base dimensions be evaluated\n- Up to 176 total checks across 29 chains in 14 dimensions when all extensions are included\n- Each check returns its own boolean; the response includes per-dimension and overall summaries\n- Dimension order is fixed: the base dimensions in the order above (`stablecoins`, `governance`, `nfts`, `staking`, `institutional_stablecoins`, `tokenized_treasuries`, `stablecoin_deposits`, `wrapped_bitcoin`, `names`, `account`), then whichever of `solana`, `xrpl`, `bitcoin`, `tron` were switched on, in that order\n- `conditionSetVersion` is a dated set id (currently `\"2026-10-08\"`), the same on every key version, signed with the profile. It names the check list that was run: log it, never reject on it\n- 3 credits standard, 6 credits with `proof: \"merkle\"`\n\n## Architectural property to preserve\n\nThe whole trust profile is signed once by InsumerAPI: one `sig` covers the entire `trust` object. The response is signed twice: ES256 (`sig`, `kid`) and a post-quantum ML-DSA-65 signature (`pqSig`, `pqKid`, optional fields: check them when present). The `kid` is `insumer-trust-v2` on v2 keys and `insumer-attest-v1` on v1 keys: read it from the response, never assume it. There are no per-dimension or per-check signatures. **Do not add an orchestrator-layer wrap.** If you build a multi-issuer trust envelope that includes this profile, carry the signed object exactly as issued, beside the other issuers' signed objects, and never re-sign it or wrap it under a new envelope signature. Verifiers should be able to check InsumerAPI's signature directly against its JWKS.\n\n## Setup\n\n```bash\nexport INSUMER_API_KEY='insr_live_...'\n```\n\n## Reference values\n\n- **Endpoint**: `POST https://api.insumermodel.com/v1/trust`\n- **Cost**: 3 credits standard, 6 credits with `proof: \"merkle\"`\n- **Wallet pattern**: `wallet` is required (EVM, `0x` + 40 hex chars). `solanaWallet`, `xrplWallet`, `bitcoinWallet`, `tronWallet`, `stellarWallet` (G-address) and `suiWallet` (`0x` + 64 hex chars) are optional add-ons.\n- **Trust profile ID format**: `TRST-XXXXX` (returned in `data.trust.id`)\n\n## Usage\n\n### Example 1: EVM-only profile\n\n```bash\ncurl -X POST https://api.insumermodel.com/v1/trust \\\n  -H \"X-API-Key: $INSUMER_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"wallet\": \"0x1601843c5E9bC251A3272907010AFa41Fa18347E\"\n  }'\n```\n\nResponse shape (abbreviated; the counts are from a real profile of this wallet, a contract on all five account chains):\n\n```json\n{\n  \"ok\": true,\n  \"data\": {\n    \"trust\": {\n      \"id\": \"TRST-81224\",\n      \"wallet\": \"0x1601843c5E9bC251A3272907010AFa41Fa18347E\",\n      \"conditionSetVersion\": \"2026-10-08\",\n      \"dimensions\": {\n        \"stablecoins\":               { \"checks\": [...], \"passCount\": 6, \"failCount\": 46, \"notEvaluatedCount\": 0, \"total\": 52 },\n        \"governance\":                { \"checks\": [...], \"passCount\": 0, \"failCount\": 8,  \"notEvaluatedCount\": 0, \"total\": 8 },\n        \"nfts\":                      { \"checks\": [...], \"passCount\": 0, \"failCount\": 3,  \"notEvaluatedCount\": 0, \"total\": 3 },\n        \"staking\":                   { \"checks\": [...], \"passCount\": 0, \"failCount\": 5,  \"notEvaluatedCount\": 0, \"total\": 5 },\n        \"institutional_stablecoins\": { \"checks\": [...], \"passCount\": 0, \"failCount\": 2,  \"notEvaluatedCount\": 6, \"total\": 8 },\n        \"tokenized_treasuries\":      { \"checks\": [...], \"passCount\": 0, \"failCount\": 15, \"notEvaluatedCount\": 1, \"total\": 16 },\n        \"stablecoin_deposits\":       { \"checks\": [...], \"passCount\": 5, \"failCount\": 34, \"notEvaluatedCount\": 0, \"total\": 39 },\n        \"wrapped_bitcoin\":           { \"checks\": [...], \"passCount\": 0, \"failCount\": 12, \"notEvaluatedCount\": 0, \"total\": 12 },\n        \"names\":                     { \"checks\": [...], \"passCount\": 0, \"failCount\": 2,  \"notEvaluatedCount\": 0, \"total\": 2 },\n        \"account\":                   { \"checks\": [...], \"passCount\": 5, \"failCount\": 5,  \"notEvaluatedCount\": 0, \"total\": 10 }\n      },\n      \"summary\": { \"totalChecks\": 155, \"totalPassed\": 16, \"totalFailed\": 132, \"totalNotEvaluated\": 7, \"dimensionsWithActivity\": 3, \"dimensionsChecked\": 10 },\n      \"profiledAt\": \"2026-10-07T21:53:04.795Z\",\n      \"expiresAt\": \"2026-10-07T22:23:04.795Z\"\n    },\n    \"sig\": \"...\",\n    \"kid\": \"insumer-trust-v2\",\n    \"pqSig\": \"...\",\n    \"pqKid\": \"insumer-trust-pq1\"\n  },\n  \"meta\": {\n    \"creditsRemaining\": ...,\n    \"creditsCharged\": 3\n  }\n}\n```\n\nThe first two `account` rows of that profile, as signed:\n\n```json\n{\"label\":\"Contract code on Ethereum\",\"chainId\":1,\"met\":true,\"evaluatedCondition\":{\"type\":\"account_code\",\"chainId\":1,\"expect\":\"contract\",\"operator\":\"code_state\"},\"conditionHash\":\"0xfd7b6aa42eb012184fa54d9d5d99c6ab18481e0ce33ec0ec0e9d28d37b54ccbc\",\"blockNumber\":\"0x18eea5a\",\"blockTimestamp\":\"2026-10-07T21:52:59.000Z\"}\n{\"label\":\"EIP-7702 delegation on Ethereum\",\"chainId\":1,\"met\":false,\"evaluatedCondition\":{\"type\":\"account_code\",\"chainId\":1,\"expect\":\"eip7702\",\"operator\":\"code_state\"},\"conditionHash\":\"0xdef6fadcef95f59f4621fa2bf788e6be0ffc0492dba22038999b8cd757adf18b\",\"blockNumber\":\"0x18eea5a\",\"blockTimestamp\":\"2026-10-07T21:52:59.000Z\"}\n```\n\n### Example 2: With a Solana wallet\n\n```bash\ncurl -X POST https://api.insumermodel.com/v1/trust \\\n  -H \"X-API-Key: $INSUMER_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"wallet\": \"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\",\n    \"solanaWallet\": \"DXK4yMpigbTSqv33nJk1tJucXB4E3rDmTXn3yZmiFAXt\"\n  }'\n```\n\n### Example 3: Multi-chain profile (EVM + Solana + XRPL + Bitcoin)\n\n```bash\ncurl -X POST https://api.insumermodel.com/v1/trust \\\n  -H \"X-API-Key: $INSUMER_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"wallet\": \"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\",\n    \"solanaWallet\": \"DXK4yMpigbTSqv33nJk1tJucXB4E3rDmTXn3yZmiFAXt\",\n    \"xrplWallet\": \"rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH\",\n    \"bitcoinWallet\": \"bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq\"\n  }'\n```\n\nEach provided Solana, XRPL, Bitcoin or Tron wallet adds its dimension to the response. A Stellar or Sui wallet (`stellarWallet`, `suiWallet`) adds no dimension; it lets the matching rows inside the base dimensions be evaluated instead of marked `evaluated: false`: the Stellar and Sui institutional-stablecoin entries, and for Sui also USDY on Sui in tokenized treasuries.\n\n### Example 4: Merkle proofs (advanced)\n\n```bash\ncurl -X POST https://api.insumermodel.com/v1/trust \\\n  -H \"X-API-Key: $INSUMER_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"wallet\": \"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\",\n    \"proof\": \"merkle\"\n  }'\n```\n\nAn EVM token row carries an EIP-1186 storage proof when its balance slot can be discovered. Computed-balance rows (Aave aTokens, BUIDL), rows with non-standard storage layouts, and rows on chains that serve no proofs are declined with a reason; NFT and non-EVM rows are declined; `account` rows carry `proof.available: false` with a reason pointing at `/v1/attest`, where an `account_code` condition in proof mode carries the account proof; unevaluated checks carry no proof key. **Costs 6 credits** instead of 3; the premium is refunded whenever no proof could be delivered. Proofs reveal raw on-chain balances. Only opt in if the consumer explicitly needs the raw balances.\n\n## When to use trust profile vs. custom attest\n\n| User asks for... | Use |\n|---|---|\n| \"Verify this wallet holds X on chain Y\" | `insumer-attest` |\n| \"Gate by USDC balance on Base\" | `insumer-attest` |\n| \"Pre-transaction trust check\" | `insumer-trust` |\n| \"Show me what this wallet holds across chains\" | `insumer-trust` |\n| \"Multi-dimensional wallet profile\" | `insumer-trust` |\n| \"Should I transact with this wallet\" | `insumer-trust` |\n\nFor multiple wallets in one call, use `insumer-trust-batch`.\n\n## Code emission rules\n\n1. **Read the API key from an env var.** Never inline.\n2. **Verify the signature offline.** Use `insumer-jwks-verify`. The signed boolean(s) is the product.\n3. **Don't re-sign or wrap the profile.** One InsumerAPI signature covers the whole `trust` object; placing it under a new envelope signature defeats the verification chain. A check whose wallet was not supplied is marked `evaluated: false` and counted in `totalNotEvaluated`, never as a failure.\n4. **Don't cache the verdict.** Cache the JWKS, not the trust profile result. Wallet state changes.\n5. **Backend only.** The API key is a backend credential.\n\n## Helper script\n\n`scripts/trust.py`: Python helper that wraps `POST /v1/trust`. Reads `INSUMER_API_KEY` from env, accepts `--wallet`, `--solana`, `--xrpl`, `--bitcoin`, `--tron`, `--stellar`, `--sui`, `--proof merkle`.\n\n```bash\npython scripts/trust.py --wallet 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\n```\n\n## Error handling\n\n| Status | Cause | Fix |\n|---|---|---|\n| `400` | Missing `wallet` or invalid format | EVM wallet `^0x[a-fA-F0-9]{40}$` is required |\n| `401` | Invalid API key | See `insumer-auth` |\n| `402` | With a key: out of credits. With no key at all: a pay-per-call quote, not a credit problem | With a key, top up via Path 4 in `insumer-auth`. With no key, set `INSUMER_API_KEY` and call again |\n| `429` | Daily request limit reached | It resets on a timer, not by slowing down: wait the number of seconds in the `Retry-After` header |\n| `503` | Upstream blockchain data source unavailable | Retryable; no credits charged |\n\nA `503` carries error code `rpc_failure`. It means a read did not complete and nothing was signed. It is never a `false`: do not report it as a check that was not held. Retry the call.\n\n## Related skills\n\n| Skill | Purpose |\n|---|---|\n| `insumer-auth` | API key creation, top-up |\n| `insumer-attest` | Custom condition (pick this if not using the curated bundle) |\n| `insumer-trust-batch` | Same primitive for multiple wallets in one call |\n| `insumer-jwks-verify` | Offline ES256 verification |\n\n## References\n\n- [InsumerAPI OpenAPI spec](https://insumermodel.com/openapi.yaml)\n- [Public JWKS](https://insumermodel.com/.well-known/jwks.json)\n- [Developer docs: trust profile](https://insumermodel.com/developers/trust/)\n"
}