Swap Amount
Value flows for cross-side swaps:
In the table, we have two scenarios in which we perform a swap when the Capital Ledger is in deadband, while we only have one scenario where a swap is performed when the Asset Ledger is in deadband. This is because we need to accumulate surpluses into the Capital Pool for Market Yield. It also follows that when we have a surplus in the Capital Pool, we do not wish to reduce this surplus unless it is strictly necessary to replenish the Asset side in cases where the ratios determine there are insufficient assets to cover potential Taker Closes (Asset Adequacy).
Under settings of asset price volatility, the protocol will tend to oscillate between its shortfall and surplus states. While there may be situations where the protocol measures an asset shortfall, it is expected that assets will generally be in surplus given that our configuration of the liquidity operating bands favours the asset side of protocol liquidity to mitigate the risk of swapping USD back for ETH. However while the protocol may routinely be in a state of shortfall, the protocol maintains the Capital Reserve to begin to cover the Liability if the currently measured yield reduces below zero (see subsection: Shortfall).
In general we wish to minimise the number of swaps (maximise swap size) due to accumulative gas costs on blockchains, but also minimise the real time to execute a swap where one may be necessary in order to minimise slippage.
The minimum swap size should be much larger than the expected gas cost (say, approximately 100 times) so as to make the gas cost small relative to the number of swaps triggered over time.
Cross-side rebalancing should be called after a user action function is used (except for Renew), and after each premium update. User action functions (Deposit, Withdraw, Protect etc) assume that protocol state is up to date (including that rebalancing has been performed). Before any rebalancing action is performed, the protocol liabilities should all be updated; the function of rebalancing is to determine how to update the values of the Pools and Reserves (see Section: System Summary - State).
By way of convention, we refer to the Asset side of the protocol as requiring it to be either bought or sold (the effect of a trade reducing/increasing tokens in one pool simultaneously reduces/increases the other).
Last updated
