Cross-Side Rebalance and Swap Deadband

CALLING REBALANCING

Rebalancing must be executed after any update to the protocol state. Specifically, when:

(i) a new price is encountered in the price feed, triggering a premium update, and,

(ii) when a user action function is called.

All protocol state updates mutate the current liabilities (B, L, D and E).

CROSS-SIDE REBALANCING

When the protocol executes a swap, it is debiting one side of the market and crediting the other. We must therefore consider the total value of the asset and capital pools at the same time in order to minimise the differences between the final value of all assets and capital against their respective adequacy targets and determine how much to trade.

• In the case of inadequate Capital, the Capital side wants the protocol to sell an increasing amount of Asset, with proceeds deposited to the Capital side.

• In the case of inadequate Assets, the Asset side wants the protocol to buy an increasing amount of Asset, with the proceeds deposited in the Asset side.

Liquidity adequacy then is determined as follows.

We define a set of measures, called the Asset Ledger (AL) and Capital Ledger (CL) to establish a minimum nominal value of Asset or Capital that each side of the protocol requires. We define displacement (in general) as the difference between a measured value and its reference.

Building upon the section dealing with the premium computation, the liquidity ratios that cover total Assets and total Capital are:

$$\begin{align*} LR_3 &= \frac{AP + AR}{B} \\[18pt] LR_{13} &= LR_{11} + LR_{12} \\[2pt] &= \frac{CP}{\text{β} \cdot L + D + E} + \frac{CR}{L} \end{align*}$$

SWAP DEADBAND

In order to minimise spurious swaps, we define a deadband around the reference ratio, wherein a liquidity ratio’s displacement from the reference ratio does not contribute to the amount of a cross-side rebalance trade (i.e. rebalancing trades only activate when one or more liquidity ratios are measured to be out-of-band).

The liquidity reference ratios (with their accompanying deadbands) are:

$$\begin{align*} r_{w,\,3}(\,\text{β}\,) &= -\;pb_{L,\,3} (\,\text{β}\,) + pb_{U,\,3} \;\;\;\; (\;\pm db_{*,\,3}\,) \\[5pt] \text{i.e.} \\[5pt] LR_3 \; &\in \; [\, r_{w,\,3}(\,\text{β}\,) - db_{L,\,3} \;\;,\;\; r_{w,\,3}(\,\text{β}\,) + db_{U,\,3} \,] \\[18pt] r_{w,\,13}(\,\text{β}\,) &= pb_{L,\,13} + pb_{U,\,13} (\,\text{β}\,) \;\;\;\; (\;\pm db_{*,\,13}\,) \\[5pt] \text{i.e.} \\[5pt] LR_{13} \; &\in \; [\; r_{w,\,13}(\,\text{β}\,) - db_{L,\,13} \;\;,\;\; r_{w,\,13}(\,\text{β}\,) + db_{U,\,13} \;] \end{align*}$$

How the deadbands are configured influences how frequently cross-side swaps occur, and by extension, the degree to which parasitic spread and slippage costs (together “Price Impact”) are incurred by the protocol and borne by its participants.

For cross-side rebalancing, our deadbands imply that the displacement is calculated from the midpoint of this band, whereas a ledger is defined by the displacement that exceeds the deadband.