Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Register
  • Sign in
  • THORNode THORNode
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 215
    • Issues 215
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • THORChainTHORChain
  • THORNodeTHORNode
  • Issues
  • #1412
Closed
Open
Issue created Sep 17, 2022 by THORChain@thorchain-adminOwner

[THORFI] Lending Design Using Derived Assets

Overview

Lending allows users to deposit collateral, then create debt at some collaterisation ratio CR. The debt is denominated in USD. These loans have 0% interest and no liquidations. Risk is contained by caps on launch, slip-based fees when opening and closing loans, dynamic CR, and a circuit breaker on RUNE supply.

WHY

Lending will bring fresh exogenous capital from new users to scale liquidity, and drive up the capital efficiency of the pools which increases System Income and real yield.

ELI5 (explain like I'm 5)

"THORChain onboards layer1 collateral to issue dollar-based debt. The collateral is stored as equity. The more collateral is taken onboard relative to the pool depths, the higher the collaterisation ratio for new loans, so users want to get in first. The higher the collaterisation ratio, the safer the system becomes. Since there are no liquidations and no interest rate, users are less likely to pay back their loans, which is beneficial to the protocol as the equity-value increases. Also, since the loans remove RUNE from the pools, the pools open back up for more TVL, causing THORChain to scale liquidity and security."

Design Goals

The primary design goals are:

  1. Minimal Cognitive Burden. The simplest UX around collateral, debt and the loan terms should be pursued.
  2. Scalable Security. The collateral should always be secured.
  3. Contained Risk. The risk of new debt being opened too fast should be throttled, and the risk of existing debt exceeding the liquidity of the system should be contained by a transparent circuit breaker.

Economic Implementation

Collateral & Debt

Collateral

The collateral should be layer1 assets, eg BTC, and the debt should USD-denominated. This is the largest addressable market. All other forms of collateral and debt denominations can be ruled out here.

The debt should not be RUNE denominated because users would be shorting RUNE. The collateral should not be RUNE denominated because it won't bring fresh exogenous capital to the system as well as create sell pressure on RUNE.

Wrapped vs Synthetic vs Derived Assets

All 3 types can achieve layer1 exposure, but only 1 can work:

  • Wrapping assets are incompatible with THORChain's coupled security model thus can be ruled out, because a security budget can not be built from entry-carrying-exit fees.
  • Synthetic Assets using pooled liquidity could work, but are competing for the same security space as the Savings + LP features, which have a cap. Thus the system would lock up and could not scale. There is also RUNE-ASSET IL risk to cover.
  • Derived Assets using RUNE equity can scale beyond the cap, drive price action into $RUNE to increase the network security and attract fresh capital to the system. There is RUNE-ASSET price risk to cover.

Debt Denomination

USD-denominated Debt is the design goal. Denominating in an external stablecoin creates a third-party dependency/risk (various centralisation concerns). Denominating against a median-priced manipulation-resistant basket of stablecoins is much safer. This is the design of $TOR.

$TOR as a unit of account is already live in the protocol today, and denominates that all L1 outbound fees pay a minimum of $1.00.

$TOR, whilst technically an algo-stable, will not be transferrable and will have no other use than being an internal unit of account.

Loan Terms

Liquidations

Unique to this design, it is irrelevant if the collateral drops below the debt value, because the collateral is the liability, not the debt. If the collateral goes to zero, the liability also goes to zero.

The liability is the collateral, which is stored as equity (RUNE). If the collateral value out-paces the RUNE value, then the liability increases. Liability around debt-collateral is only created when the RUNE-ASSET price drops AND the loan is paid back.

Liquidating collateral contains risk on a per-loan basis. However, it creates very poor UX (distressed sales at the bottom and liquidation cascades), and causes the user to worry about the price of an unrelated third asset: RUNE, thus is untenable to the design goals.

Thus instead of liquidations, the protocol will tolerate a small increase in RUNE supply, before trigging a circuit breaker and permanently sunsetting the lending feature. No new loans will be created and the RESERVE will cover the remaining collateral payouts. Since the loan terms never change even after the circuit breaker, it's less likely to become self-fulfilling and incentivise a rush-exit.

Interest Rates

Interest Rates are a mechanism to collect income on collateral. However it increases the propensity of a user to pay back their loan. THORChain's lending design can scale the most when users elect to have very long-term loans, or never pay back.

0% interest rates are the most desirable for a loan facility, and means users are least likely to pay back since their principle is never eroded. Users will pay slip-based fees when they enter or exit their position.

User Experience

From the design goals above:

  1. A user deposits layer1 asset, BTC which creates a derived asset to mark their collateral amount. Eg, 2.0 BTC

Under the hood the 2.0 l1 BTC is swapped across the pools to buy and burn 1.99 BTC in RUNE^

  1. Based on a dynamic CR, some amount of TOR-denominated debt is minted. Eg 200% CR means 20k TOR (1 BTC = $20,000)

Enough RUNE is then counter-minted to produce this debt: 1.99 / 200% = 0.995 BTC of TOR^

  1. Based on user preference, the debt can be withdrawn as another L1 asset (eg USDC). eg 20k USDC

The TOR is then swapped to 0.99 BTC in RUNE^ The RUNE is then swapped to 0.985 of USDC^

^slip-based fees apply.

Overall, 2.0 BTC is deposited and <1.0 BTC worth of USDC is withdrawn (slip fees), leading to a net-burn of >1.0 BTC in RUNE.

  1. Some time later, the user can pay back 20.1k USDC, which mints 20k TOR

The USDC is swapped to RUNE, which is swapped to TOR and cancels the debt^

  1. The debt is repaid, so the user unlocks their full collateral, 2.0 BTC

Enough RUNE is minted to swap to 1.99 in BTC^

^slip-based fees apply.

Overall, 1.0 BTC worth of USDC is deposited and <2.0 BTC worth of BTC is withdrawn (slip fees), leading to a net-mint of <1.0. BTC in RUNE.

Across the loan period no new RUNE was minted (if RUNE-BTC stayed constant), but 8 * slipFees of income was made. Essentially a single loan creation is worth 8 swaps to the network, with only 1 L1 tx in and out. Half of those swaps produce revenue for layer1 pools, while the other half burns the swap fee in rune.

Economic Reasoning

Scaling Liquidity

Due to PoL and Savers, the network is likely to max out pooled RUNE and send all yield to nodes. The protocol stops scaling until it can recruit new nodes, but this takes time. A faster mechanism to scale security (and TVL) is to attract new capital, buy out the RUNE from the pools and open up caps again. This is the lending design.

Whilst the loan is opened, it created a net reduction in RUNE in the pools, allowing more TVL to enter. It also bids on RUNE, allowing security to increase. Additionally, +ve RUNE Price action boosts the value of yields (block rewards).

This is why lending scales THORChain.

Contracting Safely

If borrowers start paying back their loans, this reverses the above sequence of events and the system contracts. RUNE is minted and sold, causing the caps to be hit, reducing yield, causing Savers to leave. The PoL exits (buys RUNE) which prevents excessive reflexivity.

However, the CR will start dropping for new loans, until a point is hit and new loans are opened under favourable CR terms. This stops a runaway bank-run on loans.

Circuit Breaker

If the RUNE price drops drastically against the majority of its collateral assets (L1 gas assets), then net inflation of RUNE will occur if users start paying back their loans, and it exceeds the margin of RUNE already historically burnt. This inflation could hit the breaker limit. At this point the system pauses new loans to be created and sunsets (turns off) lending (forever) (note, all other features of TC still function). At this point, no further inflation of RUNE can occur and the supply arrested. The RESERVE will cover the remaining collateral payouts.

Note: a 1-way circuit breaker means the only risk Lending has on the protocol is minting an extra 15m (3%) of the supply, and a reduction in the RESERVE. Thus the downside is capped. A 1-way circuit breaker will theoretically mean it is less likely to be hit, instead of a rush-exit. THORChain borrowers know their loan terms don't ever change, and if too many of them panic and payback, they know they will cause THORChain to permanently turn off Lending. Thus if Lending is a net good, there will be an incentive to keep it turned on; thus borrowers may choose to (altruistically) stay in, instead of leaving.

Loan Caps

The types of caps may include

  • max amount of collateral per pool (3-10x)
  • max value of collateral in units of RUNE compared with pooled RUNE (3-10x)

Technical Implementation

Open

open:collateralAsset:debtAsset:destinationAddress

A new loan is opened with 0 values. Then if new with 0 values, or if existing with non-0 values:

  • swap collateral to RUNE, burn it, add this rune_burnt
  • swap the qty of burnt RUNE to derived asset, add this collateral
  • apply the CR ratio against rune_burnt, mint this in rune, add this rune_minted
  • swap the rune minted to TOR, add this debt
  • swap the TOR to the desired asset, then send to the address specified
/{pool}/{lender}

{ "lender" : address,
  "debt_address" : address
  "collateral" : amount, // derived asset minted when l1 deposited (minus swap fees)
  "rune_burned" : amount, // rune burnt from collateral
  "rune_minted" : amount, // rune minted from (rune_burnt / CR)
  "total_CR" : amount, // (rune_burnt / rune_minted)
  "debt" :  amount, // TOR minted from rune_minted
  "last_deposit" : height, // track when last deposited
}

/{pool}
{ "total_collateral" : amount, // sum of all collateral held
  "total_rune_burnt" : amount, // sum of all rune burnt
  "total_rune_minted" : amount, // sum of all rune minted
  "active_CR" : amount, // (total_rune_burnt/total_rune_minted)
  "total_debt" : amount, // sum of all TOR minted
}

Close

close:lenderAddress:collateralAsset

  • ID the lender by the address (is the any issues with anyone paying back someone else's loan?)
  • The asset provided is swapped to RUNE, to TOR, then the amount reduced from their debt.
  • Anything excess of their debt is refunded back to them in TOR. (🚨 Do not apply above their debt! Warning, overflow! 🚨)
  • The pro-rata share of the debt paid back (against their total debt), is converted to collateral share, then priced in RUNE, then this is minted.
collateral_to_unlock = (debt_paid_back / debt) * collateral
rune_minted = getRUNEValue(collateral_to_unlock)
  • This minted RUNE is then swapped to their collateral type and sent to lender.

TOR

Existing implementation:

  • median price of stables added by mimir
  • virtual pool depth is sensitive to preceding swap fees generated (manipulation)
  • virtual RUNE-TOR swap fees burn rune

Mimirs

  • collateralToPooledRUNEMax = 20000 basis points (eg 2x) - stop opening new loans
  • collateralPerPoolDepthMax = 20000 basis points, eg 2x - stop opening new loans
  • CRmin and CRmax in basis points
  • torVirtualDepthMin = 10 in basis points eg 1%
  • torVirtualDepthBlocks = 100 preceding blocks to count fees over
  • runeSupplyTrigger = 1_000_000_000_00000000 = 1bn to trigger circuit breaker
  • runeSupplyRelax = 980_000_000_00000000 = 980mn supply must be less than this to relax circuit breaker
  • runeSupplyBurnRate = 2000 basis points for System Income to delete RUNE eg 20% during circuit breaker. Assuming 20% System Income, then will take 6 months (20% of 20%) to remove 2% of supply and relax breaker.
Edited Dec 04, 2022 by THORChain
Assignee
Assign to
Time tracking