Lower collateral ratio proposal

Hey team! Long-time lurker, have decided to get involved and write my first proposal.

Now that coverage pools are up and running we should reduce the collateral ratio back to 150% / 120% in order to free up collateral so that more TBTC may be minted. As we all know there’s a shortage of TBTC (as evidenced by the 2%+ premium in the market).

Coverage pools are going to be transformative for the KEEP ecosystem!
Let me know your thoughts.

6 Likes

I agree that we should do this, and would recommend increasing signer fees at the same time.

With regard to the collateral ratio we choose, coverage pools should allow us to get even lower than 150 / 120 - I’m hoping some of the folks that were discussing in discord can post their research here.

3 Likes

I personally wouldn’t touch the signer fees for now due to the extremely high gas fees for minting any size which add to the cost significantly. It feels like the signer fee change should be applied to v2 as it’ll be a lot more collateral efficient.

Thanks for making the proposal.

Initial the collateralization ratios where
150% - mint
125% - courtesy call
110% - liquidation

When a liquidation occurs the signers ETH bonds get auctioned off, starting at 66% of the bond, with the percentage of the bond being auctioned increasing over a 24 hour period (IIRC). Historically the market has been quite efficient with taking the auctions as soon as they are profitable.

The risk has been that if the value of the ETH relative to BTC drops faster than the portion of the bond being auctioned that it will never become profitable and the liquidation will stay open.

Now that we have the coverage pool to act as a buyer of last resort we know that the liquidation will be taken within 24hrs of the auction starting. In theory we could have the liquidation c-ratio be as low as 101% however this would risk the coverage pool taking some savage losses if the price of ETH relative to BTC dropped significantly after the auction starts.

Currently the collateralization ratios are
200% - mint
115% - courtesy call
110% - liquidation

There are a number of deposits that are highly over collateralised that could be redeemed to free up ETH.

The existing Keeps have alot of room for c-ratio movement before being in danger of getting a courtesy call.

It’s also worth noting that the change would only apply to new keeps being created so the risk to the coverage pool is mostly against new deposits.

I would suggest that

The new collateralization ratios become
150% - mint
110% - courtesy call
105% - liquidation

This in combination with some of the over collateralised keeps being redeemed, would free up liquidity to mint and provide room for the deposits to recover from price movements.

I am also in favour of raising the signer fees to act as a deterrent for arbitrage bots to make it easier for signers to mint and unwind their ETH positions in v1.

6 Likes

Hi all,

Agree as well on changing the System parameters as previous members have suggested. I find the distance between CC and liquidation suggested by Ben a bit short (personally, as a staker). Since I would rather receive the event with 6hrs to act, than risk that 5% collateral-price volatility.
Collateralization ratios below sound good to me
150% - mint
120% - courtesy call
105% - liquidation

In terms of signing fee, as no one has suggested numbers, I’ll break the ice. If we raise it to 3x the signer fees planned for TBTCv2, users will start to migrate naturally to v2, given there is in place a v1-v2 bridge (with also parameterizeable fee!). When v2 has been launched, users will find 1/3 of signer fees a relief.

Agree with Ben that we would like to deter arbitrage bots, so that more&cheaper liquidity is available to users. At the same time we need to find a fee that still makes the system usable while v2 fully kicks in. Currently signing fee is 5bps or 0.05%. If we are planning to keep the same on v2 at launch, that would mean increasing v1 signing fee to 0.15%, which is the same fee charged by REN, and under the 0.25% for WBTC on Coinlist.

Any further increase in signing fee should be part of a future system parameter change (i.e. not hand in hand with ratios change). We probably shouldn’t chase the 2% premium in the market and if we were to require such astronomically high fees at some point in time (e.g. to push migration to v2), again, should be a future discussion not in scope of this proposal.

6 Likes

As requested by @ninja5

Some quantitative stuff to help guide the conversation
I’ve put together a module for looking at historical volatility in the underlying assets that you can access here and play around with some of the variables:

About the Model
The model has OHLC candles for BTCUSD, ETHUSD and ETHBTC dating back to 2016-01-01.

The statistics are based on the intraday swings (high to low), so we afford a given position ~24 hours to adjust with this analysis. Happy to do a different time interval if necessary.

You can change the date in the inputs to determine where the cutoff for the stats occurs. I’ve opted for 2019-01-01 because I’m making the assumption that BTC and ETH are both getting less volatile, which is valid from a quantitative perspective. While the data also supports the claim that ETHBTC is getting less volatile, I’m personally not as confident in this claim.

You can also modify the ratios to adjust the lines on the chart and the liquidation/call thresholds.

