[Design]: Iterative Cap on Pegged sBTC

[AshtonStephens]

Design - Iterative Cap on Pegged sBTC

This ticket holds the design of Iterative Cap on Pegged sBTC and how it fits into sBTC-v1.

1. Summary

TL;DR Both the GTM strategy and a slow-rollout strategy would benefit from a cap on the maximum amount of sBTC that can be pegged-in. The cap can iteratively be increased and, eventually, lifted.

2. Context & Purpose

Relevant Research Discussions

External Resources

3. Design

3.1 Proposed Component Design

The signer binary can be programmed to stop processing deposits if the amount of sBTC pegged in is over a configured cap.

3.1.1 Design Diagram

3.1.2 Considerations & Alternatives

An alternative design would be to publish the cap on-chain. Since, however, signers can always decide not to process deposits, the additional implementation required seems to not pay dividends.

3.2 Areas of Ambiguity

---

Closing Checklist

• The design proposed in this issue is clearly documented in the description of this ticket.
• Everyone necessary has reviewed the resolution and agrees with the proposal.
• This ticket has or links all the information necessary to familiarize a contributor with the design decision, why it was made, and how it'll be included.

[djordon]

Having an iterative cap on the amount pegged into sBTC is relatively easy to implement in the signers. It is easier than an account cap but harder than a per transaction cap (both proposed in #791). I give all of these a complexity of 2 (or maybe 3).