Integration: InsumerAPI token attestation as Identity dimension signal

[douglasborthwick-crypto]

Context

Following up from the x402 #1277 discussion where we discussed integrating InsumerAPI's on-chain token attestation into DJD Agent Score's Identity dimension.

Problem

New agent wallets with zero x402 transaction history score low across all behavioral dimensions, even if the operator is legitimate. The Identity dimension (currently 20% weight) helps, but is limited to wallet age, Basename, and GitHub verification.

Proposal

Add InsumerAPI token attestation as an additional Identity signal. When scoring a wallet, optionally call InsumerAPI to check whether the wallet holds specific credential tokens (governance tokens, membership NFTs, merchant badges, etc.) on any of 31 EVM chains.

Score-time enrichment (Phase 1)

During wallet scoring, call POST https://api.insumermodel.com/v1/attest with:

{
  "wallet": "0x...",
  "conditions": [
    {
      "type": "token_balance",
      "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "chainId": 8453,
      "threshold": 1,
      "decimals": 6,
      "label": "USDC on Base"
    }
  ]
}

Response includes an ECDSA P-256 signed attestation:

{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-DB868",
      "pass": true,
      "results": [
        {
          "condition": 0,
          "label": "USDC on Base",
          "type": "token_balance",
          "chainId": 8453,
          "met": true,
          "evaluatedCondition": {
            "type": "token_balance",
            "chainId": 8453,
            "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "operator": "gte",
            "threshold": 1,
            "decimals": 6
          },
          "conditionHash": "0x63000d642ecf4cf0c78b1ae1a6d7f9bc4bc192a55bbca8be516ba74db2ddb4d5",
          "blockNumber": "0x290e25e",
          "blockTimestamp": "2026-03-07T13:01:19.000Z"
        }
      ],
      "passCount": 1,
      "failCount": 0,
      "attestedAt": "2026-03-07T13:01:20.400Z",
      "expiresAt": "2026-03-07T13:31:20.400Z"
    },
    "sig": "0ahxFqRFGJSmFGCJLkX15Bvujkj+jLuLR77I3EstoyExME2h/b8VmJuLoJdUJVp8tqR+Iq91I36YXyDfO8RuVQ==",
    "kid": "insumer-attest-v1"
  },
  "meta": {
    "version": "1.0",
    "timestamp": "2026-03-07T13:01:20.527Z",
    "creditsCharged": 1,
    "creditsRemaining": 9
  }
}

A pass: true result for one or more relevant tokens would boost the Identity dimension score, helping legitimate wallets clear the cold-start threshold while behavioral dimensions build up from actual x402 usage.

Registration-time attestation (Phase 2)

Extend POST /v1/agent/register to accept optional token attestations as part of the identity profile. These persist and don't need to be re-fetched on every score request.

Mutual MCP exposure (Phase 3)

Both projects have MCP servers (mcp-server-insumer and djd-agent-score-mcp). Document a combined workflow where agents get behavioral reputation + credential verification in one tool set.

InsumerAPI resources

• OpenAPI spec
• MCP server (23 tools)
• LangChain SDK
• Developers page

Happy to provide a test API key to get started on Phase 1.

[jacobsd32-cpu]

Hey @douglasborthwick-crypto — thanks for the detailed writeup. This is a well-scoped proposal and the phased approach makes a lot of sense.

Phase 1 (score-time enrichment) is the clear starting point. The cold-start problem is real — right now a brand new wallet with zero x402 history can only get points from wallet age, registration, Basename, and GitHub. Token attestation would be a strong additional signal in the Identity dimension, especially for wallets that can prove they hold governance tokens, membership NFTs, or meaningful balances before they've built any transaction history.

I'm thinking the integration would look like:

• Add an optional POST /v1/attest call during calcIdentity scoring
• Check against a configurable list of "recognized" token contracts
• A verified attestation would contribute to the Identity dimension alongside the existing signals (wallet age, Basename, GitHub, registration)
• Graceful degradation — if the InsumerAPI call times out or fails, scoring proceeds without it

I'd love to take you up on the test API key offer to prototype this. You can reach me at jacobsd32@gmail.com, or happy to coordinate here.

For Phase 2, extending /v1/agent/register to accept token attestations at registration time makes sense as a natural next step — store the attestation results so we don't re-fetch on every score.

Phase 3 (mutual MCP documentation) is straightforward once the API integration is solid.

Looking forward to building this out.

[douglasborthwick-crypto]

Thanks @jacobsd32-cpu, glad the phased approach resonates. Your integration sketch for calcIdentity is spot on.

API key

I've provisioned a Pro-tier key for the integration work:

[key rotated — DM me for a new one]

