tBTC v1 + coverage pools

Starting this thread to try to collect ideas & brainstorm on the Coverage pool, what is needed and what it will bring to the system, in one place.

Initial thoughts:

Some links to relevant Discord discussions on this:

The functionality of coverage pool’s in tBTC v1 is to be a ‘buyer of last resort’. The coverage pools consist of different assets (details to be released) that can be provided by anyone. In return, asset providers receive KEEP rewards.

The coverage pool is forced to buy the auction after 24 hours, regardless of the c-ratio at that time, under the condition that it has the funds.

The big impact of this is that the BTC depositor no longer has to be protected by preventing that a c-ratio will ever go below 100%, but is protected by the fact that regardless of the c-ratio the auction will be taken after 24 hours. In other words, after 24 hours there is the guarantee that there will be >100% in ETH locked for his deposit again.

This in turn enables the CC and Liquidation threshold to be dramatically reduced, for example to 101%. What benefit does this give to the system:

  • Bigger gap between start c-ratio and liquidation thresholds à less deposits will reach this state
  • Lower liquidation signer costs due to reduced notifier fee à less need / drive to prevent liquidations à less signer work & stress, less signer churning cost

Eventually, because a liquidation is not so painful, it could lead to a reduction of start c-ratio → enable additional system growth. Also this would reduce signer cost in case of a time-out liq.

In practice, the c-ratio can go 3 ways after the liquidation phase was entered at 101%.

  • The c-ratio increases above > 101% à it is likely that someone will buy the auction somewhere within the 24 hour auction timeframe
    • The signers loose x% of the bond $ in auction, and 50% of the remaining bond to the notifier
  • The c-ratio remains stable at 101% à the auction is either bought by someone or after 24 hours bought by the coverage pool
    • The signers loose max 1% of the bond $ in auction and 50% of the remaining bond to the notifier, which is max 0.5% of the bond value $
  • The c-ratio declines <101% à the auction is likely not bought, and the coverage pool will buy the auction at a loss. “the last resort”
    • The signers gain x$ value in BTC, as they receive the BTC backing the deposit which has a higher value than the ETH bond

Conclusion: On it’s own the pool will loose value in the auctions, and this will need to be offset with rewards for what it is bringing to the system.

Initial goal: Determine what is needed to make the coverage pool float, as a factor of system volume *

  • Incentives needed
  • Pool size $

*The larger the volume, the more auctions will need to be bought by the coverage pools.


  • Project the % of deposits that are expected to reach the liquidation phase based on assumed settings of c-ratio, Liq and CC thresholds and historical price movements
  • Project the coverage pool cost, and the signer cost & gains in the following liquidation process (again using price development based on historical data)
  • Have system volume as a factor here, so the effect of scaling is easily included

My current line of thinking is that we could try to create a distribution model that describes what happens along the liquidation auction. And to apply that distribution model to all liquidations that are expected to reach the liquidation phase.

This way you can run the simulation with any chosen system volume.

  • If it the auction % * c-ratio increases above x% during the auction, assume the auction is bought at a fixed percentage. For example 105%
  • If it remains stable or below assume the c-ratio at the end of the 24 hr window, assume the coverage pools buys is for the auction % (100%) * the c-ratio at that time.

Using data like provided by Qwerte and Indexed this would look something like this (would need to add the lineair increase of the auction %)

And to then translate that into a model that predicts the Auction % and c-ratio at which the aution is bought, something like this


Awesome work! Would it be possible to know what assumptions were made for the simulation? Did you use previous CCs for it or just assumed that a CC would happen daily at a set time?

1 Like

For now this is just using old available plots as example to support the brainstorm.

The c-ratio plot is made by qwerte and indexed before. I believe they made a fictive daily deposit and tracker it’s c-ratio every minute. Once it reached CC - 125 %, this is t=0, and then plot the following c-ratio development ~ 30 hrs after this.

I Imagine we do something like this, but for auction % X c-ratio.

Outcome of this will be a model predicting what happens, adding up to a 100%. So we basically would assume that model applied to each deposit reaching liq phase.

By playing around with start c-ratio, thresholds & historical price data we could determine the amount of deposits reaching this state.

What I’m also not quite sure off is if we want to use reaching cc as t=0 or we need to generalize this a bit and use max c-ratio change within 24 hrs at any start.

We could do the both so we have some sort of a sensitivity study?