Zenrock Q1 2026 - Hush Privacy Protocol Audit Report

Security Audit Report

Zenrock Q1 2026 - Hush privacy protocol

Authors: Carlos Rodriguez, Karolos Antoniadis, Ranadeep Biswas, Simon Noetzlin, Luca Joss, Last Revised: Aleksandar Stojanovic, 03.02.2026 Vukašin Dokmanović Zenrock Q1 2026 Security Audit Report

Contents Audit Overview 1 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

System Overview 3 Hush privacy protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Audit Dashboard 7 Target Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Engagement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Severity Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Threat Model 8

Findings 31 Unshield recipient address not cryptographically bound to ZK proof . . . . . . . . . . . . . . . . . . . . . 34 Note secret and randomness not cryptographically bound to spending key . . . . . . . . . . . . . . . 35 Cross-asset theft vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Circumventing fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Reusing balance nullifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Hardcoded note sequence limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Integer overflow in balance accumulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Unsanitized u64 as field element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Missing shared secret validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Stealth recovery mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Missing message validation in x/hush handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Cross-chain linkability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Mempool proof replay attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Missing tree depth validation makes the contract unusable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Lack of confirmation during admin updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Nullifier key derivation mismatch in account recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Erroneous supply stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Unbounded Merkle Depth (DoS vector) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Unbounded JSON string (DoS vector) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Missing host-side new balance validation (DoS vector) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Silent recipient string truncation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 AddCommitment overwrites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Missing check for leaf_index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Commitment field ordering inconsistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Duplicate vouchers compute wrong balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Missing integer overflow check in x/hush module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Note secret derivation inconsistency between balance notes and vouchers . . . . . . . . . . . . . . . 69 Duplicate incoming notes not validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Viewing key lifetime leak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Miscellaneous findings on hush-wasm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Miscellaneous findings in hush.masm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Miscellaneous comments on x/hush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Miscellaneous findings on CW contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Appendix: Vulnerability Classification 77

Disclaimer 81

Audit Overview

The Project In January 2026, Zenrock engaged Informal Systems to perform a security audit of the Hush Privacy protocol.

Scope of this report The audit evaluated the correctness and security properties of the hush-wasm library, the x/hush module, Miden ZK circuits, the miden-merkle contract, and the miden-verifier contract within the Hush Privacy protocol.

Audit plan The audit was conducted between January 14th, 2026 and January 23rd, 2026, by the following personnel:

• Carlos Rodriguez • Karolos Antoniadis • Ranadeep Biswas • Simon Noetzlin • Luca Joss • Aleksandar Stojanović • Vukašin Dokmanović

Conclusions The Zenrock development team has built an ambitious and technically sophisticated privacy protocol that leverages Miden STARKs to provide shielded transactions for wrapped assets on Solana. The codebase demonstrates strong engineering practices with comprehensive documentation, thoughtful architecture decisions and proactive security considerations. The team’s responsiveness to identified issues and willingness to address design concerns speaks highly of their commitment to security. However, our audit uncovered several critical vulnerabilities that required immediate attention before mainnet deployment.

We identified a design flaw where the circuit fails to cryptographically bind note_secret to spending_key, allowing anyone who knows a commitment’s pre-image to generate unlimited valid proofs using different spending keys—each producing a unique nullifier that bypasses double-spend protection. Additionally, the protocol suffers from other critical issues. Some of them are: asset type is not included in the proof’s cryptographic binding (enabling cross-asset theft where attackers can withdraw one asset using a proof for another), values throughout the system are not validated to be less than the Goldilocks field modulus before field arithmetic operations (enabling wraparound attacks), and neither asset type nor sender address are bound to proofs (enabling mempool replay attacks where valid transactions can be intercepted and replayed with modified fields). These vulnerabilities stem from missing cryptographic bindings between proof components and inadequate input validation at system boundaries.

