Port the Flutter SDK's api/wormhole.rs and quantus-cli's wormhole_lib.rs into wallet-data: ensure_circuit_binaries from a URL on our infra with a pinned BLAKE3 hash per circuits version, generate_proof on a dedicated thread with progress events to the UI, and aggregate_proofs for several leaves. The circuits version is a property of the chain profile.
Operator decision to record here before starting
Where the circuit binaries are hosted.
Acceptance
A proof for a Heisenberg reward leaf generates with a progress bar and verifies locally before submission. A binary with the wrong hash is refused and the UI says which file.
Depends on
The wormhole derivation child.
Parent: #9
## Scope
Port the Flutter SDK's `api/wormhole.rs` and quantus-cli's `wormhole_lib.rs` into `wallet-data`: `ensure_circuit_binaries` from a URL on our infra with a pinned BLAKE3 hash per circuits version, `generate_proof` on a dedicated thread with progress events to the UI, and `aggregate_proofs` for several leaves. The circuits version is a property of the chain profile.
## Operator decision to record here before starting
Where the circuit binaries are hosted.
## Acceptance
A proof for a Heisenberg reward leaf generates with a progress bar and verifies locally before submission. A binary with the wrong hash is refused and the UI says which file.
## Depends on
The wormhole derivation child.
grenade
added the child label 2026-09-15 12:41:58 +00:00
A constraint for this child, from the operator and from quantus/extension's experience: nothing that identifies which deposit is being spent may leave the client before the exit is submitted. Nullifiers are the obvious case (see the new leak issue under #9, where the wallet already gets this wrong). Proof generation adds a second one: the proof needs the Merkle path to the leaf, and zkTree_getMerkleProof(leaf_index, at_block) asks the node for that one index, which names the leaf, and a leaf carries its recipient and amount in the clear. Options to weigh before writing code: build the path locally from ZkTree::Nodes read in whole levels or large ranges, or ask for the target's proof among a shuffled set of decoy indices. Whichever is chosen, a test should assert the leaf index being spent never appears alone in a request.
A constraint for this child, from the operator and from quantus/extension's experience: **nothing that identifies which deposit is being spent may leave the client before the exit is submitted.** Nullifiers are the obvious case (see the new leak issue under #9, where the wallet already gets this wrong). Proof generation adds a second one: the proof needs the Merkle path to the leaf, and `zkTree_getMerkleProof(leaf_index, at_block)` asks the node for that one index, which names the leaf, and a leaf carries its recipient and amount in the clear. Options to weigh before writing code: build the path locally from `ZkTree::Nodes` read in whole levels or large ranges, or ask for the target's proof among a shuffled set of decoy indices. Whichever is chosen, a test should assert the leaf index being spent never appears alone in a request.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Parent: #9
Scope
Port the Flutter SDK's
api/wormhole.rsand quantus-cli'swormhole_lib.rsintowallet-data:ensure_circuit_binariesfrom a URL on our infra with a pinned BLAKE3 hash per circuits version,generate_proofon a dedicated thread with progress events to the UI, andaggregate_proofsfor several leaves. The circuits version is a property of the chain profile.Operator decision to record here before starting
Where the circuit binaries are hosted.
Acceptance
A proof for a Heisenberg reward leaf generates with a progress bar and verifies locally before submission. A binary with the wrong hash is refused and the UI says which file.
Depends on
The wormhole derivation child.
A constraint for this child, from the operator and from quantus/extension's experience: nothing that identifies which deposit is being spent may leave the client before the exit is submitted. Nullifiers are the obvious case (see the new leak issue under #9, where the wallet already gets this wrong). Proof generation adds a second one: the proof needs the Merkle path to the leaf, and
zkTree_getMerkleProof(leaf_index, at_block)asks the node for that one index, which names the leaf, and a leaf carries its recipient and amount in the clear. Options to weigh before writing code: build the path locally fromZkTree::Nodesread in whole levels or large ranges, or ask for the target's proof among a shuffled set of decoy indices. Whichever is chosen, a test should assert the leaf index being spent never appears alone in a request.