v2.4: Multi-chain attestation expansion (ENS, OP, ARB, stETH)

[jacobsd32-cpu]

Summary

Expand the Insumer attestation from a single Base USDC check to 5 multi-chain token conditions in a single request. Designed in collaboration with @douglasborthwick-crypto in #3.

Design (confirmed with InsumerAPI)

Single POST /v1/attest with conditions array. One ECDSA signature covers all conditions. 1 credit per request ($0.04 total) — regardless of how many conditions (up to 10). Parallel RPC queries — latency = slowest chain.

Proposed Weight Table

Token	Chain	ChainId	Contract	Signal	Weight
USDC (>= 0)	Base	8453	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	DeFi proof-of-existence	3 pts
ENS (>= 1)	Ethereum	1	0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72	Governance participation	3 pts
OP (>= 1)	Optimism	10	0x4200000000000000000000000000000000000042	L2 governance	3 pts
ARB (>= 1)	Arbitrum	42161	0x912CE59144191C1204E64559FE8253a0e49E6548	L2 governance	3 pts
stETH (> 0)	Ethereum	1	0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84	Long-term staking	3 pts

Total: 15 pts (same as v2.3 Insumer allocation — no rebalancing needed)

Architecture

• Iterate results[i].met from the response and apply per-token weights
• Individual booleans with independent weights (maps directly to per-condition results[] array)
• Use label field for debug logging (no contract address lookup table needed)

Request Shape (confirmed by Douglas)