Lastly, I’ve incorporated a Magnitude Amplifier, which lets you test worst case scenarios by multiplying historical volatility.

The important dots to be looking at are obviously the orange (the ETHBTC) dots because that’s the pairing that we’re concerned about. The ETHUSD and BTCUSD are really just for reference.

The TLDR
My analysis suggests that anything beyond a 15.68% movement in price is outside 3 standard deviations of the norm since 2019.

If you draw the cutoff at different years, you’ll receive the following results:
Year, 3xSTDev
2016, 29.89%
2017, 24.69%
2018, 16.54%
2019, 15.68%
2020, 17.05%

At a minimum, I believe the different between the initial at the courtesy call should be this 3xSTDev value (and can be updated annually). At a maximum, to maximize liquidity, I think it should be no more than 3.5xSTDev this value, which establishes a 99.9995% confidence interval (1 in 15787).

This analysis will also be helpful for coverage pool participants to price their risk.

I think the (courtesy call → liquidation) ratio should be thin, perhaps 1/2 this value?

Thoughts? Happy to help with more vol analysis wherever it would be helpful.

6 Likes

Thanks for putting this together @jakelynch.

It would be helpful to know, if a keep was minting on each day with a starting c-ratio of 150%, what is the lowest c-ratio that it would have reached between being minted and now.

4 Likes

Hi Jake,

Thanks for all the work! I’m wondering if there’s a type-o in the formula in F8 G8 & H8. I think it’s supposed to be 3 * StDev but it’s using row 7, so 3 * 2 * StDev → 6 StDev?

I’m trying to wrap my head around this data. Is it correct that this is basically looking at the changes within a day, and not so much a trend over a longer duration?

The initial reason why we increased the gap between start c-ratio and CC / Liq Threshold (150–>200 and 125 → 115) is because over a time-span of multiple weeks or months, deposits would slowly crawl to these levels. What we did back then analysis wise is to make theoretical mints every day, and follow the c-ratio deposit over time (hourly) from the mint up to the date of analysis. This showed that with 150/125/110% we would have a significant amount of deposits reaching liquidation at one point. This was matching reality at that time (Dec 2020). Signers were trying to redeem many deposits themselves to avoid getting liquidated, which was stressful and at significant cost.

What we essentially did with the updated 200/115/110% is increasing the gap between start C-ratio and CC to a size that based on historical price data would make the chance to reach liquidation very low.

Couldn’t find everything back but some old references here:

Maybe we need to do a similar analysis again?

@daramir regarding the proposed thresholds. I think you’re reasoning is still with the assumption that signers try to prevent liquidations because of the cost right? The way I see it, basically 4 parties can loose / win in a liquidation.

  • the notifier: The bigger the gap between the buy % and the actual c-ratio, the more he gains, since he’s receiving 50% of the remaining bond. This is a loss for the signers. The lower the thresholds, the lower the remaining bond will be → the signers loose less to the notifier.

  • the auction buyer, if not coverage pool: he’ll buy it at once economically profitable. This will directly be the case for high c-ratio deposits that are timed-out during redemption. This can cause high signer losses → the lower the start c-ratio, the lower the c-ratio during a potential time - out, the lower the signer losses

  • the auction buyer, coverage pools: the coverage pools will only buy a deposit at the end of the auction, after 24 hours. This means it’s likely not economically profitable, so it will take a loss here. The lower the thresholds, the higher the loss will be.

  • the signers: the signers can loose in an auction, because the bond that was lost in auction was more valuable than the BTC they got back and/or the notifier fee.
    Now here’s an interesting part. The lower the CC/Liq threshold, the lower the bond $ value loss and notifier fee will be. In fact, a liquidation can even become profitable. Therefore I think we maybe not even need a gap between CC & Liquidation?

Example 1:
CC & Liquidation threshold set to 101%. 0 gap. A liquidation is started, and during the auction the c-ratio drops to 95%. This means the coverage pool will buy 95% of ETH value $ and the signers get 100% of BTC value, so the signers won 5%. The notifier fee is 0, and the coverage pool took a hit of 5%.
Example 2:
CC & Liquidation threshold both set to 101%. A liquidation is started, and during the auction the c-ratio increases to 105%. This means likely an auction buyer will buy somewhere between 101 - 105% of ETH value $ and the signers get 100% of BTC value, so the signers lost 1 and 5% to the auction buyer, and the notifier fee is between 0 and 2%.

So assuming the price movement is normally distributed during an auction (50% going up, 50% going down) a signer would no longer care and would let the liquidations just happen. I think this is an important factor to investigate.

