Scoring Methodology

DJD Agent Score produces a 0–100 trust score for any wallet on Base L2. Scores are derived from on-chain data plus optional linked identity inputs like GitHub or Insumer attestations. This page explains how the model works.

How it works

When your agent calls the API with a wallet address, the scoring engine runs a five-phase pipeline:

The entire pipeline runs against live blockchain state. Scores are cached for one hour, and background jobs continuously refresh stale scores.

Cold start is real. Many Base wallets are still thin-data. An Unverified or Emerging result often means the wallet is new, lightly used, or missing identity markers, not that it has already been proven malicious. Confidence and explanation matter alongside the raw score.

The five dimensions

Each dimension measures a different aspect of wallet trustworthiness. Weights reflect how predictive each dimension is of reliable behavior.

Payment Reliability 30%

Does this wallet consistently execute transactions? Measures transaction success rate, total volume (log-scaled), nonce alignment, uptime estimation, and how recently the wallet was active.

txSuccessRate txCountLog nonceAlignment uptimeEstimate recencyBonus
Economic Viability 25%

Can this wallet actually pay? Evaluates ETH and USDC balances, income-to-spend ratio, wallet age, balance trends over 7 days, and whether the wallet has ever been drained to zero.

ethBalance usdcBalance incomeRatio walletAge balanceTrend zeroBalancePenalty
Identity 20%

Has this wallet established any verifiable identity context? Checks for optional public profile metadata, Base Name Service ownership, GitHub verification with activity signals, and multi-chain attestations via Insumer.

profileMetadata basename githubVerified githubActivity insumerAttestation
Behavior 15%

Does this wallet behave like a legitimate actor or a bot? Analyzes transaction timing patterns using inter-arrival coefficient of variation, hourly entropy (how spread out activity is across the day), and maximum gaps between transactions.

interArrivalCV hourlyEntropy maxGapHours
Capability 10%

Is this wallet actively providing services in the agent economy? Measures active x402 service endpoints, total revenue earned, unique counterparties served, and how long the wallet has been operating.

x402Services revenue uniqueCounterparties serviceLongevity

Composite score formula

The final score is not just a simple weighted average. Three additional layers refine it:

raw = Reliability×0.30 + Viability×0.25 + Identity×0.20 + Behavior×0.15 + Capability×0.10 adjusted = raw + trajectoryModifier // ±5 from sustained trends final = adjusted × integrityMultiplier // penalizes sybil/gaming/fraud output = clamp(0, 100, final) // dampened by confidence level

Trajectory modifier — analyzes the wallet's score history. Sustained improvement adds up to +5; sustained decline subtracts up to −5. New wallets start at zero modifier.

Integrity multiplier — a compound penalty from sybil indicators, gaming flags, and fraud reports. A clean wallet has a multiplier of 1.0. Flagged wallets get dampened toward zero.

Confidence dampening — wallets with long histories and many data points have high confidence, which limits score volatility. New wallets with little data have low confidence, allowing larger score swings as new information arrives.

Tiers

TierScore RangeMeaning
Elite 90 – 100 Exceptional track record across all dimensions
Trusted 75 – 89 Reliable actor with verified identity and consistent history
Established 50 – 74 Active wallet with reasonable history, some dimensions still developing
Emerging 25 – 49 Limited history or mixed signals — proceed with caution
Unverified 0 – 24 Insufficient data or significant red flags
Adaptive thresholds. Tier boundaries are not static. An auto-recalibration job runs every 6 hours, adjusting breakpoints based on the actual score distribution and outcome data. This prevents tier inflation as more wallets enter the system.

Sybil & gaming detection

A high score means nothing if wallets can fake it. The engine runs two layers of detection before scoring:

Sybil detection (7 checks)

Identifies fake wallet networks using the on-chain relationship graph stored in SQLite. Checks for circular funding patterns, shared funding sources, coordinated transaction timing, low-diversity counterparties, and other network topology signals. Flagged wallets receive hard caps on Reliability, Viability, and Identity scores.

Gaming detection

Catches wallets inflating their stats. Detects window dressing (temporarily inflating balances before a score check), wash trading (self-transfers to boost volume), and query manipulation. Gaming penalties are applied as a direct deduction from the composite score.

Two-layer penalty system. Sybil indicators cap individual dimension scores. Gaming indicators reduce the composite score directly. Both feed into the integrity multiplier, which dampens the final output. A wallet cannot game one dimension without triggering penalties that affect the overall score.

Data sources

Every signal comes from verifiable on-chain data on Base L2:

No off-chain opinions, manual reviews, or centralized reputation databases influence the score. If a signal is not on-chain or verifiably linked to the wallet, it does not count.

How Insumer fits in

Insumer is an optional identity input, not the whole identity layer. It contributes signed yes/no attestations for a small set of multi-chain conditions, which can add points inside the Identity dimension. It does not get to override Payment Reliability, Economic Viability, Behavior, or Capability.

If Insumer is unavailable or unconfigured, the score still returns normally. The wallet simply gets no Insumer attestation contribution for that request. In other words: the service degrades to the rest of the on-chain identity and behavior signals instead of failing outright.

Why use it at all? It lets the score incorporate verifiable cross-chain identity hints without exposing raw balances in the response. The scoring engine verifies the attestation client-side before it counts.

Outcome tracking

Scores are only useful if they predict real behavior. The engine tracks outcomes after scoring:

This outcome data feeds the auto-recalibration system, which adjusts dimension weights and tier thresholds over time. The model gets more accurate as more wallets are scored and more outcomes are observed.

What we don't do

Try it yourself. Score any Base wallet in under 200ms.

View API Reference →

Model version 2.5.0. This methodology is a living document — updated as the scoring engine evolves. Questions or feedback? Reach out at feedback@djdagentscore.dev.