A rules-based v1 system, not a machine-learning model and not a certification. Every signal below maps to something specific and inspectable — nothing here is a black-box number. For payment/auth mechanics instead of scoring logic, see auth.md.
Only two kinds of data feed this: a merchant wallet's observable on-chain settlement history, and its x402 activity — what it charges, how often it's paid, by how many distinct payers. Nothing here is self-reported, manually reviewed, or sourced from off-chain reputation. A merchant can't improve its own score by filling out a form.
Every real finding adds one entry to reasons and one matching code to risk_flags. Two of six are currently dormant, one is stubbed — stated plainly here, not glossed over.
Flags wallets younger than 14 days. A merchant that's only existed for a few days has no track record to speak of, independent of anything else about it.
Compares unique payers against total transaction count. Below a 0.3 ratio, volume looks concentrated among very few payers — consistent with wash volume. One override: 50+ distinct payers skips this check regardless of ratio, since a high-frequency-use API naturally drives the ratio down without real concentration risk. Both numbers are calibrated against real production data — the ratio checked against 365 live merchants, the payer floor set comfortably under where real PROCEED-tier merchants top out.
Once live: flags a merchant whose quote→pay→deliver flow gets abandoned more than 35% of the time. Currently dormant on both chains — neither ingested data source populates completed/abandoned flow counts yet.
Flags zero refunds despite meaningful volume (20+ transactions) and nonzero refund-eligible volume. Zero refunds at real volume isn't automatically suspicious, but it's a visible absence of recourse worth surfacing.
Once live: flags a merchant charging different requesters different prices for the identical resource. Currently dormant on both chains — no ingested source populates per-payer price observations yet.
Meant to catch anomalous spikes in volume or transaction size. Not yet implemented on either chain: Solana settles roughly 4x faster than Base, and a threshold tuned on Base activity would over-flag normal Solana usage — this gets implemented chain-aware, not retrofit after the fact.
The rule is a direct count, not a weighted score.
No findings at all. Also gets one explicit positive reason recorded — not just a bare “nothing wrong found.”
Exactly one finding fired. Worth a closer look, not a hard stop.
Two or more findings fired. The strongest tier this pipeline currently produces.
trust_tier (TRUSTED/CAUTION/AVOID) is the detailed read; recommendation (PROCEED/CAUTION/INSUFFICIENT_SIGNAL) is the smaller, deterministic vocabulary an agent's payment policy is meant to switch on directly. They're not the same axis:
There's no REJECT or BLOCK value. Nothing in this pipeline currently produces evidence strong enough to justify a hard block — adding one without that evidence would just be a stronger-sounding guess than the data supports.
confidence is graduated separately from the sufficiency gate above: HIGH
at 50+ transactions, MEDIUM at 15+, LOW below that. A wallet can clear the
5-transaction sufficiency bar and still only warrant LOW confidence.
payer_concentration (LOW/MEDIUM/HIGH) is derived from the same diversity ratio and
50-payer override as signal 2 above — deliberately reusing the identical numbers, so this field can never say
HIGH concentration while risk_flags stays silent on it.
When a caller supplies a price (or the merchant has its own advertised price on file), it's compared against the median of comparable prices from other merchants in the same category. Fewer than 3 comparable prices returns unknown rather than a forced answer.
These bands come from real observed spread across six categories and roughly 400 priced merchants, not an arbitrary percentage — categories like "data_api" bundle genuinely different resources at genuinely different price points, so the bands are wider than a single-product market would need.
Stated plainly, not buried.
None of this is a certification of any merchant's legitimacy. It's an algorithmic read of public, observable signals — decision support for an agent's own payment policy, not a substitute for it.