RateX is a decentralized interest rate swap (IRS) product that offers synthetic exposure to interest rates. The RateX protocol supports up to 40x leverage trading, and the trades will have expiry dates. RateX uses orderbook for trading, and it supports IRS on many protocols.
Prize Pool
RateX is a decentralized interest rate swap (IRS) product that offers synthetic exposure to interest rates. The RateX protocol supports up to 40x leverage trading, and the trades will have expiry.
Note: synthetic means you need only provide margin to trade.
For an interest rate market, suppose the underlying's variable interest rate is $r_v$. For a trade to happen the both sides should agree on a swap rate $r_s$, and each pool will have a expiry time $T_e$.
Fixed rate receivers look to exchange variable interest rate for fixed interest rate.
Variable rate receivers look to exchange fixed interest rate for variable interest rate.
Liquidators play the role of triggering the liquidation accounts that has insufficient margin through partial liquidation or total liquidation. They can earn certain rewards from doing so. Currently RateX uses Chainlink Keepers as liquidators.
You need to provide margin in order to trade. The minimum amount of margin required by a position is calculated by the maximum leverage of the pool and the position size.
Suppose the notional value is $N$, and the time the order takes place is $T_b$.
For Fixed Rate Receivers, the PnL of a position at time $T~ (T leq T_e)$ is
$$
ext{PnL} = N cdot ig((T - T_b) cdot r_s - int_{T_b}^{T} r_v mathrm{d}tig) = N cdot (T - T_b)cdot (r_s - overline{r_v})
$$
For Variable Rate Receivers, the PnL of a position at time $T~(Tleq T_e)$ is
$$
ext{PnL} = N cdot ig(-(T - T_b) cdot r_s + int_{T_b}^{T} r_v mathrm{d}tig) = N cdot (T - T_b)cdot ( -r_s + overline{r_v})
$$
The average variable interest rate $overline{r_v}$ is over the period $T_b$ to $T$ and is read via the oracle.
The margin ratio $R_M$ of a position at time $T$ is calculated as
$$
R_M = frac{M + ext{PnL}}{N}
$$
$M$ is the total margin provided by the user for this position.
RateX supports leverage trading, the maximum leverage $lambda_m$ is defined by the pool. If a trader is to open a position with leverage $lambda$, and the notional value is $N$, then he need pay $lambda cdot N$ as margin.
When the loss of a position is high, and the margin ratio falls behind a certain ratio, the maintenance margin ratio, the liquidators will be allowed to liquidate the position. The maintenance margin ratio $overline{R_M}$ is a parameter calculated by the parameters in pool.
When a position's margin ratio is below the maintenance ratio, the liquidators can liquidate his position. The liquidation process goes as follows.
The liquidator takes over the position owned by the user, and a portion of the user's margin goes into the liquidator's account. Then the liquidator will supplement for the position's margin to ensure that the counterparties can continue to earn profit.
When a liquidator liquidates, he will take over ALL the positions that have insufficient margin ratio. By doing so, he will also be rewarded by funds in the insurance fund if no one liquidates within a certain time.
The matching engine will match the orders that appears on the orderbook.
The market orders will be automatically filled by being matched with limit orders. The limit orders will appear on the orderbook and wait to be matched. Currently all the limit orders follows a good-till-date manner. The pool will collect $0.02% cdot frac{T_e}{365} cdot N$ fee for each trade. Parts of them will go into the insurance fund. (Currently set to 50%)
By closing a position, the trader posts a liquidation order to the liquidators. Then the liquidator can take over your position even if your margin left is above of maintenance margin. The remain margin the trader can receive is calculated in the same way as the that of positions being liquidated.
The pool will have estimation of lower and upper bounds of interest rate of the underlying, which are denoted by $r_l$ and $r_u$ separately.
Suppose that the time after the creation of the pool is $T$, and if at this point a trader is to trade $N$ notional the minimum amount of margin needed is
$$
M_{min} = Ncdot frac{T_e - T}{365} cdot (r_u - r_l) cdot mu
$$
Where $mu = 1.5$ is the reserve factor for the trade.
We set the minimum margin needed in order to avoid liquidation from happening while maximizing capital efficiency. Still in severe cases liquidations can happen, so we define the following.
The position can be liquidated when the margin plus PnL (suppose that value is $M_l$) at some time $T$ is less than
$$
M_{maintain} = Ncdot frac{T_e - T}{365} cdot (r_u - r_l)
$$
The amount of margin taken by the liquidator will be ($r_s$ is the swap rate)
$$
C=
egin{cases}
frac{T_e - T}{365} cdot {(r_u - r_s)} cdot N & ext{when the fixed rate receiver is to be liquidated}\
frac{T_e - T}{365} cdot {(r_s - r_l)} cdot N & ext{when the variable rate receiver is to be liquidated}
end{cases}
$$
And the rest of the margin plus PnL $M_l - C$ will be returned to the trader.
Example setting for aUSDC supply rate:
r_l = 0.5%
r_u = 20%
T_e = 30 (days)
leverage_max = 40x (on genesis)
Suggestion: leverage be <= 20x if you do not check your margin ratio often.
The pool is the place where trade can take place. A pool specifies the underlying interest rate / debt rate to speculate, provide the PnL oracle, the term length and transaction parameters such as max leverage, maintenance ratio, and exit fee (fee to pay when one party exists in advance).
The order book module lists, matches and executes the orders. There are two kinds of orders in total, market order and limit order. Also, the order book collect fees from trades and send parts of them into the insurance fund.
The position manager manages all users' position and margin. It records each position after an order is (fully or partially) filled, each position's PnL / Margin Ratio. Also, it allows users to increase / decrease margin for their position, and it will allow liquidators to execute liquidation orders when one position's margin ratio is below maintenance ratio.
The insurance fund will collect parts of the transaction fees. When a liquidation is to happen, the insurance fund will compensate the liquidator with parts of its vault's storage.
The oracle will record the interest rate from Aave or Compound or Yearn by Chainlink Keepers constantly. The PositionManager will use the oracle to calculate PnL of each position, and to decide whether a position is liquidable.
Before coming up the idea of RateX -- an orderbook-based IRS protocol, we made a thorough investigation on the current market. We found that we need a protocol that do not need liquidity but can improve current liquidity usage, and we also noticed the IRS idea in traditional finance barely had no counterpart in the DeFi world. Therefore, we decided to develop an IRS DeFi 2.0 project, which is RateX that we present you here.
We first developed the mathetical model of RateX, including the leverage trading, the liquidation details, and the whitepaper can be accessed in our github. Then we started writing the contracts in Solidity, during which we leveraged the Aave interest rate oracle, the Compound interest rate oracle and Yearn interest rate oracle to grant users exposure to interest rates from various protocols. We also made full use of Chainlink Keepers to liquidate the positions and to update interest rates. Finally we tested our protocol using Remix and wrote up all the documents.
The highlight of this project has two parts. The first part is about how it is going to contribute to the current DeFi world since it is delicately designed both idealogically and mathematically. The other part is that the different technologies that we use such as Chainlink Keepers, Aave Oracles, etc. to keep the contract working and enable it to keep track of different rates from different protocols.