sBTC Research - Handling Practical Withdrawal Limit

[AshtonStephens]

This is a research discussion post meant to be edited with research notes surrounding how the sBTC system will behave when the withdrawal limit is reached.

Related topic: stacks-network/sbtc#321

In any sBTC design there will be a practical limit to the number of withdrawal requests when the volume exceeds the stacker's ability to fulfill them.

The current SIP calls for a load sheding approach where Stackers can:

1. Prove that they are currently overloaded and thus not get punished by having the Pox taken away
2. Shed some of that load during a Peg transfer, where the act of doing a Peg transfer cancels any pending withdrawal requests.

The research in this discussion is to determine either a better and simpler approach, or to verify that this our chosen approach with documentation on the downsides and very high level implementation details.

[AshtonStephens]

Currently under investigation by @soju-drinker.

[soju-drinker]

I'm unsure what a proof of being currently overloaded would look like, but given that we assume that this aspect is handled, then there are a few ways to approach the problem of dealing with such a case. One of the simplest is somewhat akin to recovery mode where we do not cancel any of the pending withdrawals currently in queue to be processed but we automatically do not accept any new withdrawal requests until the current queue is decongested. This would be fairly easy to implement, whereby a boolean flag would determine whether the system is currently actively accepting new withdrawal requests or a user needs to try again later. The second more complicated approach would be the one outlined above where there is some sort of load shedding method where certain withdrawal requests, although already accepted, are refused and the sBTC unlocked for the user to try again later. On top of being more complicated to implement, I do not like this approach because it does not guarantee a reliable system once a request has been accepted. Refunds are arguably a worse user experience, because the user has already spent gas fees on the transaction that was refunded and will have to spend it again, perhaps an infinite number of times until it is finally fulfilled. I strongly prefer the other approach

[AshtonStephens]

This question ended up being somewhat pre-resolved with the added detail being: at the end of the cycle all in flight pending transactions need to have their penalty timer stopped. We may add more details here later.