$SUI Peak TPS indicates how many operations the system can handle, but users are more concerned with another question: How exactly can they get their deposited BTC back? The previous article covered the purpose of Hashi’s financing and its capital commitments. This time, I followed the design documents to take a closer look at the exit path. After reading them, I wouldn’t equate “BTC stays on the Bitcoin network” with “users can transfer it out on their own at any time.”
The key distinction is that which chain an asset is on and who can authorize a spend are two different things. According to Hashi’s User Flows, users deposit BTC to a dedicated Bitcoin address and receive hBTC on Sui once the deposit is confirmed. Normal spending uses a 2-of-2 structure: one party is Hashi’s MPC committee, and the other is the Guardian. MPC means multiple parties work together to produce a signature, while the Guardian provides a second layer of checks. A user submitting a withdrawal request does not mean they hold a key that lets them bypass the protocol and transfer BTC directly.
These checks help constrain the release of assets in abnormal situations such as vulnerabilities or malicious behavior. But security design can also affect how quickly users can exit. The Limiter document states that withdrawals are subject to a maximum capacity and a quota that replenishes over time; if capacity is insufficient, users have to wait. A request that exceeds the maximum capacity will be skipped until the limit is raised, and users may also cancel requests according to the rules. Requests are generally processed on a first-in, first-out basis, but this is not strictly guaranteed. So if a withdrawal takes a long time, the delay alone is not enough to conclude that funds have been stolen; nor does the existence of safeguards guarantee that funds will arrive immediately. The configured limits, queue, and actual execution all need to be considered together.
There is also a recovery path worth explaining separately. The Address Scheme document states that, in addition to normal spending, the script allows the MPC committee to spend funds on its own after a 60-day relative timelock, once a UTXO has been confirmed. A UTXO can be understood as an on-chain output that has not yet been spent. This design provides an alternative recovery path in situations such as the loss of the Guardian key. The timer starts when that output is confirmed, not when a user submits a withdrawal request. This does not give every user recovery rights, nor is it a service commitment that “all withdrawals will take no more than 60 days.”
So when assessing whether Hashi delivers on its promises, I would look not only at how much BTC can be deposited, but also at whether normal withdrawals work smoothly, how transparently rate limits are disclosed, and how recovery and committee handover are verified if the Guardian fails. Adding a security check and allowing users to retain full unilateral control are two different arrangements. Whether this setup is suitable for a particular type of funds depends on all of these exit conditions.
This assessment is based on the currently available public design documents, whose pages are still marked Testnet; they do not support a claim that the mainnet is already operating at scale under the same parameters. The October 8 announcement described a phased rollout this month. The system will need to be reassessed against actual deployments and real withdrawal records as they become available. A demonstration of 40.6 million TPS and capital commitments exceeding $500 million are no substitute for that. The additional takeaway for now is that validating Hashi’s value requires looking both at whether activity can come in and whether assets can exit according to the rules under normal and abnormal conditions. Sources: Mysten Labs’ Hashi User Flows, Guardian, Limiter, and Address Scheme documents; the accompanying illustration is a schematic of the mechanism.
The key distinction is that which chain an asset is on and who can authorize a spend are two different things. According to Hashi’s User Flows, users deposit BTC to a dedicated Bitcoin address and receive hBTC on Sui once the deposit is confirmed. Normal spending uses a 2-of-2 structure: one party is Hashi’s MPC committee, and the other is the Guardian. MPC means multiple parties work together to produce a signature, while the Guardian provides a second layer of checks. A user submitting a withdrawal request does not mean they hold a key that lets them bypass the protocol and transfer BTC directly.
These checks help constrain the release of assets in abnormal situations such as vulnerabilities or malicious behavior. But security design can also affect how quickly users can exit. The Limiter document states that withdrawals are subject to a maximum capacity and a quota that replenishes over time; if capacity is insufficient, users have to wait. A request that exceeds the maximum capacity will be skipped until the limit is raised, and users may also cancel requests according to the rules. Requests are generally processed on a first-in, first-out basis, but this is not strictly guaranteed. So if a withdrawal takes a long time, the delay alone is not enough to conclude that funds have been stolen; nor does the existence of safeguards guarantee that funds will arrive immediately. The configured limits, queue, and actual execution all need to be considered together.
There is also a recovery path worth explaining separately. The Address Scheme document states that, in addition to normal spending, the script allows the MPC committee to spend funds on its own after a 60-day relative timelock, once a UTXO has been confirmed. A UTXO can be understood as an on-chain output that has not yet been spent. This design provides an alternative recovery path in situations such as the loss of the Guardian key. The timer starts when that output is confirmed, not when a user submits a withdrawal request. This does not give every user recovery rights, nor is it a service commitment that “all withdrawals will take no more than 60 days.”
So when assessing whether Hashi delivers on its promises, I would look not only at how much BTC can be deposited, but also at whether normal withdrawals work smoothly, how transparently rate limits are disclosed, and how recovery and committee handover are verified if the Guardian fails. Adding a security check and allowing users to retain full unilateral control are two different arrangements. Whether this setup is suitable for a particular type of funds depends on all of these exit conditions.
This assessment is based on the currently available public design documents, whose pages are still marked Testnet; they do not support a claim that the mainnet is already operating at scale under the same parameters. The October 8 announcement described a phased rollout this month. The system will need to be reassessed against actual deployments and real withdrawal records as they become available. A demonstration of 40.6 million TPS and capital commitments exceeding $500 million are no substitute for that. The additional takeaway for now is that validating Hashi’s value requires looking both at whether activity can come in and whether assets can exit according to the rules under normal and abnormal conditions. Sources: Mysten Labs’ Hashi User Flows, Guardian, Limiter, and Address Scheme documents; the accompanying illustration is a schematic of the mechanism.