Build / SDK conformance
One call.
What happens next?
Do the FLOP SDKs behave as documented? Run the published packages against scripted responses. See every retry and every mismatch.
pnpm --filter @flop-lab/sdkconf start runOffline runner · pinned releases · no wallet required
01 / Follow the evidence
A retry is another request.
This recorded class handshake sends the unpaid request again before attaching proof. The server responses and payment are synthetic.
- 1POST /v1HTTP 402
Initial request
+0.11 ms from scenario start - 2POST /v1HTTP 402
Request repeated
+0.32 ms from scenario start - 3POST /v1HTTP 200
Payment proof attached
+0.49 ms from scenario start
02 / Coverage
Package × behaviour
These are scenario outcomes, not an SDK-wide certification. README claims, type contracts and issue regressions are labelled in each check.
| Behaviour | Gateway client0.2.1 | Chain SDK0.4.0 | Network CLI0.4.0 | Python SDK0.2.0 |
|---|---|---|---|---|
| Discovery | · | · | · | |
| Validation | · | · | · | |
| POST retry | · | · | ||
| Cancellation | · | · | · | |
| Replay identity | · | · | · | |
| Faucet refusal | · | · | · | |
| Retry bounds | · | · | · | |
| 402 handshake | · | · | · | |
| README example | · | · | · | |
| Worker capacity | · | · | · | |
| Wallet reporting | · | · | ||
| CLI startup | · | · | · | |
| MCP | · | · | · | |
| HTTP health | · | · | · |
03 / Inspect and reproduce
Open the request trace.
9 checks shown
What this does not verify
These checks do not establish live service behaviour, duplicate payments, wallet creation on chain or settlement finality. Faucet refusals, payment challenges and chain calls are synthetic. CLI coverage is limited to startup and help. Python coverage is limited to async health.
The model feed and MCP response were recorded from public services. They are fixed fixtures, not current devnet measurements. No hosted MCP client is documented by the pinned SDKs; the shared flop-lab MCP client checks that fixture separately.