THORFi Lending within THORChain
Lending allows users to deposit native collateral, and then create a debt at a collateralization ratio
CR(collateralization ratio). The debt is always denominated in USD (aka
TOR) regardless of what L1 asset the user receives.
All loans have 0% interest, no liquidations, and no expiration. Risk is contained by limits on collateral for each pool, slip-based fees when opening and closing loans, dynamic CR, and a circuit breaker on RUNE supply.
Lending allows users to:
- Create loans using native assets as collateral
- Hold a loan without the risk of liquidation
- Be short on USD and long on crypto assets such as Bitcoin
Lending benefits the protocol by:
- Increased capital efficiency of the pools which increases system income and real yield.
- Creating additional trading volume
- Increased total bonded, allowing THORChain to scale.
- Providing an attractive sink for capital
Lending will need to be adopted by node operators before it is added to THORChain. Questions and discussions are in the #lending channel of the dev discord.
Derived assets, such as
thor.tor, are algorithmic coins that are backed by the liquidity of RUNE, and the liquidity of that is based on the RUNE-ASSET pair. Derived Assets are swapped from or swap to L1 assets, via RUNE, using derived asset pools which are based on the equivalent L1 pools. Unlike, Synethic Assets, derived assets are independent of Liquidity Pools and all swap fees are burnt. Derived assets are for accounting and there are no plans for them to be exportable or held by users.
thor.tor) is a non-transferable unit of account within THORChain designed to match the value of $1 USD and has been in use since ADR 003. It cannot be exported anywhere and always has a market cap of $0. TOR is valued by taking the median price of the active USD pools.
All collateral, debit and repayments within Lending are converted to and accounted for in TOR.
The user provides Bticoin collateral and can receive the debit in any asset however it is all accounted for in TOR.
- 1.User sends in collateral (BTC.BTC -> Rune, Rune -> thor.btc)
- 2.thor.btc is held as collateral in the Lending module
- 3.Convert thor.btc value to TOR terms
- 4.Calculate debt in TOR based on CR and collateral TOR value.
- 5.Mint TOR,
- 6.TOR -> RUNE, RUNE -> L1 out (e.g. - ETH)
Users can repay loans at any time, with any amount in any asset. Repayment is converted into TOR.
- 1.L1 -> RUNE (optional, user can also pay back with RUNE)
- 2.RUNE -> Mint TOR
- 3.Burn TOR (amount deducted from loan debt)
- 4.Burn Derived Asset (thor.btc) (amount is the same percentage of collateral as a percentage of loan debt paid) -> Mint RUNE
- 5.RUNE -> BTC.BTC (loan originator)
Collateral is not returned until the loan is fully repaid. The user will always have the right to have their returned collateral if they repay the loan.
Derived/virtual pool are created for each derived asset, including TOR, to allow swapping between L1 assets and derived assets va RUNE. Their depths expand and contract to throttle the amount of slippage users pay when swapping from an L1 asset to a derived asset. In periods of volatility, pool depth contracts to increase the slippage on swaps during this period of time. This incentivises users to wait for a period of lower volatility to exit/enter lending and protects the system against pool manipulation.
The TOR pool is a derived asset pool and operates the same as other derived asset pools except the TOR price comes from the medium of the four pools instead of one L1 Asset Pool.
totalRuneDepth: Sum of all RUNE in anchor pools (i.e. - USDC, USDT, BUSD-BD1 for TOR or just BTC.BTC for the L1)
Protocol Setting, blocks to accumulate slip
Protocol Setting, Min derived pool depth
Protocol Setting, increase/decrease derived pool depth
Protocol Setting, Max allowed slip on derived pool
Update rune depth to constrict based on slip:
Derived Asset Pool depth ranges from
derivedMinDepthto 100% of L1 asset but is reduced by
totalSlip. Target is 90%-100%.
Derived Asset Pool spawn as required within a block and derived asset swaps are processed after all L1 swaps within the swap queue.
Lending is capped by limited the collateral that can be received by the protocol.
LendingLever: throttles the amount of RUNE available for lending, in basis points.
Current Rune Supply is Native RUNE Circulating Supply.
totalAvailableRuneForProtocolis distributed among pools available for lending based on their RUNE depth. For each lending pool, the
totalAvailableAssetForPoolis convert rune value to Asset Terms. This imposes a collateral holding limit for each pool, a new loan cannot be opened if the new gross collateral exceeds this amount.
A dynamic CR increases as loans are opened within a pool and reduces as loans are repaid.
Current pool collateral + new loan collateral
Ratio in basis points, (LTV = 1/CR)
Basis points, protocol setting
As more loans are taken out, the collateral limits are increased and so does the CR. The higher the collateralization ratio, the safer the system becomes.
Debit is calculated based on the collateral provided and the CR of the pool.
Collateral Value in TOR
The TOR Debt is swapped to the requested L1 asset and then sent to the user, slip fees apply.
The protocol setting
LoanRepaymentMaturitydefines the number of blocks before a loan can be repaid/closed. There is no option for repayment before this period.
Opening new loans creates a deflationary effect on the $RUNE asset, whereas closing loans creates an inflationary effect on $RUNE.
If the value of $RUNE relative to $BTC is the same when the loan is opened and closed, there is no net inflationary effect on $RUNE (same amount burned as minted minus the swap fee). However, if the value of the collateral asset increases relative to $RUNE between the time the loan is opened and closed, there will be net inflation of $RUNE supply.
Lending controls are in place to address these concerns.
Documents / Spreadsheets