# Margin Trading - Preliminary Math Spec

## Global State

### Token States ($\mathbf{T}$)
The primary set of state variables of the margin trading module are token pools.

| Name | Description | Symbol |
|----|----|----|
| X Assets | Quantity of tokens of type X as an asset | $X_{A}$ |
| X Principal Liabilities | Quantity of tokens of type X as a principal liability| $X^P_{L}$ |
| X Interest Liabilities | Quantity of tokens of type X as an interest liability| $X^I_{L}$ |
| X Custody | Quantity of tokens of type X held in custody|$X_{C}$ |
| Y Assets | Quantity of tokens of type Y as an asset| $Y_{A}$ |
| Y Principal Liabilities | Quantity of tokens of type Y as a liability| $Y^P_{L}$ |
| Y Custody | Quantity of tokens of type Y held in custody|$Y_{C}$ |

$Z$ symbols used in the double swaps: using a token $X$ to swap into $Y$ and thence into $Z$.
| Name | Description | Symbol |
|----|----|----|
| Z Assets | Quantity of tokens of type X as an asset | $Z_{A}$ |
| Z Principal Liabilities | Quantity of tokens of type X as a principal liability| $Z^P_{L}$ |
| Z Custody | Quantity of tokens of type X held in custody|$Z_{C}$ |
| Y Assets | Quantity of tokens of type Y as an asset| $Y^z_{A}$ |
| Y Principal Liabilities | Quantity of tokens of type Y as a liability| $Y^{Pz}_{L}$ |
| Y Custody | Quantity of tokens of type Y held in custody|$Y^z_{C}$ |

### Stateful Metrics
| Name | Description | Symbol |
|----|----|----|
| Price | Token price | $P$ |
| Pool Health | Metric describing the health of the MTP liabilities | $H(X,Y)$ |
| Gain Factor of Pool Health | Gain factor used for borrow fee calculations | ${K_H}$ |

### Stateful Parameters
Stateful parameters are akin to the Parameter dictionary implemented in a Cosmos SDK. Values stored in the parameter dictionary may be constant, but they do not need to be. Methods to update parameter values may be implemented as well.

The Stateful Parameter set is necessary to maintain the Global State of the state variables listed above. Thus, the distinction between the two is nuanced.

| Name | Description | Symbol |
|----|----|----|
| Permit Borrowing | Binary choice to allow borrowing in a liquidity pool | $Allow$ |
| Maximum borrow fee rate | Maximum borrow fee rate that an $mtp$ can incur when it's open. Typically applies to unhealthy $mtp$'s. | $\beta_{max}$ |
| Minimum borrow fee rate | Minimum borrow fee rate that an $mtp$ can incur when it's open. Set by the liquidity pool and typically applies to well performing $mtp$'s. | $\beta_{min}$ |
| Swap fees | Fees applied to swapping in a borrowing enabled liquidity pool | $f(\cdot)$ |
| Margin Maintenance Threshold | The value of h(x) upon mtp creation | $a$ |
| Default Threshold | Health level below which any agent in the pool can cover the defaulted MTP | $b$ |
| Maximum allowed leverage | Maximum leverage allowed when opening an mtp with a given collateral size | $\eta_{max}$ |
| Maximum opening position | Maximum size of position permitted to open an MTP | $\eta_{max}(X)$ |

#### Stateful Parameters in the context of Borrow Fee

| Name | Description | Symbol |
|----|----|----|
| Maximum borrow fee rate | Maximum borrow fee rate that an $mtp$ can incur when it's open. Typically applies to unhealthy $mtp$'s. | $\beta_{max}$ |
| Minimum borrow fee rate | Minimum borrow fee rate that an $mtp$ can incur when it's open. Set by the liquidity pool and typically applies to well performing $mtp$'s. | $\beta_{min}$ |
| Target borrow fee | Upcoming borrow rate is computed for each $mtp$ in a pool applied over next epoch. | $\beta^\star$ |
| Target borrow fee health | Health component of $\beta^{\star}$ | $\hat{\beta}$ |
| Epoch Length | Defined number of blocks (or time) where upcoming borrow rate is computed for each $mtp$ | $T$ |

