Haycen Money Privacy Architecture

A zero-knowledge proof lets you prove a statement is true without revealing the underlying data. Haycen Money uses Groth16, a well-established zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proving system.

When a user wants to mint, transfer, or burn tokens, they generate a proof locally on their device. This proof mathematically guarantees — for example — that the sender has enough balance to cover a transfer, without revealing the balance or the amount. The smart contract then verifies this proof on-chain in constant time.

Proof Circuits

Haycen Money uses four distinct proof circuits:

• Registration — Proves ownership of a cryptographic key pair when registering to use the system.
• Mint — Proves that a confidential mint operation is valid, using a nullifier to prevent double-minting.
• Transfer — Proves the sender has sufficient encrypted balance to cover the transfer amount.
• Burn — Proves that the amount being burned does not exceed the user’s encrypted balance.

Trusted Setup

Groth16 requires a one-time trusted setup ceremony to generate the cryptographic parameters used by each circuit. This is a two-phase process:

Phase 1 — Powers of Tau (shared across all circuits)

Haycen Money’s underlying circuits use parameters from the Hermez (iden3) Powers of Tau ceremony — a public, multi-party computation with hundreds of participants. The security guarantee is straightforward: as long as at least one participant was honest, the parameters are secure. This phase produces the shared alpha, beta, and gamma values used by all verifier contracts.

Phase 2 — Circuit-specific setup (unique per circuit)

Each circuit (mint, transfer, burn, registration) undergoes its own Phase 2, which encodes the circuit’s specific constraints into proving and verification keys. This produces the delta values — the circuit-specific component that differs between each verifier contract.

The result: each verifier contract has hardcoded cryptographic constants. The shared constants (alpha, beta, gamma) come from the public Hermez ceremony. The unique constants (delta) come from the circuit-specific Phase 2. No party holds a secret key that could forge proofs — that is the entire point of the ceremony.

These parameters can be independently verified:

snarkjs zkey verify <circuit>.r1cs powersOfTau28_hez_final_15.ptau <circuit>.zkey

Inheritance Model

Haycen Money is built on top of EncryptedERC, an open-source privacy protocol developed by Ava Labs. Rather than wrapping EncryptedERC as an external dependency, HaycenMoney directly inherits its building blocks:

• TokenTracker — Token registration and metadata management.
• EncryptedUserBalances — Encrypted balance storage, addition, and subtraction.
• AuditorManager — Auditor public key management for compliance.
• EncryptedMetadata — Encrypted metadata support for token operations.

This direct inheritance approach gives Haycen Money full control over the token lifecycle while leveraging battle-tested cryptographic primitives.

Standalone Token

Unlike wrapped privacy tokens that add a confidential layer on top of an existing ERC-20, Haycen Money operates as a standalone token. hm is minted and burned natively — there is no underlying public token to wrap or unwrap. This simplifies the trust model and eliminates an entire class of bridge-related risks.

Allowlist

All token operations — minting, transferring, and burning — require both the sender and recipient to be on an allowlist. This is managed through a dedicated AllowlistRegistry contract, providing a compliance gate that ensures only verified participants can interact with hm.

If a user is removed from the allowlist (e.g. for sanctions compliance), the contract owner can force-reset their encrypted balance via forceResetBalance(). This zeroes the on-chain ciphertext and invalidates all pending balance history — an irreversible compliance mechanism for de-listed addresses.

User Registration

Before participating in any token operation, users must register their BabyJubJub public key with the HaycenRegistrar contract. This registration is verified by a zk-SNARK proof confirming ownership of the corresponding private key. The registered public key is then used for all subsequent encrypted operations.