de9a79298c
Zero dependencies, no account, no API. Every command takes --rpc, so it runs against a node you operate and never needs ours. That is the point: an exposure measurement you cannot re-run is an opinion with a logo on it. Ships with two self-checks meant to be run by you, not just by us. The second, proba-vocabular.mjs, exists because of a real defect found on 2026-08-16: the scanner emits RED / YELLOW / GREEN, two downstream files each wrote their own copy of that list, and both wrote AMBER, so a hybrid contract, exactly a client who has already started migrating, was reported as unmeasurable. Both sides were self-consistent, so nothing we had could see it. The vocabulary now has one exported source, and the test walks the whole path with a negative control that makes it able to fail. The same scanner returns RED about our own contracts. See VERIFY-US.md.
49 lines
2.6 KiB
Markdown
49 lines
2.6 KiB
Markdown
# Check us, do not trust us
|
|
|
|
This toolkit exists so that nothing we say about quantum exposure has to be taken on faith,
|
|
including what we say about our own chain.
|
|
|
|
## Run it against a node we do not control
|
|
|
|
node scan.js <address> --rpc https://your-own-node
|
|
|
|
Every command here takes `--rpc`. None of them requires our endpoint, our API, or an account with
|
|
us. If your number differs from ours, that difference is the interesting part and we want to hear
|
|
about it.
|
|
|
|
## Run it against us, and expect it to be unkind
|
|
|
|
The same scanner that produces a client report produces our own findings, and it returns RED about
|
|
our own contracts. Measured 2026-08-16 on three of our live addresses: two GREEN, one RED. A vendor
|
|
whose tool has never returned a red verdict about the vendor is selling a brochure.
|
|
|
|
## Prove that the tool can fail
|
|
|
|
Two self-checks ship with it, and both are meant to be run by you, not just by us:
|
|
|
|
node selftest.js the analysis fixtures, including cases the scanner used to get wrong
|
|
node proba-vocabular.mjs every verdict survives the whole path from scanner to client wording
|
|
|
|
The second one exists because of a real defect. The scanner emits RED / YELLOW / GREEN, and two
|
|
downstream files each wrote their own list of those words, and both wrote AMBER. So a hybrid
|
|
contract, which is exactly a client who has already started migrating, was being reported as
|
|
"we could not measure this address". Both sides were self-consistent, so no test we had could see
|
|
it. The fix was to give the vocabulary one exported source that the consumers call.
|
|
|
|
That test carries a negative control on purpose: an input with no verdict must still come out as
|
|
NOT MEASURED. Without it, the test would pass even if the reader returned a constant, and would
|
|
prove nothing. You can verify that claim yourself: change `VERDICTE` in `lib/bytecode.js` to
|
|
contain AMBER instead of YELLOW, run `node proba-vocabular.mjs`, and watch it exit non-zero.
|
|
|
|
## What the tool does not do
|
|
|
|
It reads bytecode and what that bytecode can reach. It does not read your repositories, your TLS
|
|
configuration, your dependencies, your key custody or your HSMs. When it cannot settle a question
|
|
from bytecode alone, it says so in the output with a `[VERIFY]` or `[MEASURE]` marker, and every
|
|
report that uses it carries those markers through word for word instead of smoothing them away.
|
|
|
|
A live post-quantum verifier reachable from a contract does **not** make that contract
|
|
quantum-safe. If the transaction that calls it is authorised with ECDSA, an adversary forges the
|
|
outer transaction and the verifier is irrelevant. Anyone selling you the opposite can be taken
|
|
apart in five minutes.
|