500 attestation credits, 10K daily reads. That's plenty for prototyping and load testing. Pass it as X-API-Key header.

Quick test

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "X-API-Key: [key rotated — DM me for a new one]" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "conditions": [
      {
        "type": "token_balance",
        "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
        "chainId": 1,
        "threshold": 1,
        "decimals": 18,
        "label": "UNI >= 1"
      }
    ]
  }'

Response includes ok, data.attestation.results[].met (boolean per condition), data.attestation.pass (all conditions met), and data.sig (ECDSA P-256 signature).

Thoughts on integration point

Looking at your scoring architecture, I see two viable fits:

Option A: Identity signal (my recommendation for Phase 1)
Add 10-15 pts in calcIdentity for wallets that hold recognized credential tokens. This is the simplest path: during scoring, call /v1/attest with a configurable list of "recognized" contracts (governance tokens, membership NFTs, etc.). A met: true result adds points alongside Basename, GitHub, and wallet age. The cold-start problem is the strongest motivator here. A new wallet holding UNI governance tokens or a BAYC NFT is meaningfully different from an empty fresh wallet, even before any x402 history.

Option B: Capability signal (Phase 2)
Once agents are actively using attestation as part of their workflows (verifying counterparty wallets before transacting), that usage itself becomes a capability signal. But this requires indexing attestation activity, which is heavier.

On graceful degradation

Agree completely. The /v1/attest call has a 30-second timeout on our end. I'd suggest a 5-second client timeout in calcIdentity with a fallback of 0 pts for the attestation signal. The existing signals carry the score if the call fails.

Merkle proofs (optional, for Phase 2+)

We recently shipped proof: "merkle" on the attest endpoint. This returns EIP-1186 Merkle storage proofs that can be verified against public block headers without trusting our API. Costs 2 credits instead of 1. Could be interesting for the integrity layer: if the attestation result is independently verifiable against the blockchain's state root, it's a stronger signal than a signed boolean alone.

I can sketch a PR against your repo for Phase 1 if you'd like to see code first, or we can continue scoping async here.

[douglasborthwick-crypto]

Quick update relevant to your integration: we just published insumer-verify (npm, zero dependencies, Node.js 18+ and browsers). It takes a raw /v1/attest response and runs 4 independent checks: ECDSA P-256 signature, condition hash integrity (SHA-256 of canonical JSON), block freshness, and attestation expiry.

For the score-time enrichment path, this means DJD can verify attestation results client-side without trusting InsumerAPI as a black box. The signature check confirms the response wasn't tampered with, and the condition hash check confirms the exact contract/threshold/chain that was evaluated.

Also worth noting: POST /v1/attest supports proof: "merkle" which returns EIP-1186 Merkle storage proofs alongside the boolean result. That lets you verify the on-chain state directly against the block header. Available on a subset of EVM chains (Merkle proofs require direct RPC access). Costs 2 credits instead of 1 and reveals the raw balance to the caller.

Depending on how much trust minimization you want in the Identity dimension, you could use standard attestations (signed boolean, cheapest) for routine scoring and Merkle proofs for high-stakes verification where the score consumer needs to check the proof themselves.

[jacobsd32-cpu]

This is great — implemented in v2.3.0! 🎉

We've integrated insumer-verify into the Identity dimension. Here's how it works:

What we added:

• New src/insumer.ts module that calls InsumerAPI /v1/attest and verifies the response client-side using insumer-verify (ECDSA P-256 signature, condition hash integrity, block freshness within 5 min, attestation expiry)
• Standard attestations (1 credit) — we attest balanceOf >= 0 on Base USDC, proving the wallet interacts with the contract without revealing balances
• The Insumer attestation runs in parallel with existing blockchain RPC calls, so no added latency to the scoring pipeline
• Verified wallets earn 15 pts in the Identity dimension (point budget reallocated from wallet age and basename)
• Graceful fallback: if INSUMER_API_KEY isn't configured, scoring still works — the attestation just returns unverified

On Merkle proofs: We're set up for it — fetchAndVerifyAttestation accepts a { merkle: true } option that requests EIP-1186 storage proofs from InsumerAPI. We're not using it in routine scoring yet (standard attestations are sufficient for the boolean "does this wallet exist on-chain" signal), but it's ready for a future high-stakes verification tier where consumers want independently verifiable balance proofs.

Model version bumped to 2.3.0. Thanks for the suggestion — this is a solid addition to the trust signal stack.

[douglasborthwick-crypto]

This is fantastic — congrats on v2.3.0! The integration design is exactly right:

