Reporting Prices and Fees

What is the PriceAndFeeCalculator?

Every FeeVault (a vault that is capable of charging fees) has to use the corresponding fee calculator. Each fee calculator is shared among multiple vaults.

For multi depositor vaults the fee calculator also provides pricing which is used as input in the Provisioner. For that reason this contract is called the PriceAndFeeCalculator.

Each fee calculator designates a special operator called the accountant which submits the vault's unit price on a regular cadence. The price updates are further guarded to prevent staleness or price manipulation and “out of bounds” updates lead to pausing the fee and price calculator for that vault.

Two types of fees are derived from the submitted unit prices: TVL fees and performance fees. The price and fee calculator calculates the owed fees and reports them to the vault in the event of a claim.

How fees are calculated

TVL fees are accrued in proportion to the vault's TVL (lowest of the last two reported prices multiplied by the lowest of the last two reported total supply of vault units) and the time that has passed since the last reported price. TVL fees are accrued linearly on every price update.

Performance fees are accrued when the last reported price is larger than the highest vault unit price up to the prior price report (saved in highestPrice). Performance fees are accrued in proportion to the profit (calculated as the difference between the latest reported price and the highestPrice).

A protocol fee based on both TVL and performance is calculated in the same way but with smaller fee rates.

Why It Matters

In order to price user orders and collect fees fairly, each vault needs to be able to calculate the value of its holdings. Since Aera vaults can support arbitrary assets, a universal onchain calculation is not possible. Instead, an accountant needs to compute the price of a vault unit (total holdings divided by total supply of vault units) and report it to the vault.

Doing so naively could lead to accidental price spikes so the PriceAndFeeCalculator embeds several protections on the range of prices that can be submitted and when they can be submitted.

How to Report Prices as an Accountant

The designated vault accountant can call setUnitPrice, naming the vault, the reported timestamp and the vault unit price at that timestamp.

The price is accepted if:

  • The price is nonzero;

  • The timestamp provided is after the last price update but not in the future;

  • The timestamp is not too far into the future (meets maxPriceAge threshold). This avoids stale prices being submitted.

After the price is accepted, the price and fee calculator is immediately paused for that vault:

  • If price was submitted too soon (under the minUpdateInterval);

  • If price was submitted too late (longer than maxUpdateDelayDays since the last update time);

  • Or if the price is larger than currentPrice * maxPriceToleranceRatio or lower than currentPrice * minPriceToleranceRatio.

It's important that the accountant uses a consistent policy for price submissions and that the solver is aware of this policy. We describe two valid policies that can be used.

Proactive price submission

This is the simplest price reporting policy. The accountant submits prices on a predictable interval. The solver fills orders immediately after each price update. During price updates, the reported price may deviate from the vault's holdings.

Reactive price submission

In this model the accountant aims to prevent the reported price from deviating beyond a certain threshold (e.g., 0.5%). If the price is close to deviating, the accountant reports a price. In this model the solver can fill orders at any point as the accountant prevents the price from getting stale. Note that in the event of fast price movements, the accountant will be forced to report a price sooner than the minUpdateInterval allows and therefore the price and fee calculator will be automatically and temporarily paused as a safety measure.

Note the onchain protections don't enforce a specific policy but are compatible with both.

Caveats

Since the vault does not maintain a highest price watermark for each depositor, in rare cases (e.g., after a significant price drop) the vault may need to reset the highest price watermark using resetHighestPrice.

Last updated