Deposits

High-level overview of the deposit flow

To make a deposit, the user first instantiates a deposit by calling a contract called the Deposit Manager. Instantiating a deposit entails two things:

1. Specifying the asset/amount the user would like to deposit + the stealth address they would like to "own" the deposited funds

2. Sending the specified asset and amount to the Deposit Manager contract

The Deposit Manager is a temporary "waiting room" where pending deposit request and related funds sit. If the user would like to retrieve their deposit, they can call on the Deposit Manager contract to retrieve their funds at any time.

While the funds sit in the Deposit Manager, a permissioned actor called the deposit screener polls for new deposits submitted to the Deposit Manager, signs all deposits under an acceptable risk threshold, and "completes" the deposit by submitting their signature to the Deposit Manager.

Upon receipt of a "complete deposit" transaction containing a valid screener signature, the Deposit Manager will move the funds into the primary "entry point" of the protocol - the Teller. Additionally, the deposit completion will trigger a third contract called the Handler to create a note listing the deposited asset as the asset, the deposited amount as the amount, and the deposit address as the note's owner.

Once the note is created, it is queued for insertion into an on-chain merkle tree called the commitment tree. The commitment tree is a merkle tree of all notes ever created by the protocol. Later, when the user wishes to spend the note, they will prove its validity inside a ZKP by proving membership of the note in the tree.

Once the note is queued for insertion, the transaction is complete. The note will soon be inserted via a Subtree Update in a batch together with other new notes to save gas. See Commitment Tree for details on the subtree update mechanism.