• balanceOf >= 0 on Base USDC as a proof-of-existence signal is a clever use of the threshold condition. It answers "has this wallet ever touched a real DeFi contract?" without needing to know balances — which is the ideal cold-start signal for Identity scoring.
• Parallel execution with existing RPC calls is the correct architecture. The attestation call shouldn't be on the critical path.
• Client-side verification via insumer-verify means DJD consumers don't need to trust our API as a black box. The ECDSA check + condition hash integrity gives you the same trust guarantees as verifying against the chain directly, at 1 credit instead of 2.

The 15-point allocation in Identity feels well-calibrated — meaningful enough to differentiate wallet-native agents from fresh throwaway addresses, but not so heavy that a single signal dominates the dimension.

A couple of things from our side:

1. We'd love to feature this as a case study. DJD Agent Score is the first third-party project to integrate InsumerAPI with insumer-verify for client-side cryptographic verification. Would you be open to us referencing this integration on our developers page and in a blog post? We'd link back to the DJD repo and credit you directly.

2. If you want to expand the attestation set, some token contracts that would be high-signal for agent trust scoring:

• ENS Token (0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72, Ethereum) — governance participation
• Optimism OP (0x4200000000000000000000000000000000000042, Optimism) — L2 governance
• ARB (0x912CE59144191C1204E64559FE8253a0e49E6548, Arbitrum) — L2 governance
• stETH (0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84, Ethereum) — long-term staking signal

Each adds a distinct trust dimension. You could weight governance token holders higher than pure DeFi users, for example.

3. On the Merkle proof tier: when you're ready to activate it, the proofs verify against the block's stateRoot — so a score consumer with access to a block header can independently confirm the balance without trusting either our API or your scoring pipeline. Good for enterprise use cases where auditability matters.

Looking forward to seeing how this evolves. Happy to support however we can.

[jacobsd32-cpu]

Thanks Douglas — really appreciate the detailed technical feedback and the kind words on the integration design.

Case study — absolutely yes. Happy to be featured on the developers page and blog. DJD Agent Score is a public repo so feel free to reference any of the code, architecture decisions, or scoring methodology. If you need quotes, screenshots, or want to collaborate on the write-up, just ping me here or reach out directly. Linking back is much appreciated.

Multi-chain token expansion — those contract suggestions are excellent and line up with where we want to take the Identity dimension next. The signal taxonomy makes a lot of sense:

• ENS / OP / ARB → governance participation = "this wallet has skin in the game beyond just holding tokens"
• stETH → long-term staking = temporal commitment signal, similar to what wallet age captures but on-chain verifiable

We're thinking about this for v2.4 — the main design question is whether to treat each token as an independent boolean (like the current USDC check) and weight them individually, or aggregate into a single "on-chain engagement" sub-score. Leaning toward individual booleans since the attestation credit cost stays at 1 per condition and we can tune weights independently. Would love your input on whether InsumerAPI handles multi-chain conditions in a single request or if each chain needs a separate attest call.

Merkle proof tier — very interested in this for enterprise use cases. The idea that a score consumer can verify against the block's stateRoot without trusting either pipeline is a strong selling point for institutional integrations. When we're ready to activate it, I'll loop back. Curious if you're seeing demand from specific verticals — compliance platforms, custody providers, etc.?

Looking forward to building on this. The insumer-verify DX was genuinely great — zero-dependency, clean types, deterministic checks. Made the integration a lot smoother than expected.

[douglasborthwick-crypto]

Thanks for the v2.3.0 shoutout — great to see the integration live.

Multi-chain in a single request: yes. POST /v1/attest accepts a conditions array of up to 10 objects, and each condition carries its own chainId. So you can check ENS on Ethereum, OP on Optimism, ARB on Arbitrum, and USDC on Base in one call:

