Distributed BTC Custody

Summary

Terra need to solve distributed custody for the BTC in the protocol Bitcoin Reserve.

The BTC is currently in this multisig address
https://bitinfocharts.com/de/bitcoin/address/bc1q9d4ywgfnd8h43da5tpcxcn6ajv590cg6d3tg6axemvljvt2k76zs50tv4q

There are currently proposals to wrap this Bitcoin on to the network and use in a Virtual AMM.

Proposal

A decentralised stablecoin, $UST, with a reserve of a decentralised asset $BTC needs a decentralised custody solution.

There are two parts to decentralised custody

  1. The technical implementation
  2. The economic security architecture

The proposal discusses both aspects.

Technical Implementation

All 130 LUNA nodes must participate in the custody, with 1 node = 1/130 key share.

There are two viable solutions:

  1. Use ECDSA Threshold Signatures based on GG20 Method.
  2. Use Schnorr Multisignature

(1) Is a proven high-bandwidth method. Downside is quadratic scaling challenges, solved by vault sharding. 30/45 TSS signs within 15-30sec, would need 3 vaults. Implemented by THORChain https://gitlab.com/thorchain/tss/tss-lib
(2) Is an unproven method, but can linearly scale. 87/130 could be signed within a minute.

Nodes must

  • be able to shard the vaults to handle bandwidth limitations
  • be able to churn the vaults to handle validator-set changes

This can be coordinated at the Terra State Machine level.

BTC Nuances

  • dynamic BTC gas fees need nodes to post networkFee messages. The recommended approach is post the average blockFees/blockSize, then use a 10-block trailing floor
  • child-pays-for-parent logic to be added
  • 1BlockValue confirmation counting confsRequired = sumOfBlockReceivedValue/blockCoinbaseValue
  • post re-organisations to the state machine, with an errata message if a tx is found missing in the new chain
    More details
    UTXO Chains - THORChain Docs

Economic Security

$(BTC) - the value of the BTC
$(STAKE) - the value of the stake in Terra nodes

There are three approaches:

  1. Hard Security Coupling: force the $(BTC) < $(STAKE) at all times
  2. Soft Security Coupling: using revenue, drive the $(STAKE) >= $(BTC) via discounted future cash flows
  3. Speculative Security Coupling: let $(BTC) cause speculative price action on $(STAKE) to keep it high

(1) would require the protocol to start discounting BTC redemption price if $(STAKE) drops to encourage users to redeeming and removing BTC from the vault. Would likely interfere with and exacerbate a LUNA unwinding cycle.
(2) would require the protocol to charge fees for holding the BTC, and paying those fees to the nodes. The fee rate is tweaked to target 20x PE. With $27bn LUNA staked, this is enough to secure $10bn BTC. If the $(STAKE) drops below $(BTC), an annual holding fee rate is charged on the BTC and paid to nodes. Ie, if the $(STAKE) drops to $5bn, then $5bn security budget has to be bought: $5bn / ($10bn*20PE) = 2.5% this requires a 2.5% annual fee rate to be charged on the BTC.
(3) is the “secure enough for now approach” and adds no economic coupling. The fact that LUNA nodes are securing $(BTC) is enough to keep $(STAKE) higher than it at all times.

Summary

Terra to investigate and outline:

  1. The technical architecture
  2. The economic architecture

For achieving distributed custody of the BTC in the reserve.

3 Likes