Methodology / Honest boundaries
What the checks can establish
Know what each evidence layer can establish, and where a conclusion still depends on a source or user assertion.
Evidence checks in v1.0
Live collector receipts authenticate observed source records against a pinned key. Case review checks transaction IDs, public previous outputs and exact refund candidates. Public testnet collection includes signed public-source observations. Optional full-node proofs verify transaction Merkle paths and block-header hashes locally. Wallet exports support Ironwood and remain assertions. Provider-reported candidates and user-selected roles remain distinct from canonical-chain and wallet ownership proof. Export original evidence alongside the report for independent replay.
Evidence comes first
The original flow fixtures are illustrative. The mainnet inspection sample contains historical transaction bytes whose ID and public outputs are reproduced locally; it is not presented as a refund. The signed API sample is an authentic dry quote fetched on 12 October 2026 using dummy addresses. It created no deposit address or transaction. The importer verifies signed quote fields against the provider key pinned by SDK 0.1.26. Status fields and wallet context have separate, weaker trust labels. There is no chain consensus or wallet ownership verifier in this release. Zcash v4/v5 and NU6.3/NU7 v6 transaction content, including Ironwood, is decoded and checked against supplied IDs.
Four patterns it checks
Each rule is a small, separate check with its own tests. A flow fails only on a high-severity finding.
High
refund-address-reuseA refund goes back, unshielded, to a transparent address that funded a shield earlier in the same flow. This exposes a repeated address relationship in the supplied flow. It does not establish the real-world identity of its owner.
Medium
unjustified-unshielded-hopValue leaves the shielded pool between the shield and the settlement with no stated reason. Declare why the hop is needed, or keep the funds shielded.
Medium
timing-correlationA settlement lands within two minutes of the shielded intent. Short timing is a heuristic signal, not proof that an observer can identify the sender.
Info
turnstile-exposureA pool migration goes through the turnstile, which reveals the amount by design. Reported so you know about it, and not counted as a failure.
How Veylens relates to Zcash
| Component | Current implementation | Remaining work |
|---|---|---|
| Zcash flow concepts | Models shielding, unshielding, refunds, settlements, and migrations. | Validate records with a supported wallet or transaction source. |
| librustzcash | No dependency or direct integration. | Transaction decoding or wallet integration remains a separate milestone. |
| Zebra | Exported getrawtransaction data can be imported locally. | Independent chain anchoring and consensus validation remain missing. |
| NEAR Intents | Local 1Click quote/status import and pinned-key quote verification. | Authenticate on-chain execution and wallet context. |
| Cryptographic reports | SHA-256 digest and Ed25519 signature. | Evidence authenticity and signer trust are separate requirements. |
| Competition fit | Intended for Core and Tooling, based on the supplied brief. | Official eligibility, originality, deadline, and requirements need organizer confirmation. |
Resources are not automatically mandatory integrations
The brief supplied in the conversation lists developer docs, ZIPs, librustzcash, Zebra, a reference wallet, and NEAR Intents as resources. It does not establish that every submission must integrate all of them. Adding unused dependencies would not demonstrate Zcash functionality.
Interpret findings carefully
Refund reuse identifies matching address strings in a declared sequence. A transparent-hop finding depends on supplied events and its optional reason. Timing uses a 120-second heuristic, without measuring an anonymity set, comparing asset values, or proving public observability. Turnstile exposure uses a supplied flag, rather than decoding a migration transaction.
“Insufficient evidence” means chain evidence is incomplete, regardless of whether a configuration risk matched. A high-severity result refers to the declared source/destination relationship and is still not a verified on-chain leak. The original flow path also returns insufficient evidence when no high finding matches.
Privacy of the tool
The application bundle has a default-deny content policy and same-origin lookup access when requested. Navigation and ordinary hosting requests still reach the host. Lookup identifiers and their bounded previous-transaction requests reach the collector and its configured source. Local imports and address inspection remain local. Public explorer observations do not establish canonical-chain membership. Downloads contain findings, event identifiers, and the flow identifier. Review those before sharing. The intro preference uses session storage. An explicit verifier handoff keeps source and report in this tab for at most two minutes and is consumed on arrival. Optional local case snapshots use passphrase encryption. No evidence is saved automatically.
Historical case and source status
The earlier build cites a reported CrossPay refund issue. This release preserves its fixture for reproducibility but does not claim the original vulnerability remains open. The historical report is a research lead, not independently verified chain evidence.
Historical report cited by the original build
Open full size Cryptopolitan’s coverage of the disclosure.
Open full size Illustration credited to ZachXBT in the report.
Official technical resources
Next evidence milestone
Zcash transaction bundles now import with raw identifier checks, exact transparent outputs, and source-digest replay. Next are independently anchored chain records, wallet evidence, and an attributed real refund example. The signed dry quote authenticates configuration only.
Open workspace