There’s 2 parties here that are only taking value out of the tBTC system, the notifier and the auction buyer. This is value loose for the signers, which is offset by KEEP rewards.

By reducing the CC and Liquidation threshold we are reducing these losses to the system. Yes, they come at a cost of the coverage pools, but these are offset by KEEP rewards. The alternative is that they come at a cost of the signer, which also requires KEEP rewards.

I think the sum of KEEP needed would be lower with lower thresholds, since there is less value flowing out of the system to the notifier and auction buyer.

My initial feeling is that something in below ranges would make sense, in line with what Ben is suggesting.

  • C-ratio 140 - 150%
  • CC 101 - 105%
  • Liq 101 - 105%

And to do some more research on:

  • How often would a liquidation be triggered at these levels & historical price data
  • What is the expected c-ratio development during an auction / 24 hours → to estimate coverage pool cost / signer cost
  • Estimate the effect of concentrated minting data. Typically when capacity opens up, this is directly re-minted resulting in a concentration of deposits at 1 date and at 1 c-ratio. This could eventually lead to a group of deposits entering liquidation at the same time.
2 Likes

Thanks for catching that Nax, you’re absolutely correct. I’ve fixed that mistake and obviously the result is a much lower threshold needed by those standards.

@benlongstaff also requested this analysis:

Give me a day and I’ll see what I can put together. In the meantime, do you (or anyone else) have any thoughts on what timeframe is relevant for back testing?

3 Likes

@jakelynch ok so I’m, a bit slow so I thought about it a bit more and didn’t realise this yesterday, that your model is basically predicting how much price movement you can expect within 24 hours, so how much the collateral ratio is expected to change during the auction.

So if we were to confirm that the data is normally distributed, we could use the data to determine the ranges in which 99.7% of the auctions would fall vs the CC/Liq threshold. For example if the CC-threshold is 101%, and ETHBT 2xStDev is 5.7% & 3xStDev is 8.55 (Based on Jan 1st 2020 up to Oct 7th 2021) we could expect 95% of the auctions to be between 95.3% and 106.3% after 24 hrs. And 99.7% would be between 92.45% and 109.55%.

Is that also your line of thinking to how to use this data?

On the second point, not sure. Maybe January 2020 - 2021 YTD data? I do still have these old files from before, I could populate these with new data.

2 Likes

Excellent discussion, and it seems like we could be closing in on numbers we can get consensus on. Thanks for proposing @hellomoon! I’m more of a commenter but one of these days I’ll get a proposal up, as well.

Super helpful analysis @benlongstaff, @daramir, @jakelynch, @Naxsun - thank you! (And Nax, if you’re “a bit slow”, then I’m really slow; still getting my head around these options. :slight_smile: )

Naxsun’s scenarios are really valuable. I think the second bullet got cut off, and you meant to write that the lower the start c-ratio, the lower the signer loss?

I agree that "There’s 2 parties here that are only taking value out of the tBTC system, the notifier and the auction buyer", and there’s been some discussion in Discord that the notifier getting 50% of remainder while 3 signers split the other 50% is unduly harsh on signers (I certainly think so, and it’s been painful when I’ve been liquidated).

I also agree that “the sum of KEEP needed would be lower with lower thresholds, since there is less value flowing out of the system to the notifier and auction buyer”, and for the reason just noted I think it’s better for losses to come mainly from a coverage pool that is designed for this, than from signers who already bear risk and have paid for it.

Interesting point that perhaps we don’t need a gap between CC and liquidation if the threshold is low enough.

As for increasing the signer fee, gas fees are high but I think the benefit of encouraging migration to v2 and bot deterrence outweigh this - and tBTC’s value proposition has motivated usage despite fees (presumably given the utility of being able to eat your BTC and have it, too).

3 Likes

Yeah got cut off, indeed what I meant. Updated it, thanks!

Haha, together this group of slow frens will manage😄

Made this sketch to clarify what I mean. And yes, my writing is sort of cryptographic as well, as in hard to decypher.

This is supposed to represent the C-ratio distribution, 24 hours after auction start, with a CC & Liq Threshold at 101%.

+/- 1 sigma → 68% of the deposits are expected to be within this range
+/- 2 sigma → 95% of the deposits are expected to be within this range
+/- 3 sigma → 99.7% of the deposits are expected to be within this range

2 Likes

Well said. This is the reason coverage pools exist, and exactly what underwriters signed up for!

2 Likes

Not sure if it changes any of the math here, but want to point out that liquidation auctions start with the bonded collateral and then top-off from the Coverage Pool (if it needs to spill over).

Based on the discussions above my proposal would be
Start c-ratio 150%
CC threshold 101%
Liq threshold 101%

