Yield AMM

Yield AMM (YAMM) pools cater to the unique requirements of principal and yield token trading. Each refractable asset has a corresponding pool, comprising cAsset and active pAsset tokens as liquidity. As time progresses and new maturity levels are introduced (or old ones expire), the amm module automatically updates the related pAssets in the respective pools.

Preliminaries

The refractor exchange rate is the ratio of the total supply of pAsset to the cAsset amount in the Refractor vault.

This rate at time $t$ is denoted as $\rho(t)$. If a user refracts a cAsset amount $a$, they will receive $\rho(t)a$ of pAsset and an identical amount $\rho(t)a$ of yAsset.

The yield rate to maturity $r$ for a specific pAsset can be calculated using the formula

$$r=\left(\frac{1}{p \cdot \rho(t)}\right)^\frac{1}{t_0}-1,$$

where $p$ is the pAsset's market price (in terms of the cAsset) and $t_0$ is the pAsset's time to maturity.

Design

YAMM utilizes Balancer's constant weighted geometric mean formula, expressed as

$$\prod_{j=0}^ n x_j^{w_j} = C \ ,$$

where, for each $j \in \{0, 1, . . . , n\}$, $x_j$ and $w_j$ denote the balance and weight of token $j$ in the pool, respectively, and $C$ is a real number. Token $0$ represents the cAsset while tokens $1$, $2$, $\ldots$, $n$ are the pool's pAssets.

In the YAMM model, weights vary over time. We also incorporate virtual balances and leverage parameters to ensure that the balance curves for the cAsset and any pAsset progressively flatten, mirroring the balance curve of the YieldSpace AMM. YAMM trading adheres to standard Balancer formulas.

To account for a token's time to maturity, we introduce the $\alpha$ parameter, computed as:

$$\alpha_j(t) = \min \left\{\frac{t - a_j}{b_j - a_j}, 1 \right\} \ .$$

In this formula, $j$ signifies each pAsset, $a_j$ and $b_j$ denote the initial and maturity time of the pAsset, respectively, and $t$ represents the current time. Note that $\alpha_j(a_j)$ equals 0 and $\alpha_j(b_j)$ equals 1. For all $t\in [b_j,+\infty)$, $\alpha_j(t)$ is set to 1. The expression $1-\alpha_j(t)$ represents the scaled time to maturity of token $j$, which varies from 0 to 1.

Leverage Parameters

The YAMM utilizes leverage parameters for each pAsset in the pool to enhance pricing precision for traders and replicate the YieldSpace curve. Denoted as $k_j$, these parameters are dynamic and time-dependent. For each $j\in\{1,2,\ldots,n\}$, we define the leverage parameter as:

