Allow TBTC and ETH usage for signing bonds in v2

[mhluongo]

Enabling TBTC as signing bond collateral can lower the overall collateral requirements of the supply peg.

Consider 10 BTC under custody. With a 6 month deposit term and 50 basis point fee, 9.95 TBTC are in circulation, and 15 BTCETH ("15 BTC worth of ETH") is bonded.

With optional TBTC signing bonds, 9 more BTC can be deposited and backed by 9 TBTC, meaning a total TBTC supply of 19 TBTC, only requiring 15 BTCETH in additional collateral. That's a 1.79X collateralization across the whole system, including Bitcoin and signing bonds- versus the 2.5X collateralization required naively by an ETH-only signing bond.

Fully playing out the example, more and more BTC can be deposited and backed by TBTC signing bonds. At 100 BTC, collateralization is only 1.15X- and as the BTC collateral grows further, the total collateral requirements approach 1.

At 100 BTC, however, only 9.5 TBTC is fully liquid- meaning that a 50 basis point return to signers and the use of 9.5 TBTC is the only incentive driving this loop. To see this behavior live, there needs to be additional incentive to sign and deposit. This incentive can be accomplished via #117. As long as signing bonds can be safely lent, the returns on those loans should incentivize signers to also act as large depositors.

• [x] Document the new behavior. A single signer can provide as much ETH as is required for overcollateralization, or 1X the TBTC they're signing for. No signers can mix collateral in a particular deposit, though across a deposit different signers can have chosen different types of collateral. For example, a 1 BTC deposit can be backed by a signing bond of 0.5 TBTC and 0.75 BTCETH.
• [x] Document how this impacts bonding choices and add any additional states
• [x] Document the lowered total collateral requirements by the whole system (demonstrated above)
• [ ] Implement the bond undercollateralization logic
• [ ] Implement the liquidation special case- the TBTC portion of a signing bond doesn't need to be liquidated, only burned.
• [ ] Implement the either / or option for bonded keeps.

[liamzebedee]

This is so crazy, it might just work. Had some time to brew over this:

• obviously this introduces a dependency loop in the design, which rings a couple bells. I want to know why MakerDAO doesn't do this already (vuja de - someone must've thought of this before)
• the bond needs to have value - unlike ETH, TBTC isn't volatile, so it's lower risk for signers in terms of upkeep. I like this, it sounds nice, but ... no free lunch?
• if this does reduce collateral requirements by over 120%, how/where is the exposure to risk being reduced? Rehash - collateral is to insure the cryptoeconomic game is in equilibrium, principally against the price fluctations and fraudulent/abort behaviour. My gut instinct says that the price fluctuation is still insured against, but the behaviour of signers I'm not so sure of.

• Leverage is tricky. If we pursue this, it counters potential malicious signing fine but lowers the exchange rate delta the system can tolerate, since all signing bonds move together.

  Salient point from https://github.com/keep-network/tbtc/issues/14#issuecomment-471380393 - if we stick to a purely BTC<->ETH price oracle, not including a Uniswap pool for example, then the peg should be maintained and there shouldn't be a feedback loop. I'm still weary that this makes the system more fragile, and governance less effective at overseeing the ecosystem (ie custodial fees).

  eg. I wonder about a scenario like MakerDAO had for DAI - TBTC is always backed by a real amount of BTC, but will it have a different price on the market (ie. from lower Eth tx fees)? And what does that mean for overcollateralisation?

Have to think more on this tomorrow. Might be tired, might be a complex issue, but very keen if we can do this.

[mhluongo]

I want to know why MakerDAO doesn't do this already

They're planning to do part of it- the part where bonds can be deposited elsewhere (eg Compound) then locked in a CDP. For DAI, though, this trick doesn't work- the point of the reserve is to stabilize the price, and that doesn't stabilize the price.

For us, it's a supply peg, not a price peg. The tricky part is making sure signing fees are high enough to justify locking up the TBTC you minted to sign for more to be minted.