#### Stateful Parameters in the context of Liquidity Remove Restrictions

| Name | Description | Symbol |
|----|----|----|
| Liquidity Remove Floor | Minimum size required for a liqudity remove request to face restrictions | $\phi$ |
| Time lock duration | The entire duration of the time lock on a liquidity removal | $\Pi$ |
| Time lock period | Duration of intervals in the time lock | $\pi$ |
| Liquidity Remove drip | Percentage of tokens requested in a liquidity remove that drip out in each time period in a time lock | $\theta$ |
| Liquidity remove volume | Volume of liquidity that would is removed in the current epoch | $p$ |
## Local State
Local state is the state necessary for having a legal and active account with a margin trading position ($mtp$). The local state also includes the information necessary for properly interacting with the margin trading system ($MTP$).
| Name | Description | Symbol |
|----|----|----|
| MTP State | State of an individual MTP | $mtp$ |
| $mtp$ $id$ | Individual margin trading position address of an $mtp$ owner | $\mathcal{A}_{mtp}$ |
| Size of action (x) (asset) | Quantity of tokens of type X used to perform action (collateral)| $x_{A}$ |
| Size of action (x) (liability) | Quantity of tokens of type X in principal liabilities taken on| $x^P_{L}$ |
| Size of action (x) (liability) | Quantity of tokens of type X in interest liabilities accrued| $x^I_{L}$ |
| Size of action (y) (asset)| Quantity of tokens of type Y that are held in custody by taking on liability position in x | $y_{C}$ |
| Closing value | Value of y expressed in terms of x as an mtp is being closed | $\bar x$ |
| Closing value | Value of x expressed in terms of y as an mtp is being closed | $\bar y$ |
| Borrow fee rate | Interest rate applied to a borrow during when an $mtp$ is opened. This rate is $mtp$-specific and event and time varying.| $\beta$ |
| Accumulated Interest fees | Interest fees that accrue over time, payable upon $mtp$ close | $\beta(\cdot)$ |
| Leverage | Leverage multiplier on amount borrowed | $\eta_{mtp}$ |
| MTP Health | Metric describing the health of an individual MTP | $\overrightarrow{h(X,Z)}$ |

#### Local State in the context of Borrow Fee

| Name | Description | Symbol |
|----|----|----|
| Borrow fee rate | Interest rate applied to a borrow during when an $mtp$ is opened. This rate is $mtp$-specific and event and time varying.| $\beta(\cdot)$ |
| Block (time) count between epochs | Count for borrow fee and interest liability local computation | $t$ |

#### Local State in the context of Forced Settlement by Any Address
| Name | Description | Symbol |
|----|----|----|
| Forced Settlement Reward function | Computes the percentage to be applied to the Forced Settlement Reward amount | $R_{FS}(\cdot)$ |
| Forced Settlement Reward | Amount of tokens rewarded to an agent that makes a forced settlement call | $R_{FS}$ |

#### Local State in the context of Liquidity Remove Restrictions
| Name | Description | Symbol |
|----|----|----|
| Number of intervals | Number of intervals in which the liquidity is removed. Also the number of token drips, as tokens are dripped in 1 drip per perio | $n$ |
| Liquidity Remove drip amount | Amount of tokens requested in a liquidity remove that drip out in each time period in a time lock | $\theta$ |
| Total Available Liquidity | Scalar quantity that describes the total liquidity available in the pool considering the available liquidity in both sides of the X-Y token pair | $\Omega$ |
| Liquidity Remove Requested Amount | Amount of liquidity to be removed requested by an LP | $\Theta$ |

## Chain State and Full State

Throughout the specifications for the margin trading system, we refere to a Chain State and a Full State. The **Chain State** comprises all the state variables, where each of these state variables are computed and updated on-chain with every state change.

