Protocol guide

Hashi, in plain English

Hashi lets BTC held on Bitcoin be represented as hBTC on Sui. It coordinates Bitcoin transactions, a validator committee, a Guardian, and Sui smart contracts. HashiScan does not move funds—it reads the evidence those systems produce and explains the current step.

Test networks only. The current deployment uses Bitcoin Signet and Sui Testnet. It is not ready for real BTC.

What is Hashi?

A two-way system between native BTC and hBTC on Sui.

Bitcoin, the Hashi committee, and Sui connected by deposit and withdrawal flows — BTC stays in a Hashi-managed Bitcoin UTXO pool while corresponding hBTC can be used on Sui. Withdrawing reverses the path.

BTC remains on Bitcoin

Deposits create real Bitcoin UTXOs. Hashi tracks those UTXOs as the backing pool used for future withdrawals.

hBTC exists on Sui

After a deposit passes protocol checks, the Sui contract mints the corresponding hBTC to the destination address.

No single approval is enough

Committee certificates, onchain rules, and separate Guardian/MPC signing paths govern the lifecycle.

How a deposit works

Why sending BTC does not mint hBTC immediately.

Four-stage Hashi deposit flow: request, verify and approve, safety delay, and mint — The live confirmation threshold, minimum amount, and safety delay are configuration values—not assumptions made by this diagram.

Send and request.A Sui address derives a unique Taproot deposit address. The user sends BTC there and records the Bitcoin UTXO in a Sui deposit request.
Verify and approve.Committee members wait for enough Bitcoin confirmations, perform their checks, and produce a quorum certificate.
Wait through the safety delay.Approval and minting are deliberately separated. Operators can pause the service if an approval looks faulty.
Mint hBTC.The contract re-checks the certificate and delay, mints hBTC, and adds the deposited UTXO to the managed pool.

How a withdrawal works

How hBTC is redeemed for native BTC.

Five-stage Hashi withdrawal flow from hBTC request to confirmed Bitcoin payment — Approved requests can share one Bitcoin transaction. Each request still receives its own destination output.

Request BTC.The user submits hBTC and a Bitcoin destination address to the Sui contract.
Approve the request.The protocol checks rate limits and the destination; a committee quorum certifies the request.
Build a Bitcoin transaction.A leader may batch approved requests, select pool UTXOs, calculate fees, outputs, and change, then commit the unsigned transaction on Sui.
Sign through two paths.The Guardian and threshold MPC committee each produce the required Schnorr signatures.
Broadcast and confirm.The signed transaction is sent to Bitcoin and monitored until it reaches the configured confirmation threshold.

How to read HashiScan

Use the explorer as an evidence map, not as a wallet.

Search an identifier

Paste a Sui transaction digest, Bitcoin txid, Hashi request ID, or Sui address.

Read the current phase

The timeline separates completed, current, pending, attention, and unknown states.

Open the evidence

Follow the external Bitcoin and Sui explorer links. Each live fact includes its source and observation time.

Open a real Testnet deposit →Read the data methodology Read the Hashi protocol docs ↗

Quick glossary

UTXO: A spendable Bitcoin output. Hashi tracks deposited UTXOs and later selects them for withdrawal transactions.
hBTC: The Sui-side representation issued after a Hashi deposit is approved and confirmed.
Quorum: Enough committee members agreeing to produce a valid certificate—not merely one member’s vote.
Guardian: A separate signing and policy-control path used alongside committee threshold signing for withdrawals.
Safety delay: A configurable pause between deposit approval and minting, allowing intervention before hBTC is issued.
Signet / Testnet: Public testing networks whose assets have no mainnet monetary value.