UTXOs, Commitments & Nullifiers

UTXOs, Commitments, and Nullifiers

Hinkal uses a UTXO (Unspent Transaction Output) model, where each UTXO contains the following elements:

• tokenAddress: The address of the token represented by the UTXO.

• amount: The token amount within the UTXO.

• stealthAddress: The stealth address that "owns" the UTXO.

• timestamp: The creation time of the UTXO.

• tokenId (optional): A unique NFT identifier.

For each UTXO, a cryptographic commitment is generated either off-chain or on-chain. A commitment is a cryptographic primitive that enables users to commit to a value while keeping it hidden, retaining the ability to reveal the value later. These commitments are created during deposits, transfers, and other interactions, and are subsequently spent (nullified) when the UTXO is consumed. Each commitment is calculated as the Poseidon hash of the UTXO's attributes:

$Commitment = Poseidon_4(tokenAddress, amount, stealthAddress, timestamp)$

The nullifier, which ensures that a UTXO can be spent only once, is a Poseidon hash derived from the nullifier signature and the commitment.

$$Nullifier = Poseidon_2(Signature(Commitment), Commitment)$$

The signature is computed as the Poseidon hash of the shielded private key and the commitment.

UTXO spending requires users to generate a zero-knowledge proof demonstrating control over the shielded private key associated with a commitment in Hinkal's Merkle tree, accompanied by the commitment's unique nullifier. Once the transaction is processed, the commitment is marked as nullified and the nullifier is recorded on-chain, creating an immutable record that prevents commitment reuse.

UTXOs: On-Chain vs Off-Chain Creation

UTXOs in the Hinkal Protocol can be created through two distinct mechanisms: off-chain creation and on-chain creation. This dual approach provides flexibility for different transaction types and privacy requirements while maintaining the protocol's zero-knowledge properties.

Off-Chain UTXO Creation

When a UTXO is created off-chain, the complete UTXO data (including amount, token address, stealth address, timestamp, and other metadata) is computed and encrypted client-side. Only the commitment hash of this UTXO is stored on-chain in the protocol's Merkle tree, along with encrypted output data that allows the intended recipient to decrypt and reconstruct the full UTXO.

Off-chain UTXOs are essential when transaction amounts are known beforehand, particularly when sending tokens to another user. In these scenarios, the sender knows exactly how much they want to transfer, the recipient's stealth address, and all other UTXO parameters before the transaction is submitted. This allows for complete client-side preparation of the UTXO data, maximizing privacy by keeping all transaction details encrypted and only revealing the commitment hash on-chain.

When a user wants to utilize an off-chain UTXO, they must demonstrate ownership through proving they can reconstruct the UTXO commitment by applying the correct Poseidon hash operations to the decrypted UTXO data (amount, token address, stealth address, timestamp).

On-Chain UTXO Creation

When a UTXO is created on-chain, the smart contract itself constructs the UTXO data during transaction execution based on the actual token balances and external action results. The contract creates the full UTXO struct and computes its commitment on-chain.

The fundamental requirement for on-chain UTXO creation arises when we cannot determine the exact amounts before executing the transaction on-chain. In scenarios such as DEX swaps with slippage, yield farming rewards, or liquidity provision where the final output amounts depend on real-time market conditions, external protocol states, or complex calculations that can only be performed during execution, the protocol must create UTXOs on-chain using the actual resulting amounts rather than predetermined values.

This dual approach allows Hinkal Protocol to maintain privacy for predetermined transactions while supporting complex DeFi interactions where output amounts are only known during the execution.

When a user wants to utilize an on-chain UTXO, they must demonstrate ownership through elliptic curve cryptographic operations involving their spending key. The verification process works as follows:

1. Point Generation: The system uses the user's spending key and randomization parameter to generate a stealth address on the Baby Jubjub elliptic curve: $(H_0,H_1) \in F^2$

2. Stealth Address Reconstruction: The user must prove they can reconstruct the stealth address commitment by applying the correct elliptic curve operations.

3. Mathematical Verification: The protocol verifies that:

$Stealth Address Commitment = Poseidon_4(H_{0x}, H_{0y}, H_{1x}, H_{1y}))$

This cryptographic proof system ensures that only the legitimate owner of the spending key can demonstrate ownership of the on-chain UTXO, maintaining security while enabling the transparency required for external protocol interactions. The stealth address structure serves as both a privacy-preserving identifier and a cryptographic commitment to the user's ownership.

Approved UTXOs

In addition to regular private UTXOs, Hinkal Protocol implements a specialized type called Approved UTXOs, which serve as an on-chain allowance mechanism for external protocol interactions. These UTXOs have a distinct structure and behavior compared to their private counterparts.

Approved UTXOs consist of three essential elements:

• tokenAddress: The contract address of the ERC-20 token being approved

• amount: The quantity of tokens available for spending by the authorized contract

• inHinkalAddress: A unique, contract-specific identifier derived from the user's shielded key and the external contract address

Approved UTXOs maintain user privacy through contract-specific addressing. The inHinkalAddress is computed as a Poseidon hash of the user's shielded private key and the target contract address:

$$inHinkalAddress = Poseidon_2(shieldedKey, interactionAddress)$$

This means the same user will have different inHinkalAddress values for different smart contracts, preventing cross-protocol linking while enabling proper verification.

Unlike regular off-chain UTXOs, which exist only as cryptographic commitments in Hinkal's Merkle tree while keeping their details private, Approved UTXOs are stored directly on-chain.

Approved UTXOs function similarly to traditional ERC-20 token approvals but within Hinkal's privacy-preserving framework:

1. Creation: When a user wants to interact with an external protocol (like Uniswap), they can create Approved UTXOs by converting some of their normal UTXOs balance into approved UTXOs balance. For example, approving 5 USDC to Uniswap creates an Approved UTXO with amount 5 and inHinkalAddress corresponding to the Uniswap contract's address.

2. Consumption: When executing transactions with the approved protocol, these UTXOs are automatically consumed ("burned") to fund the external interaction. The protocol deducts the required amount from the user's Approved UTXO balance.

3. Supply Constraint: Users cannot create Approved UTXOs exceeding their actual shielded token balance, maintaining the protocol's accounting integrity.