The **Full State** comprises all all stateful metrics - global and local. These are higher-order and can be deterministically computed from a set of the latest Chain State state variables polled from the blockchain. The logic for this computation may be housed off-chain, say on the UI, thus improving performance by saving on on-chain computational and storage costs.

Metrics in the Full State can be calculated via a pre-defined computation that lives in the end-user application layer, akin to Cosmos SDK's `Query` method.

If **all** information could be computed every block for **nearly no** cost, there would be no need for the distinction between the **Chain State** and the **Full State**. This idealized scenario would result in perfect information knowledge. Decisions on the frequency to call the `Query`, triggering events, and dependent computation updates, such as updates to parameter methods determine the difference in knowledge between the information in the **Chain State** and the information in the **Full State**.

## MTP Lifecycle

### Open $mtp$

In order to take a Margin Trading Position (${mtp}$), an agent can perform an ***Open $mtp$*** action.

#### Operational Requirement
> This action can only be performed by an $mtp$ owner, and it can only be perfomed when the $mtp$ is in a *healthy* posterior state.

The Open $mtp$ action is composed of two primitives - Borrow and Swap - described in more detail in the "Mechanisms" section.

1. **Borrow**
The agent borrows $x_L = x_A \eta_{mtp}$ amount of X-tokens against collateral $x_A$ which already exists in their wallet. The agent borrows this amount from the liquidity pool. $\eta_{mtp}$ is the leverage multiplier and $\eta_{mtp} > 0$. $$CLP \overset {borrow \: x_L} \longrightarrow Agent$$

2. **Swap**
The borrowed amount $x_L$ is swapped for $y_L$ amount of Y-tokens, thus creating a long position in the opposite side of the trading pair. This amount is held in a separate trading account for some duration so as to allow it to appreciate. The Sifchain protocol has custody over the account; while the agent can take some actions against these funds, he cannot use them for arbitrary purposes not intended for an mtp. $$x_L \overset {swap} \longrightarrow y_L$$

In this case, the agent borrows $x_L$ as a liability against a collateral of $x_A$ as an asset. So the leverage is $$\eta_{mtp} = \frac{x_L}{x_A}$$

### Hold $mtp$
Once the $mtp$ starts, the agent accumulates an interest fee $\beta(\cdot)$ on the initial borrowed amount over time. As the agent accrues interest, their mtp's liability grows.

During this phase, the price $P_{Y \rightarrow X}$ of Y-tokens for X-tokens can remain the same, appreciate, or depreciate. The movement of $P_{Y \rightarrow X}$ determines the health of the MTP.

The agent is able to add collateral beyond the initial collateral they offered to reduce their leverage and increase the health of their mtp.

### Close $mtp$

In order to close their $mtp$, an agent can perform a ***Close $mtp$*** action. This action can only be performed by an $mtp$ owner (or a separate function in the case of liquidation). The close $mtp$ action is composed of two primitives - Swap and Repay.

When an agent performs an Close $mtp$ action,

1. **Swap**
The amount held in the agent's trading account $y$ is swapped for its current value in terms of X-tokens, $\bar x$ $$ y \overset {swap} \rightarrow \bar x$$

2. **Repay**
The agent pays back to the CLP $x_L$ amount of X-tokens plus accumulated interest. $$Agent \overset {x_L + \beta(\cdot)} \longrightarrow CLP$$

Upon closing the $mtp$, the agent would net a profit or loss which is the difference between the value of their current holdings and the amount repaid, as well as the borrow fee upon opening the $mtp$. $$profit\_or\_loss_{mtp} = \bar x - (x_L + \beta(\cdot))$$

## Principal Liabilities and Interest Liabilities

We can characterize liabilities into four distinct categories based on their path of execution, how they can be computed, and which entity incurs them.

### Liabilities in the Global State

Each liquidity pool that offers margin trading takes on $MTP$ Principal Liabilities and $MTP$ Interest Liabilities.

**$MTP$ Principal Liabilities** are liabilities that the pool captures upon any participant opening an individual $mtp$. This is the running sum of all the borrow amounts $x_L$'s from all individual $mtp$'s opened excluding all the amount repaid, and excluding any interest fee.

