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
The original lending design is proposed here.
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.

Lending Fundamentals

Derived Assets and Pools

Derived assets, such as thor.btc andthor.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.

TOR Accounting

TOR (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.

Open Loan Flow

The user provides Bticoin collateral and can receive the debit in any asset however it is all accounted for in TOR.
  1. 1.
    User sends in collateral (BTC.BTC -> Rune, Rune -> thor.btc)
  2. 2.
    thor.btc is held as collateral in the Lending module
  3. 3.
    Convert thor.btc value to TOR terms
  4. 4.
    Calculate debt in TOR based on CR and collateral TOR value.
  5. 5.
    Mint TOR,
  6. 6.
    TOR -> RUNE, RUNE -> L1 out (e.g. - ETH)

Loan Repayment / CloseFlow

Users can repay loans at any time, with any amount in any asset. Repayment is converted into TOR.
  1. 1.
    L1 -> RUNE (optional, user can also pay back with RUNE)
  2. 2.
    RUNE -> Mint TOR
  3. 3.
    Burn TOR (amount deducted from loan debt)
  4. 4.
    Burn Derived Asset (thor.btc) (amount is the same percentage of collateral as a percentage of loan debt paid) -> Mint RUNE
  5. 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 Depth

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
totalSlip=∑i=blockMaxAnchorBlockspoolSlip(i)totalSlip = {\sum_{\substack{i=block}}^{\text{MaxAnchorBlocks}}}{poolSlip(i)}
MinRuneDepth=derivedMinDepth10,000∗totalRuneDepthMinRuneDepth = \frac{derivedMinDepth}{10,000} * totalRuneDepth
startRuneDepth=derivedDepthBasisPts10,000∗totalRuneDepthstartRuneDepth = \frac{derivedDepthBasisPts}{10,000} * totalRuneDepth
Update rune depth to constrict based on slip:
newRuneDepth=MaxAnchorSlip−totalSlip10,000∗totalRuneDepthnewRuneDepth = \frac{MaxAnchorSlip - totalSlip}{10,000} * totalRuneDepth
FinalRuneDepth=MAX(minRuneDepth,totalRuneDepth)FinalRuneDepth = MAX({minRuneDepth, totalRuneDepth})
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 Controls

Collateral Limits

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.
runeBurnt=MaxRuneSupply−CurrentRuneSupplyruneBurnt= {MaxRuneSupply - CurrentRuneSupply}
Current Rune Supply is Native RUNE Circulating Supply.
totalAvailableRuneForProtocol=LendingLever10,000∗runeBurnttotalAvailableRuneForProtocol = \frac{ LendingLever}{10,000} *runeBurnt
totalAvailableRuneForProtocol is distributed among pools available for lending based on their RUNE depth. For each lending pool, the totalAvailableRuneForPool (tarfp) is:
tarfp=poolRuneDeothtotalRuneDepthofLendingPools∗totalAvailableRuneForProtocoltarfp = \frac{ poolRuneDeoth } {totalRuneDepthofLendingPools} * {totalAvailableRuneForProtocol}
totalAvailableAssetForPool is 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.

Collateralization Ratio

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
CR=ab∗(maxCR−minCR)+minCRCR = \frac{a}{b} * {(maxCR - minCR) + minCR}
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
Collateralization ratio
Debit=CollateralValueInTOR∗10,000CRDebit = CollateralValueInTOR * \frac{10,000}{CR}
The TOR Debt is swapped to the requested L1 asset and then sent to the user, slip fees apply.

Loan Repayment Maturity

The protocol setting LoanRepaymentMaturity defines the number of blocks before a loan can be repaid/closed. There is no option for repayment before this period.

Concerns + Considerations

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.

Lending Resources

Documents / Spreadsheets