{
  "wallet": "0x...",
  "conditions": [
    { "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": 8453, "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "threshold": 0, "decimals": 6, "label": "USDC on Base >= 0" }
  ]
}

One request, one ECDSA signature covering all conditions. Response includes per-condition met booleans plus an overall pass (all conditions met). Costs 1 credit per request regardless of how many conditions are included. Multi-chain conditions are evaluated in parallel, so latency is roughly the slowest single chain response, not the sum.

For v2.4, individual booleans with independent weights is the right call — it maps directly to the per-condition results[] array in the response. You'd just iterate results[i].met and apply your weight per token type.

On Merkle proof demand: early interest is from two directions — (1) compliance-adjacent platforms that need audit trails proving a specific on-chain state at a specific block height, and (2) multi-agent orchestration where the consuming agent doesn't trust the scoring pipeline and wants to verify against the block's stateRoot independently. Your use case fits the second category well if DJD score consumers ever want to spot-check Identity dimension inputs. No rush — standard attestations are the right default for routine scoring.

Case study write-up is in progress on our end. Will share a draft before publishing.

[jacobsd32-cpu]

This is incredibly helpful — the multi-chain single-request design is exactly what we needed to confirm the v2.4 architecture.

v2.4 plan is now clear:

The conditions array maps 1:1 to what we need. Four conditions, each as an independent boolean feeding into Identity with individual weights:

Token	Chain	Signal	Proposed Weight
USDC (balanceOf >= 0)	Base	DeFi proof-of-existence	4 pts
ENS (balance >= 1)	Ethereum	Governance participation	4 pts
OP (balance >= 1)	Optimism	L2 governance	4 pts
stETH (balance > 0)	Ethereum	Long-term staking	3 pts

That's 15 pts total for the Insumer attestation block (same allocation as v2.3, but now covering 4 chains instead of 1). A wallet that holds all four is a fundamentally different trust profile than one that only touched Base USDC — and the cost is just 4 credits per score.

We'll iterate results[i].met exactly as you described. The label field in conditions is a nice touch — we can log those for debugging without having to reverse-map contract addresses.

On Merkle proofs for multi-agent orchestration — that's the use case I'm most excited about. If an orchestrator agent calls our /score endpoint and wants to independently verify the Identity inputs, we could include the Merkle proof in the response metadata. The orchestrator verifies against the stateRoot, confirms the attestation is legitimate, and trusts the score without trusting our pipeline. That's a strong differentiator for DJD in enterprise contexts. Will definitely want to build this out once we have the multi-chain attestation stable.

Looking forward to the case study draft. Happy to review and add any context from our side.

[douglasborthwick-crypto]

As promised, here's the case study draft for your review before we publish. The article would live at insumermodel.com/blog/djd-agent-score-insumer-api-integration.html.

Title: Case Study: DJD Agent Score Integrates InsumerAPI for On-Chain Trust Scoring

Category: For Developers

Sections:

1. The problem: cold-start wallets score low — New wallets with zero transaction history get penalized. Wallet age and Basename aren't enough to distinguish legitimate operators from throwaway addresses.

2. The approach: token attestation as identity signal — Single InsumerAPI call during Identity scoring. Attests balanceOf >= 0 on Base USDC as a proof-of-existence signal. Runs in parallel with existing RPC calls. 15 points in the Identity dimension. Graceful fallback if the call fails.

3. Client-side verification with insumer-verify — Covers the four independent checks (ECDSA signature, condition hash integrity, block freshness, attestation expiry). Notes that this gives the same trust guarantees as verifying against the chain directly at 1 credit instead of 2.

4. Why this works for trust scoring — Explains why balanceOf >= 0 is a smart design choice: it answers "has this wallet ever touched a real contract?" rather than "is this wallet wealthy?" Also covers the privacy model (boolean only, no balance amounts).

5. Architecture — Six-step flow from scoring request to composite score. Notes INSUMER_API_KEY is optional and the system deploys without external dependencies.

6. What comes next — v2.4 multi-chain governance tokens (ENS, OP, ARB), multi-chain conditions in a single request, Merkle proofs for enterprise auditability.

7. The cold-start problem is solvable — Wraps up with the link to the DJD Agent Score repo on GitHub.

The article links back to github.com/jacobsd32-cpu/djdagentscore and credits DJD directly throughout. No quotes attributed to you (just factual description of what you built). The CTA at the bottom points developers to our API, not to your repo.

Let me know if you'd like anything changed, added, or removed before we publish. Happy to share the full HTML if you want to see exact wording.

[douglasborthwick-crypto]

Case study is live: insumermodel.com/blog/djd-agent-score-insumer-api-integration.html

Thanks for the approval and for being the first third-party integration. Links back to the DJD repo throughout. Let me know if you want anything adjusted.

[jacobsd32-cpu]

Looks great — thanks for the quick turnaround. Appreciate the repo links throughout.

One ask: any chance DJD could get a persistent mention on the main developers page as well? Blog posts get buried over time — a reference under "Integrations" or "Case Studies" on the dev docs would have more lasting value for both of us.

Either way, happy with the write-up. Looking forward to giving you more to write about with v2.4.

[douglasborthwick-crypto]

Done — DJD Agent Score now has a permanent section on the developers page: insumermodel.com/developers

It sits between the "Who Uses This" and "Trust Model" sections. Links to the full case study blog post and your GitHub repo. Should persist well beyond the blog.

[douglasborthwick-crypto]

Hey @jacobsd32-cpu — checking in on the v2.4 multi-chain expansion (ENS/OP/ARB/stETH). The original key was rotated back in February, so you'll need a fresh one. Quickest way: POST https://api.insumermodel.com/v1/keys/create with {"email":"...","appName":"...","tier":"free"} — takes 10 seconds. Once you're set up, send me the last 4 characters and I'll bump your credits for the integration work.