$$X^P_{L} = \sum\limits_{i=0}^N x^P_{L,i}
$$

where $i$ is the index of individual $mtp$'s and $N$ is the total number of all $mtp$'s currently in the pool.

At any given state, the total $MTP$ pool liabilities are $MTP$ Principal Liabilities.

$$X_L = X^P_{L}
$$

:::warning
Interest liabilities are accumulating at the $mtp$ level, but are not considered part of the liquidity pool liability
:::

### Liabilities in the Local State

Similarly, each $mtp$ owner also takes on liabilities, one of which is set at the time of opening or borrowing more, and another that accumulates over time.

**$mtp$ Principal Liabilities** are the liabilities that the $mtp$ owner gets upon opening an $mtp$. This is the borrow amount $x^P_L$ that is used to open the $mtp$, excluding any added collateral $x^P_A$ through margin maintenance on the same $mtp$, and excluding all interest fees.

$$ \mathbf{x}^P_{L} = x^P_{L,t} - \sum\limits_{t=0}^{\mathbf t} x^P_{A,t}
$$

At the borrow amount at $t=0$, i.e mtp start is $x^P_{L,0}$. Substituting,
$$ \mathbf{x}^P_{L} = x^P_{L,0} - \sum\limits_{t=0}^{\mathbf t} x^P_{A,t}
$$

where $t$ is the period and ${\mathbf t}$ is the current period.

> **Note**
> At this time, agents are not permitted to add more liabilities to an existing open $mtp$. If they would like to add liabilities, they can open a new $mtp$ in the same pool.

**$mtp$ Interest Liabilities** are liabilities that the $mtp$ owner incurs over time from the accumulating interest fees $\beta(\cdot)$ owed on their $mtp$. This is the running sum of interest fee incurred by the $mtp$ from each period, less all the already paid interest fees.

$$ \mathbf{x}^I_{L} = \sum\limits_{t=0}^{\mathbf t} x^I_{L,t}
$$

where $t$ is the period and ${\mathbf t}$ is the current period.

At any given state, the $mtp$ owner's liabilities are a sum of $mtp$ Principal Liabilities and $mtp$ Interest Liabilities.

$$\mathbf{x}_L = \mathbf{x}^P_{L} + \mathbf{x}^I_{L}
$$

## Borrow Fee

### Borrow Fee Between Epochs
At each epoch $T$, the target borrow fee $\beta^{\star}$ for the next epoch is computed and broadcast for each open $mtp$. Furthermore, there is a higher interest rate component associated with positive length queues determined by $s(q)$.

$$ \beta^{\star} = \hat{\beta} + s(q)$$

with

$$\hat{\beta} = K_H({H(X,Y)})$$

where $K_H$ is a tuneable gain factor.

At the start of each epoch, $t=0$ and $\beta_t \approx \beta^\star_{T-1}$. At the end of each epoch, $t=T$ and $\beta_t \approx \beta^{\star}_T$.

During each epoch, we want $\beta$ to move toward $\beta^{\star}$, where the diffence between the previous borrow fee and the target and the rate of update are the expected inputs:

$$ \beta^+_t = f(\beta^{\star}_T , t)$$

Under an assumption decreasing rate of change $\beta^+_t$ during the epoch, we can allow local computation of the borrow fee in this manner:
$$\Delta \beta_t = (\beta^{\star}_T - \beta^{\star}_{T-1}) \cdot \frac{\ln(2)}{t \cdot \ln(T)}$$
for $T >1$, and where the term $\frac{\ln(2)}{\ln(T)}$ is a constant for any $T$.

:::warning
What is the desired borrow fee compounding strategy? What will be the corresponding borrow rate annualization?
Exponential (increasing rate) of an exponential (on worsening health) can explode interest liabilities. Proper tuning of gain necessary.
Time to default if no maintenance is one metric to determine range of K. Another is annualized realized rate.
:::

