Hashi Reworks the Trust Model Behind Bitcoin Bridges

A wrapped Bitcoin asset can look decentralized once it appears on another blockchain. The token moves through smart contracts, users can trade it without asking permission, and every transfer is visible. But the harder question sits one layer below the interface: who can authorize movement of the actual Bitcoin that backs it?

That is where many bridge designs become less decentralized than they first appear. The destination token may be onchain, while control of the source-chain reserves still depends on a custodian, a federation, or a relatively small group of signers. Hashi’s bet is not that those trust assumptions can disappear. It is that they can be distributed, constrained and made easier to inspect.

Hashi is a Sui-native system for turning native Bitcoin into programmable collateral on Sui. The BTC remains on the Bitcoin network, while a corresponding asset on Sui can be used inside lending markets and other applications. Hashi is currently on Sui devnet, and its documentation describes the architecture as a living design rather than a finalized mainnet system.

The bridge is only as decentralized as its signers

Bridge security is often discussed as if it were mainly a smart-contract problem. Contracts matter, but they do not answer the most important custody question: what combination of people, machines or keys can move the reserve?

Hashi draws its operating committee from Sui validators that choose to participate and run separate Hashi infrastructure. Their voting weight follows stake, giving the protocol a committee that can change as the validator set changes rather than relying on a permanent list of companies.

When a user deposits BTC, the funds go to a unique Bitcoin address associated with that user’s Sui address. According to the documented deposit flow, Hashi operators monitor Bitcoin, verify the deposit and reach the required agreement before the corresponding hBTC is created on Sui. The original BTC does not cross chains; it remains in Bitcoin UTXOs controlled by Hashi’s spending rules.

That distinction matters. hBTC is the programmable representation, but redemption still depends on the source-chain system being able to produce a valid Bitcoin transaction. Hashi therefore separates Sui-side approval from Bitcoin-side signing instead of treating minting and custody as the same problem.

The model gives applications something they cannot get from Bitcoin alone: an asset that can participate in smart-contract workflows while remaining redeemable for native BTC. That is the commercial reason the infrastructure exists. The security question is whether the mechanism connecting those two environments is more resilient than the centralized balance sheets it is meant to replace.

One key, split across a committee

Hashi uses distributed key generation and threshold Schnorr signing so that committee members hold shares of the Bitcoin signing key rather than one operator holding the complete secret. Enough participating weight must cooperate to produce the committee’s signature, but no single validator can independently sign a withdrawal.

This is the most important departure from a conventional custodian. Compromising one server, one company or one key share should not be enough to move the reserve. Committee changes also require the signing shares to be redistributed, allowing the operators behind the key to change without replacing the public key controlling existing deposits.

Hashi adds a second barrier through a separate guardian. Under the normal Taproot spending path, moving BTC requires both the committee’s threshold signature and the guardian’s signature. The guardian cannot spend by itself, and the committee cannot use the normal path without the guardian.

The guardian also limits the pace of withdrawals. Instead of allowing every otherwise valid request to leave immediately, a token-bucket limiter can slow aggregate outflows until capacity replenishes. That turns the guardian into more than another key holder: it is an independent policy layer intended to make a sudden reserve drain harder even if the committee side is compromised.

That defense comes with a clear tradeoff. If the guardian is unavailable, misconfigured or refuses to sign, legitimate withdrawals can be delayed. Hashi addresses permanent guardian failure with a recovery branch that lets the committee spend matured UTXOs without the guardian after a 60-day relative timelock. The delay is deliberate: the fallback protects recoverability without turning the guardian into a check that can be bypassed immediately.

Distributed is not the same as trustless

Hashi still has trust assumptions. Users depend on participating validators remaining available, the MPC implementation behaving correctly, the guardian and its policies operating as intended, Sui contracts enforcing the right state transitions, and Hashi nodes observing Bitcoin accurately. Committee reconfiguration and operational security also become part of the custody model.

Those dependencies do not make the design meaningless. They make the word “trustless” the wrong test. The relevant comparison is whether control is concentrated in one balance sheet or signer, or divided across independent systems that must agree before reserves can move.

Natsai is participating in Hashi testnet operations, which exposes the less visible side of that model: operators need synchronized Bitcoin and Sui infrastructure, MPC services, secure key material, backups and monitoring. The protocol may make custody programmable, but the security promise still has to be delivered by production systems that remain online and behave predictably.

For investors and builders, the opportunity is straightforward. Bitcoin can become useful inside programmable credit and collateral markets without being sold or represented by an opaque corporate liability. The risk is equally straightforward: the architecture is still pre-mainnet, its parameters can change, and distributed custody is only as strong as the software, incentives and operators behind it.

Hashi’s contribution is not a claim that Bitcoin bridging has become trust-free. It is a design that makes custody authority harder to concentrate, harder to exercise unilaterally and easier to reason about. For any Bitcoin-backed asset, that is the question that matters most: not how decentralized the token looks after minting, but who can authorize movement of the Bitcoin underneath it.