[mhluongo]

the bond needs to have value - unlike ETH, TBTC isn't volatile, so it's lower risk for signers in terms of upkeep. I like this, it sounds nice, but ... no free lunch?

Free lunch my man. We only need ETH to bootstrap the bonds. The rest is just BTC opportunity cost.

[mhluongo]

TBTC is always backed by a real amount of BTC, but will it have a different price on the market (ie. from lower Eth tx fees)?

This was always the case due to signing fees- and that's okay, as we're building a supply peg, not a price peg.

This could actually counter that by acting as a TBTC "savings account".

Luckily

what does that mean for overcollateralisation?

The answer here appears to be "very little".

[liamzebedee]

it's a supply peg, not a price peg

Those magic words - this is the essence of it. Let's do it!

[mhluongo]

I've discussed this with a couple folks outside Github, and I'm seeing confusion around

why MakerDAO doesn't do this already

Intuitively, folks are asking "well, why can't we just do this with DAI? DAI backed by DAI?"

The answer I've intuited is that in a price peg, reflexive collateral leads to a more volatile peg, "diverging"- and that with a supply peg, more reflexive collateral "converges"- because we're leaning more and more on someone else's Bitcoin being the collateral, and lowering the amount of F/X risk the system is built around.

At scale, if tBTC as a system approaches being entirely bonded on the EVM side with TBTC, there is no F/X risk- but there's also no liquid TBTC on the EVM, as it's all required for signing collateral.

[mhluongo]

@gakonst would be fun to get your take on this. No idea if we can feel good / comfortable getting this into the docs by initial spec peer review but I think we could announce it as a major improvement shortly after.

In addition to the docs it's probably worth a long-form blog post- https://crosschain.group/ launching will give us a place for stuff like that.

[mhluongo]

We can either do this all in one PR, or split this into a doc and implementation PR- open to either

[gakonst]

Documenting this process is next on my schedule for #238.

[gakonst]

https://github.com/keep-network/tbtc/pull/238/commits/02f84ef96a40246ef56bf3d1f2c58ac5a53b38fd should address the first 3 unchecked boxes

[gakonst]

238 got merged but let's keep this open for implementation tracking

[mhluongo]

@Shadowfiend @NicholasDotSol have we gotten anywhere with this? Working to make sure we all know what "done" is for #326

[NicholasDotSol]

have we gotten anywhere with this? Working to make sure we all know what "done" is for #326

Totally lost track of this one. On it.

[NicholasDotSol]

Had some preliminary thoughts, probably best to write down here. Assumptions:

• Single keep implementation, but with ETH / TBTC bonding option.
• Singe contract for holding ETH/ERC20 bonds. (assuming no lending)
• No mixed Deposit collateralization

Requirements / initial thoughts:

• check for collateralization type; maybe around retrieveSignerPubkey. This needs to be set somewhere
• Any case/assumption affecting contract balance combined with seizeSignerBonds is now under scrutiny again. Redemption and liquidation flow specifically.
• When tBTC-bonded, purchaseSignerBondsAtAuction won't have an auction. bonded tBTC will be seized from signers and sent to TDT owner. TDT owner should receive a full tBTC (maybe minus signer fee if not fraud?) since the user should not be punished further in case of signer fraud or abort. tBTC burned if TDT owner is vending Machine. There isn't much wealth to spread, so caller incentives might be odd here. Don't have TBTC to skim, so maybe signer fee...
• SeizeSignerBonds - rewrite for erc20 support.

[Shadowfiend]

gotten anywhere

Late to the question ofc, but I'm not sure what this question was meant to be asking in the first place. We aren't doing this, so in that sense… No? The ball's in your court if you're wanting to land this post-audit or for follow-up audit purposes. Implementing it would need to push into the Keep side to support ERC20 bonds, and we could look at that as part of our poking at adding to the Keep staking mechanism.