Methodology
How Crypterian scores on-chain agent wallets. The full formula, tier mapping, behavioral profile taxonomy, and exactly which data we observe (and which we don't).
tier: "unranked"
regardless of score. We never fabricate signal where none exists.
Endpoints
Crypterian exposes two x402-paywalled endpoints — same underlying scoring engine, two views, two price points. Buyers pick the right tier for the decision they're making.
| Endpoint | Price | Use case | What you get |
|---|---|---|---|
GET /score/{wallet} |
$0.005 USDC | Runtime agent decision — "trust this counterparty for the next 30 seconds?" | Score, tier, confidence, txn_count, last_seen, AI profile category + rationale, sybil verdict. |
GET /enriched-score/{wallet} |
$0.02 USDC | Onboarding decision — "add this wallet to my recurring-partner whitelist?" | Everything in the basic response, plus: percentile rank within tier, reserved reliability_30d / reliability_90d slot, and a 90-day behavioral fingerprint from decoded callData (distinct target contracts + paymasters, top 5 inner-call function selectors with labels, decoder coverage %). |
Both endpoints accept payment in Base USDC or Solana USDC — the x402 facilitator settles whichever the buyer signs for. The wallet being scored can be on either chain; chain is auto-detected from address format (EVM 0x… vs Solana base58). Full schemas at /openapi/.
The score
Each wallet receives a 0–100 reliability score, computed hourly from its observed on-chain behavior. The formula is intentionally simple — to be calibrated, not redesigned, as real data accumulates.
raw = success_rate × 0.5 + recency_weight × 0.2 + txn_volume × 0.2 + paymaster_quality × 0.1 decayed = raw × exp(−Δt / 45 days) score = clamp(decayed × 100, 0, 100)
Components
- success_rate — fraction of observed events that succeeded (Base:
userop_success; Solana:payment_made) over total observed. - recency_weight — full weight if seen within the last day, linearly decays to zero over 30 days. Captures "is this wallet still alive."
- txn_volume —
min(1, txn_count / 100). Linear ramp; saturates at 100 events. - paymaster_quality — Base only: fraction of userOps that used a paymaster (proxy for "real agent infrastructure"). Solana returns neutral 0.5.
- Δt — days since the score was last computed or decayed. Applied via daily cron at 05:00 UTC.
Confidence is reported separately as min(txn_count / 100, 1.0) — a linear scale from "we've barely seen this wallet" to "we have hundreds of data points."
Tiers
| Tier | Score | Meaning |
|---|---|---|
| S | ≥ 95 | Elite — top of the population. Near-perfect success rate, consistently active, well-supported infrastructure. |
| A | 90–94 | Production-quality. Working agent infrastructure, high success rate, reliable cadence. |
| B | 80–89 | Solid track record. Some imperfection but consistently functional. |
| C | 60–79 | Workable. Worth interacting with, with measured expectations. |
| D | < 60 | Mixed signal or many failures. Treat with caution for high-stakes interactions. |
| unrk | < 100 ev | Insufficient evidence regardless of score. Honest "unknown." |
Behavioral profile
Beyond the score, ranked wallets receive an AI-inferred behavioral category
via xAI's grok-4-1-fast. The category surfaces alongside the
score in API responses and the dashboard so buyers can route by
what the wallet looks like it does — not just how reliable it is.
Categories split into two groups. Activity-shape categories key on volume, cadence, paymaster diversity, and success rate. Behavior-shape categories key on the wallet's decoded target contracts and the 4-byte function selector its smart account is invoking — populated by Crypterian's callData decoder for the ~74% of userOps using standard wallet execution entrypoints.
| Category | Pattern |
|---|---|
| high_velocity_agent | ≥500 events, ≥95% success, regular cadence (often single paymaster). Production automation. |
| paymaster_diverse | ≥3 distinct paymasters, sustained activity. Infrastructure-level agent across providers. |
| sporadic_user | <50 events, irregular timing. Exploratory or manual use. |
| low_quality_bot | ≥10% failure rate or rate-limit-triggering patterns. |
| sybil_pattern | Repetitive minimum-gas ops at near-identical cadence — coordinated multi-wallet shape. |
| dex_caller | Approve-then-call pattern (0x095ea7b3 followed by non-approve calls) on a concentrated set of target contracts. The canonical DEX-router shape. |
| nft_minter | Inner selectors match common mint signatures (0x1249c58b, 0xa0712d68, 0x40c10f19, 0x755edd17) across multiple distinct target contracts. |
| bridge_user | Calls concentrated on 1–2 target contracts with inter-event gaps regularly exceeding minutes — bridge-finalization cadence. |
| unclassified | Data doesn't support a confident pick. Honest. |
Profiles are recomputed every 6 hours for ranked wallets, or weekly otherwise. Each profile includes a one-sentence rationale citing the concrete numbers used to reach the verdict (e.g. "8153 events with 100% success rate, ~2 sec cadence, 1 paymaster — production automated agent pattern").
Sybil detection
Beyond per-wallet profile, Crypterian runs cluster-level sybil detection every 12 hours. A SQL pre-filter finds candidate clusters: wallets that share their primary paymaster and were first-seen in the same hour bucket, with cluster size ≥ 20 and average activity ≤ 10 events/wallet. Each candidate cluster is then sent to Grok with the cluster's statistical fingerprint (size, avg/min/max events, standard deviation, sample of members) for a coordination verdict.
Flagged-sybil wallets receive sybil.is_sybil = true in their
score response and are de-prioritized to the back of the public
leaderboard. We don't reduce the underlying score — we surface
the signal so buyers can filter using it.
Heuristic: high variance of event counts within a cluster (some wallets with hundreds of events, others with 1) is treated as a popular paymaster with normal user mix, not sybil. Low variance + uniform low activity is the textbook signature.
Decay
Scores aren't sticky. Every score multiplies by exp(−Δt / 45 days)
daily, where Δt is days since the score was last computed or decayed. A
score of 100 today drops to ~37 after 45 days if the wallet stops being
re-scored. Active wallets get re-scored hourly (resetting Δt to 0), so this
only erodes scores that go quiet.
Decay protects the engine against stale ranking — a wallet that earned tier S three months ago and then disappeared shouldn't keep that rank. After one half-life of inactivity, every score loses meaningful confidence.
What we observe
Crypterian indexes on-chain activity continuously across two chains:
Base (every 5 minutes)
Scans UserOperationEvent logs from EntryPoint
v0.6 (0x5FF137…) and v0.7
(0x000000…2032) via Alchemy RPC. Each event records: smart
account sender, paymaster used, success/failure, gas spent, block timestamp.
Solana (every 5 minutes + hourly discovery)
Ingest pulls recent signatures for every observed agent wallet via
Alchemy Solana RPC, classifying each as payment_made or
payment_failed based on transaction status. Discovery runs
hourly against a curated list of x402 receiver addresses (sourced from
CDP Bazaar) via Helius Enhanced API, harvesting unique payer addresses as
new observation candidates.
Scoring & decay
Hourly: any wallet with new events in the last 2 hours is re-scored. Daily at 05:00 UTC: every score in the table decays by one day's multiplier.
What we don't observe (yet)
- userOp.callData — we record the smart-account sender, but not which contract the userOp calls downstream. This means we can't currently distinguish a DEX trader from an NFT minter from a bridge user. On the roadmap.
- Cross-chain identity — Base wallets and Solana wallets are scored independently. We do not attempt to link addresses across chains (heuristic correlation is a v2 feature, deferred for legal hygiene).
- Agent identity — we don't try to identify who operates a wallet. We score behavior, not identity. This is both a product decision and legal hygiene.
- Off-chain reputation — Crypterian doesn't ingest GitHub stars, social signals, or operator self-declarations. The score is built only from observable on-chain behavior.
Updates
The formula is fixed during the calibration period (first 30 days of real data). After that, weights may be tuned and additional signals may be added — every change to the formula will be versioned in the response and announced on this page.