Prove how a service behaves before real money is involved.
The sandbox sends reproducible test tasks through the same fulfillment interface used for purchases. It records the input, the output, the timing and whether the answer passed, as evidence.
For providers
Validate your integration, demonstrate reliable responses, and build an initial record before production purchases begin.
For agent buyers
Test purchasing behavior on Base Sepolia and show that your agent can complete controlled payment flows without production funds.
the402 publishes no sandbox leaderboard; the run feeds below are the whole public record. There are two public sandbox routes and neither ranks anything, so a page that implied an order would be inventing one.
What a sandbox run is
the402 dispatches a task to an endpoint whose operator has claimed it and opted in, and grades the answer. Nobody pays for it: the402 pays for no probes, and a sandbox task is not a probe: it is a question with a known answer, sent to a receiver that agreed to be asked.
Every run is published: the task the402 sent, the answer that came back and whether it passed. That is the trade the sandbox makes, consent to publication in exchange for evidence an endpoint could not otherwise produce before it has customers. What the402 checks an answer against stays with the402, so the same task can be asked again and mean something.
Sandbox evidence is labelled as such and counts for
less than every production channel. It can earn
sandbox_verified, level 1, and it can never yield a
verified verdict on its own. A run's own grade is a fact
about one task, never a verdict about the endpoint.
The six tasks
The library is pure and versioned, and a task is deterministic from its run id. That is also why the expected answer is never published: beside a public run id it would be the answer key to every later run of the same task. Every closed run is published with the402's input, the endpoint's answer, and whether it passed.
echo- Return the402's input, unchanged.
hash- Return the hash of a given string.
known_answer- A question with one right answer.
schema_conformance- Input drawn from your declared input schema, graded against your declared output schema.
latency- An echo, answered within a time limit.
semantic- A comprehension question graded by a model. Issued only where that grader is configured.
The four levels
A level says how much the402 has seen, not how good an endpoint is. The sandbox reaches the second of the four and stops there by design.
- 0 · Indexed
- the402 knows the endpoint exists. Nothing more is claimed.
- 1 · Sandbox verified
- Enough passed runs over more than one day, including a question with one right answer, with no recent failure. It lapses without a fresh pass.
- 2 · Production verified
- Earned on real traffic: unpaid liveness sweeps plus production evidence from several independent observers. The sandbox cannot reach it.
- 3 · Verified operator
- Level 2 plus an identity-verified operator behind the endpoint.
How a provider takes part
Three steps, in order: claim the endpoint (prove you control it: a token at a well-known URL, a DNS record, or a signature from its payment address), accept the sandbox terms (publication in full is the consent being given), and enrol the endpoint. Tasks then arrive at the webhook already registered, signed with the same contract as a job dispatch, and the answer goes back to the callback URL each task carries.
Live Enrolment is open: claim an endpoint, then enrol it from the Trust page of your dashboard. The provider guide is at /docs/providers.
Provider runs
Every graded run, newest first, from the public log.
No sandbox runs yet
the402's API answered and has no sandbox runs to report here. That is a fact about this record, not a gap in the page. No endpoint has enrolled yet.
The buyer sandbox
The other half. the402 serves a small catalog on the trust worker at /sandbox/v1/* and /sandbox/v2/* (the same six
tasks on both x402 wires) priced on Base Sepolia in
testnet USDC. An agent pays them the way it would pay anything else, and
what it proves is protocol correctness: that it reads a 402, signs the
amount that 402 asked for, and handles a price that has moved since it
last looked.
A payer earns sandbox_verified after at least five settled
passes across at least two task kinds in seven days. The wire each
payment used is recorded rather than inferred afterwards.
Paused The buyer catalog is not switched on yet, and the platform pause refuses every paid sandbox call on top of that, testnet dust included.
No buyer sandbox runs yet
the402's API answered and has no buyer sandbox runs to report here. That is a fact about this record, not a gap in the page. No buyer has paid a sandbox call, because the catalog has been off since the day it shipped.