#### Effects of Liquidity Pool Actions on Borrow Fee
Available liquidity (function value) as well as add and remove liquidity actions (derivative) are expected to affect $H(X,Y)$ and subsequently affect $\beta$. Likewise, opening and closing an $mtp$ will also effect $H(X,Y)$ and $\beta$. We can explore both cases with partial derivatives, where there is an action taken on $X$ and we resolve the metric:

$$ \frac{\partial\beta}{\partial X} = \frac{\partial}{\partial X}\bigg(\frac{K}{h(x)}\cdot f(H(X,Y))\bigg)$$
If we use the version from the previous section where:
$$f(H(X,Y))= \frac{K_H}{H(X,Y)}$$
Then,
$$ \frac{\partial\beta}{\partial X} = \frac{\partial}{\partial X}(\frac{K_h}{h(x)}\cdot \frac{K_H}{H(X,Y)})$$
Pulling out the constant term:
$$ \frac{\partial\beta}{\partial X} = \frac{K_h}{h(x)} \cdot \frac{\partial}{\partial X} (\frac{K_H}{H(X,Y)})$$
And differentiating:
$$ \frac{\partial\beta}{\partial X} = -\frac{K_h}{h(x)} \cdot \frac{K_H}{H(X,Y)^2}\cdot {\partial X} $$
### Applying pending liquidity removes to interest rate
A liquidity removal from a pool can cause the health of the pool $H$ to drop if the withdrawal is large enough. To avoid this, there is a governance-set threshold health level, $\bar{H}$, below which liquidity cannot be removed. The part of liquidity removal requests that would cause $H(X,Y)$ to drop below $\bar{H}$ is placed on a waiting list.

Liquidity withdrawals on this waiting list are disbursed at a point in the future when there is enough liquidity in the pool for the pool's health to stay at or above $\bar{H}$. Denote by $X_A',Y_A'$ the assets in the pool after some widthdrawal. Denote by $\theta_t$ the maximum amount of requested liquidity that can be withdrawn on period $t$ such that $H(X',Y') \geq \bar{H}$. $\theta_t$ is distributed proportionally among the requests on the waiting list. Denote the amount of liquidity withdrawals on the waiting list $\omega_t$ at block $t$.

At time $t$, $q_t$ is defined as:

\begin{cases}
0 & \text{if } \omega_t = 0 \\
q_{t-1} + \omega_t & \text{otherwise.}
\end{cases}

Thus $q$ can be interpreted as the sum of the time-value of all elements that have been in the waitlist since it last cleared (either $x$ or $y$) in a common denomination (Rowan). The natural unit for this is Rowan blocks of queued assets. For example, 5 Rowans worth of tokens queued for 1 block is equivalent to 1 Rowan queued for 5 blocks.

$$
s(q) = \min{ ( a\cdot q , s_{\max})}
$$

## Interest Liabilities
### Accumulated Interest Liabilities Domain Mapping
The interest liabilities for each position $mtp$ is the accumulated interest fee for that position.

$x^I_{L}$ is a function of:
$$ x^I_{L,t} = f(\beta_t, x_{L,t}) $$

$$ x^I_{L,t+1} = \beta_t \cdot (x^I_{L,t}+x^P_{L,t}) $$

Interest liabilities can computed from $x^P_{L,0}$. Each computation of interest liabilities in the time history can be used to compound the interest on the $mtp$.

$$x_{L,t} = x^P_{L,0} + x^I_{L,t-1}$$

So the interest liabilities at $t$ are
$$ x^I_{L,t} = f(\beta_t,t_{block},x^P_{L,0} + x^I_{L,t-1})$$
for $t>1$.

Computed as an integral for each successive block where each rectangular area segment is the $\beta \cdot x_L$

### Interest Liabilities between Epochs
At the individual $mtp$ level, interest liabilities $x^I_L$ need to be a part of the Chain State at the epoch level, as the calculation of $mtp$ health $h(\mathbf x)$ is contingent on it.

