How CredScore builds a wallet risk score
The CredScore engine is deterministic. The same wallet, on the same chain, with the same input data, produces the same score every time. No model in the scoring path. No black box. Every signal has an explicit numeric weight, and every weight is documented here.
The design choice: behavior over labels
Most wallet risk products evaluate the present state of a wallet. Is it on a sanctions list right now. Does it currently hold funds from a known incident. Has it interacted with a mixer in the last thirty days. CredScore evaluates the on-chain record. What did this wallet do, and what does that history say about who you are about to transact with.
The distinction is small in writing and large in practice. A wallet that drained a protocol three years ago, returned the funds, and went dormant is low risk by present-state criteria. It is high risk by behavior-over-labels criteria, because the on-chain record still contains the original exploit, the post-theft distribution, and the entity attribution that links it to the incident. A compliance analyst can defend the behavior-based verdict in an internal review six months or six years after the fact. The present-state verdict resets after dormancy, and quietly clears every actor who waits long enough.
CredScore picked the harder verdict on purpose. The signal categories below, the weights, the posture rules, all of it serves that one design choice. Two recent case studies show the choice working in practice.
Two wallets, two opposite extremes. A 15-month-dormant attacker who returned the funds, and an 8-day-old exploiter who never had a label to begin with. Same verdict shape from the engine. That consistency is what the rest of this page describes the mechanics of.
The score is a sum of weighted signals
A wallet's analysis runs through a fixed pipeline. First, the engine fetches the wallet's transfer history from a configured RPC provider. Then it computes a snapshot of behavioral metrics: age, balance, transfer count, counterparty diversity, velocity, concentration, structural routing patterns. Each metric maps to one or more signals. Each signal has a numeric impact on the score, positive or negative. The impacts sum into a raw score100 in the range 0 to 100. Higher is safer.
The raw score is then clamped, capped where a combination override is active (for example, direct sanctions exposure caps the score at a low value regardless of stabilizing signals), and converted to a tier (low, medium, high, unknown) and a posture (proceed, review, escalate). The posture is the recommended action; the tier is the colored label.
Six signal categories
Every signal the engine evaluates falls into one of six categories. The number next to each name is the category's weight in the final scorecard. Higher weight means a stronger pull on the final score.
Direct or counterparty exposure to sanctioned addresses, mixers, hack-proceeds wallets, and other named high-risk entities. This is the strongest category by weight because the regulatory implications are unambiguous.
- Wallet appears on OFAC SDN list
- Counterparty matches a known mixer protocol (Tornado, Sinbad, Railgun)
- Counterparty matches a publicly attributed hack (Bybit, Drift, Ronin)
Patterns in transfer velocity, structural routing, and counterparty topology that suggest distribution, layering, or obfuscation. None of these are misconduct on their own, but combinations of them raise review priority.
- Rapid outflow bursts
- Fan-out distribution to many recipients
- Multi-hop obfuscation chain
- Circular funding pattern
How dependent the wallet is on a single counterparty or single inbound source. Extreme concentration is a feature of payment processors, treasuries, and scam-distribution wallets alike; concentration plus other signals is what tips review.
- Single source supplies >99% of inbound value
- Top counterparty share over 50%
- Funding dependency concentration
Timing-based signals: dormancy followed by sudden reactivation, burst activity in a compressed window, velocity acceleration above baseline. Time-of-flight is harder to fake than topology alone.
- Burst activity (compressed window)
- Dormancy reactivation pattern
- Velocity acceleration detected
How complete the data view is. When transaction history hits the fetch cap or counterparty attribution is sparse, the engine reads the signal more conservatively. Coverage gaps don't increase risk; they reduce confidence.
- Transaction history capped by fetch limit
- Weak attribution coverage (<10%)
- Enrichment partial or unavailable
Positive context that improves trust: long observable history, large held balance, attributed interactions with reputable exchanges or known-good public entities. Stability support raises the score; it does not erase concurrent adverse signals.
- Established history (>1 year)
- Strong attribution coverage
- Known-good public entity context
Decision posture rules
The posture is not just a function of the score. A wallet scoring 70 with direct sanctions exposure still escalates, because category-level overrides can elevate posture above what the raw score implies. A wallet scoring 50 with no adverse signals but very thin data can still land in review rather than escalate, because the engine treats low coverage as low confidence, not as risk.
No dominant adverse drivers under current coverage. Behavioral context reads as stable. The wallet can be treated as routine, though higher-stakes interaction should always be paired with broader exposure intelligence.
One or more review-sensitive signals fired. This is not an automatic stop, but the current signal mix or confidence level is not strong enough to treat the case as routine without human review.
Direct sanctions exposure, hack-proceeds attribution, or a combination of adverse signals severe enough that proceeding without escalation creates unacceptable regulatory or operational risk.
Confidence is separate from score
Score answers "how risky is this wallet." Confidence answers "how reliable is the score." A 70 with 90% confidence is a different artifact than a 70 with 30% confidence, even though the verdict label is the same. Confidence is a function of signal quality and data coverage: how many transfers were observed, how much of the activity was attributed to named entities, whether the transfer history hit the fetch cap, and whether key snapshot fields (balance, age) resolved cleanly. Confidence below 45% is surfaced to the analyst as a caution; it never silently changes the verdict.
Coverage and the Insufficient Signal verdict
CredScore returns a meaningful behavioral verdict on any wallet with five or more observable transfers on a supported chain. Wallets below that threshold — typically very new or unused addresses — receive an “Insufficient Signal” classification rather than a fabricated score. This is intentional: the engine’s deterministic design reports uncertainty when it exists rather than confabulating a number. When you see Insufficient Signal, the engine is telling you it doesn’t have enough behavioral evidence to call a verdict, not that the wallet is safe and not that it is risky.
In live screening workflows, expect approximately 5–10% of wallets to return Insufficient Signal under typical traffic. That share trends lower for wallets being actively investigated (which generally have meaningful activity) and higher for freshly-funded or single-use addresses. When CredScore returns Insufficient Signal, the recommended workflow is to either pair it with your primary screening tool’s read, defer the verdict until more activity accrues, or escalate based on off-chain context alone.
Supported chains as of the current engine version: Ethereum mainnet, Tron mainnet (USDT-TRC20 and TRX flows), Base, Arbitrum One, Optimism, and Polygon PoS. Coverage depth on each is equivalent at the transfer level. Roadmap chains are gated on signal-quality validation, not on customer count; CredScore ships a chain when the behavioral verdict on that chain is as reliable as on Ethereum, not before.
What the engine does not do
The engine does not use machine learning, large language models, or probabilistic inference in the scoring path. Briefing text is generated from the same deterministic signals, not from an LLM rewriting the output. Bridge, DEX, and aggregator activity are treated as operational context unless paired with stronger adverse signals; they are not, on their own, evidence of risk. Off-chain context (ownership, intent, legal entity attribution) is not in the engine's view, and the engine says so explicitly when it matters.
Versioning and reproducibility
Every analysis is stamped with the engine version that produced it. When the weighting model changes, the version increments and prior verdicts retain their original engine version stamp so an audit can replay exactly what the engine knew at the time. This is the "regulator-defensible" property: a verdict from six months ago is reproducible today using the engine version recorded with it.
This page is the methodology document. Print it, attach it to a compliance review, hand it to a regulator. The engine is open enough about its own logic that the score is defensible without having to defend "the model."
Run a wallet through the engine — free, no signup