How does Zeekay work

Workflow of the solution

In this section, we provide an overview of the Zeekay application workflow. Subsequent sections delve deeper into the specific technologies employed within the application and demonstrate their implementation within the protocol. By breaking down each component, we aim to provide a comprehensive understanding of how the Zeekay application functions.

Step 1: Creating an account - While initiating the Zeekay application, a randomized number is generated ( and a seed phrase is created too) on the user's device and their wallet address (referred here to as an Account). It serves as the key for depositing and withdrawing funds from the Zeekay contract.

Maintaining the secrecy of the account's randomized number is crucial for the security and anonymity of transactions. If the phrase is exposed online, it could allow unauthorized individuals to withdraw funds and compromise the anonymity of the transaction. Therefore, it is vital to handle the phrase with utmost care.

To withdraw deposited funds, a Zero-Knowledge proof must be submitted as evidence of knowledge of the randomized number. Since the proof is Zero-Knowledge, it prevents any outside observers from determining which phrase was used for the withdrawal, maintaining transaction privacy.

Step 2: Depositing assets - To deposit assets into Zeekay's contract, the user must create a commitment based on their randomized number. This commitment is essentially a MiMC hash of the randomized number value. The user then initiates a transaction using their account, including the commitment as a parameter. This commitment is added to an internal merkle tree, which functions as a cryptographic accumulator. However, before the deposit can be accepted, the user's account must pass an AML test. The account undergoes evaluation on hapi.one's database to determine its risk score. If the account receives an acceptable risk score, it is added to the allowlist merkle tree, which is another cryptographic accumulator. If the account's risk score exceeds the acceptable threshold, the deposit will not be accepted.

Step 3: Sending ZK proof to relayer - To initiate a withdrawal from the contract, the user must provide a Zero-Knowledge proof that verifies the following:

• The user's randomized number commitment is present in the merkle tree

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

• The user's randomized number has not been used for any previous withdrawals

It's worth noting that this proof doesn't reveal any information regarding the original depositor's account or the randomized number associated with the deposit. As a result, the transaction history remains private and cannot be traced to any specific user. This ensures that the anonymity and privacy of the users are maintained throughout the entire transaction process.

Step 4: Transferring assets or data - Upon receiving the Zero Knowledge Proof, the contract performs a simple verification process to determine its validity. If the proof is valid, the contract transfers the initial deposit to the recipient specified in the transaction. This ensures that only authorized individuals with valid proofs can withdraw funds and receive the transfer.

Considerations:

Gas fees: Suppose you're attempting to maintain complete anonymity by transferring funds to a new account. In that case, the new account will not have sufficient funds to pay for gas charges. If you transfer funds to the new account to enable it to pay for gas, you would create a link between your account and the new account, thereby compromising the privacy of the transaction. This issue would contradict the purpose of using a privacy tool. Therefore, it's essential to consider the gas cost when using a privacy tool to ensure that anonymity is preserved throughout the transaction process.

Relay function: Once the user submits a Zero-Knowledge proof as evidence of their knowledge of the randomized number, the relayer receives the proof and validates its authenticity. The relayer then includes the proof in a withdrawal transaction. It is crucial to note that the relayer cannot steal the funds as the Zero-Knowledge proof is only valid for the recipient address specified by the user during proof generation. This ensures that the funds are withdrawn only by the intended recipient and prevents any unauthorized access to the funds.