This will leave a gap of 49% between start c-ratio and CC threshold, two times more than what we started with.
This will also significantly reduce and in some cases fully eliminate Staker bond value loss to auction buyers and notifiers

Around 70% of the deposits that go into liquidation will still end up in a range of 98.5 - 103.5 % (probably more narrow band since the data is based on low - high of a day, so this is worst case).

Going with higher thresholds leads to increased rate of liquidations and doesn’t really utilise the coverage pool for what it’s intended for and leaves the liquidation cost largely at the stakers

1 Like

One issue with Courtesy Call and Liquidation threshold being the same number is that it effectively eliminates the CC. 1) Better not to change that now as some became signers with the CC as a buffer, and 2) We’ve never run this live without it, so there could be an edge case issue that comes up.

I suggest a few % between CC and Liquidation. Also, we can go lower than 150% once we try it out, but perhaps better not to go so far initially.

How about?

Start c-ratio 150%
CC threshold 106%
Liq threshold 101%

From the docs

In case of liquidation due to undercollateralization or abort, the remaining bond value is split 50-50 between the account which triggered the liquidation and the signers.

I think the liquidation threshold change to 101% makes a lot of sense since it eliminates the economic incentive for notifiers to time things out. I think the proposal should also include turning the coverage pool on to back TBTC v1 deposits.

1 Like

There are two different calculations going on here and, consequently, two different methods we should use to justify the decisions.

When setting the initial c-ratio, the question we are asking is: "what is a comfortable level that liquidations won’t be common?"

Historically, we’ve tried to answer this question by backtesting positions opened each day to test if they would get liquidated.

I’ve conducted an analysis with that methodology, that can be found in this repo:

A small detail about the analysis that is worth knowing: I did not use ETHBTC, I used ETHUSD and BTCUSD, so I was unable to include highs and lows b/c the high/low for ETH and BTC are asynchronous on a daily candle. I don’t think this should drastically affect our decision as there is a positive correlation here. I’ve left the dataset in there with the ETHBTC data though if anyone wants to adapt the code for that calculation lmk.

Processing: plot.png…

As you can see in the notebook, running a series for everyday from 2020-01-01 results in the liquidation of 2.08% of positions if we use the 150%-110%-101% (initial-CC-liq). It’s been a relatively good two years for Ethereum, which in large part contributes to that metric because ETHBTC has performed pretty well.

That means that the $ risk for a coverage pool participant from 2020-01-01 until now can be expressed as:
(0.02 x Value of Outstanding Collateral) - (amount generated from collateral auctions).

Now, it’s worth noting that if we move this timeline back to include 2019, the rate of liquidated positions spikes upwards to 20%. However, I don’t think that affects this decision, it’s just important information for coverage pools to know. Can elaborate more on this if needed.


When setting the courtesy call and liquidation threshold, we should be asking: "what is the delta needed for someone to reasonably unwind a position in the 24h period after receiving a CC?"

This value is best estimated using daily vol metrics, which I wrote about in this post (above):

This data shows that 5% and 8% (with data starting from 2019) are the 2x and 3x std, so:

  • The conservative approach would be 8-9% (e.g. liq @ 101% and cc @ 110%)
  • The more aggresive approach would be ~5% (e.g. liq @ 101% and cc @ 106%).

Anything thinner than these gaps I think would be moving into a zone where the CC has no function, as John was describing above.


Hope this will help us drill down on a specific value.

FWIW I support the 150-110-101 slightly more than 150-110-105 or any other variation.

2 Likes

Thanks again for all the work @jakelynch! The 2.08% mentioned above for 2020-2021 YTD, is that the % of deposits reaching CC or Liq Threshold?

The Courtesy Call duration is 6 hours, after which a liquidation can be triggered by anyone. This trigger is typically directly done since it can be quite lucrative. The higher the CC threshold is, the higher the potential bond loss & notifier fee for the stakers.

My ‘fear’ with a CC of 110% is that a liquidation remains costly for a staker, because the C-ratio after 24 hours will be in the range of 102 - 118%. So stakers want to prevent from being liquidated, by redeeming these deposits during CC. This can be stressful in a relatively tight window of 6 hours, and also acquiring the TBTC for this requires to have the capital on hand and acquire the TBTC.

The lower the thresholds, the lower the cost for a staker will be, the less they will need to worry about this. To a point where they would just let a liquidation happen. The market or Coverage pool would do the work depending on the price movement.

I also understand the newness around this, so maybe something like 150-105-101% would make sense indeed.

With that added insight, I think that makes sense as well.

This is reaching the liquidation threshold.