Every claim is “this exact revision of this flow passed these properties at this height, and here is the evidence”. Evidence, not scores: re-run zanary-report verify <report.json> to falsify any row.
no anchor record beside this report — unanchored evidence is only as old as the file that carries it
6 evidence entries · merchant side simulated (stated)
the files behind this row: report.json — download one and re-run zanary-report verify on it
property
sev
verdict
what
payer-linkability
D
SKIP
clustering needs at least two payments by one payer (this run made a single payment; with one payment there is no pair to cluster)
policy-downgrade
D
PASS
the wallet layer was never told to relax its privacy policy
receiver-reuse
D
PASS
one payment, one fresh diversified Orchard receiver
transparent-fallback
D
PASS
the payment path is Orchard-only; no transparent address is accepted or produced by it
unshielding
D
PASS
value moved into the shielded pool; none left it
amount-fingerprint
W
FAIL
payment amount echoes a public funding amount: four 6.25 ZEC coinbase inputs, 24.9975 ZEC output (on a public chain the multiset of funding amounts would already be visible; on mainnet, fund the flow from a larger anonymity set or vary the funding amounts)
memo-absent
W
PASS
invoice 4471 is bound to its payment in a shielded memo a verifier can recompute
memo-content
W
PASS
the memo carries an invoice id and a receipt seed, nothing permanent and personal
same-block-roundtrip
W
PASS
funding and spending never share a block
server-metadata
W
PASS
the simulated merchant received the invoice id and the txid, and nothing that identifies the payer (merchant side was simulated by the rig; this is what the rig's own merchant observed, stated as such)
timing-correlation
W
SKIP
no repeat spend/funding pattern to correlate in this run (one payment, delay to nearest preceding inflow is 100 blocks; the correlation window is not exercised)
report-leak
N
SKIP
no receipt or report artifact was exported by this run (nothing to inspect for excess disclosure)
canary-checkout-control @ a7ade74d922a…live
chain regtest · verified at height 273 · verified_at 2026-10-10T21:05:00Z · ttl 30d · expires in 21d 11h
no anchor record beside this report — unanchored evidence is only as old as the file that carries it
6 evidence entries · merchant side simulated (stated)
the files behind this row: report.json — download one and re-run zanary-report verify on it
property
sev
verdict
what
receiver-reuse
D
FAIL
invoice 4470 was paid to the same receiver as invoice 4471 (the fix is a fresh diversified receiver per invoice; the rig's own second run deliberately re-uses one to demonstrate the regression)
payer-linkability
D
SKIP
clustering needs at least two payments by one payer (this run made a single payment; the pair analysis needs the previous run's observation set)
policy-downgrade
D
PASS
the wallet layer was never told to relax its privacy policy
transparent-fallback
D
PASS
the payment path is Orchard-only; no transparent address is accepted or produced by it
unshielding
D
PASS
value moved into the shielded pool; none left it
amount-fingerprint
W
FAIL
payment amount echoes a public funding amount: four 6.25 ZEC coinbase inputs, 24.9975 ZEC output (on a public chain the multiset of funding amounts would already be visible; on mainnet, fund the flow from a larger anonymity set or vary the funding amounts)
memo-absent
W
PASS
invoice 4470 is bound to its payment in a shielded memo a verifier can recompute
memo-content
W
PASS
the memo carries an invoice id and a receipt seed, nothing permanent and personal
same-block-roundtrip
W
PASS
funding and spending never share a block
server-metadata
W
PASS
the simulated merchant received the invoice id and the txid, and nothing that identifies the payer (merchant side was simulated by the rig; this is what the rig's own merchant observed, stated as such)
timing-correlation
W
SKIP
no repeat spend/funding pattern to correlate in this run (one payment, delay to nearest preceding inflow is 100+ blocks; the correlation window is not exercised)
report-leak
N
SKIP
no receipt or report artifact was exported by this run (nothing to inspect for excess disclosure)
a bounded payer stays inside its grant (this run had no bounded payer: nothing held a grant, so there is no authority to check against the ledger)
payer-linkability
D
PASS
payments are not clusterable by an observer (no pair reached threshold=0.70; highest pair confidence=0.20 across 2 payments)
policy-downgrade
D
PASS
no privacy-policy downgrade instructed or implied (every recorded policy token was checked against the downgrade fragments; none matched, and no shielded→transparent/cross-pool spend was observed)
receiver-reuse
D
PASS
no receiver reused across distinct payments (no receiver repeats among 2 payments; note the spec calls for N>=5 payments (two payers, two amounts) for a meaningful reuse window)
transparent-fallback
D
PASS
no transparent address anywhere in the flow (checked 13 observed addresses (payment recipients/senders, funding receivers, observed values); none transparent)
unshielding
D
PASS
no value leaves the shielded pool (2 payments checked; no transparent pool_out, no shielded→transparent movement across 2 pool snapshots, no transparent hop between shielded legs)
amount-fingerprint
W
PASS
amounts do not fingerprint deposits or repeat (2 payments checked against 11 funding events; no round, repeated or echoed amounts (epsilon=5000 zat))
memo-absent
W
PASS
invoice-bearing payments bind their invoice in a memo (2 invoice-bearing payments checked; every one carries a memo that contains its invoice id)
memo-content
W
PASS
memos carry no PII or free text (2 memo(s) decoded and scanned for emails, phone/gov-id shapes, long digit runs, key-like labels and free text; none flagged)
same-block-roundtrip
W
PASS
funding and spending do not share a block (2 spend(s) checked against 11 funding event(s); no shared heights)
server-metadata
W
PASS
merchant side receives no payer identity or linkage (2 merchant-side request(s) checked for identity fields, identity-shaped values, and cross-payment linkage; none found)
timing-correlation
W
PASS
spends are not tightly correlated with their funding (2 spend(s) checked against 11 inflow(s); none within the 1 block window (delay 0 excluded by design))
report-leak
N
PASS
exported artifacts reveal no more than their claim (2 exported artifact(s) checked for excess disclosures, key material, unknown addresses and PII; none found)
zanary-ci-checkout-control @ 05cc6aeb22eb…live
chain regtest · verified at height 134 · verified_at 2026-10-19T10:03:03.355225244Z · ttl 30d · expires in 29d 23h
no privacy-policy downgrade instructed or implied (explicit fragments checked: AllowRevealedAmounts, AllowRevealedSenders, AllowRevealedRecipients, AllowLinkingAccountAddresses, AllowFullyTransparent and equivalents; negation prefixes (no/not/disallow/deny/without/block/never) are excluded. Implicit: shielded→transparent or shielded→mixed-bundle spends reveal amounts; zcashd refuses those by default with "…would reveal transaction amounts. THIS MAY AFFECT YOUR PRIVACY…".)
receiver-reuse
D
FAIL
no receiver reused across distinct payments (grouping is exact-string on recipient receivers; groups span distinct payment labels, so a retry of one invoice is not counted as two payments. Diversified unified addresses of one account are not detectable from address strings alone (documented model gap).)
payer-policy
D
SKIP
a bounded payer stays inside its grant (this run had no bounded payer: nothing held a grant, so there is no authority to check against the ledger)
payer-linkability
D
PASS
payments are not clusterable by an observer (no pair reached threshold=0.70; highest pair confidence=0.25 across 2 payments)
transparent-fallback
D
PASS
no transparent address anywhere in the flow (checked 13 observed addresses (payment recipients/senders, funding receivers, observed values); none transparent)
unshielding
D
PASS
no value leaves the shielded pool (2 payments checked; no transparent pool_out, no shielded→transparent movement across 2 pool snapshots, no transparent hop between shielded legs)
amount-fingerprint
W
FAIL
amounts do not fingerprint deposits or repeat (thresholds: round granularity=10000000 zat (0.1 ZEC), echo epsilon=5000 zat; near-echoes are flagged only when exactly one funding candidate exists (candidate count is reported per match).)
memo-absent
W
FAIL
invoice-bearing payments bind their invoice in a memo (binding = alphanumeric-lowercase containment between invoice id and memo plaintext, either direction. Memos are the only reconciliation channel a shielded payment has; without the binding the merchant falls back to transparent rails.)
memo-content
W
SKIP
memos carry no PII or free text (no memo bytes were recorded on any payment; there is nothing to inspect)
same-block-roundtrip
W
PASS
funding and spending do not share a block (2 spend(s) checked against 11 funding event(s); no shared heights)
server-metadata
W
PASS
merchant side receives no payer identity or linkage (2 merchant-side request(s) checked for identity fields, identity-shaped values, and cross-payment linkage; none found)
timing-correlation
W
PASS
spends are not tightly correlated with their funding (2 spend(s) checked against 11 inflow(s); none within the 1 block window (delay 0 excluded by design))
report-leak
N
PASS
exported artifacts reveal no more than their claim (2 exported artifact(s) checked for excess disclosures, key material, unknown addresses and PII; none found)
Regressions
A property that passed earlier now fails — both runs linked, because the failure is the finding.
receiver-reuseD passed at 8b4908e1a54a… (2026-10-10T20:30:00Z) and now fails at 904274f8bff5… (2026-10-10T21:05:00Z)