$\beta^*$ and $h(\mathbf x)$ will be computed at every epoch. Thus, $x^I_L$ needs to be polled with the once per epoch frequency. Within an epoch, $x^I_L$ accumulates off chain. It is realized on-chain at the start of the next epoch. To summarize,
- $x^I_L$ is in Chain State at the epoch level
- $x^I_L$ is in Full State within an epoch

### Effects of interest liabilities on $mtp$ health
At the epoch level, as interest liabilities accumulate, $mtp$ health deteriorates.

$$ h(x) = \frac{x_A}{x_A + x_L}$$

The decline in $h(x)$ affects the steady state interest rate $\beta^*$ as

$$ \beta^{\star} = \frac{K_h}{h(x)} \cdot \frac{K_H}{H(X,Y)}$$

Thus, within an epoch, $\beta^{\star}$ is an *attractor*. In the above equation, the $\frac{K_h}{h(x)}$ term is $mtp$ specific and forms a *local attractor*. Whereas the term $\frac{K_H}{H(X,Y)}$ is akin to a base rate applied to all $mtps$ in the pool and forms a *global attractor*. The local attractor term $\frac{K_h}{h(x)}$ includes interest liabilities $x^I_L$ as $$ h(x) = \frac{x_A}{x_A + x_L}$$ and $$x_L = x^P_L + x^I_L$$

### Effects of interest liabilities on $MTP$ health

There is no notion of interest liabilities at the $MTP$ pool level, however, the individual $mtp$ level accumulating interest liabilities do have an indirect effect on the $MTP$ pool health.

As $x^I_L$ accumulates, $h(\mathbf x)$ drops if the $mtp$ owner does not cover it at every epoch. As $h(\mathbf x)$ declines, more $mtp$s default and that causes $H(X)$ to decline.

---
Updated Composite Mechanism Map:

---
Event Sequence Diagrams Partitioned by $mtp$ status

For a healthy $mtp$:

For an at-risk $mtp$:

For a default, covered $mtp$:

For a default, not covered $mtp$:

## Systemic Risks

Risks may be classified into **$MTP$ Pool Risks** and **Individual $mtp$ Risks**. These ultimately inform the health of the entity and are used as a basis for characterizing their health metrics $H(\mathbf X)$ and $h(\mathbf x)$. The systemic risks outlined below must be tracked and captured either via the health metrics or other performance metrics.

### $MTP$ Pool Risk

As each $MTP$ pool is part of the larger Liquidity Provider (LP) Subsystem, there needs to be a sufficient amount of tokens available on both sides of the X:Y pair in order maintain the core functionality of the LP Subsystem. Two LP subsystem actions that can be be adversely affected by increasing $MTP$ pool risk are:
1. Swaps
2. Removing Liquidity

There needs to be some minimum amount of tokens available in the Liquidity Pool in order to carry out core activities like swapping and removing liquidity. We can define this amount as a **slack**, and set lower bounds such as:
1. Minimum slack required for any agent to perform swaps
2. Minimum slack required for currently outstanding liquidity providers to remove liquidity


#### Risk from cascades of liquidity removes

A significantly large liquidity remove could trigger a cascade of more liquidity removes.

**Operational Requirement**: The $MTP$ pool must be able to handle multiple consecutive large liquidity removes gracefully, while ensuring the availability of a minumum slack required for swaps and liquidity removes.

#### Risk from cascades of $mtp$ defaults

If a significantly large $mtp$ defaults and is not covered, it could trigger a cascade of more $mtp$'s defaulting as a result of deteriorating pool health $H(\mathbf X)$.

**Operational Requirement**: The $MTP$ pool must be able to handle multiple consecutive $mtp$ defaults gracefully, while ensuring the availability of a minumum slack required for swaps and liquidity removes.


:::warning
- What percentage of event sequences trigger a cascade?
- Under which **sequence of events** are cascades likely to occur?
- Are there risks due to correlated behaviour?
:::

The above questions can be answered empirically using cadCAD models. To do this, we need a stochastic process model of the system. The two areas where cascading failures can be triggered are $mtp$ defaults and liquidity removes. This is because both of these have a reinforcing causal loop that can lead to an unhealthy system state. First we need a probability distribution of liquidity removes that considers both their frequency as well as the magnitude. Likewise we need a probability distribution of $mtp$ defaults that considers both their frequency as well as the magnitude.

