Setup

Cryptographic Primitives

• Poseidon hash: a SNARK‑friendly hash used to create commitments and to build the Merkle tree.

• Groth16 proofs: zero‑knowledge proofs that assert a transaction is valid (ownership, no double‑spend, balance conservation) without revealing the private data.

• BabyJub/JubJub curve math: used to construct unlinkable stealth addresses per transfer.

Key Derivation & Stealth Addresses

• Derivation from a wallet signature

  • On first connect, a signed message is used as seed material to derive Hinkal‑specific secret(s). These never leave the client and are unrelated to the EOA private key.

  • The same signature always recreates the same Hinkal identity, so users can restore access without storing anything new.

• Viewing and spending

  • The derived secrets enable two capabilities: viewing (scanning commitments to detect funds) and spending (proving ownership in zero knowledge).

• Stealth addresses

  • For every transfer, the sender combines random entropy with the recipient’s public viewing data to compute a one‑time stealth address. Funds sent to this address are indistinguishable on‑chain and only the intended recipient can discover and spend them.

  • Alongside the stealth address, an encryption public key can be derived for secure off‑chain payloads (e.g., memo or ciphertext for the recipient).

UTXOs, Commitments & Nullifiers

• UTXOs (Unspent Transaction Outputs)

  • Each balance fragment is a UTXO containing the token amount, token identity (ERC‑20 or NFT), a stealth address, and metadata (e.g., timestamp). UTXOs are private by construction.

• Commitments

  • A cryptographic commitment is computed from each UTXO and inserted into a global Merkle tree. Commitments reveal nothing about the underlying values but can be referenced in proofs.

• Nullifiers

  • When a UTXO is spent, a unique nullifier is revealed. A nullifier can appear only once; this guarantees a note cannot be spent twice while still hiding which note it was.

Merkle Trees

• The system maintains an append‑only Merkle tree of commitments. Newly created UTXOs add leaves; the Merkle root summarizes the private state.

• Wallets track recent roots and produce inclusion proofs for notes they intend to spend. Verifiers only need the root and the proof, not the note itself.

• Keeping a window of recent roots allows users to spend against slightly older states while the system evolves.

User Experience (High‑Level)

1. Connect a wallet and sign once. The signature deterministically restores your Hinkal identity and viewing keys.

2. Receive funds to your private balance: senders compute a stealth address for you and create UTXOs in the system.

3. Spend or swap privately: your wallet proves in zero knowledge that you own certain UTXOs and that outputs conserve value, without revealing which notes you spent.

4. Your public EOA is never tied to private inflows or outflows; only commitments, nullifiers, and Merkle roots are visible on‑chain.