Does your wallet keep coins separate?
Check what happens after a payment, after spending the change, and after restarting the wallet.
Run 27 shared policy cases with Python. Then connect your wallet's test exporter, check an independent auditor, or reproduce payments on regtest.
Python 3.10+ · No packages to install for offline checks · Release & checksum
- Start with two labeled coin poolsA payment may spend from only one.
- Pay, then classify the changeThe change keeps the same pool label.
- Restart, then pay againThe saved wallet must retain its labels.
- Refuse an unsafe top-upInsufficient eligible coins means refusing, even if the other pool has enough.
One command.
No node needed.
Extract the ZIP and open a terminal in the folder containing START_HERE.md and test_policy.py. On Linux or macOS:
python3 conformance.pyWindows PowerShell command
“Extract All” may create two nested folders with the same name. Open the inner one containing conformance.py.
py -3 conformance.pyExpected: 27 cases checked, 27 passed. The report compares each expected outcome with the auditor's result, including deliberate pool merges and invalid evidence.
Ready for fresh transactions? Follow the isolated regtest instructions. To use your wallet's evidence, start with the trace format.
What has been
observed so far.
Author's local run · September 25, 2026
Bitcoin Core 31.1 · Linux / WSL
Configured rates: 1, 10, 50 sat/vB
| Controlled scenario | Observed result |
|---|---|
| Payments from the selected pool | 6 confirmed |
| Saved-wallet restarts | 3 preserved labels |
| Fee, balance or missing-label refusals | 9 expected refusals |
| Deliberate pool merges | 3 detected |
Raw transactions, results & provenance · Offline CI results
This is developer research tooling. The live fixture uses synthetic labels and an explicit coin-selection adapter. It does not run a privacy protocol, measure anonymity, or establish that a production wallet is safe. The offline audit relies on the labels and history supplied by its exporter.
Your wallet's facts.
A repeatable check.
Export raw transactions, initial pool labels and payment requests from a synthetic wallet test. The bridge derives the transaction details and checks the supplied history. Everything runs locally.
python3 export_trace.py example-export.json --output example.trace.json
python3 audit.py example.trace.jsonConnect an exporter or an independent checker →
The included example is unsigned synthetic data. This is a draft project format; passing its cases is not wallet certification. The kit adds no service or transaction step for wallet users. Fees, insufficient eligible funds and lost labels still need to be tested in the wallet.
Would you use this
in a wallet test?
Tell us what ran, where you got stuck, or which wallet behavior you need to check. A reason to pass on it is useful feedback too.
GitHub account required to post. Reports are public: share only synthetic evidence, never wallet files or private transaction histories. Independent reproductions and concrete integration requests are the next milestones.