advanced
+300 XP

Advanced Hashi

Compose hBTC into a real product โ€” PTB integration, relayed and gas-sponsored deposits, keeper-driven confirmation, and the production realities of shipping a Bitcoin on-ramp.

Lesson Syllabus

Composing hBTC in a PTB
๐Ÿช™

hBTC Is an Ordinary Coin

Hashi mints `hBTC` as a plain Sui coin โ€” 8 decimals, `Coin<BTC>` and `Balance<BTC>` like any other asset. Your Move code needs no Hashi-specific interface, no allow-list, no registration. That is the whole composability story: the bridge stops mattering the moment the coin exists, and everything you already know about moving coins on Sui applies unchanged.

โ›“๏ธ

Use It in the Same Block

Once hBTC sits in the user's wallet, one programmable transaction block can source it and hand it straight to your protocol. `tx.balance({ type, balance })` selects and merges the sender's hBTC coins at execution โ€” the same helper the SDK uses to fund a withdrawal. The user signs once, and the balance never sits idle between transactions.

๐Ÿ”

Custody Is Enforced, Not Promised

hBTC mints to the `recipient` address as an owned coin. Your app can move it only inside a transaction the user signs. Hashi itself has no admin cap anywhere โ€” minting needs a committee BLS certificate over the specific UTXO, and moving real BTC out needs both the MPC committee and the independent guardian. Custody is a property of the chain, not a line in your marketing copy.

Gasless and Human-Friendly
๐ŸŽซ

The Signer Is Not the Recipient

`deposit({ signer, txid, utxos, recipient })` keeps those two fields independent. Your relayer signs the Sui transaction and pays its gas; `recipient` becomes the UTXO's `derivation_path`, so hBTC mints straight to the user. They can arrive holding zero SUI and still end up with a coin. This is the single most valuable seam the SDK leaves open.

โฑ๏ธ

Let a Keeper Own the Clock

`deposit` and `confirm_deposit` are both permissionless โ€” only `approve_deposit` needs the committee certificate. So a keeper can watch `confirmableAtMs` from `view.depositStatus(digest)` and fire `confirm_deposit` the millisecond the 10-minute delay elapses. The user's last action becomes the Bitcoin send itself. Everything after that happens whether or not they keep the tab open.

๐Ÿ“Š

Render the Seventy Minutes

Six Bitcoin confirmations plus a 10-minute delay is roughly 70 minutes of apparent nothing. `waitForDeposit(digest)` polls every 15 seconds, and `view.depositStatus` gives you status, `approvalTimestampMs`, and `confirmableAtMs`. What it will not give you is Bitcoin confirmations โ€” the SDK never scans that chain. You supply those from mempool.space, an Esplora instance, or your own node.

Production Realities
๐ŸŽฏ

Give hBTC Somewhere To Go

A bridge token with no destination is churn: the user paid a miner fee, waited an hour, and got a balance that does nothing. Navi, Scallop, Suilend, and AlphaLend are day-one mainnet lending partners, so borrowing a stablecoin against BTC without selling it is the obvious first use. Decide the destination before you build the on-ramp, not after.

๐Ÿงฑ

The Friction You Cannot Remove

Be honest about the floor. The user must already hold BTC. The Bitcoin miner fee is paid in BTC on L1 and can never be sponsored. Both minimums sit at 30,000 sats. A withdrawal can be cancelled only by its owner, only after a one-hour cooldown, and never once it reaches processing โ€” by then the hBTC is already burned.

๐Ÿงช

Testnet Today, Mainnet Later

Hashi runs on Sui testnet against Bitcoin signet, and signet coins come from third-party faucets nobody on the team operates. Mainnet is not deployed and has no announced date; the SDK throws on a network it has no ids for. The contracts are audited by Asymptotic, Certora, and OtterSec. Read every limit at runtime โ€” all of them are governance parameters.