Bitcoin Never Leaves the Chain: The Signer Nobody Listed

On 8 October, at Sui Basecamp, the Sui Foundation announced that Hashi mainnet goes live this month in a phased rollout, carrying more than $500 million in committed capital from a coalition of over 20 firms including BitGo, Bullish, Cumberland, FalconX, Ledger and, as of that announcement, Anchorage Digital. The product it is launching has one sentence at its centre, and the sentence is a good one: your Bitcoin never leaves the Bitcoin network.

That sentence is true. I checked it, and I could not break it. What I could break is the sentence sitting four paragraphs below it on the same page, which reads: “Two trust assumptions: (1) the Sui validator set and (2) the smart contract governing the loan. Nothing else.”

There is something else. There are several somethings else, one of them answers an unauthenticated HTTP request, and I spent this morning asking it questions.

TL;DR

• Sui’s Hashi lets you lock native BTC on Bitcoin and mint hBTC on Sui. The product page claims exactly two trust assumptions and “nothing else”; the spec, the launch announcement and the live deployment all describe more.
• Every normal spend of a Hashi deposit needs a 2-of-2 signature: the MPC committee plus a Guardian. The Guardian is a cloud enclave at a fixed URL. It answered my unauthenticated probe and returned its own Bitcoin public key, which matches the key stored in Sui’s on-chain Hashi config byte for byte.
• The live committee is 60 members out of 112 active Sui testnet validators, not “the Sui validator set”. The deployed emergency-pause threshold is 500 basis points and the unpause threshold is 6,667, so on today’s weights one member can pause the protocol and seventeen are needed to restart it.
• The deployed collusion parameter is mpc_max_faulty_in_basis_points = 3333, the weakest value in the range the docs reserve. Seven of the sixty members reach it.
• Each committee member screens your withdrawal destination with its own TRM Labs account and its own risk tolerance, so your exit is a vote, not a signature you control.
• None of this is expressible on Bitcoin. A Hashi deposit is a Taproot output with a nothing-up-my-sleeve internal key, so the ledger holding your coin records where it is and never who may move it.

Give Hashi its due first, because it has earned it

Hashi is the best-documented bridge-shaped thing I have read this year, and calling it a bridge is already unfair to it. You send native BTC to a Bitcoin address derived uniquely from your Sui address. Committee members watch the Bitcoin chain, wait six confirmations, vote, and mint hBTC on Sui against your deposit. You use that hBTC as collateral in Sui lending markets. When you want out, you burn it, and a Bitcoin transaction pays native BTC to an address you nominate.

The economics are unusually clean. Hashi charges no protocol fee at all, deposits are free, and a withdrawal pays only the Bitcoin miner fee, deducted from your output rather than from the pool so that your exit cost is not socialised across everyone who has not left yet. Certora formally verified the Move contracts. CommonPrefix reviewed the MPC cryptography. The TypeScript SDK carries a blunt warning that it is pre-1.0 and not production-ready, which is more honesty than most mainnet launches manage.

I also checked their arithmetic rather than taking it on trust, because published constants are exactly where a document quietly stops being true. The 60-day recovery timelock is specified as the BIP-68 sequence 0x0040278D, which the docs say is 4,204,429, being the time-based type bit 1 << 22 combined with 10,125 units of 512 seconds. Sixty days is 5,184,000 seconds, which is 10,125 units exactly. 4,194,304 plus 10,125 is 4,204,429, which is 0x0040278D. Their 4,320-block figure for 30 days is right too. Every number I recomputed came back identical, which is rarer than it should be.

So this is not a post about a sloppy protocol. It is a post about which document people read.

Three documents, one organisation, one week

The Sui Foundation’s launch announcement says this, plainly: “BTC collateral is secured through a 2-of-2 multisig structure requiring authorization from Hashi validators and the guardian. The Guardian Layer provides an additional check before BTC leaves the system and can slow or stop suspicious collateral movement.”

