# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.aera.finance/entry-exit-with-provisioner.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.