How it works

Overview

This section explains the overall workflow for the entire HYC application. The inner sections will explain each technology used in the application in depth and show how it is applied to the protocol.

Workflow

Depiction of HYC's workflow

1. Create Ticket

The starting point for the application is the creation of a Ticket. The Ticket is a random number based on a random seed generated on the user's machine and in the wallet address of the user (Account 1 in this scheme).

The Ticket is used to deposit and withdraw from the HYC contract. It is supposed to be kept in secret, if the Ticket value is leaked on the web (1) other people will be able to withdraw the funds instead of you and (2) your transaction will not be anonymous anymore. That is why you have to be extra careful with your tickets, read the Tutorial tutorial for more information.

After depositing the funds using the Ticket, these funds can only be withdrawn by submitting a Zero-Knowledge proof - proving that you know the random number of the Ticket. Since this is a Zero-Knowledge proof, it is impossible for observers to infer which Ticket was used for the withdrawal, keeping the transaction private.

2. Deposit with Ticket

To deposit assets to the HYC's contract, the user is going to create a commitment based on the ticket. The commitment is essentially a MiMC hash of the Ticket value.

The user issues a transaction with their Account 1 containing the commitment as a transaction parameter. This commitment is included in an internal merkle tree - which acts as a cryptographic accumulator.

Besides the deposit action, the user's account must first pass the AML test. Essentially the account will be queried on hapi.one's database to evaluate if it possesses a suitable risk score. If the account is approved in this process, it is included in the allowlist merkle tree, which is another cryptographic accumulator.

In case the account's risk is above the accepted threshold, the deposit is not accepted.

3. Send ZK Proof to relayer

To withdraw the tokens from the contract, the user needs to generate a Zero-Knowledge proof proving that:

1. Their Ticket's commitment is included in the merkle tree

2. The original user who deposited the assets is included in the allowlist merkle tree

3. Their Ticket has not yet been used for any withdrawal

This proof, however, does not reveal which account was the original depositor or which Ticket was associated with that deposit. Thus, anyone looking into the transaction history can't link who sent funds to whom.

There is a big problem with this setup though - to send the withdrawal transaction with the ZK Proof to the HYC contract, an account needs to pay for the transaction's gas fees.

If you are trying to be 100% anonymous by sending funds to a new account, that account is not yet going to have any funds to pay for gas. If you were to transfer funds so that the account could pay for gas, you would be revealing a link between your account and the new account. This problem would defeat the purpose of using a privacy tool.

That is why HYC includes a relaying service. Those are web servers that will pay gas fees for you when transferring and, as a reward, will take a small percentage fee on top of your transfer.

So all the user has to do is send the ZK proof they generated to the relayer's API endpoint.

4. Relay ZK Proof to Contract

The relayer is going to receive the Zero Knowledge proof, certify that it is valid, and submit the proof in a withdrawal transaction.

It is important to note that there is no way for the relayer to steal the funds because the Zero-Knowledge Proof is only valid for the recipient address specified by the user when generating the proof.

5. Send Funds to New Account

After receiving the Zero Knowledge Proof, the contract simply verifies if the proof is valid. If the proof checks out, it transfers the initial deposit to the recipient specified in the transaction.