THORFi Economic Design
Overview
The design of THORFi:
- TOR - a unit of account for debt, pegged to the purchasing power of USD stablecoins.
- Lending - borrow USD from blue-chip LP positions with 0% interest, no liquidations, with as low as 100% collateralization ratio
- THORSavings - an interest-bearing account with single asset exposure.
Why
THORFi is important for two reasons, in this order:
- To attract TVL to the network
- To develop a long-term RUNE premium
THORFi achieves (1) since the lending feature attracts L1 liquidity, and (2) because RUNE becomes deflationary.
TOR
RUNE is burnt to mint TOR, and TOR is burned to redeem RUNE. An in-built liquidity-sensitive fee is paid on mint/redeem which meters demand, prevents attacks and foregoes any need for caps or timelocks. Since perfect redemption is possible in small quantities, TOR will always be exactly $1.00:
In a small enough qty, 1.00 in TOR can be burnt to $1.00 in RUNE, and $1.00 in RUNE can be swapped to $1.00 in L1 assets at any time. The only burden on the system is to have sufficient arbitrage to prevent L1 assets building up a premium on the network, although any premium would only be temporary.
RUNE supply is responsive in this design, and RUNE liquidity in L1 liquidity pools is accountable for any price reflexivity of RUNE.
Price Oracle
The median price of USD in computed using "anchor pools" already on THORChain: USDT, USDC, BUSD, and DAI. More pools can be added downstream from a variety of ecosystems. The price of RUNE is transmitted by these pools, and the price of TOR is thus the inverse.
Price Manipulation
Since THORChain controls its primary markets (anchor pools), it can sense if the pool(s) are being manipulated with an unusually high liquidity/swap fees collected in them; or if an outlier is detected. THORChain responds by simply lowering the virtual depth of TOR, causing fee-amplification to increase, but does not change the pegged price relationship since fees asymptote to zero.
In typical peg attacks, a malicious actor can push the price of the base asset on primary markets, mint USD at premium, then depress the base asset price and in finally redeem USD for a profit. Other protocols protect from this by a "fast mint slow burn" process. By throttling the burn process, it makes it very difficult to price manipulate and profit at the same time. The issue with throttles and caps is the stablecoin can inadvertently break peg under demand.
Minting and Burning via RUNE-TOR pool
TOR comes with guaranteed on-chain liquidity, via a special RUNE-TOR pool.
- balances are completely virtual, and there are no LPs
- RUNE balance is not part of the incentive pendulum calculation
- RUNE quantity is NOT counted against network security
This virtual pool will have the rune depth of all anchor pools combined (with a computed asset depth using the anchor price). This ensures it is always the deepest stable pool in the network and therefore the cheapest stable by fee.
Neither the RUNE or the TOR actually exist in the virtual pool. It is there merely to convey the burn/mint price and swap fees that are collected. Any swap fees collected will be added to the TOR vault.
Mint/Redeem Fees
All mint/redeem fees are collected and paid into either the RESERVE, or later once the model is proven, into a TOR savings account. The reason why the conservative approach is chosen is to limit demand for TOR in the early days.
Lending
THORChain users can deposit collateral and mint debt as TOR. Collateral is always LP units of the primary asset of any chain (ie ETH but not ERC20s). Since the collateral is LP units, lending makes the pools deeper.
0% Interest
Borrowers forego the yield from their collateral and thus pay 0% interest. To ensure the network does produce yield, all loans must remain open for 100 days at minimum. Loans can be closed sooner for a 1% fee per day early. At the time the loan is open the network takes a snapshot of the asset depositValue and rune depositValue of the collateral, (similar to how impermanent loss protection works). When the user repays their loan in full, they are given LP units that equal this rune/asset deposit value back to them. Any remainder the network keeps, which is used to pay yield for THORSavings.
Collateralization Ratio
The CR (collateralization ratio) is determined by the amount of the pool depth is LP vs loan collateral. The higher the collateral, the higher the CR, with a max value called maxCR
(controlled via mimir). The first lender gets ~100% CR. At 50:50; the lender is getting ~200% CR. Above that it asymptotes to maxCR
(eg, 350%)
Over time, as older loans are paid back and new loans are taken out, they will be taken out typically at a higher CR. This should result in the network earning more yield as the feature matures.
maxCR
can be adjusted after time to match the behavior of Lenders to target maximal participation.
Debt
The debt amount is calculated as collateralValue / (CR/100)
, and minted in TOR. Minting the debt is the same process as minting TOR (above), so it creates fees for USD savers. If the TOR holder then swaps TOR into another asset, they pay the redeem fee.
Thus a healthy lending market produces fees and drives up demand of USD savers.
No Liquidations
No liquidations of collateral are executed, even if collateral drops below debt value.
- While the collateral < debt, a borrower will not likely repay. This means locked LP units stay as LPs-of-last-resort (maintaining deep pools during bear markets)
- All collateral is yield-producing blue-chip assets, and all debt is USD. THORChain users are necessarily long-crypto-short-USD
- USD is not backed by debt-collateral; it has its own peg mechanism, which is reliant on RUNE itself.
One may guess that when the loans become "insolvent" that creates an issue for the protocol, but in fact it does not. This is because the lender (the protocol) always gets repaid back immediately the debt paid out, and therefore no longer "cares" if a loan is solvent or insolvent, or even gets repaid or not.
This is because when a loan is opened, the lender (the protocol) mints value (TOR) to the borrower in the amount of their debt (minus fees). Because the added loan collateral to the pool, the yield of THORSavings increases, creating market demand for users to burn $RUNE to enter THORSavings. This is why on each loan, the lender/protocol mints the debt, but the market burns the value of the collateral in $RUNE to gain access to higher THORSavings yield. So every loan actually net burns $RUNE. Since the $RUNE supply decreases with each loan, lending is never "insolvent" because it's always operating at a profit.
Collateral Types
Users have two choices:
- Lock LP units as collateral, forfeit the yield on that, but always be repaid the same
asssetDepositValue + runeDepositValue
. - Lock asset as collateral, which generates LP units and forfeit the yield on that, but always be repaid the same
assetDepositValue * 2
The key difference is that (2) allows singled-sided BTC deposits, with redemption always to the same qty of BTC. (1) is for existing LP'ers to convert to a loan on their position.
To do (2), instead of computing getUnits(assetDepositValue, runeDepositValue)
, the protocol first computes runeWithdrawalValue = runeValue(assetDepositValue)
.
The difference between the runeWithdrawalValue
and runeDepositValue
is the RUNE qty the protocol has to mint and send into the pool (for redemption to the member), or the qty to withdraw from the pool and burn, since it is no longer required.
Then the protocol does: getUnits(assetDepositValue, runeWithdrawalValue)
, and redeems this to the member.
- the member will get all their BTC back, with no price exposure to RUNE
- if RUNE goes up, a net amount of RUNE is withdrawn from the pool and burnt
- if RUNE goes down, a net amount of RUNE is minted and added to the pool
- other LPs are unaffected (no IL)
The protocol has two choices to offer single-sided BTC collateral. Using LP collateral above, with protocol insurance; or using THOR.BTC. The difference is the LP method directly adds to the pool making it deeper. Using THOR.BTC does not directly make the pools deeper, and could cause a "top-heavy" design, where the derivative markets (THOR.BTC, TOR) become much larger than the spot market - L1 pools. In past top-heavy designs exhibit unstable characteristics.
THOR Savings (Interest Accounts)
There are two types of Saver Vaults. TOR and BlueChip; with slight nuances. The mechanism for participation is simply locking an eligible asset in its vault; the yield claimed is pro-rata. A 14-day adjustable lock on deposits is added to prevent attracting mercenary capital.
TOR Savings
Swap fees from minting/burning TOR (and all BlueChips, below), will start by being sent into the RESERVE as extra network income. Once the pools are deep, some or all of the revenue can diverted into a TOR savings account to grow demand for the feature.
Mint/redeem fees are expected to be high even though the TOR pool is not arb'ed. This is because commonly arb bots use a stable coin as their settlement asset to start and end in. This is the reason why the BUSD pool has such a high yield. But once this pool becomes available, it will offer arbs faster and cheaper fees (even more so than synthetic stables). In the event that this assumption proves to be incorrect, the vault can be subsidized by block rewards to drive up demand and achieve produce market fit. Assuming vault depth is $100m, mint-redeem fees are 2-5% APY, block rewards are 7% 100m / 42000r * $5 * 365days * 10% = 7.6%
- total yield around 10-12% APY.
Blue Chip Savings
Blue Chip assets (base assets on all chains) are also eligible for the exact same mechanism as USD.
- Price oracle from 1 or more L1 pools
- Mint/Redeem using RUNE
- Virtual depths with amplification and liquidity-sensitive fees
Blue Chip Savers earn all the yield captured from loan collateral; BTC collateral is paying BTC savers, ETH collateral is paying ETH savers. For each pool, the outstanding deposit values of loans can be computed. The locked LP unit value is compared to this and will always be positive, since pool LUVI always goes up. Each time THORSavings are interacted with, the excess LUVI is skimmed and paid to the savers-vault to be redeemed.
If the Pool is earning 20% APY, and 50% of the pool is lender collateral, then the savings vault should have a minimum depth of 50% the Pool, with savers earning a minimum of 20% APY. Since the friction to participate in savings is much lower than LP, potentially the savings depth will be higher than Lender depth.
UX
Savers lock value (as L1) directly from their wallets via a simple memo. To them, there is no new/wrapped/synthesized balance. Just a L1 balance entry and an ongoing yield rate. There are no deposit tokens or two-step process.
Economic Reasoning
This design works:
- USD is backed by the liquidity of RUNE, which is on-chain
- USD-savers earn the yield from mint-redeem fees (plus some subsidization)
- Lenders lock yield-producing collateral for the privilege of shorting USD
- The protocol sells USD to buy up liquidity if RUNE price goes down
- RUNE holders are willing to wear short-term price depression to insulate the USD peg
- Savers earn the yield from foregone Lender collateral
Further, in a pool:
- LPs earn their yield, plus the yield from all Synth holders
- Savers earn the yield from Lender collateral
- Lenders forgo their yield to Savers
- Synth-holders forgo their yield to LPs
So with adoption of Savers and Lenders, Pool yield will go up to those remaining to participate. This stops the "Agent Smith" problem.
RUNE Supply
RUNE supply is decreased when acquiring TOR or when someone participates in THORSavings. The supply is increased when lending (ie TOR is minted to give the borrower their debt, which can be burned to RUNE). However, when a loan takes place, it naturally creates demand for THORSavings via increasing the yield. Because of this, the act of adding $10k in loan collateral, creates economic pressures to burn at least $10k RUNE value into THORSavings. This means that even a loan at 100% CR, the RUNE supply net neutral. Above 100%, the RUNE supply decreases, the higher the CR, the more the supply is decreased.
To walk through an example, Alice has $10k of LP units, half of that value is in RUNE and half in BTC. The Bitcoin pool currently earns 20% APY for LPs and for THORSavings. This would insinuate that the amount of value in BTC THORSavings is equal to the value of BTC loan collateral. If THORSavings APY was higher than 20%, then collateral > savers, if lower than 20% then savers > collateral. Alice deposits her $10k collateral and receives a TOR loan for $9.8k at a 100% CR (she paid swap fees to get her TOR, the fees are paid to USD Vault). Alice is long BTC, so she swaps her TOR to BTC, causing her TOR to burn and RUNE to be minted at $9.7k value. The RUNE supply has increased by $10k ($9.7k to Alice, $0.3k to USD vault). But now the collateral > savers, and the THORSavings APY has increased to 23%, above LP's 20%. This will either trigger new savers to deposit into THORSavings or LPs to withdraw and move their capital to savers. Someone will burn $10.2k RUNE to take a $10k position into savers (swap fees again are sent to USD vault) filling the savers gap that the loan created. At the end of the day, even 100% CR (which isn't possible in any other lending protocol in DeFi) still creates a neutral effect to the supply of RUNE (minted $10k loan, savers burns $10k). If Alice had a 200% CR, the RUNE supply would net decrease by $5k (minted $5k loan, savers burns $10k). At 300% CR, Alice's loan would net decrease the supply of RUNE by $6.7k (minted $3.3k loan, savers burns $10k).
When combined with positive RUNE price action from participation; not all the RUNE will be minted to pay back debt since it will be a higher price, so long term THORFi is deflationary to RUNE supply.
Degrees Of Freedom
Adjust:
- Pool Amplification Factor to tweak mint/redeem fees (down to force higher fees)
- Saver Block Reward Frequency to tweak USD Saver yield (down to force higher yield)
- Saver Deposit Time Minimum to tweak attracting mercenary capital (down to get more capital)
- Loan Deposit Time Minimum to tweak attracting mercenary lenders (down to get more lenders)
- Loan MaxCR to tweak attracting all lenders (down to get more lenders)
Additional Thoughts
Since the design of THORFi Savings is heavily predicated on successful lending; it lending uptake is found to be lacking, the yield-skimming can be abandoned and yield returned back to the lender as an additional feature "self-paying loans". In this case the yield is skimmed and debt paid off for each lender.
Yield streams can be adjusted to drive participation where it is needed.
Implementation
Anchor
- price median of USDC, USDT, DAI, BUSD
- pause-on-outlier
RUNE-TOR Pool
- burn RUNE, mint TOR IAW mint/redeem formula
- virtual depths as per below
x: input amount (RUNE or TOR)
X: virtual input side (RUNE or TOR)
Y: virtual output side (RUNE or TOR)
y: output amount (RUNE or TOR)
mint/redeem
y = (x * X * Y)/(x + X)^2
Virtual Depths
p: anchor Price of TOR (inverse of RUNE price)
u: TOR minted
U: TOR virtual depth
R: RUNE virtual depth
Mint
U' = U + u
Redeem
U' = U - u
Depths
R' = p * U'
TOR Vault
- collect fees and move to TOR vault
f: fee collected
x: input amount (RUNE or TOR)
X: input side (RUNE or TOR)
Y: output side (RUNE or TOR)
f = (x * x * Y)/(x + X)^2
- member lock/unlock USD with memo
++
--:BASISPOINTS
- track vault membership
u: usd locked by user
U: vault TOR depth
v: VaultUnitsMember
V: VaultUnitsTotal
v = V * u / U
shareOfVault = U * v / V
Lending
- member lock LP Units, mint TOR debt
LOCK:ASSET
- record deposit values, debt qty
- member repay debt, unlock LP Units
UNLOCK:ASSET
with TOR payload - update deposit values, debt qty
r: rune deposit value
a: asset deposit value
R: rune depth in pool
A: asset depth in pool
d: total deposit value
u: debt minted
Rv: virtual rune depth
Uv: virtual TOR depth
d = r + (R/A * a) # Get deposit_value in rune terms, where deposit_value = collateral value * CR
u = (d * Rv * Uv)/(d + Rv)^2 # calculate debt minted
Collaterisation Ratio
P = total rune in pool (pooled rune)
C = total rune in pool as loan collateral (collateral rune)
uC = user rune collateral
maxCR = maximum collateralization ratio
CR = ((C + uC)/P * (maxCR-1)) + 1
Savings
- member lock synths,
++:BTC/BTC
- membership tracked with vaultUnits per pool (same as above)
- member unlock savers,
--:BTC/BTC:BASISPOINTS