The design spec goes further and is better still. The Hashi committee is “a subset of the Sui validator set”, with registration optional. The Guardian is “a second signatory on the managed Bitcoin deposits”, implemented as “a cloud enclave that enforces policies independently of the MPC protocols”. The withdrawal limiter is a token bucket the Guardian enforces when it co-signs, and sanctions screening is done by each member against its own vendor account.

And the product page, the one with the big type and the code sample, says there are two trust assumptions and nothing else. Nobody is hiding anything here. The complete, honest answer was published by the same organisation, on the same domain, in the same week. It is simply not in the document that does the persuading. That is a different failure from the ones this series usually finds, and I think it is a more common one.

I asked the second signer directly

The Guardian is not an abstraction. Its address is a string in Sui’s on-chain Hashi configuration object, right next to the deposit minimum. I read that object from two independent Sui testnet endpoints, which agreed, and then I called the Guardian myself. It answered on the first try, unauthenticated, on 9 October:

{"limiter":{"state":{"numTokensAvailableSats":"999999671797",
"lastUpdatedAtSecs":"1791534982","nextSeq":"101"},
"config":{"refillRateSatsPerSec":"11574074",
"maxBucketCapacitySats":"1000000000000"}},
"gitRevision":"0873917ea3daf0ac99e123215808ad602eb5fafb",
"committeeEpoch":"1247",
"btcPubkey":"7a708f475562163946faaa1626e65c8907ee1007a1916e7415940fdc33fe7cd3",
"signingPubKey":"677cc02b0f7c81c866edafff49a7a0f127bb7fae148ea1b2e975aa0695c0b9f1"}

Two cross-checks, both of which passed. The btcPubkey the Guardian reports is byte-for-byte the guardian_btc_public_key stored in the Hashi object on Sui. Its committeeEpoch of 1247 matches the committee epoch recorded in that same object. As a control, I called the node-facing Guardian endpoint, which is documented as serving only current or pending committee members presenting a registered TLS client certificate, and the connection died exactly as the documentation says it should. The public one talks. The private one does not. Both behaved as specified.

Read the limiter numbers, because they are the shape of the thing. Maximum bucket capacity is 1,000,000,000,000 satoshis, which is 10,000 BTC, about $824 million at this morning’s $82,472. The refill rate of 11,574,074 satoshis per second is not an arbitrary figure: multiply it by 86,400 and you get the capacity back, so the bucket is sized to refill exactly once per day. A withdrawal larger than the bucket is not slowed. The spec says it “is skipped until the limit is raised”, and its owner may cancel it. There is a size of exit that simply does not have a queue position.

The nextSeq of 101 says the Guardian has written a hundred signed session records, and the bucket was 328,203 satoshis short of full, the footprint of a small withdrawal moments earlier. This is a test deployment, so those counts are small by construction. The architecture is not.

One member can pause it. Seventeen are needed to restart it.

The same object carries the committee and the governance thresholds, so I read all of it. On testnet, at epoch 1247:

Reading	Value
Committee members	60
Active Sui testnet validators	112
Committee share of operators	53.6%
Committee share of network voting power	65.81%
governance_emergency_pause_threshold_bps	500
governance_emergency_unpause_threshold_bps	6667
mpc_max_faulty_in_basis_points	3333
withdrawal_cancellation_cooldown_ms	3600000

I matched all sixty committee addresses against the live validator set, and every one is a currently active testnet validator. Then I sorted them by weight. The largest single member holds 5.42% of the committee’s combined voting power, which clears the 500 basis point emergency pause threshold on its own. Clearing that pause again takes 6,667 basis points, which on the same weights is seventeen members acting together. Mysten Labs, which wrote Hashi, operates five of the sixty, carrying 20.85% of committee weight between them.

