[Feature Request] Add wallet reputation check before transfers

[jacobsd32-cpu]

Problem

When an AgentKit agent executes a transfer action, it sends USDC/ETH to a wallet address with no way to assess the recipient's trustworthiness. A fresh sybil wallet looks identical to a 6-month-old legitimate operator.

Proposal

Add an optional pre-transfer reputation check using DJD Agent Score, a free API that scores wallets on Base based on their on-chain transaction history.

The integration is 5 lines in the transfer action:

// Before executing transfer, check recipient reputation
const scoreRes = await fetch(
  `https://djd-agent-score.fly.dev/v1/score/basic?wallet=${recipientAddress}`
);
const { score, tier, confidence } = await scoreRes.json();

if (score < 40 || confidence < 0.2) {
  return `Warning: Recipient wallet ${recipientAddress} has a low reputation score (${score}/100, ${tier}). This wallet may be newly created or exhibit suspicious patterns. Proceed with caution.`;
}

// Continue with existing transfer logic...

Why this matters

• Free tier: 10 calls/day, no API key, no signup, no payment
• Fast: <200ms response time, cached scores
• On-chain data only: Scores are based on real USDC transaction history, partner diversity, account age, and 12 behavioral sybil/gaming checks
• x402 native: Paid tier uses the same x402 protocol AgentKit already supports

Try it

curl "https://djd-agent-score.fly.dev/v1/score/basic?wallet=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"

API Docs · OpenAPI Spec · GitHub

[douglasborthwick-crypto]

Good proposal. DJD's approach of checking behavioral history before transfers makes a lot of sense for AgentKit.

One gap worth considering: cold-start wallets. A brand-new recipient wallet has zero transaction history, so behavioral scoring can't differentiate it from a sybil. But you can check what it holds on-chain right now as a complementary signal.

InsumerAPI does this — returns a trust profile checking 17 conditions across stablecoins, governance tokens, NFTs, and staking on 31 chains:

const trust = await fetch('https://api.insumermodel.com/v1/trust', {
  method: 'POST',
  headers: { 'X-API-Key': process.env.INSUMER_API_KEY, 'Content-Type': 'application/json' },
  body: JSON.stringify({ wallet: recipientAddress })
}).then(r => r.json());

const { totalPassed } = trust.data.trust.summary;
if (totalPassed === 0) {
  return `Warning: ${recipientAddress} holds no verifiable on-chain credentials across 31 chains.`;
}

The response is ECDSA P-256 signed (data.sig), verifiable via JWKS at /.well-known/jwks.json — useful for audit trails.

Could work well alongside DJD: behavioral checks for wallets with history, credential checks for wallets without.

AI Agent Verification API guide · Docs

[jacobsd32-cpu]

Douglas laid this out really well. DJD's Identity dimension uses InsumerAPI attestations as one of its core scoring signals — 5 multi-chain conditions checked in a single request, ECDSA-signed and independently verifiable. The cold-start gap he's describing is genuinely the hardest edge case in wallet reputation: a fresh wallet has no history to analyze, period. InsumerAPI's credential checks solve that cleanly by looking at what the wallet holds right now across 31 chains. It's the reason we integrated it in the first place.