$$k_j(t) = \left\{ \begin{array}{cl} \dfrac{1}{1-\alpha_j(t)} & \textnormal{if }\alpha_j(t) \leq 0.98 \\ 50 & \textnormal{if }\alpha_j(t) \geq 0.98 \end{array}\right.$$

To avoid numerical issues when $\alpha$ nears $1$, it's essential to cap the leverage parameter $k_j$; we set this limit at $50$. It's worth noting that in practice, we enforce a configurable maximum parameter to limit the alpha parameter, not the fixed $0.98$ value used here.

Lambda Parameter

The lambda parameter is another leverage parameter for the cAsset, denoted by $\lambda$. This parameter is constant for each pool and must meet the condition $\lambda \geq 1$. A larger $\lambda$ results in flatter curves and better trader prices, but less price discovery. We suggest a default $\lambda = 10$, although this can be configured per pool.

Parameter $L$

Parameter $L$ gauges the pool's liquidity. At all times, $L$ should equal the number of LP tokens in circulation. We also recommend that the initial number of LP tokens assigned to the pool creator—or the initial liquidity provider—should equal the quantity of cAsset deposited when the pool is established. As such, $L$'s initial value is $C$.

Virtual Adjustment Balances

To facilitate smooth transitions when adding or removing pAssets from the pool, we introduce virtual adjustment balances. These are amounts added to the YAMM pool's virtual balances, and are time-dependent functions. Generally zero, these balances deviate from zero when a new token is added to the pool or an existing one is removed. In these cases, the corresponding virtual adjustment balance will incrementally increase or decrease. Each pAsset in the pool has a corresponding virtual adjustment balance, denoted by $D_1(t),\ldots,D_n(t)$.

Virtual adjustment balances are defined using parameter $L$ as follows. For each $j\in\{1, 2, ...., n\}$ we define:

$$D_j(t) = d_j(t) \cdot L$$

The function $d_j(t)$ is defined as:

• When pAsset$_j$ is added to the pool:

  $$d_j(t)=A-\frac{A}{T}\cdot \min\{t-t_0,T\} \ , \textnormal{for }t\in [t_0, t_0+T]\ ,$$

  Here, $t_0$ is when the new pAsset is added to the pool, $T$ is the time during which the virtual adjustment balance gradually decreases to $0$, and $A=5$. In the implementation, $A$ corresponds to the configurable property introduction_virtual_balance_scaler. $T$ can be any appropriate time duration (e.g., a week, fortnight, month) that allows a gradual decay of the virtual adjustment balance. Note that at $t_0$, $d_j(t_0)=A$ and at $t_0+T$, $d_j(t_0+T)=0$.

• When pAsset$_j$ is removed from the pool, we denote the time of maturity of the pAsset by $b$ and the length of the asset removal period by $T$ (for instance, a week). We then define $d_j(t)$ as follows:

  $$d_j(t)=10 \cdot \frac{t+T-b}{T}\ , \textnormal{for }t\in[b-T,\infty]\ ,$$

  Here, $d_j(b-T)=0$ and $d_j(b)=10$. As mentioned in the introduction, we don't use a constant $10$ in the implementation. Instead, this constant can be configured through the expiration_virtual_balance_scaler property. It's important to note that $t$ can be as large as possible, meaning the virtual balance continues to increase even after the interval has ended. This process continues until the token balance is zero, at which point it is removed from the pool.

• If the above conditions do not apply, then $d_j(t)=0$ for all $t$.

To manage the virtual adjustment balances, we store an object of the following type for introducing or removing tokens:

message VirtualBalancePoolToken {
  uint64 pool_id = 1;
  string denom = 2;
  string target_virtual_balance = 3 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = false
  ];
  int64 start_unix_millis = 4;
  int64 end_unix_millis = 5;
}

The target virtual balance represents the scaler parameter used in calculating $d_j$. For introducing tokens it corresponds to the $A$ parameter, set as introduction_virtual_balance_scaler, while for expiring tokens it is set as expiration_virtual_balance_scaler.

Virtual Balances

The pool has virtual balances for trading, defined as follows. Let $B_0,B_1,\ldots,B_n$ represent the real balances of all tokens in the pool. The virtual balances $V_0,V_1,\ldots,V_n$ are defined by

$$V_0 = B_0 + (\lambda-1) \cdot L$$

and

$$V_j = B_j + (k_j(t)-1) \cdot L + D_j(t)$$

for $j\in\{1, 2, ..., n\}$.

Weights

The weights of different tokens vary over time. The refractor exchange rate at time $t$ is denoted by $\rho(t)$. We define the weights $w_j$, $j\in\{0, 1, ..., n\}$, as follows:

$$w_0=\rho(t) \lambda$$

and

$$w_j = k_j(t)$$

for all $j\in\{1, 2, ...., n\}$. The weights are then scaled proportionally so that $\displaystyle \sum_{j=0}^n w_j = 1$.

Trading Fee

The YAMM is designed for trading among yield-bearing tokens, so it's logical that the trading fee isn't a fraction of the token amounts traded, but rather a percentage of the yield rate. The traditional constant fee rate can be problematic in this setting as it can cause a significant difference in the yield rate of the token if the yield is small or if the pAsset is nearing maturity. To define a meaningful trading fee, we'll create a fee that varies with time. Let $r$ denote the expected average monthly yield rate of the pAssets. If we have no information about the expected yield rate, we can set $r$ to a constant value of 0.01. For each $j \in\{1,2, \ldots, n\}$, let $\tau_j$ denote the period, in months, between the introduction and maturity of pAsset $j$. This means $\tau_j$ equals $b_j-a_j$ measured in months, where $b_j$ and $a_j$ are the maturity's expiration and introduction times, respectively.