{
  "wallet": "0x...",
  "conditions": [
    { "type": "token_balance", "chainId": 8453, "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "threshold": 0, "decimals": 6, "label": "USDC on Base >= 0" },
    { "type": "token_balance", "chainId": 1, "contractAddress": "0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72", "threshold": 1, "decimals": 18, "label": "ENS >= 1" },
    { "type": "token_balance", "chainId": 10, "contractAddress": "0x4200000000000000000000000000000000000042", "threshold": 1, "decimals": 18, "label": "OP >= 1" },
    { "type": "token_balance", "chainId": 42161, "contractAddress": "0x912CE59144191C1204E64559FE8253a0e49E6548", "threshold": 1, "decimals": 18, "label": "ARB >= 1" },
    { "type": "token_balance", "chainId": 1, "contractAddress": "0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84", "threshold": 0, "decimals": 18, "label": "stETH > 0" }
  ]
}

Alternative: /v1/trust Profiles

Douglas noted a new option: POST /v1/trust — wallet trust profiles across 14 curated checks (stablecoins on 7 chains, governance tokens UNI/AAVE/ARB/OP, NFTs). 3 credits ($0.12), ECDSA-signed. Also POST /v1/trust/batch for up to 10 wallets with shared block fetches (5-8x faster).

Tradeoff:

• /v1/attest (1 credit): We choose exact tokens and thresholds — maps directly to our weight table
• /v1/trust (3 credits): Pre-built cross-chain profile with per-dimension pass/fail counts — richer signal but less control

Potential hybrid: use /v1/trust for initial scoring (richer data), fall back to /v1/attest for targeted checks. Decision depends on whether trust response includes individual check results.

Future: Merkle Proof Tier

After multi-chain is stable, add optional Merkle proof support for enterprise consumers who want to verify Identity inputs against stateRoot independently. Two demand verticals: compliance platforms (audit trails) and multi-agent orchestration (trust-minimized verification).

Prerequisites

• Let v2.3 run for a period to collect real attestation data
• Confirm credit pricing with Insumer for 4-condition requests ✅ Confirmed by Douglas: 1 credit per request
• Case study published first (avoid moving target) ✅ Published

References

• Design thread: Integration: InsumerAPI token attestation as Identity dimension signal #3
• insumer-verify: https://www.npmjs.com/package/insumer-verify
• InsumerAPI docs: https://insumermodel.com/developers

[douglasborthwick-crypto]

Good design. A couple of things to confirm before you build:

Credit pricing is better than you think. POST /v1/attest is 1 credit per request, not per condition. Your 4-condition expansion is still 1 credit ($0.04) total — same as the current single USDC check. Up to 10 conditions per request at the same price.

Request shape looks correct. One thing: your weight table has stETH but the JSON example has ARB. Both can go in the same request — you have room for up to 10 conditions, so you could include all 5 (USDC, ENS, OP, ARB, stETH) for the same 1 credit.

New option since #3: POST /v1/trust. We just shipped wallet trust profiles — you send a wallet address, you get back a structured fact profile across 14 curated checks (stablecoins on 7 chains, governance tokens including UNI/AAVE/ARB/OP, and NFTs). Single call, 3 credits ($0.12), independently ECDSA-signed. There's also POST /v1/trust/batch for profiling up to 10 wallets in one request (significantly faster than sequential calls).

Depending on how you want to weight things, trust profiles might give you a richer Identity signal without hand-picking conditions. The tradeoff: attest lets you choose exact tokens and thresholds; trust gives you a pre-built cross-chain profile with per-dimension pass/fail counts.

One more: the docs URL is insumermodel.com/developers (not docs.insumermodel.com).

[jacobsd32-cpu]

Thanks Douglas — this is really useful clarification.

Pricing correction noted. We had it backwards in the issue description — updating the spec to reflect 1 credit per request (not per condition). That changes the cost picture significantly: all 5 conditions (USDC, ENS, OP, ARB, stETH) for $0.04 total. No reason not to include them all.

Updated request shape. Will add stETH as a 5th condition alongside the existing four. The weight table already had it — we just hadn't included it in the example JSON. Corrected in our implementation plan.

POST /v1/trust is interesting. 14 curated checks across 7 chains for 3 credits ($0.12) is a compelling alternative to hand-picking conditions. The tradeoff you described maps well to our scoring dimensions:

• /v1/attest (1 credit): Better for the specific Identity signals we weight — we control exactly which tokens and thresholds map to our scoring model
• /v1/trust (3 credits): Better for a broader signal that could feed into multiple dimensions. The per-dimension pass/fail counts could potentially enrich both Identity and Reliability scoring

Thinking about this more — we could potentially use both:

1. Default path: /v1/trust for the initial score (richer data, one call)
2. Targeted path: /v1/attest for specific high-signal tokens that aren't covered by the trust profile's 14 checks

Would be helpful to know: does the /v1/trust response include the individual check results (which tokens passed/failed), or just the aggregate pass/fail counts per dimension? That'll determine whether we can map it cleanly to our weight table.

Also: /v1/trust/batch for 10 wallets at once could be very useful for our leaderboard refresh cycle, where we re-score the top agents periodically. Good to know that exists.

Docs URL fixed — will update to insumermodel.com/developers.

Thanks for the heads up on the new endpoints. This gives us more options for the integration design.

[douglasborthwick-crypto]

Yes — individual check results, not just aggregates. Each dimension returns a checks array where every token has its own met boolean. Here's the structure (trimmed):

"dimensions": {
  "stablecoins": {
    "checks": [
      { "label": "USDC on Ethereum", "chainId": 1, "met": true, "conditionHash": "0x3a7f..." },
      { "label": "USDC on Base", "chainId": 8453, "met": false, "conditionHash": "0x9b2c..." },
      { "label": "USDT on Ethereum", "chainId": 1, "met": true, "conditionHash": "0x..." }
    ],
    "passCount": 3, "failCount": 4, "total": 7
  },
  "governance": {
    "checks": [
      { "label": "UNI on Ethereum", "chainId": 1, "met": true, "conditionHash": "0x..." },
      { "label": "ARB on Arbitrum", "chainId": 42161, "met": false, "conditionHash": "0x..." }
    ],
    "passCount": 2, "failCount": 2, "total": 4
  },
  "nfts": {
    "checks": [
      { "label": "BAYC on Ethereum", "chainId": 1, "met": false, "conditionHash": "0x..." }
    ],
    "passCount": 0, "failCount": 3, "total": 3
  }
}

So you can map individual checks directly to your weight table — e.g. pull governance.checks where label contains "ARB" or "OP" and read the met value. Each check also includes conditionHash (SHA-256 of the evaluated condition) and blockNumber/blockTimestamp for auditability.

The hybrid approach you described makes sense:

• /v1/trust for the initial score — you get 14 checks across stablecoins, governance, and NFTs in one call, and can cherry-pick the individual results that map to your dimensions
• /v1/attest for anything outside the curated 14 — e.g. stETH, which isn't in the trust profile's default condition set

For the leaderboard refresh — /v1/trust/batch accepts up to 10 wallets per call at the same 3 credits/wallet rate. It's significantly faster than 10 individual calls. Returns results in input order, with partial success (failed wallets return an error object without consuming credits).

Full response schema is in the OpenAPI spec under TrustProfile if you want the complete field list.