Accounting Manager Flows

This is the share token contract of each vault in NOYA.

This contract is in charge of:

1. Accounting of Noya vaults (calculating the value of each share)

2. BookKeeping for noya shareholders. It inherits the ERC4626 standard to handle the shares of the user.

3. Implementing the delayed withdrawals and deposits

Shares of the vault in Noya

Shares represent the value that each user owns from the vault. They can be minted using the deposit flow and can be burned (transferring the base tokens to the users) using the withdraw function.

The value of each share is calculated using this formula:

baseTokenValue = (shareAmount) * totalAssets / totalShares (totalAssets is a function in accountingManager that calculates the value of all positions based on the baseToken. totalShares is also can be fetched by totalSupply function of the accountingManager that returns the total amount of minted shares).

Deposit flow:

1. User deposits some amount of base token using the "deposit" function

Copy

    function deposit(address receiver, uint256 amount, address referrer)

2. After all of the positions that have time (look at positionTimestamp in HoldingPI struct) update their time, (or immediately if there is no position with timestamp) the keeper can call the calculateDepositShares function. This will calculate the shares of this deposit and record it in the queue, and update the middle of the queue that indicates which records have been calculated.

3. After a specified time, the keeper can call the executeDeposit function to mint the actual share tokens to the users and send the calculated amount to an active connector. This will also update the queue variables and total deposited amount.

Withdraw flow

1. User initiates the withdraw request

function withdraw(uint256 share, address receiver);

2. After all of the positions that have time (look at positionTimestamp in HoldingPI struct) update their time, (or immediately if there is no position with timestamp) the keeper can call the calculateWithdrawShares function. This will calculate the assets of this withdraw and record it in the queue, and update the middle of the queue.

3. After the keeper calculates a couple of withdrawal records, it can start a withdrawGroup. Withdraw group is being used to retrieve the needed tokens to the AccountingManager so we can send them to the users.

4. The keeper should use the connectors’ functions to burn positions and swap tokens to the “baseToken” (so it can be withdrawn in the next step).

5. Once we have the needed amount (or a part of it) we can use the “retrieveTokensForWithdraw” function to move the assets from different connectors to the accounting manager for withdrawal and updates the “amountAskedForWithdraw” variable to prevent moving more or less base tokens that is needed.

6. Once we have requested all the tokens that we’ve calculated for withdrawal, the keeper will call the “fulfillCurrentWithdrawGroup” to finish the process of retrieving tokens for withdrawal.

7. Then we are ready for withdrawals. We can execute the withdrawal requests that the waiting time after the calculation has been passed by calling the “executeWithdraw” function.

8. After a specified time (withdrawWaitingTime), the keeper can call the executeWithdraw to burn the share tokens to the users and send the calculated amount to the user.

Security checks of the accountingManager

1. All deposits and withdrawals are delayed which means that if something happens to the vault, we'll have the needed time window to fix the issue.

2. There is a function called "resetMiddle" to force the smart contract to do the vault deposits (/withdrawals) calculation again.