I want to be careful about what that does and does not mean, because it would be easy and wrong to make it sound like a trapdoor. A pause threshold far below the unpause threshold is a deliberate safety bias and it is the correct bias: you want the alarm easy to pull and the all-clear hard to declare. The docs are explicit that a pause refuses new requests while leaving cancellation and governance alive. This is competent design, not a backdoor.

But a competent design is still a design, and the question this series keeps asking is not “is it good” but “is it in the list”. A party that can stop your withdrawal with a single transaction is a trust assumption whether or not it would ever want to. It is not in the two.

The security parameter that is still a range

The MPC spec parametrises the protocol by two values. It operates while fewer than f of staking power is unresponsive, and it is secure while fewer than t of staking power is colluding. The spec then says, in the present tense, that in the first version t “is expected to be in the range of 33% to 50%” and f “in the range of 20% to 33%”.

The deployed value is readable, and it is mpc_max_faulty_in_basis_points = 3333. That is 33.33%, the bottom of the reserved range, the weakest setting the document contemplates. On the current committee weights, seven of the sixty members reach it between them.

Set that beside the product page’s summary of the same mechanism: “No single point of failure. Improbable collusion.” Both of those claims are defensible. Neither tells you the number is seven, and neither tells you the parameter is still written as a range in the specification, which means the honest reading is that it has not been finally decided. A security parameter expressed as an interval is not an assumption you are making. It is a question somebody else has not finished answering.

Your exit is screened by each signer separately

Here is the part that has the least to do with cryptography and the most to do with whether you get your Bitcoin back. From the spec on sanctioned addresses: “Each node operator screens with their own TRM Labs account.” Not the protocol’s account. Their own. With their own API key, their own configured risk tolerance, and, if they have not configured a key at all, no screening whatsoever.

Four things get screened. On deposit, the Bitcoin transaction coming in and the Sui address being credited. On withdrawal, the Bitcoin destination address and the Sui address that asked. A node declines to vote if the screened party is attributed to a High or Severe category, if the transfer raises an alert at that level, or, and this is the clause that matters operationally, if “TRM cannot screen the transfer, or rejects the request”. A vendor outage is indistinguishable from a refusal, from the outside.

Deposits and withdrawals are not symmetric either. A quorum can accept a deposit a member did not want, and that member must then treat the coins as the pool’s. A withdrawal has to be positively approved by a quorum before it is picked up at all. Add the hour-long cooldown before you may cancel your own request, the first-in-first-out queue that is explicitly “not a strict requirement”, and the 30,000 satoshi minimum, which at today’s price is $24.74 and below which a withdrawal cannot be made at all.

Your authority over your own Bitcoin, in this system, is the authority to file a request.

Bitcoin cannot tell you any of this, and that is the actual point

Every Hashi deposit address is Pay-to-Taproot with a two-leaf script tree. One leaf is the 2-of-2 between the committee key and the Guardian key. The other lets the committee key spend alone, 60 days after the output confirms, as an escape hatch if the Guardian key is ever lost. The internal key is the BIP-341 nothing-up-my-sleeve point with no known private key, which guarantees that every spend has to go through the script path.

Now consider what a stranger can read off the Bitcoin blockchain about one of those outputs before it is spent. A Taproot output is thirty-two bytes of tweaked public key. It does not say there are two leaves. It does not say one of them is a 2-of-2. It does not say a cloud enclave in a company’s infrastructure holds the second key, and it does not say that after 60 days it will not need to. The tree is a commitment, and a commitment reveals nothing until it is opened. The leaf becomes public at the moment somebody uses it, and not one second earlier.

So “Bitcoin never leaves the Bitcoin network” is completely true and almost entirely empty. The Bitcoin ledger is a record of location. It was never a record of authority. Your coin is exactly where they said it is, and the chain that proves it is there is structurally incapable of telling you who can move it, how many of them there are, or what has to be true about a sanctions vendor’s uptime for it to come home.

Why this is a new shape for the series

