Congrats. Now this is just feedback, and this is very opinionated and in no way is meant to deter you all from your progress.

I see VSC/magi is using GG20, which is 4 rounds of communication per signing session. At 50 block signing interval, that is totally fine. But I am a math guy, and this is my calculation.

The most common scenario in blockchain is market crashes.

If there is hysteria, and let's say 200 users decided to simultaneously withdraw their BTC in the same minute (you plan for certain edge cases, this is one). So now you have each withdrawal as a separate signing session. GG20 sessions are normally stateful, so you are running one at a time. that is 200 withdrawals × 2 seconds per signing session = 400 seconds = 6+ minutes of pure signing backlog.

Plus, the 50-block batching interval means your users are now waiting up to 2.5 min before their withdrawal even enters the queue. Your worst-case scenario is a user at the back of the queue waiting 8 minutes just for the TSS signature, before the Bitcoin transaction even broadcasts. Bitcoin confirms in around 10 minutes.

Of course, I do see you guys have implemented batching, so you could just batch all of them together and use a single signing session. My point being, I would highly recommend testing these edge cases and submitting a benchmark for performance.

Also, FROST + taproot deposits would be just plain better because it has just 2 rounds of communication per signing session, but I am guessing your team couldn't find any production-ready GO libs.

Would love to see some more unit and e2e tests in Altera as well.

In my very humble opinion, you guys are on the right track, so good luck, and I am rooting for you all.