Additionally, other findings around input validation, duplicate detection, commitment ordering inconsisten cies, and mempool replay attacks highlight gaps in defense-in-depth. A critical overarching issue is that circuit inputs on both the operand stack and advice tape are frequently not sanitized before being treated as field elements—all numeric values (amounts, fees, assets, sequences, leaf indices) should be explicitly reduced modulo p and validated against reasonable protocol-specific bounds (e.g., maximum amount per note of 2^62 to prevent accumulation overflow). Beyond these specific vulnerabilities, we recommend to deploy zrchain to a dedicated security testnet with adversarial testing scenarios (cross-asset proofs, nullifier replays, field overflow edge cases, mempool front-running) to validate that on-chain validation and ZK circuit constraints properly mitigate these attacks. This complements static code review by verifying runtime behavior under real attack conditions and ensures the circuit-client-chain integration behaves correctly under Byzantine inputs.

Once the initial audit ended, the development team addressed all findings shortly after and we reviewed the fixes and updated the status of the findings.

System Overview

Hush privacy protocol The Hush privacy protocol provides privacy for wrapped assets (zenBTC, jitoSOL) through a two-chain architecture combining Solana’s settlement layer with zrchain’s privacy layer. Users shield tokens on Solana by transferring them to a vault, receiving cryptographic commitments on zrchain that obscure amounts and ownership. They can then perform untraceable shielded transfers to other users or unshield to a new Solana address with no on-chain link to the original shield transaction. The protocol operates across three layers:

• Solana (token custody via vaults), • zrchain (shielded state management via x/hush module, miden-merkle contract for Merkle tree operations, and miden-verifier contract for STARK proof verification), • and browser (hush-wasm library for client-side proof generation).

Validator sidecars coordinate between chains by monitoring Solana events and submitting transactions to both the module and MPC keyrings for signature generation. The privacy guarantees are enforced through ZK circuits written in Miden assembly (hush.masm) that define the proving logic for unshield and shielded transfer operations.

The protocol achieves transaction unlinkability through zero-knowledge proofs that allow users to prove they own shielded tokens without revealing which specific tokens they’re spending. Each shielded balance is represented by a cryptographic commitment that hides both the amount and the owner, and when spending, users reveal a nullifier that prevents double-spending but cannot be linked back to the original commitment. The system supports different levels of access through tiered viewing keys: spending keys provide full control, full viewing keys allow auditing of all transactions, and incoming viewing keys only permit viewing received amounts. All commitments are stored in a Merkle tree that maintains historical snapshots, allowing users to generate proofs against any past state of the system.

System architecture

Components

hush-wasm library The hush-wasm library serves as the client-side cryptographic engine for the privacy protocol, providing browser-based implementations of all cryptographic operations required for shielded transactions. It acts as the bridge between user wallets and the on-chain privacy system, compiling Rust cryptographic code to WebAssembly for execution in web browsers.

The library computes commitments from secret values that represent shielded notes in the Merkle tree implemented in miden-merkle CW contract and derives nullifiers that mark notes as spent. For shielded transfers, it handles ephemeral key generation and performs key exchange to establish shared secrets, then encrypts transfer amounts so only the intended recipient can decrypt them. The library also derives the hierarchical key structure from the wallet signature, producing nullifier keys for spending operations and viewing keys that enable audit or receive-only capabilities without exposure to spending authority.

When configured with the prover feature, the library generates full STARK proofs directly in the browser. It assembles the complete execution program from the Miden assembly circuit, constructs the advice stack with all private inputs, including note secrets and Merkle authentication paths, builds the public stack inputs with the outputs commitment hash and Merkle root, and executes the Miden VM to generate a proof that can be verified on-chain.

The library also implements deterministic wallet recovery that allows users to reconstruct their entire trans action history from a wallet signature. By signing standardized messages with sequential indices, users derive the same note secrets they originally generated for each voucher, then query the blockchain for vouchers with matching commitments to identify their own. Voucher amounts are encrypted on-chain using keys derived from the spending key (for own balance notes) or ECDH shared secrets (for incoming trans fers), allowing the library to decrypt and recover complete voucher data even if browser storage is cleared.

