Entry/Exit with Provisioner

What is the Provisioner?

NOTE: These details are only important if you want to directly interface with the Provisioner contract. The simplest way to deposit/withdraw is to use the app.

The Provisioner is the contract that depositors interface to mint or burn vault units in multi-depositor vaults. More technically, it is the only contract that is authorized to mint and burn shares for a given MultiDepositorVault.

The Provisioner has the following features:

1. Synchronous deposits. Direct deposits allow users to deposit in line with the current vault value. Units are initially locked for a period of time to prevent arbitrage attacks. In extreme cases, the authorized operator can call refundDeposit to refund a user's deposit while the units are locked.

2. Asynchronous deposits/redemptions. The most general way to enter/exit the vault is by creating a deposit/redemption request. Requests can be filled by solvers at a price that is valid at the time of solving (but still respecting any constraints imposed by the depositor).

3. Batch solving. Solvers can solve many orders atomically in a batch.

Why it Matters

The Provisioner allows users to choose the deposit/redemption policy that expresses their requirements in the best way. Some users want to prioritize rapid entry, others want to place a limit order. Others yet will trust the pricing on the vault but may want to configure the specific solving fee that should go to the solver.

Having the deposit/withdraw logic in a separate contract allows Aera vaults to upgrade their provisioner contracts in the future to support additional mechanisms for entering/exiting the vault.

How to Use the Provisioner

deposit

Deposit requires you to specify token (the deposit token), tokensIn (the amount to deposit) and minUnitsOut (a minimum amount of units you expect to receive).

If the deposit succeeds, you'll receive the units but they will be locked for the duration of the deposit refund period to protect other depositors against arbitrage attacks.

The deposit can fail for various reasons:

• Not enough tokens have been provided to mint any units

• minUnitsOut is not met at current unit price

• token is not an approved deposit token

• synchronous deposits are not enabled for the vault

• the deposit cap would be exceeded

NOTE: Mint works analogously.

requestDeposit

There are two types of asynchronous deposit orders so each argument has slightly different context depending on which order is considered. The order type is specified by setting isFixedPrice.

Argument	Meaning for fixed price orders	Meaning for auto priced orders
token	The token to deposit	Same
tokensIn	The amount of tokens to deposit	Same
minUnitsOut	Minimum amount of units expected	Same
solverTip	Needs to be 0. Solver receives difference between tokens needed to deliver minUnitsOut and actual units delivered	Tip to offer solver
deadline	Timestamp until which the request is valid	Same
maxPriceAge	Maximum age of price data that solver can use	Same

When a request deposit order is made a solver may fill it until the deadline. If the order is a fixed price order, the fill price will be minUnitsOut but if the order is an auto price order then the active unit price will be used and the solverTip will be calculated and sent to the solver.

If the deadline passes and the order wasn't filled, anyone can call refundRequest to refund the order.

NOTE: Request redeem works analogously.

Caveats

When using the Provisioner directly, ensure you are familiar with the solver's solving policy. While solvers are operating in a fair manner, the platform in itself cannot provide guidelines that your orders will be successfully filled.