An AI agent wants to pay for an API call. The facilitator needs to decide: should I settle this payment? The wallet might be brand new. It might have a long history of completed transactions. It might have been rated by other services. Each scenario requires a different trust signal. This article describes the three layers and shows how they compose in a single middleware hook.
The problem: one signal is not enough
Coinbase's x402 protocol adds native payments to HTTP. An agent sends a payment header with its request, and a facilitator settles the transaction. But the facilitator has a decision to make before settlement: is this wallet trustworthy?
A single trust signal breaks down at the edges. Behavioral scoring requires history, so it fails on day-zero wallets. On-chain reputation requires prior interactions with the specific service. Credential checks can verify holdings but say nothing about past behavior. Each layer covers a different phase of the wallet lifecycle.
Layer 1: On-chain credentials (pre-history)
A wallet has never transacted with any x402 service. No behavioral history exists. No reputation has been accumulated. But the wallet might hold governance tokens on multiple chains, staked ETH, and stablecoins across several networks. That presence is a meaningful signal.
InsumerAPI's trust endpoint runs 36 checks across 4 dimensions in a single call:
curl -X POST https://api.insumermodel.com/v1/trust \
-H "X-API-Key: insr_live_YOUR_KEY_HERE" \
-H "Content-Type: application/json" \
-d '{
"wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
}'
The response includes per-dimension results and an overall summary:
{
"ok": true,
"data": {
"trust": {
"id": "TRST-D4F6A",
"wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
"conditionSetVersion": "v1",
"dimensions": {
"stablecoins": { "passCount": 3, "failCount": 4, "total": 7 },
"governance": { "passCount": 2, "failCount": 2, "total": 4 },
"nfts": { "passCount": 0, "failCount": 3, "total": 3 },
"staking": { "passCount": 1, "failCount": 2, "total": 3 }
},
"summary": {
"totalChecks": 17,
"totalPassed": 6,
"totalFailed": 11,
"dimensionsWithActivity": 3,
"dimensionsChecked": 4
},
"profiledAt": "2026-03-06T10:00:01.000Z",
"expiresAt": "2026-03-06T10:30:01.000Z"
},
"sig": "...",
"kid": "insumer-attest-v1"
},
"meta": { "creditsRemaining": 94, "creditsCharged": 3, "version": "1.0", "timestamp": "2026-03-06T10:00:01.000Z" }
}
The 4 dimensions cover stablecoins (USDC on 7 chains), governance tokens (UNI, AAVE, ARB, OP), NFTs (BAYC, CryptoPunks, Pudgy Penguins), and staking (stETH, rETH, cbETH). Each check returns a boolean. No balance amounts are ever exposed.
A wallet with activity in 3 or more dimensions is a very different counterparty than an empty wallet created five minutes ago. For the cold-start case, this is the only meaningful signal available.
Layer 2: Behavioral scoring (transaction history)
Once a wallet has on-chain transaction history, behavioral analysis becomes possible. DJD Agent Score, part of the Coinbase x402 ecosystem, evaluates wallets across multiple dimensions: transaction patterns, wash trading detection, interaction diversity, and identity signals.
DJD already integrates InsumerAPI for its Identity dimension. When a wallet has no behavioral data, the on-chain credential check provides the fallback signal. When behavioral data is available, DJD's scoring engine provides a richer picture.
The two signals are complementary. A wallet might hold governance tokens (Layer 1) but have suspicious transaction patterns (Layer 2). Or a wallet might have healthy behavioral scores but hold no real assets. Neither signal alone tells the full story.
Layer 3: On-chain reputation (post-interaction)
After a wallet has actually completed x402 payments, a third signal becomes available: reputation from real economic interactions. The ERC-8004 Reputation Registry standard, implemented by projects like Azeth, allows wallets to accumulate reputation scores on-chain based on completed service interactions.
The key design property: only wallets that have completed a payment to a service can rate that service. Opinions are weighted by cumulative USDC volume between the rater and the service. This makes sybil attacks economically expensive rather than just rate-limited.
Scores live on-chain, so any facilitator can read them directly from contract state without trusting a centralized API. This is the highest-fidelity signal, but it requires the most history to accumulate.
How the three layers compose
The x402 protocol provides a beforeSettle hook where facilitators can inject trust logic before settling a payment. The three layers map to different phases of the wallet lifecycle:
- **Pre-history** (Layer 1): wallet has never transacted with any x402 service. On-chain credentials are the only signal.
- **Behavioral** (Layer 2): wallet has on-chain transaction history that can be scored, but has not interacted with this specific service.
- **Post-interaction** (Layer 3): wallet has completed x402 payments and accumulated on-chain reputation from real economic interactions.
Signal fidelity increases across the phases. Asset holdings are a useful proxy. Behavioral patterns are stronger but gameable with enough volume. Payment-weighted on-chain feedback is the hardest to fake, because manipulation cost scales with the reputation being built.
The beforeSettle hook
Here is how the three layers compose in a single beforeSettle hook. Each layer is independently opt-in. A facilitator can start with one and add others as needed.
beforeSettle: async (payerWallet) => {
// Layer 1: On-chain credentials via InsumerAPI
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: payerWallet }),
}).then((r) => r.json());
const hasCredentials =
trust.data.trust.summary.dimensionsWithActivity >= 2;
// Layer 2: Behavioral scoring via DJD Agent Score
const djd = await fetch(
`https://djd-agent-score.fly.dev/v1/score/basic?wallet=${payerWallet}`
).then((r) => r.json());
const hasBehavior = djd.score >= 25;
// Layer 3: On-chain reputation (ERC-8004)
// Read directly from contract state on Base
// const reputation = await readReputationScore(payerWallet);
// const hasReputation = reputation.averageScore >= 25;
// Gate: require at least one signal
if (!hasCredentials && !hasBehavior) {
throw new Error(
"Wallet has no on-chain credentials and no behavioral history"
);
}
}
Layer 1 and Layer 2 run in parallel. The facilitator requires at least one positive signal before settling. A cold-start wallet passes on credentials alone. An established wallet passes on behavioral score alone. A wallet with both signals is the strongest counterparty.
Why each layer matters
Layer 1 solves cold start. Every wallet starts with zero behavioral history. On-chain credentials are the only signal available at time zero. A wallet holding stablecoins across 3 chains, governance tokens, and staking positions carries evidence of legitimacy that no behavioral model can produce before the first interaction.
Layer 2 adds pattern detection. Behavioral scoring catches things that static holdings cannot: wash trading, interaction diversity, transaction frequency patterns. A wallet might hold real assets but behave suspiciously. Behavioral analysis catches that.
Layer 3 closes the loop. Once enough agents rate services on-chain, new agents can route payments by reputation score rather than hardcoded URL. The trust layer becomes a routing layer. This is where the system gets interesting, but it requires a critical mass of interactions to become useful.
Verifying the credential signal
The trust profile from InsumerAPI is ECDSA-signed. A facilitator can verify the signature independently using the public key from the JWKS endpoint at /.well-known/jwks.json or GET /v1/jwks. The insumer-verify npm package handles this automatically:
import { verifyAttestation } from "insumer-verify";
// Pass the full API response envelope, not trust.data
const result = await verifyAttestation(trust);
if (!result.valid) {
throw new Error("Trust profile signature verification failed");
}
This means the facilitator does not need to trust InsumerAPI as a black box. The same pattern DJD Agent Score uses in production: call the API, then verify the response cryptographically before acting on it.
Where this is headed
The three-layer model is not theoretical. DJD Agent Score already runs Layer 1 and Layer 2 in production for Coinbase x402 wallets. ERC-8004 is live on Base Sepolia. The pieces exist. What is missing is a standard interface that lets facilitators plug in trust providers without coupling to any single source.
A composable beforeSettle that accepts pluggable trust providers, each returning a score and confidence level, would let facilitators mix signals without custom integration work for each provider. The x402 protocol already has the hook. The trust layers already have the data. The composition layer is next.
, before CTA) -->
Share this article
[
Share on X
](#)
[
LinkedIn
](#)
[
Reddit
](#)
Discord
Copy Link
InsumerAPI is free to start. Get an API key and try it. View API Docs
Top comments (0)