Cashu Fault LabCashu delivery fault injection and recovery evidence
Make Cashu delivery fail safely.
Inject response loss, retries, duplicates, and process crashes across real wallets and mints—then prove every implementation converges.
npx cashu-fault-lab demo- Seed
- cashu-fault-lab-v0.1.2-demo
- Fault program
- http-response-lost
- Evidence
- 18 invariants
- Outcome
- ✓ passed
Deterministic fault trace
A lost response is not a lost result.
The lab repeats the exact delivery after transport ambiguity, then checks proof state and durable credit before it calls the run converged.
- 01Reserve proofs
- 02Send delivery
- 03Response lost
- 04Exact retry
- 05Recover proofs
- 06One durable credit
Reviewed demo artifact
Evidence, not a success boolean.
This report is retained from the reviewed v0.1.2 demo. Commands, proof secrets, and arbitrary evidence payloads never reach this page. It is example evidence, not a v0.1.2 qualification result.
- Seed
- cashu-fault-lab-v0.1.2-demo
- Commands
- 3
- Timeline observations
- 14
- Invariants evaluated
- 18
- Passed15
- Failed0
- Not observable0
- Not applicable3
Invariant evidence states
Every evaluated invariant remains visible; unsupported observations are never promoted to passes.
Requires context
Unavailable or out-of-scope observations, with the reason kept visible.
- No false rejection after possible consumption
no-false-rejection-after-possible-consumptionEvidence basisDerivedNot applicableNo rejected receipt was observed.
- Crash recovery
crash-recoveryEvidence basisDerivedNot applicableThe scenario does not restart a component.
- Transport convergence
transport-convergenceEvidence basisDerivedNot applicableThe scenario does not use multiple transports.
Supported by reviewed evidence
Checks supported by the artifact’s declared evidence basis.
- At most once redemption start
at-most-once-redemption-startEvidence basisAdapter claimedPassed - At most one merchant credit per request
at-most-one-merchant-credit-per-requestEvidence basisAdapter claimedPassed - At most one merchant credit per delivery
at-most-one-merchant-credit-per-deliveryEvidence basisAdapter claimedPassed - Proof set exclusivity
proof-set-exclusivityEvidence basisAdapter claimedPassed - Delivery identity immutability
delivery-identity-immutabilityEvidence basisAdapter claimedPassed - Exact net amount
exact-net-amountEvidence basisAdapter claimedPassed - No premature settlement
no-premature-settlementEvidence basisAdapter claimedPassed - Monotonic receipts
monotonic-receiptsEvidence basisDerivedPassed - Stable duplicate response
stable-duplicate-responseEvidence basisAdapter claimedPassed - Eventual terminal or recovery state
eventual-terminal-or-recovery-stateEvidence basisDerivedPassed - Retry convergence
retry-convergenceEvidence basisDerivedPassed - Independent mint evidence
independent-mint-evidenceEvidence basisAdapter claimedPassed - Independent ledger evidence
independent-ledger-evidenceEvidence basisAdapter claimedPassed - Reproducibility
reproducibilityEvidence basisDerivedPassed - No unsupported pass
no-unsupported-passEvidence basisDerivedPassed
Repository fault programs
Explore fault scenarios
Choose a deterministic break point, inspect its exact command sequence, and link every run back to reviewed JSON.
32checked-in scenarios
- RETRYResponse loss and retry
Lose requests or responses across HTTP and Nostr, then repeat the exact delivery.
04 programs - RECOVERCrash recovery
Restart senders and receivers around persistence, settlement, and receipt boundaries.
15 programs - RACEDuplicate and concurrency
Challenge single-use guarantees with duplicates, conflicts, and concurrent delivery.
09 programs - BOUNDARYSecurity and malformed transport
Probe malformed input, CORS, redirects, and server-side request boundaries.
04 programs
What gets tested
Ambiguity at the delivery boundary.
The lab controls faults and observes outcomes while wallet and mint implementations keep their native behavior.
Response loss
Drop the transport response after a receiver may already have accepted the proofs.
Exact retries
Repeat one immutable delivery identity and payload instead of creating a second payment.
Duplicate delivery
Send the same delivery more than once and verify that side effects remain singular.
Process crashes
Restart senders and receivers at persistence boundaries, then inspect durable recovery.
cashu-delivery-v1 flow
One identity from reservation to recovery.
An experimental application profile makes retries observable without changing the underlying Cashu or Nostr protocols.
- 01
Reserve
Bind one proof set to one immutable delivery identity.
- 02
Deliver
Send the exact payload over a declared transport.
- 03
Observe
Record receipts, proof state, ledger credit, and fault history.
- 04
Converge
Retry or recover until one terminal, evidence-backed result remains.
Invariant coverage
Safety, liveness, and independent evidence.
18structured invariant results in every artifact
- SafetyNo duplicate credit, proof reuse, or mutable delivery identity.
- LivenessRetries and recovery reach a terminal state.
- EvidenceMissing observations stay not observable; they never become passes.
Adapters
Bring the implementation. Keep its behavior.
Language-neutral HTTP adapters expose wallet capabilities and test controls. The lab does not require cashu-ts, CDK, or another implementation to share its runtime.
Integrate an adapterSecurity boundary
The implementation does not judge itself.
The independent oracle consumes adapter observations and lab-controlled transport, ledger, and mint evidence. Reports expose counts and safe references—not proof secrets or arbitrary evidence values.
Review the threat modelRelease status
Useful evidence. Not certification.
The checked-in delivery-v1 policy requires 2 qualifying implementation pairs and 2 distinct mints. Current signed qualifying matrix evidence: 0 pairs and 0 mints.
Inspect the blocked release gateContribution