Vaults
Last updated
Last updated
Vaults are the names we have given to tap-scripts that determine the spending conditions for an offered loan. We have divided the spending conditions into three functions. Each of these functions has a series of requirements to activate or deactivate. We will go through them in detail in this section. As a recap, we currently have three spending conditions: Mint, Redeem, and Liquidate.
It's important to understand that the protocol will construct the taps-script on behalf of the user, and the user will commit that transaction alongside their BTC to unlock the loan.
The diagram above illustrates the tap-script, which we have named 'vault'. Each will have to be generated for each UNIT creation. The tap-script will contain all the user's spending conditions, including all vault parameters, which the protocol will use to determine auctioning and liquidations.
The protocol will construct the tap-script on behalf of the user, and then the user will commit that transaction alongside their BTC to receive the loan. This process will credit the amount of UNIT tokens directly reflecting the collateral the user wishes to have in their vault. This effectively blocks Bitcoin in exchange for the runes tokens. This is done in three steps.
Request the tap script to the network.
Tap-script locks the current BTC outputs when the tx is mined.
The outputs to spend the equivalent amount of UNITS are unlocked.
For every mint, there is an option to redeem. This works very similarly to minting but the other way around. We would use the spending conditions of a vault to lock some outputs that belong to a rune and unlock the outputs for the equivalent amount of BTC. Redemptions have a special characteristic: they will be blocked for n Blocks after the initial transaction is mined to ensure the redemption was not subject to a race condition.
The liquidate function is very straightforward. We plan to leverage the linearity property of Schnorr signatures to influence the spendability of the outputs in the tap-script. So that when a value x is derived from the BTC that the user held, it is no longer spendable and can, trustlessly, be put up for auction.
A useful example comes with this question:
I’m about to be liquidated; hence, I repay the loan just in time. But within the block time of my Tx, the price of BTC takes a sharp nosedive. Do I get liquidated or not? And who bears the risk?
“Just in time” would be a misnomer in this scenario; "Just in time" would be in the block before the liquidation event; otherwise, the user is late. If this were not the case, there would be endless race conditions. BTC is the source of truth. If a transaction has not been settled by the time the liquidation price is reached, then the user loses the custody of their funds to the protocol, which puts them up for auction. This is to say there is no provable difference between:
BTC price drops, and a user sends a Tx to settle the balance
A user sends a Tx, and the BTC price drops.
The user will be liquidated if their Tx is NOT included in a block before the liquidation price hits. Our source of truth is the Bitcoin blockchain. We don't want to store state since this would move us into L2 territory. Therefore, only information stored on the Bitcoin blockchain will count as valid.
The key Risk Parameters for a Vault are:
Debt Ceiling: The Debt Ceiling is the maximum amount of debt the Vault can create. Once enough debt has been created by a CDP of any given type it becomes impossible to create more Ʉ unless existing CDPs are closed.
Liquidation Ratio: The Liquidation Ratio is the collateral-to-debt ratio at which the Protocol marks a CDP for liquidation.
Interest Rate: The Interest Rate is a monthly rate paid by Borrowers. [It will be initially set to 0%].
Liquidation Penalty: The Liquidation Penalty [initially set to 16%] serves two purposes. Initially, it sets a floor for the Liquidation Auction. Assuming the Liquidation Penalty is not the winning bid, the full balance of the Liquidation Penalty is remitted to the Reserve.
Auction duration: The duration of the collateral auction once a Liquidation has been triggered.
Auction increment size: The minimum increase a bid must be above the current bid when bidding in an auction. This risk parameter incentivises early bidders and prevents “pennying” existing bids.