As the system is a state-dependent stochastic process, we also need to consider the current system state. The probability distributions of liquidity removes and $mtp$ defaults combined with the system state gives the stochastic process model of the overall system.

A Maximum Likelihood Estimator can be used to obtain the percentage risk of cascade failure due to either liquidity removes or mtp defaults.

We can perform controlled experiments with
- liquidity removes ON and mtp defaults OFF
- liquidity removes OFF and mtp defaults ON

to get the independent risk potential of either factor.

Finally, to study the interaction effects and identify any risks due to correlated behaviour, we can perform an experiment with both liquidity removes ON and mtp defaults ON. If all parameters are set to represent a typcial scenario and the probability distributions are neutral, this experiment would give a realistic estimate of the % risk estimate of cascade failures in the system.

The % risk estimate can be be surfaced as a stateful metric as well. This requires that it be updated at every state. We can create a rolling % risk estimate due to cascade failures $\alpha$ that is updated using a Bayesian update

---
## Close Mechanism
| Name | Symbol | Definition |
| -------- | -------- | -------- |
| Local State | $mtp$ | Individual MTP Position |

| Name | Description | Symbol |
|----|----|----|
| Size of action (x) (asset) | Quantity of tokens of type X used to perform action (collateral)| $x_{A}$ |
| Size of action (y) (asset)| Quantity of tokens of type Y that are obtained from action | $y_{A}$ |
| Size of action (x) (liability) | Quantity of tokens of type X used to perform action (collateral)| $x_{L}$ |
| Size of action (y) (virtual liability)| Quantity of tokens of type Y that are obtained from action | $y_{L}$ |
| Current value | Current value of y expressed in terms of x | $\bar x$ |
| Current value | Current value of x expressed in terms of y | $\bar y$ |

:::warning
Ownership of $y_A$?
Compute $\Delta y_{close}$ not only as necessary to close position, but also as a comparator to $\Delta y_{open}$ for $mtp$ holder profit ($\Delta y_{close}<\Delta y_{open}$) and loss ($\Delta y_{close}>\Delta y_{open}$). This may also be used for determination of the forced close condition.
:::

# NOTES

#### Risk from accumulating interest liabilities

Interest liabilities $X^{I}_{L}$ accumulate over time as a running sum of interest fees from all currently open $mtp$'s. This continually drives down the pool health $H(\mathbf X)$ as
$$ H(\mathbf X) = \frac{X_A}{X_A + X_L}$$ and
$$X_L = X^P_{L} + X^{I}_{L}
$$

As $X^{I}_{L}$ increases, $X_L$ increases, and $H(\mathbf X)$ decreases due to inverse proportionality.

#### Applying pending liquidity removes to interest rate
We desire to modulate the interest rate of $mtp$'s based on the volume of pending liquidity removes in the liquidity pool that the $mtp$ belongs to. To do this, we can compute the expected pool health at the next state $H^+(X)$. We know the amount of tokens $p^+$ that will drip out of the pool in the next epoch. This amount will be deducted from the pool's assets, so the health results in
$$ H^+(X) = \frac{X_A - p^+}{(X_A-p^+) + X_L}$$

where $p^+$ is the volume of liquidity that would be removed from the pool in the next epoch. This pool health can be used to compute interest rate, as it incorporates the volume of pending liquidity removes in the upcoming state.

$$ \beta^{\star} = \frac{K_h}{h(\mathbf x)} \cdot \frac{K_H}{H^+(\mathbf X)}$$

:::warning
Note that this method introduces variable interest rates. A varying $\beta^*$ could be a UX concern depending on the degree of variability. $mtp$ owners may want some guarantees around $\beta^*$ in order to prepare for regular interest payments, make projections on margin trading profitability, among others.
:::

---
Continue Reading the [Mechanism Specification](https://hackmd.io/e2K_VzC-TFyC8MDjqHwczA)