Version 1.0.0 · Public · Base mainnet · sentinel-agent.dev
SENTINEL is an agent-to-agent transaction safety oracle: it scores the trustworthiness of x402 payment counterparties so that an autonomous agent can decide whether to transact before it settles a payment. A rating is only as credible as the method behind it. This document states that method in full — what SENTINEL measures, how it weighs each signal, and the principles it will not compromise — so that any party relying on a SENTINEL score can examine the reasoning, not just the number.
Following the model of established rating agencies, the method is public even where specific inputs remain proprietary. The weights and rules below are the ones the system actually applies.
SENTINEL produces a score from 0 to 100 (higher is more trustworthy) in two directions:
Each score is issued as an ES256 attestation (JWS), verifiable offline against the public key at /.well-known/jwks.json (key id sentinel-2026-01), and is also published on-chain via the SentinelOracle for smart-contract composability.
The maturity component of the buyer score depends only on time — wallet age and days since first observed x402 payment — gated in steps at 7, 14, 30, and 90 days. No volume of payments accelerates it. This neutralizes trust-farming, the attack where many small legitimate payments inflate a score before a single large abuse.
A counterparty score blends seller behavior, buyer behavior, and facilitator reliability. If any single leg is critically weak, it caps the composite rather than being averaged away. A transaction is only as safe as its most compromised participant.
Every verified incident is recorded in an append-only, hash-anchored Default Registry. Entries cannot be edited or deleted — enforced at the database level, not by policy. A score marking a counterparty as risky links to the specific incidents behind it, so the judgment is auditable after the fact.
SENTINEL is a consumer-pays oracle. The agent asking for a score pays for it; the party being rated never does. An issuer-pays model — where a service pays to be rated — creates a structural conflict of interest that has damaged credit rating agencies before. SENTINEL prohibits it by design.
The buyer score (0–100) is a weighted sum of four components, with a hard floor imposed by verified incidents.
| Component | Weight | What it measures |
|---|---|---|
| History | 40 | Completed x402 payments, failure/revert rate, payment-size asymmetry |
| Maturity | 30 | Time only — wallet age and x402 tenure, stepped (§2.1) |
| Velocity | 15 | Payment cadence; robotic bursts and near-identical intervals penalized |
| Graph | 15 | Common-funder heuristic: recent shared funding with already-flagged wallets |
0d→0 · 7d→8 · 14d→14 · 30d→22 · 90d→30. Effective tenure is capped so a very old wallet with no x402 history cannot claim full maturity on age alone.
Verified incidents in the Default Registry (non-payment, replay abuse) override the weighted sum and force the score to a low ceiling. Conduct that has already caused harm cannot be outweighed by favorable surface signals.
For seller-side counterparties, SENTINEL actively probes live x402 endpoints without assuming a directory listing is truthful. It checks liveness, whether the 402 challenge is well-formed, whether a Base+USDC offer is present, and — critically — whether the price advertised in the discovery directory matches the price the endpoint actually demands. A mismatch is recorded as a dishonesty incident. Verification is done without paying; only conduct that is verifiably dishonest or non-delivering produces an incident, never a mere inability to complete a payment.
| Type | Meaning |
|---|---|
| non_payment | A buyer that fails to settle an authorized charge |
| replay_abuse | Reuse of a payment authorization / nonce |
| non_delivery | A seller that charges and returns nothing usable |
| quality_fraud | Advertised price or content does not match what is delivered |
An honest methodology names its own boundaries.
Beginning with the first score snapshot recorded on 2026-08-01, SENTINEL maintains a continuous, append-only history of the scores it issues. SENTINEL commits to publishing an annual Default Study — an aggregate review of how its scores related to subsequent observed outcomes — with the first study due July 2027. A rating agency should be judged by whether its scores were right, and this is the record that makes that judgment possible. The exact rules that study will follow -- what counts as a default, how scores are grouped, how mid-window changes are handled -- are pre-registered in the Default Study Methodology, published now, before any results exist.
SENTINEL Methodology v1.0.0. Reference implementation of the x402 trust-provider extension (issue #2299). This is sentinel-agent.dev, on-chain oracle 0x6841496c3e7eDF9eEB02bE64ab98CF5D5c5aF813, distinct from unrelated projects sharing the SENTINEL name. Machine-readable version at /methodology.json.