Token Model
The Nexus Mutual protocol has a mechanism that allows members to freely mint and redeem NXM and ensures all claims can be confidently paid should a major loss event occur. This mechanism is referred to as the Ratcheting Automated Market Maker (RAMM), a two-pool system built on top of the Capital Pool that allows members to redeem and mint NXM.
To strike a balance between ETH flowing into the Capital Pool, ETH flowing out of the Capital Pool, cover being underwritten by staked NXM, Capital Pool investment allocations, and asset-liability management, the protocol uses this automated mechanism to manage the amount of capital that is provided as liquidity for NXM holders.
Members can use the crypto assets held in the Capital Pool to underwrite various cover products and/or propose and vote on Capital Pool investment allocations. For more information, see the Staking and Investments pages.
Ratcheting Automated Market Maker (RAMM)
The RAMM model is made up of two virtual one-sided Uniswap v2-style pools, which determine the price at which the mutual is willing to buy and sell NXM in value-accretive ranges for the mutual, complemented by a price ratchet to enable price discovery.
The Below Pool and Above Pool are the two pools present in the system. These pools contain a defined amount of ETH liquidity paired with “virtual” NXM. This creates two internal pools, which have the same ETH liquidity; the NXM reserves in each pool are represented by a virtual NXM balance. The ETH and NXM balances change over time as NXM is sold and purchased.
The two pools are described below:
Below Pool. This pool handles swaps below the Book Value. NXM sold in this pool is burned and ETH is distributed from this pool. NXM can be swapped for ETH in this pool only at an NXM spot price less than or equal to the Book Value. NXM can only be redeemed in this pool; NXM mints occur in the Above Pool.
Above Pool. This pool handles swaps above the Book Value. ETH is contributed to this pool and, in return, NXM is minted. NXM can be purchased from this pool only at an NXM spot price greater than or equal to the Book Value. NXM can only be minted in this pool; NXM redemptions occur in the Below Pool.
Behaviours in the pools
| Above Pool | Below Pool |
|---|---|
| 1) When NXM is purchased in this pool, the price increases as the ETH liquidity increases and the virtual amount of NXM decreases. | 5) During periods where no NXM is being redeemed for ETH, the ratchet mechanism will move the price back toward the Book Value. |
2) This pool operates within the following price range: [(100+ oracle buffer)% * Book Value,∞) | 6) This is the Book Value, which the ratchet mechanism will "ratchet" up to in the absence of NXM redemptions in this pool. |
| 3) During periods where no NXM is purchased, the ratchet mechanism will move the price back toward the Book Value. | 7) When NXM is redeemed in this pool, the price decreases as the ETH liquidity decreases and the virtual amount of NXM increases. |
| 4) This is the Book Value, which the ratchet mechanism will "ratchet" down to in the absence of NXM purchases in this pool. | 8) This pool operates within the following price range: (0, (100-x)% * Book Value] |
How liquidity is managed within the RAMM
The Nexus Mutual protocol holds crypto assets within the Capital Pool, and the RAMM is designed to allocate a certain amount of liquidity from the Capital Pool on an ongoing basis. ETH liquidity is added to the RAMM over time when the liquidity in the RAMM is below the target liquidity value. When members contribute ETH to the Capital Pool and mint NXM, any ETH liquidity in the RAMM in excess of the target liquidity is removed from the RAMM over time.
To be sure all claims can be paid, the Minimum Capital Requirement (MCR) is the only threshold that can prevent additional liquidity from being sent to the RAMM.
The MCR is driven by the Active Cover Amount going forward. The onchain formula for the MCR is presented below:
MCR = Total Active Cover Amount / 4.8
At launch, members signalled support for a target liquidity of 5,000 ETH.
Liquidity in the Below and Above Pools
Below Pool
As members redeem NXM for ETH, there will be less ETH held in the pools until more liquidity is injected to reach the target liquidity value–this happens automatically, given the system checks if the liquidity in the pools is less than the target liquidity value at each swap. The only scenario where liquidity will not be added to the pool will be when the ETH balance in the Capital Pool is less than or equal to the MCR plus the target liquidity: Capital Pool < MCR + target_liq
Above Pool
As members purchase NXM with ETH, the amount of ETH liquidity in the pools will increase. If the ETH liquidity is greater than the target liquidity, then ETH will be removed over time–this also happens automatically. The system checks if the liquidity in the pools is greater than the target liquidity value at each swap, cover buy and claim payout.
During periods where members are not redeeming NXM for ETH or contributing ETH in return for NXM, the ratchet mechanism moves the price. We’ll review that in the next section.
How the ratchet mechanism works
The ratchet mechanism allows for price discovery over time by moving the price toward the Book Value over time in the Below Pool and/or the Above Pool. The redemption price will decrease when NXM is redeemed in the Below Pool and the minting price will increase when NXM is purchased in the Above Pool, but the ratchet mechanism moves the prices to the Book Value over time.
Ratcheting up in the Below Pool
During periods when NXM is not being redeemed for ETH, the ratchet will move the spot price by reducing the number of NXM in the virtual pool.
In the example below, you can see a scenario where NXM is redeemed for ETH at Step 1 and Step 6.
The graph on the left shows the spot price dropping in Steps 1 and 6 when NXM is redeemed for ETH and subsequently increasing again as the ratchet moves.
In the graph on the right, you can see the amount of ETH in the pool. As NXM is redeemed for ETH, liquidity is reduced. When the liquidity in the pool is below the target (e.g., in this case, 5000 ETH is the target), more ETH is injected into the pool over time. As the pool reaches the target liquidity, no more ETH is injected into the pool.
Ratcheting down in the Above Pool
During periods when NXM is not being purchased with ETH, the ratchet will move the spot price by increasing the number of NXM in the virtual pool.
If someone purchases NXM, the price will increase and then, if no other NXM purchases are made, the ratchet will move the spot price back toward the Book Value in the Above Pool.
The graph on the left shows the spot price increasing in Steps 1 , 6 and 17 when NXM is purchased with ETH and subsequently decreasing again as the ratchet moves toward the Book Value.
In the graph on the right, you can see the amount of ETH in the pool. As NXM is purchased with ETH, liquidity increases. When the liquidity in the pool is above the target (e.g., in this case, 5000 ETH is the target), more ETH is removed from the pool over time. As the pool reaches the target liquidity, no more ETH is removed from the pool.
The Ratcheting AMM Whitepaper
The above is an overview of the RAMM, how the mechanism works, how liquidity is managed, and how the ratchet works. For more detailed information, please see the Ratcheting AMM Whitepaper, which contains an in-depth review of the RAMM mechanism and the various parameters.
Current Parameters
| Parameter | Description | Proposed Value |
|---|---|---|
| liqtarget | Target ETH liquidity | 5,000 ETH |
| liqSpeedout | Max amount of ETH that is removed from the pools daily as long as liq > target_liq | 100 ETH |
| liqSpeedin | Long-term state: max amount of ETH that is added to the pools daily. This value becomes active after an amount of ETH equal to initialBudget has been injected into the pools | 100 ETH |
| ratchetTarget | Middle value towards which the spot prices move | Book Value |
| oracleBuffer | Margin to allow for oracle lag when calculating Book Value in ETH. Secondary function - create spread | 1% |
| ratchetSpeeda | Daily decrease in spota when above ratchetTargeta | 4% of ratchetTarget |
| ratchetSpeedb | Long-term state: Daily increase in spotb when below ratchetTargetb | 4% of ratchetTarget |
| Parameter | Description |
|---|---|
| Book Value ("BV") | Capital Pool value in ETH / NXM supply |
| liq | ETH liquidity in the pools |
| NXMa | Notional NXM reserve in the Above Pool |
| ka | Above Pool invariant equal to liq * NXMa |
| NXMb | Notional NXM reserve in the Below Pool |
| kb | Below Pool invariant equal to liq * NXMb |
| spota | Current price at which members can exchange ETH for NXM. Equal to liq / NXMa |
| spotb | Current price at which members can exchange NXM for ETH. Equal to liq / NXMb |
| ratchetTargeta | Value towards which spota moves. Equal to (1 + oracleBuffer) * ratchetTarget |
| ratchetTargetb | Value towards which spotb moves. Equal to (1 - oracleBuffer) * ratchetTarget |
| twapa | Time-weighted average price of the Above Pool |
| twapb | Time-weighted average price of the Below Pool |
| cumulativePricea | Cumulative price of the Above Pool |
| cumulativePriceb | Cumulative price of the Below Pool |
| observation | A single observation contains the cumulative price for each pool and the timestamp for when the cumulative price sample was taken |
| granularity | Number of observations stored at one time by the twap mechanism |
| obsIndex | Index of the observation where each sample for the twap is stored |
| periodSize | Size of time period over which the twap observations are taken |
| currentTimestamp | Timestamp of the current block, in the same units as periodSize |
| pa | Above pool price allowing for the spot price, calculated as pa = min(twapa, spota) |
| pb | Below pool price allowing for the spot price, calculated as pb = min(twapb, spotb) |
| ipFloor | Used to set a floor for the internal price, expressed as a percentage of BV |
| ipCeil | Used to set a ceiling for the internal price, expressed as a percentage of BV |
| Internal Price ("ip") | Final internal price used by the system, calculated as: ip = max(min(pa + pb – BV, ipCeil * BV), ipFloor * BV) |
Additional Information
In the following sections, you will find the history of capitalization controls and the drivers of Capital Pool growth within the Mutual.
The history of capitalization controls is optional: you can skip to the drivers of Capital Pool growth section to learn about the conditions under which the Capital Pool expands and contracts.