Loading…
Proof
Noa cannot stop an action that never reaches it.
Five examples of bad signatures, keys or text that this site's receipt checker rejects. A receipt checker is also called a verifier. You can try it in the playground. The sixth card links to the public comparison of verifier results; it is not another bad input. These checks detect changes to signed bytes. They do not prove who held a key, what a person understood, or that a payment happened.
Live today: the open-source receipt checker. Open-source reference: the Gate prototype. The vault guard is being built: its verification specification and test vectors are public in noa-mandate-core; the guard itself is not yet available. all four rules are required.
Ed25519 is the signature method used here. These test cases build seven other valid-looking signatures over the same message. The cofactored check, which RFC 8032 allows, accepts them; the strict check rejects them.
Why it matters — If two receipt checkers give different answers for the same receipt, nobody can rely on the result. Ours uses the strict check, in Node and in the browser.
Test result. The Node verifier and the browser verifier reject all seven tested look-alikes.
[8]S′B = [8]R′+[8]k′A holds → a cofactored verifier accepts it, ours rejects itA public key lets someone check a signature. These eight test keys use weak mathematical points, rather than a suitable signing key.
Why it matters — A weak key can defeat the check that is supposed to keep forged signatures out.
Test result. All eight tested weak keys are rejected before signature checking.
8/8 small-order encodings tested → 8/8 rejectedA signature contains numbers. One number, called S, must be smaller than the limit L. These tests supply a number outside that range.
Why it matters — Skipping this limit can allow another form of the same signature.
Test result. The verifier rejects S ≥ L, including the tested S + L case.
S′ = S + L (still < 2²⁵⁶) → rejected by an explicit pre-check, not curve mathA public key has a fixed byte format. These tests supply a coordinate, called y, outside the permitted range.
Why it matters — Different tools might read those invalid bytes differently.
Test result. The verifier rejects y ≥ q, where q is the field limit, including y = q.
y = q (boundary) and y = 2²⁵⁵−1 (all-0xff) → both rejectedBase64 is a way to send bytes as text. These tests add spaces, newlines or invalid padding to that text.
Why it matters — Accepting extra characters would allow more than one text form for the same signed bytes.
Test result. The decoder refuses these malformed text forms before checking the signature.
embedded space · extra '=' padding · embedded newline · non-canonical padding → all rejectedA verifier is a tool that checks a receipt. The public matrix records checks for TypeScript, Python, Go, Rust and C#.
Why it matters — The ports use different test sets. Python is compared with TypeScript; Go, Rust and C# are compared with Python. This is not evidence that five independently built tools passed one identical test set.
Evidence limit. The matrix was publicly available on 2 October 2026. The captured evidence does not establish a fresh successful conformance CI run for all five ports.
PUBLIC MATRIX · observed 2026-10-02 · different test sets; chained comparisonsBrowser and Node checks
Vectors 01–05 run against both the canonical Node verifier and the browser-swap verification module the /playground client bundle uses — asserted identical on every push to main and every pull request into main, in this site's own CI.
Public verifier comparison
The matrix was publicly available on 2 October 2026. It records different test sets and comparisons between ports. The captured evidence does not prove a fresh successful automated test run for every port.
Read the spec. Verify the receipts. Trust nobody's word for it — including ours.
Open-source, Apache-2.0. The rejection rules and the verifier are both public.