We'll also establish a parameter $\nu>0$, initially set to 1. Governance can later adjust this to raise or lower pool fees.

With these parameters in place, we define the fee for each pAsset $_j$ at time $t$ as:

$$\phi_j(t)=\left(\alpha_j(t) \cdot 0.000125+\left(1-\alpha_j(t)\right) \cdot 0.002\right) \cdot 12.84 \cdot \nu \cdot\left((1+r)^{\tau_j}-1\right)$$

The factor $\left((1+r)^{\tau_j}-1\right)$ is the yield rate of $\mathrm{pAsset}_j$ from introduction to maturity. We can round the parameter $\tau_j$ to the nearest integer to reduce computation.

Importantly, $\phi_j$ doesn't depend on the pAsset's price—an intentional design choice to avoid manipulation.

For the cASSET, we define the fee as $\phi_0(t)=0$ for all $t$. Now, for $i, j \in\{0,1, \ldots, n\}$, the trading fee for trading assets $i$ and $j$ at time $t$ is:

$$\phi=\max \left\{\phi_i(t), \phi_j(t)\right\} .$$

Pool Interactions

Since yamm pools are based on weighted pool designs, standard operations like swapping, depositing liquidity, and withdrawing liquidity all function as outlined in the weighted pools page.

Zero Impact Join

If a user wants to join a pool using only cASSETs, we need to use non-proportional join methods, which involve underlying swaps. But swaps during joining can cause high price impact. To solve this, we've developed a zero-impact join feature that lets users join a YAMM pool with just cASSETs, minimizing price impact.

The zero-impact join includes two steps:

1. Refract a portion of the cASSET into pool maturities.
2. Use the remaining cASSET and pASSETs to join the pool.

The user receives LP tokens and yASSETs from the initial refraction.

To refract the correct amount of cASSET for each maturity, we need to get the right proportion of each token to join the pool. If the pool contains $n+1$ tokens with balances $\{B_0,B_1, ..., B_n\}$, where $B_0$ is the cASSET balance and the others are pASSETs, we calculate the required cASSET amount to refract for each token to match the pASSET balance in the pool:

$$\forall_{j>0} C_j = \frac{B_j}{\rho_e}$$

Here, $\rho_e$ is the refractor's effective exchange rate, accounting for the protocol fee. The effective exchange rate can be calculated as $\rho_e = (1-\phi) \times \text{exchangeRate}$. After determining the amount of cASSET necessary to match the actual balances in the pool, we can calculate the total cASSET required using the following formula:

$$C_{total} = B_0 + \sum_{j>0}C_j = B_1 + \frac{\sum_{j>0}B_j}{\rho_e}$$

This allows us to establish the ratio associated with each pASSET:

$$\forall_{j>0} r_j = \frac{C_j}{C_{total}} = \frac{B_j}{\rho_e B_1 + \sum_{j>0}B_j}$$

In these equations, we assume $j\leq n$ to iterate through the pool's tokens.

Using these ratios, we can calculate the amount of cASSET to refract for each maturity, represented as $r_j \times C_{\text{in}}$, where $C_{\text{in}}$ is the user-supplied input cASSET amount.

YAsset Trading

YAMM pools are designed to facilitate trading between cASSET, pASSET, and yASSETs. However, the pool structure includes just cASSET and pASSET, which makes direct yASSET trades impossible via the weighted pool equations. To allow such trades, we employ flash loans and interact with the refractor module. Note that YAMM pools only support trading between yASSET and cASSET (or vice versa), while trades involving yASSET and pASSETs necessitate two-step batch swaps.

Buying yASSETs: The buying process for yASSETs follows these steps:

1. Borrow a cASSET amount, $c_{loan}$, from ammVault.
2. Refract the $c_{in}+c_{loan}$ amount.
3. Trade all received pAssets for cAssets to repay the loan, and provide the yAsset to the user.

The loan amount needs precise computation to carry out these steps. Assuming that the Refractor module has a fee ratio of $\phi_R$ and an exchange rate of $E_R$, let $\rho = \phi_R \times E_R$ denote the effective exchange rate of the refractor. Thus, the refracted pASSET would be $\rho \times (c_{in}+c_{loan})$. As outlined in the steps, we must sell this pAsset for cAsset to recover the loan amount.

We now define a few parameters and functions to simplify our calculations.

$$c_{\mathrm{loan}}=k B_o\left(1-\left(\frac{k B_i}{k B_i+(1-\phi) \rho\left(c_{\mathrm{i} n}+c_{\mathrm{loan}}\right)}\right)^{\frac{w_i}{w_o}}\right)$$

In the formula above, $i, o$ stand for the pAsset and cAsset indices, respectively. We also define the function $g(x)$ as below for added clarity.

$$g(x)=\left(\frac{k B_i}{k B_i+(1-\phi) \rho\left(c_{\mathrm{i} n}+x\right)}\right)^{\frac{w_i}{w_o}}$$

We further define the function $f(x)$ as:

$$f(x)=\frac{1}{k B_o} x-1+g(x)$$

We now can apply newton method steps as:

$$x_1 = c_in * \frac{pAssetPrice}{yAssetPrice} \\ x_{n+1}=x_n-\frac{x_n-k B_o+k B_o g\left(x_n\right)}{1+k B_o g^{\prime}\left(x_n\right)}$$

This Newton method applies for a maximum of 15 steps or stops early if the following condition is met:

$$|x_{n+1}-x_{n}| < x_n\times 1e^{-10}$$

Recall that this method approximates the loan amount. However, for practical purposes, we need to ensure that we can repay the loan. To make allowances for any estimation errors, we propose a loan fee, which is adjusted by the BuyYGivenInLoanFeeRatio parameter. This fee is deducted from the $c_{in}$ before applying the Newton method, and later added back to the amount being refracted. Consequently, we only need to replace $c_{in}$ in the Newton method with $c_{in}\times (1-feeRatio)$. Nevertheless, when we want to perform the refraction, we use the actual $c_{in}+c_{loan}$.

Buying yASSET given out: This scenario indicates that we know the yASSET amount and we must calculate the required cASSET. Let's assume that the refractor converts an amount of cASSET into another amount using a function $\mathcal{R}$. Given that the output amount is $y_{out}$ and $C = c_{in}+c_{loan}$, we have:

$$\mathcal{R}(C) = y_{out} \\ \Leftrightarrow \mathcal{R}^{-1}(y_{out}) = C$$

With the quantity $C$, we then refract this amount and acquire $y_{r}=p_{r}$ amounts of yAsset and pAsset respectively. Due to rounding errors if $y_r < y_{out}$ the opration fails but if $y_r \ge y_{out}$ we take the required output amount for the user and the remaining is taken as fee. The computation of $c_{loan}$ and $c_{in}$ amounts can be done by trading $p_r$ for the cAsset. The output amount becomes $c_{loan}$, and $c_{in} = C - c_{loan}$.

The challenge lies in figuring out the value of $C$. Given the refractor equations with roundings and an exchange rate of $E$, we formulate as follows:

$$\begin{align} & \lfloor \left( C-\lceil C \times \phi_r \rceil \right) \times E \rfloor = y_{out} \\ \underrightarrow{y_{out} \text{ is integer } \ } & \left( C-\lceil C \times \phi_r \rceil \right) \times E \ge y_{out} \\ \underrightarrow{\lceil C \times \phi_r \rceil \ge C \times \phi_r \ \ } & C- C \times \phi_r \ge \frac{y_{out}}{E} \\ \Rightarrow & C(1 -\phi_r) \ge \frac{y_{out}}{E} \\ \Rightarrow & C \ge \frac{y_{out}}{E \times (1 -\phi_r)} \end{align}$$

This set of equations helps us determine the value of $C$, ensuring the trades can be executed efficiently.

The process can also be given as follows:

$$\begin{align} & \lfloor \left( C-\lceil C \times \phi_r \rceil \right) \times E \rfloor = y_{out} \\ \underrightarrow{y_{out} \text{ is integer } \ } & \left( C-\lceil C \times \phi_r \rceil \right) \times E \le y_{out} + 1 \\ \underrightarrow{\lceil C \times \phi_r \rceil \le (C \times \phi_r + 1) \ \ } & C- C \times \phi_r - 1 \le \frac{y_{out}}{E} + \frac{1}{E} \\ \Rightarrow & C(1 -\phi_r) \le \frac{y_{out}}{E} + \frac{1}{E} + 1\\ \Rightarrow & C \le \frac{y_{out}}{E \times (1 -\phi_r)} + \frac{1 + E }{E \times (1 -\phi_r)} \\ \underrightarrow{C \text{ is integer } \ } & C \le \left\lfloor \frac{y_{out}}{E \times (1 -\phi_r)} + \frac{1 + E }{E \times (1 -\phi_r)} \right\rfloor \end{align}$$

We can use the right-hand side of equation (11) as an estimate for $C$, which also satisfies equation (5). Therefore, we get:

$$C = \left\lfloor \frac{y_{out}}{E \times (1 -\phi_r)} + \frac{1 + E }{E \times (1 -\phi_r)} \right\rfloor$$

Note that if rounding errors were not considered, we would have:

$$C_{float} = \frac{y_{out}}{E \times (1 -\phi_r)}$$

Hence, the impact of considering rounding is accounted for the fraction $\frac{1 + E }{E \times (1 -\phi_r)}$. If the refractor fee is less than $0.5$ (which is reasonable), this value would be less than $2 + \frac{2}{E}$. Assuming that the exchange rate is at least 1 (a reasonable assumption), the error would, at most, be 4. Given that cASSET has a 6-decimal place precision, this error translates to $4\times 10^{-6}$ cASSET, a relatively insignificant value.

Selling yAssets: If a trader intends to sell a yAsset quantity $a$ to gain cAsset, the protocol must perform these steps:

1. Borrow a suitable $c_{\text {loan }}$ quantity of cAsset.
2. Trade the $c_{\text {loan }}$ cAsset amount to receive a quantity $a$ of pAsset.
3. Redeem the $a$ amounts of pAsset and yAsset in the refractor module to get cAsset.
4. Use the acquired cAsset amount to repay the loan. The remaining cAsset goes to the trader.

In this context, the loan amount does not necessitate complex calculations or estimates. Since we know the required pASSET amount from the trade in step 2, we can execute a swap given out. The AMM's core equations take care of computing the loan amount.

Selling yAssets given out: Let's consider a situation where the trader wants to receive a specific cAsset amount $c_{\text {out }}$, and we must compute the yAsset quantity $a$ that the trader needs to sell.

Let's consider $\rho$ as the effective refractor exchange rate (encompassing the fee). Given that refracting a cASSET amount $c$ results in a pAsset quantity of $\rho c$, we get:

$$c_{\mathrm{out}}+c_{\mathrm{loan}}=\frac{a}{\rho} .$$

Similarly, the cAsset amount $c_{\text {loan }}$ can be determined as:

$$c_{\text {loan }}=\frac{k B_i}{1-\phi}\left(\left(\frac{k B_o}{k B_o-a}\right)^{\frac{w_o}{w_i}}-1\right) .$$

Here, $i$ refers to the cAsset index and $o$ refers to the pAsset index. Let's define $g: \mathbb{R}_{>0} \rightarrow \mathbb{R}$ as:

$$g(x)=\frac{k B_i}{1-\phi}\left(\left(\frac{k B_o}{k B_o-x}\right)^{\frac{w_o}{w_i}}-1\right)$$

Therefore, $c_{\text {loan }}=g(a)$ and

$$\frac{a}{\rho}=c_{\mathrm{out}}+c_{\text {loan }}=c_{\mathrm{out}}+g(a) .$$

This leads to:

$$c_{\mathrm{out}}+g(a)-\frac{a}{\rho}=0 .$$

Applying Newton's method to find the value of $a$. Let's define $f: \mathbb{R}{>0} \rightarrow \mathbb{R}$ as:

$$f(x)=c{\mathrm{out}}+g(x)-\frac{1}{\rho} x.$$

We proceed with setting $x_1 = \frac{c_{\text {out }}}{yAssetPrice}$ and, for each $n \in \mathbb{N}$, we define:

$$x_{n+1}=x_n-\frac{f\left(x_n\right)}{f^{\prime}\left(x_n\right)} .$$

Consequently,

$$x_{n+1}=x_n-\frac{f\left(x_n\right)}{f^{\prime}\left(x_n\right)}=x_n-\frac{c_{\mathrm{out}}+g\left(x_n\right)-\frac{1}{\rho} x_n}{g^{\prime}\left(x_n\right)-\frac{1}{\rho}} .$$

Given that the $y_{in}$ amount is computed iteratively using the Newton method, approximation errors are likely. These errors might cause the operation to fail if the merge output is insufficient to pay the loan amount. To prevent this, we compute a fee using $fee=YammSellYGivenOutFeeRatio*c_{out}$, and calculate the loan amount as if $y_{out}$ was equal to the 'actual $y_{out}$' plus the fee. For the merge and swap processes, the 'actual $y_{out}$' is used, and the fee is disregarded.

Refractor action computation: Note that all these yAsset trade types include a step of interaction with the refractor module. Given that the vault in this module is different from the AMM module vault, actual bank transfers are necessary to carry out these operations. In normal swaps, as previously described, we don't transfer any amount until the operation's end. At that point, we offset the input/output amounts and then execute the transfers. To maintain this convention here, in each yAsset trade, we don't execute the refract/redeem actions. Instead, we use the refractor API to compute the actions. These actions are aggregated together and executed at the end of the entire swap or batch swap operation.

YAMM Pool Configurations

In the YAMM pool design, we've introduced unique parameters not found in other Weighted pool types. Each pool stores these parameters in the following structure:

message YammConfiguration {
  uint64 pool_id = 1;

  string lambda = 2 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  // duration (milliseconds) for virtual balance when adding new pAssets to yamm pools
  string maturity_introduction_interval_millis = 3 [
    (cosmos_proto.scalar) = "cosmos.Int",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Int",
    (gogoproto.nullable) = true
  ];
  string maturity_expiration_interval_millis = 4 [
    (cosmos_proto.scalar) = "cosmos.Int",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Int",
    (gogoproto.nullable) = true
  ];

  string introduction_virtual_balance_scaler = 5 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  string expiration_virtual_balance_scaler = 6 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  // if the value is not set, will be read from module parameters
  string buy_y_given_in_loan_fee_ratio = 7 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  // if the value is not set, will be read from module parameters
  string sell_y_given_out_fee_ratio = 8 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  string max_alpha = 9 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  string avg_monthly_yield_rate = 10 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];

  string yield_fee_scaler = 11 [
    (cosmos_proto.scalar) = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable) = true
  ];
}

• pool_id: YAMM pool ID.
• lambda: Pool's $\lambda$ parameter.
• maturity_introduction_interval_millis: Duration (in milliseconds) of the virtual balance for new pAssets in YAMM pools.
• maturity_expiration_interval_millis: Duration (in milliseconds) of the virtual balance for removed pAssets from YAMM pools.
• introduction_virtual_balance_scaler: Scaler for the virtual balance of new pAssets.
• expiration_virtual_balance_scaler: Scaler for the virtual balance of removed pAssets.
• buy_y_given_in_loan_fee_ratio: Loan fee ratio for purchasing yASSET.
• sell_y_given_out_fee_ratio: Fee ratio for selling yASSET.
• max_alpha: Maximum number for clipping the $\alpha$ parameter.
• avg_monthly_yield_rate: The $r$ parameter in trading fee equations.
• yield_fee_scaler: The $\nu$ parameter in trading fee equations.

If a parameter value is unset, it defaults to the module parameters.