x/hush module The x/hush Cosmos SDK module serves as the privacy layer within the zrchain blockchain, orchestrating confidential transactions using zero-knowledge proofs. It coordinates between user operations, blockchain state, and cross-chain token movements, allowing users to deposit tokens from Solana into a shared privacy pool, transfer funds within the pool with hidden amounts, and withdraw to any address without observers being able to link deposits to withdrawals. By design, the module operates on a model where each shielded voucher can be spent exactly once, with nullifiers serving as spent markers to prevent double-spending while maintaining unlinkability between commitments and their spent state.

The module handles three core operations:

• Shield deposits occur when validators detect incoming transfers on Solana, screen the sender for compli ance, and if approved, add the commitment to the privacy pool and issue a new voucher to the depositor. • Unshielding allows users to withdraw tokens by submitting a cryptographic proof of ownership. • Shielded transfers move value between users within the privacy pool by accepting ownership proofs, creating new encrypted vouchers for recipients and change, and collecting fees.

The module maintains several key data structures to enable privacy operations. It tracks which vouchers have been spent through permanent nullifier records, manages the lifecycle of withdrawal requests from submission through signing and broadcasting to completion with automatic retry logic for failed attempts, and coordinates with the miden-merkle contract to maintain a rolling window of valid historical roots that users can prove against. For each operation, the module independently reconstructs a cryptographic summary of all public transaction data and combines it with the user’s proof inputs to ensure verification matches what the proof actually commits to, preventing any tampering with transaction details after proof generation.

Miden ZK circuits The hush.masm circuit functions as the cryptographic core of the privacy protocol, implementing a zero- knowledge STARK program that proves the validity of unshielded and shielded transfers. The circuit receives private inputs through Miden’s advice stack mechanism, including the user’s spending key, existing balance note data (secret values, randomness, amount), and up to 24 incoming notes with their authentication paths. It derives the nullifier key from the spending key, recomputes commitments for all input notes to verify they match the claimed values, generates nullifiers to mark these notes as spent, and verifies each note’s membership in the Merkle tree by checking authentication paths against the public root. The circuit then accumulates all input amounts from both the existing balance and incoming notes, ensuring accounting across note claims.

miden-merkle contract The miden-merkle CosmWasm contract maintains a depth-configurable sparse Merkle tree to store com mitments. When a commitment is added through the SudoMsg::AddCommitment interface (only callable by the chain), the contract computes its position in the tree based on a sequential leaf index, updates all parent hashes along the Merkle path using the RPO256 hash function, and stores the new root. To support proof verification against historical states, the contract maintains a rolling window of recent roots via the ROOT_HISTORY map, with a configurable HISTORY_SIZE that defaults to 1000 blocks.

miden-verifier contract The miden-verifier CosmWasm contract serves as the zero-knowledge proof verification endpoint. It acts as a thin wrapper around the Miden VM’s native STARK verifier, translating data structures into the formats required by Miden’s proof system. By design, the verifier is exclusively callable through the SudoMsg interface, ensuring that only the x/hush module keeper can submit proofs for verification.

The contract’s primary responsibility is to verify Miden STARK proofs against a specified program hash and public inputs. When the x/hush Keeper submits an unshielded or shielded transfer transaction, it calls SudoMsg::Verify with four components: the program hash (identifying which circuit was executed), the stack inputs (public values available to the verifier), the stack outputs (expected final stack state), and the base64-encoded proof bytes. The contract deserializes the program hash into a RpoDigest, constructs a ProgramInfo with the default Miden kernel, converts stack inputs and outputs into the appropriate Felt representations, and invokes Miden VM’s verify() function.

Audit Dashboard

Target Summary • Type: Protocol and implementation • Platform: Cosmos SDK, Go, Rust, CosmWasm, MASM • Artifacts: At commit hash 6f555b9: ‣ hush-wasm library ‣ x/hush module ‣ Miden ZK circuits ‣ miden-merkle and miden-verifier contracts

Engagement Summary • Dates: January 14th, 2026 → January 23rd, 2026 • Method: Threat modeling, manual code review, testing

Severity Summary Finding Severity Number

Critical 6

High 5

Medium 11

Low 3

Informational 8

Total 33

Table 1: Identified Security Findings

Threat Model Assumptions:

• For zrchain:

The blockchain state is persistent and not subject to corruption or data loss.
Consensus mechanism properly replicates

Excerpt (19997 of 157377 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation