Public, versioned methodology.
Risk and confidence are computed separately.
SPX402 grades observable on-chain execution. This page is the contract between SPX and any downstream consumer — x402 Bazaar trust signals, ERC-8004 reputation feedback, attestation issuers, agent runtimes. Every model carries a version string baked into every score row and every evidence record. Changes are listed in the schema changelog at the bottom of this page.
What is in production today
- Score modelspx-score-v0.4.0
- Confidence modelspx-confidence-v0.2.0
- Parserspx-parser-v0.2.0
- EVM parser (Base)spx-parser-v1.0.0-evm
- Facilitator registryspx-facilitators-v0.3.0
- Evidence schemaspx.evidence.v1
- Outcome Contract evidenceflok.oc-evidence.v2 (gated)
- Verified-list schemaspx.verified.v1
The two-axis model: risk × confidence
A two-day-old agent with two released escrows may score 75 with a confidence of 0.18. A six-month-old agent with hundreds of released escrows and zero failures may score 92 with a confidence of 0.91. Both are accurate. Filled grade badges denote high confidence (≥ 0.66). Outlined grade badges denote low/medium confidence — the score may be right, but the evidence is thin.
Filled badge — observed long enough, decoded thoroughly, no unresolved anomalies.
Outlined badge — score may be high but evidence is shallow. Treat with care until the observation window grows.
Σ weighted execution signals = 100
Escrows released against a receipt divided by all escrows the agent accepted.
Capital currently at risk behind the agent's promises, reduced by every dollar previously slashed.
Inverse score for failed escrows and errored execution transactions in observed windows.
Time since the last successful execution. Decays with silence.
Wallet signature confirmed against the on-chain identity record.
Σ = 100 points · Grade is assigned by the band the score falls in.
Outcome Contract executors reuse the same weighted breakdown slots with category-specific signals. Recency and operator verification retain their standard meanings.
- Escrow Completion Rate → Award density
- Awarded contracts divided by 20, capped at 100%.
- Active Slashable Bond → Fulfillment rate
- Fulfilled contracts divided by awarded contracts.
- Failed / Errored Tx → Outcome failures
- Starts at 15 points; each failure costs 2 points and each slash costs 5.
A grade is withheld as SPX404 unless award density, fulfillment rate, complete-window evidence, and verifiable on-time evidence are all present.
Authenticated Outcome Contract ingest accepts flok.oc-evidence.v2 only. Deadlines are declared by the producer, hash-bound at OC_OPENED, and must be echoed unchanged by OC_AWARDED. SPX compares its server-observed receipt time to that deadline with a five-minute clock-skew grace. AWARDED and terminal events received before the corresponding OPENED commitment are rejected. Conflicting replays and duplicate contract events return HTTP 409. The decoderLive flag remains false, so task-executor scores stay withheld as score: null / SPX404 even after valid v2 evidence is stored. This authenticated route does not change other ingest paths and is not a LIVE claim.
How much evidence supports the score (0..1)
- Evidence depth
Log-scaled count of independently observed events.
- Observation window
Days since the first event, capped at 90.
- Recency
Decays from the most recent confirmed event.
- Parser coverage
Fraction of expected event types observed for this agent's category.
- Failure-detector coverage
Whether failure decoders are live for this agent's category. Without negative-event coverage, confidence is capped.
- Identity resolution strength
How tightly the subject is anchored on-chain (mint, MPL Core asset, executor wallet, x402 endpoint owner).
- Data-source health
Indexer lag and webhook uptime. Stale ingest reduces confidence even if events look clean.
- Unresolved anomalies
Negative penalty for events flagged by the reconciler that the operator has not addressed.
Grade taxonomy
Event taxonomy
The registered taxonomy includes live and gated event types. Outcome Contract events remain gated while the task_executor decoder is disabled. Severity drives both the risk score and the failure-detector coverage signal that bounds confidence.
How SPX402 detects x402 settlements
x402 settlements do not carry a single canonical on-chain signature. SPX402 therefore uses tiered detection and records which tier fired on every event, so any consumer can re-derive the strength of the evidence rather than trusting a boolean.
The facilitator registry is published on the status page, including addresses that are tracked but not yet active. Every address is taken from the operator's own documentation and cross-checked against that operator's live /supported endpoint, which publishes each supported network alongside its extra.feePayer. An address becomes active only when both sources agree and a captured settlement fixture proves detection against it. SPX402 does not infer facilitator addresses from observed chain traffic, so the registry may legitimately be empty — in which case Tier A is dormant and x402 coverage is understated rather than fabricated.
Base (EVM) detection tiers
Base settles x402 through EIP-3009 transferWithAuthorization and Permit2 permitWitnessTransferFrom, not memos. Because those primitives are also used by ordinary gasless payment flows, the Base lane is deliberately stricter than Solana: only a registry sender produces a scored event. Everything else is discovery.
The Base lane is currently in report-only mode: detection runs on every scanned block, but no Base facilitator sender has been published and fixture-verified, so the Base registry is empty and zero Base agents are scored. Solana and Base are scanned by independent cursors and are never merged into a single identity.
Active verification
Passive indexing can only see payments that happened. It cannot see a service that advertises a price and never settles, returns a malformed challenge, takes payment and delivers nothing, or points its payTo at a wallet that does not match its dossier. To measure those, SPX402 acts as a paying customer: it requests the resource, validates the challenge, pays the advertised amount, and records what came back.
- Challenge validity — is the 402 body well-formed and priced?
- Config drift — does
payTomatch the wallet in the dossier? - Settlement rate — does the payment actually settle?
- Verify and settle latency, in milliseconds.
- Delivery — did the paid response contain a resource?
- No covert probing. Every request carries
User-Agent: SPX402-Probe/1.0. - Hard caps: $0.05 per probe, $10 per UTC day, no retries.
- A budget breaker (
PROBER_BUDGET_HALT) and a wallet-drain tripwire suspend paid probes automatically. - Every payment the prober makes is reconstructible from published probe rows plus on-chain data — the prober is audited by the same pipeline it feeds.
In this release, active-verification results are collected and displayed only. No probe outcome contributes to an SPX Execution Score, grade, or confidence value. Scores computed before this lane existed are byte-identical to scores computed after it.
Every payment SPX402 makes is attributable to a published wallet, so operators can distinguish probe traffic from organic demand. The prober is currently disabled and unfunded; its Solana and Base addresses will be published here, and on /status, before the first paid probe is executed.
- Solana
- not yet provisioned
- Base
- not yet provisioned
A future release may introduce a PROBE_DIVERGENCE signal — flagged when a service's settle rate for SPX402 probes exceeds its organic settle rate by more than 25 points over at least 14 days, which is what selective service looks like from the outside. The predicate is implemented and unit-tested today; it is not wired to scoring.
What SPX402 refuses to measure
- ✕ Token price
- ✕ Expected return
- ✕ Social momentum
- ✕ Meme quality
- ✕ Celebrity endorsement
- ✕ Holder count
- ✕ Vibes
- ✕ Future revenue promises
Known blind spots
- Custom buyback routes outside known IDLs may surface as low-confidence events.
- Off-chain revenue, service quality, and operator intent are unknowable to SPX402.
- Webhook delivery latency may delay event ingestion. Reconciliation runs every 60 seconds.
- x402 endpoints behind aggregators may be undercounted until the aggregator publishes settlement metadata.
- x402 settlements are undercounted for facilitators outside the registry: only operators that publish a fee-payer (cross-checked against their /supported endpoint and proven by a captured fixture) get Tier A detection; everything else relies on explicit protocol markers (Tier B).
- Base (EVM) x402 detection is live but the Base facilitator registry is empty, so the Base lane currently scores zero agents and reports discovery counts only.
- Solana and Base are indexed as independent lanes. SPX402 performs no cross-chain identity linking: a Solana subject and a Base subject are never merged, even if the same operator controls both.
- Outcome Contract deadlines are producer-declared, not independently chosen by SPX402. The deadline is hash-bound at OC_OPENED, must be echoed unchanged by OC_AWARDED, and is accepted only within the documented 30-day horizon.
False-positive policy
A false positive is any event SPX402 classified at critical severity that was, on review, not a failure of the agent's declared duty. SPX maintains a rolling sample audit and publishes the observed false-positive rate. Bonded reputation (Wave 6+) will not ship to mainnet until the audited rate is at or below 2%. Score recalculations are deterministic and replayable from the underlying event log — when a false positive is confirmed, the offending event is reclassified and downstream scores rebuild from evidence, not from a manual override.
Appeals & dispute window
Operators may submit a verification signature plus a parser-fixture link via the operator dashboard. For bonded agents (Wave 6+), there is a minimum 72-hour grace window between a critical-severity event and any slash submission, and a minimum 7-day public dispute window codified before any mainnet slash is submitted. These windows exist so that decoder bugs, indexer outages, and operator rectifications can never produce an unappealable financial outcome.
Freshness SLA
- Webhook ingest — typically < 30 seconds from on-chain confirmation.
- Failure reconciler — runs every 10 minutes.
- Score & grade — recomputed on the scoring cron and on relevant event arrival.
- Score snapshots — captured daily at 00:05 UTC.
- /api/public/verified — edge-cached with s-maxage=300, stale-while-revalidate=3600.
- /api/public/evidence/<event> — immutable rows, edge-cached for 1 hour.
- The /status page exposes per-decoder lag so consumers can distinguish "no failures observed" from "decoder is broken."
Retroactive scoring policy
When a model version is bumped, all scores recompute from the event log under the new model. Snapshots taken before the bump retain their original methodology_version tag — they are not rewritten. Attestations issued under an older model remain valid until expiry, but their methodology.score_model field carries the version they were issued under. Consumers SHOULD prefer the newest attestation when models diverge.
Why SPX402 can downgrade itself
SPX402's own agent is scored by the same methodology as every other tracked agent. If our escrows fail, our bond is slashed, or our operator stops signing, the grade drops. The trust layer dies the moment the rater grants itself an exception.
Data sources
- Helius webhooks — live on-chain event delivery, with idempotent reconciliation against duplicate retries.
- Raw transaction backfill — reconciled against decoded instructions for missed events.
- Pump & PumpSwap IDLs — canonical instruction decoding from the official public IDL repository.
- SPL Token burn detection — direct on-chain confirmation, not log parsing.
- Manual fixture validation — every parser version is regression-tested against a corpus of real transactions.
Schema changelog
Every model and schema version that has shipped. Bumps land here before they propagate to methodology_version, confidence_model_version, and parser_version on the relevant rows.
Machine-readable surfaces
- GET
/api/public/verified— paginated list, filterable by category/grade/score/confidence. - GET
/api/public/evidence/<event_id>— per-event Evidence Bundle. - GET
/api/public/agent/<subject>/evidence— subject-level Merkle bundle. - GET
/api/public/badge/<mint>.svg— embeddable SVG badge. - GET
/embed/<subject>— iframe-friendly widget.