Solving Orders in the Provisioner

What is the Provisioner?

The Provisioner is an upgradable module in multi-depositor vaults that allows external depositors to enter and exit the vault using various order types and for solvers to fill these orders.

The solver supports 5 types of orders which can be enabled/disabled:

• Asynchronous deposits with a fixed price. A depositor may request a deposit at a fixed price (analogous to a limit order).

• Asynchronous deposits with an “automatic” price. A depositor may request a deposit at the accountant reported price. The price is checked when the order is filled but the depositor can put bounds on acceptable prices.

• Asynchronous redemptions with a fixed/automatic price. These work exactly like asynchronous deposits but allow users to exchange units for underlying assets.

• Synchronous deposits. Units are received instantly but there is a cooldown period for transfers. If the deposit price was found to be inaccurate (e.g., market volatility), the deposit may be refunded during the cooldown period.

Orders can be created in one of the whitelisted underlying assets.

Why Does It Matter?

Since the accountant submits vault prices, allowing instant non-refundable deposits and redemptions could lead to exploitable arbitrage. To protect all depositors, the Provisioner introduces a solver layer that allows users to make orders and for them to be filled when prices are accurate.

The Provisioner also allows maximum flexibility for users and they can prioritize an order type that optimizes for the factors they care about such as price efficiency (fixed price orders), speed of solving (auto price orders) or price transparency (synchronous deposits), etc.

How to Solve Orders in the Provisioner?

Anyone can be a direct solver for fixed price orders if they have the offer asset by calling solveRequestsDirect, however, they are effectively taking “the other side” of the order and need to be happy to solve at the fixed price. This allows sophisticated market participants another pathway to enter/exit the vault or speed up solving when deposit/redeem orders can be matched.

The Provisioner also may whitelist a number of vault solvers who can fill orders using the assets in the vault in accordance with their solving policy. The solveRequestsVault function will then solve a batch of orders as follows:

• For automatically priced orders, solveRequestsVault exchanges the assets between the Provisioner and the vault (at the last reported price) and pay the solver via the provided solverTip in the original order;

• For fixed price orders, solveRequestsVault solves the orders when the fixed price is favorable to the solver, exchanging assets between the Provisioner and vault (at the last reported price) and returning the difference as a solver tip to the solver. If a solver wants to do an “unprofitable” solve, they can do so via a direct solve.

Caveats

The solver needs to be aware of the accountant's price reporting policy to solve at the times which will result in the most accurate pricing of vault units.

Each solver should also maintain a consistent solving policy. While the protocol doesn't enshrine any particular policy, the following considerations are important among others:

• solverTip policy,

• Solving latency and guarantees,

• Solving during emergencies or moments of price volatility,

• Guarantees around solving order.