Integration: On-chain wallet attestation as cold-start signal

[douglasborthwick-crypto]

Context

AgentKarma's 7-signal scoring model is built on behavioral history — Loyalty, Activity, Diversity, Feedback, Volume, Recency, Age. Strong for wallets with transaction history, but new wallets score zero across all signals until they accumulate enough on-chain activity.

This is the cold-start problem: a legitimate operator with a well-funded wallet full of governance tokens and staking positions scores the same as a sybil wallet that was created 5 minutes ago.

Proposal

InsumerAPI provides a cold-start signal via on-chain wallet attestation. A single API call returns an ECDSA-signed wallet trust profile — 17 checks across 4 dimensions (stablecoins, governance tokens, NFTs, staking positions) on 31 EVM chains:

curl -X POST https://api.insumermodel.com/v1/trust \
  -H "X-API-Key: $KEY" \
  -d '{ "wallet": "0x..." }'

Response includes per-dimension passCount/failCount and per-check met booleans. A wallet holding USDC on 3 chains, UNI, and stETH gets a different profile than an empty wallet — before any behavioral history exists.

This could map to a bonus signal in your scoring algorithm (similar to the +5 ERC-8004 bonus), or as an 8th weighted component alongside the existing 7.

Why it fits

• Sybil-resistant: token holdings cost real capital to fake
• Instant: no history required, works on day-zero wallets
• Multi-chain: 31 EVM chains vs your current 3 (ETH, Base, Arbitrum) — the trust profile covers all of them in one call
• Signed: ECDSA P-256, verifiable via JWKS at /.well-known/jwks.json
• Cached: 30-min TTL, so you don't need to re-check on every score request

Also available as a compliance check for Coinbase KYC and Gitcoin Passport attestations — relevant for the Feedback signal (attested wallets are more trustworthy raters).

Integration effort

One HTTP call added to the scoring pipeline. OpenAPI spec | MCP server | npm SDK for client-side signature verification.

Happy to set up a test API key with 500 credits. DJD Agent Score already integrates InsumerAPI in their Identity dimension — similar pattern, same cold-start problem solved.

[rushikeshmore]

Hey @douglasborthwick-crypto — this is exactly the right problem to solve. The cold-start gap is real: a well-funded whale wallet with governance tokens and staking positions scores the same 0 as a fresh sybil wallet. That's wrong.

Wallet attestation across 31 EVM chains would give us a pre-behavioral trust signal that's hard to fake — you can't easily mint governance tokens or build staking positions for thousands of wallets.

Here's how I'd think about integrating this:

1. As an 8th scoring signal — attestation_score weighted alongside the existing 7 signals. Probably 8-12% weight, taking proportionally from activity/diversity/volume since those are the signals most correlated with what attestation would capture.

2. Cold-start path specifically — only apply the attestation boost when the wallet has <5 transactions (where our behavioral signals are weakest). Once sufficient history exists, behavioral data takes over.

3. Sybil resistance — attestation data should be hard to game. Staking positions, governance tokens, and long-held assets are expensive signals. This aligns well with our existing anti-sybil logic (loyalty cap, concentration detection).

Questions:

• What's the API latency? We serve scores from a CF Worker in ~150ms.
• Is the 31-chain attestation a single API call or per-chain?
• What does the response look like for a wallet with zero attestable assets? (We'd want to distinguish "no data" from "checked and empty")
• Pricing for production usage? We're open-source/free tier right now.

I'd be up for a proof-of-concept integration. If you can share API docs + a test key, I'll prototype the 8th signal and measure the impact on our score distribution.

[douglasborthwick-crypto]

Good questions. Let me correct some numbers from the original issue — the trust profile has been expanded since March 1.

Latency: The trust profile evaluates 36 conditions across 21 EVM chains in parallel, so it's in the seconds range, not milliseconds. But the 30-min TTL is designed for exactly your pattern — call once on first score request, cache the signed result, serve from your Worker at 150ms using the cached profile, re-fetch on expiry. The credit cost (3 per call) makes this the natural integration anyway.

Single call: Yes — one POST /v1/trust with a wallet address, all 4 dimensions come back. No per-chain orchestration on your side. Optional solanaWallet and xrplWallet params add those dimensions if provided.

Empty wallet: Full signed response with every check met: false, passCount: 0 across all dimensions, dimensionsWithActivity: 0. You know we checked and found nothing — distinct from an error or timeout. The signature covers the empty result, so you can verify the absence of holdings is attested, not assumed.

Pricing: Grab a free key at POST https://api.insumermodel.com/v1/keys/create with {"email":"...","appName":"AgentKarma","tier":"free"}. That gives you 10 attestation credits (3 per trust call) — enough to hit the endpoint and see the response shape. Share the last 4 characters of your key here and I'll bump you to 500 credits for the prototype.

Updated numbers: The original issue said 17 checks — the stablecoin dimension has since expanded from 7 to 26 checks (16 USDC + 10 USDT across chains). Current totals: 36 base checks across 4 EVM dimensions (stablecoins, governance, NFTs, staking) on 21 chains, plus optional Solana USDC and XRPL stablecoins (up to 39 total).

The OpenAPI spec has the full response schema if you want to mock the integration before the key arrives.