Hinkal Protocol - 2
Summary
Hinkal is a privacy protocol designed to bring universal, compliant confidentiality to payments, settlements, and payouts. It enables institutions, payment platforms, and individuals to operate on-chain without exposing their balances, transaction history, or counterparty identities. Operating non-custodially, Hinkal utilizes a UTXO model combined with stealth addresses and zero-knowledge proofs. To ensure privacy, transaction data remains encrypted client-side, while only cryptographic commitments and nullifiers are published on-chain. The core Hinkal contracts handle state management and constant-size merkle tree operations, while helper contracts facilitate confidential asset swapping. For stateful interactions with external dApps and DeFi protocols, Hinkal relies on the Emporium controller contract, which acts as a strict, exclusive gateway to the user's ERC-7702 based Hinkal Wallet. This ensures that complex, stateful on-chain actions, such as paying relayer fees, handling NFTs, or providing liquidity, can be executed securely and non-custodially without compromising the user's privacy. To guarantee transaction validity without exposing sensitive data, Hinkal relies on zero-knowledge proofs (specifically Groth16) generated client-side using Circom circuits. When a user interacts with the protocol, these circuits generate a cryptographic proof verifying that the user owns sufficient unspent UTXOs and is publishing valid nullifiers to prevent double-spending, all while keeping the actual amounts and identities hidden. The audit reviewed two Circom circuits, `MainEVMCircuit` and `MainEVMCircuitMin`. `MainEVMCircuit` proves the validity of a private, multi-token UTXO transaction by verifying authorization, input membership and nullifiers, output commitments, amount conservation, and stealth-address derivation. The `MainEVMCircuitMin` is a significantly stripped back version of this used when no output UTXOs are created and only proves knowledge of the seed underlying the public Poseidon message. The stealth-address circuit validates the \(H_0\) base-point coordinates as an on-curve point in the BabyJubJub prime-order subgroup before performing scalar multiplication. We also confirmed that the deployed verifiers enforce Num2Bits(250) for the nullifying key constraining the value to be between 0 and 2**250. In the EVM contracts we have identified a way to fill the merkle tree at only gas cost, potentially locking the protocol in extreme cases (#HIN-1). The remaining low-severity findings focus on potential MEV exploits (#HIN-2), inconsistent fee calculations (#HIN-5), minor accidental native token loss (#HIN-6) and various input validation related concerns. Further, we'd like to point out dangers around arbitrary outbound calls from emporium, security-critical privileged changes without timelock and potentially problematic configurations, as well as some suggestions for improvements.
Issues (14)
Low | Medium | High | Critical | Total | |
|---|---|---|---|---|---|
Not fixed | 2 | - | - | - | 2 |
Acknowledged | 3 | - | - | - | 3 |
Fixed | 8 | 1 | - | - | 9 |
| Total | 13 | 1 | 0 | 0 | 14 |