PrivX Hurricane

PrivX Hurricane — Protocol Docs

PulseChain's first PLONK-based multi-token privacy protocol. Shield 6 tokens. Generate a Proof of Privacy. Mine PRIVX on every withdrawal.

Chain: PulseChain (chainId 369)  ·  Circuit: PrivXMixer(14) PLONK  ·  Powered by: PrivX Hurricane

PrivX Hurricane is PulseChain's first PLONK-based privacy protocol, and the first of its kind to shield multiple tokens simultaneously. Deposit any of 6 supported tokens into a shielded pool and withdraw them to a completely unlinked address. Every withdrawal generates a Proof of Privacy (POP) and automatically pays PRIVX mining rewards. No PRIVX required to deposit — it is what you earn, not what you spend.

0.5% fee in the shielded token → Fee Vault → swapped to PRIVX → 80% PRIVX/WPLS Protocol-Owned Liquidity (locked permanently) / 10% POP Mining Vault (self-funding rewards) / 10% burned to dead address. Every token shielded creates permanent PRIVX buying pressure.

PrivXMixer(14) — 14-level incremental Poseidon Merkle tree with 16,384 leaves per pool. PLONK proofs are generated entirely in the browser. The recipient address is cryptographically embedded into every proof at generation time — no relay, no intermediary can redirect your withdrawal. Proof generation ~15–30s depending on device.

The proving key underpinning every PrivX Hurricane proof was derived from the Hermez Network Powers of Tau ceremony — a multi-party computation with 54 independent contributors from across the world. The security guarantee is absolute: every single one of those 54 participants would need to have colluded and preserved their secret randomness for the system to be compromised. In practice, this is computationally and logistically impossible.

Unlike older ZK systems that require circuit-specific trusted setups — creating additional attack surface — PrivX Hurricane uses PLONK, a universal proving system. There is no secondary ceremony, no circuit-specific toxic waste, and no privileged key holder. The ceremony file is independently verifiable by anyone in the world via its publicly known cryptographic fingerprint.

The same proving key powers every shield across every token. No new ceremony is ever required to add a token — only the on-chain verifier and shield contracts are needed.

The PrivXMixer(14) circuit was analysed using two independent methods: snarkjs R1CS constraint inspection and Ecne — a Julia-based SMT solver that mechanically verifies every signal in the R1CS is uniquely determined by the inputs. The circuit source, compiled R1CS, and symbol file are published on GitHub for independent verification by anyone.

Signal counts verified (snarkjs R1CS):

Ecne SMT analysis — under-constrained signal check:

Critical constraints confirmed:

Ecne confirmed all 8,349 signals are uniquely determined — no signal can be freely set by a prover without violating a constraint. The wire/constraint gap of 19 is consistent with this result. The two equality constraints (nullifierHash binding and Merkle root) are enforced through R1CS signal aliasing — the circom compiler merged them to the same wire, which is a stricter form of enforcement than an explicit constraint row.

Circuit source: circuits/PrivXMixer.circom · R1CS: build/PrivXMixer.r1cs · Symbol file: build/PrivXMixer.sym — all published on GitHub for independent analysis.

A full security audit of all V3 shield contracts was performed in June 2026, covering: fake proof attacks (ZEC/Sapling-style), recipient substitution and MEV, cross-denomination replay, reentrancy, double-spend via nullifier mapping, field-element aliasing double-spend (SNARK_FIELD overflow), zero-root attack, commitment grief, and Mining Vault manipulation.

Result: No theft vectors found in any deployed V3 contract.

Key V3 fix — field-element aliasing: BN254's scalar field is ~254 bits; Solidity's uint256 is 256 bits. Without an explicit check, a value X and X + SNARK_FIELD are equivalent modulo the field — the ZK proof verifier treats them identically. An attacker could exploit this to double-spend: withdraw with nullifierHash=N (proof valid, N recorded as spent), then withdraw again with nullifierHash=N+SNARK_FIELD (proof still valid, mapping lookup misses because N ≠ N+SNARK_FIELD as uint256). V3 closes this with require(_pubSignals[i] < SNARK_FIELD) on all 4 public signals before any other checks run.

Every withdrawal requires a small amount of PLS for gas. If your fresh wallet has never been funded, it can't submit the transaction itself. Relayer Mode solves this — your browser generates the ZK proof and packages it as a JSON file that any willing wallet can submit on your behalf.

Why the relayer can't steal: The recipient address is cryptographically embedded inside the ZK proof at generation time as a public signal. The contract enforces that the address passed to the function exactly matches what's inside the proof. If a relayer tries to change the recipient, the transaction reverts with recipient: mismatch. This is mathematically enforced — not a policy.

⚠ Critical — note vs proof: Your private note (the privx-hurricane-… string) must never be shared. It contains the nullifier and secret — anyone who has it can generate a proof to any recipient they choose. The proof JSON is safe to share — it contains no private data, only the completed proof locked to your specified recipient.

Funding your fresh wallet another way: If you have a PLS shield deposit, withdraw it first. A PLS shield withdrawal sends native PLS directly to the recipient in the same transaction — your fresh wallet arrives already funded and can submit its own token shield withdrawals from that point on with no relayer needed.

Every deposit pays a 0.5% fee in the shielded token. Fees accumulate here until converted — swapped to PRIVX, then split: 80% locked as permanent PRIVX/WPLS liquidity, 10% sent to fund withdrawal rewards, 10% burned forever.

Pays PRIVX rewards on every PrivX Hurricane withdrawal. Quadratic decay — fuller vault = higher rate. Auto-refills from Fee Vault conversions.