Eighty-nine instalments of this series have looked for the gap between what a proof covers and what somebody assumed it covered. This is the first one where the complete and honest answer was already written down by the same people who wrote the claim, and the gap sits between a specification and its own summary.

That makes it different from the near neighbours, and I want to name them rather than let them blur. In the eighty-second instalment the defect was tense: a protection described in the future, promised by a third party who had agreed to nothing. Here every party exists today and does its job on request. In the seventy-second an asset moved chains and silently swapped the properties it had inherited. Here the asset does not move at all, which is the selling point, and the unwritten properties change anyway. In the fifty-second a balance was true twice over because the chain has no field for exclusivity. This is the adjacent hole: the chain has no field for permission either.

The verification industry cannot close this one, and it is worth being clear about why. Proof of reserves would pass here. The coins are real, they are on Bitcoin, the address is derivable, the balance is auditable to the satoshi. Every instrument we have built points at quantity, and the thing you need to know is a spending policy that was never an on-chain fact in the first place.

What this means for a game, and for us

Picture a raffle on Sui with a prize denominated in hBTC. The draw itself can be genuinely provable: as we established last week, Sui ships native on-chain randomness as sui::random at reserved address 0x8, with a shared Random object no transaction can mutate. A well-built Sui raffle can tell a stranger who won and let them check it.

Then the winner tries to take it to Bitcoin. Now the prize is a queue position, a sanctions screen run separately by up to sixty operators, a co-signature from an enclave at a hostname, and a token bucket with a maximum size. Every one of those is reasonable. Not one of them is random, and not one of them is covered by the sentence that said the game was fair.

This is the uncomfortable half, and refusing to say it would make the series worthless: provable fairness has no vocabulary for the exit. A proof is a statement about a selection. It says who won. It has never said the prize can leave.

Satoshie runs on Base with Chainlink VRF, the proof is verified on-chain by the coordinator before the payout callback may act, and escrow, resolution and payout settle in a single transaction with no admin key that reaches a live draw. That closes the gap between winning and being paid, which is the gap we can close. It does not close this one, and we do not get to be smug about it, because our prizes are denominated in a dollar stablecoin whose issuer holds a freeze function. That is a second signer with a veto over a payout, and we have never listed it either. Naming it is not solving it. It is just the minimum.

Honest limits

Four, and they are real. First, everything I measured is the testnet deployment on Bitcoin signet, because mainnet is not live yet and the SDK still throws if you point it there. The mainnet committee, the mainnet Guardian and its limiter will be provisioned separately and their values are not public. Second, 60 of 112 validators is a test deployment’s participation rate, not a forecast; the spec expects more than 90% on mainnet and that may well happen. Third, I cannot tell from the object whether the governance thresholds are measured against committee weight or network weight, so treat “one member can pause it” as the committee-weighted reading and not as a claim about the Move code, which I did not read. Fourth, the Guardian’s limiter is a protection, and a post that only counts it as a risk is not being straight: a bucket that stops an attacker draining 10,000 BTC in an afternoon is worth having, and it is the same bucket either way.

Three questions worth asking of anything holding Bitcoin for you

1. How many separate parties must act for your coins to come back, and is that number in the marketing or only in the spec? If the two documents disagree, the spec is the product.
2. Which of those parties can refuse unilaterally, and what is the published threshold for undoing a refusal? An alarm anyone can pull and a committee is needed to silence is a good design and a disclosed liability.
3. If your withdrawal were declined, how would you find out why? “A vendor could not be reached” and “you were flagged” produce identical silence.

The picture at the top of this post is two padlocks, one on each of two doors, photographed from the only side anyone ever stands on. You can count them. That is the whole of what the photograph gives you, and it is more than a Taproot output gives you, because a padlock at least has the decency to hang on the outside where it can be seen. Hashi’s locks are real, they are well made, and they are committed to a hash. The coins never leave Bitcoin. Neither does anything that would tell you who is holding the keys.

📷 Photo by sq lim on Unsplash