[Hashi’s Time Locks Protecting BTC, and the 60-Day Exception] @SuiNetwork @SuiNetworkKR For regular withdrawals, Hashi requires signatures from both the Committee and the Guardian, with waiting periods embedded at various points in deposits and withdrawals as safety safeguards. However, once a UTXO has been confirmed and 60 days have passed, a committee-only recovery path becomes available, bypassing the Guardian entirely. We followed this structure as defined in the official design documentation. Lesson 1: When entering, wait 10 minutes; when stopping, set the threshold at 5% BTC deposits must wait for six Bitcoin confirmations (approximately one hour on average), and even after the Committee approves them, an additional minimum 10-minute delay is required before hBTC is issued. The documentation describes this 10-minute window as a buffer to detect and halt erroneous approvals before issuance. The threshold for halting is intentionally low: an emergency stop can be passed with just 5% weighted voting support from the Committee, but lifting it requires 66.67%. This design ensures that if suspicion arises, a minority can initiate a pause, and only the majority can re-enable it. Lesson 2: When withdrawing, require two signatures and a replenishing withdrawal limit Regular withdrawals require signatures from both the Committee (a multi-signature generated by Sui validators via MPC) and the Guardian (a separate signer operating in an isolated cloud environment). Each time the Guardian signs off on a withdrawal, it deducts from a configurable withdrawal limit. This limit gradually replenishes over time; if depleted, withdrawals must wait until sufficient capacity is restored. As long as the Guardian operates normally, even if the Committee erroneously approves a withdrawal, funds cannot be drained all at once—giving operators time to detect anomalies and initiate a stop. Thoughts and Questions: The 60-Day Recovery Path Considers Only Time To account for potential loss of the Guardian key, each UTXO’s address script includes a recovery path that becomes accessible to the Committee alone after 60 days of confirmation. This script does not evaluate whether keys are lost—it tracks only elapsed time. Once a UTXO exceeds 60 days, it can be accessed via this path without requiring the Guardian’s signature or respecting its withdrawal limit. The withdrawal logic interacts with this timer: Withdrawals prioritize larger UTXOs first. When combining inputs within a fee budget, UTXOs older than 4,320 blocks (~30 days) are prioritized. Any change is returned to a new address under the same 60-day condition, restarting its confirmation timer. We understand this rule effectively re-enters some older funds back into the dual-signature requirement period. We also calculated the cost of refreshing small UTXOs using this method. Each input adds approximately 108 vB to a transaction (based on our calculation: two signatures, script, and control block). At Hashi’s default minimum fee of 3 sat/vB, just the input cost amounts to 324 sats—1.08% of the minimum deposit value of 30,000 sats. If such a UTXO were refreshed six times per year, input costs alone would total 6.48%. For a 1 BTC UTXO, this cost would be only ~0.0003% per refresh—meaning these fees disproportionately affect small UTXOs. Do small UTXOs nearing the 60-day mark get refreshed individually? If they are refreshed, who bears this cost? If not, how are funds eligible for committee-only recovery managed? #Sui #Hashi