DEV Community

Baris Sozen
Baris Sozen

Posted on

FAQ: Can my Bitcoin balance be collateral for a trade settled on Sui — without wrapping it?

#mcp #ai #cryptocurrency #blockchain

This question keeps coming up from people building agent treasuries. The agent holds native BTC. It wants to do a trade whose other leg lives on Sui — say, sell some BTC into ETH, or use BTC as collateral for an SUI-denominated forward. The default answer in 2025 was "wrap it." In 2026 there's a better one.

Below is the short FAQ.

Q1. Why is this even a question? Bitcoin is just on Bitcoin.

Right — that's the whole problem.

Bitcoin script can hold value, lock value, time-lock value, and (with HTLC-style scripts) release value against a hash preimage. What it cannot do is reason about what's happening on another chain. So if you want to use BTC inside a trade whose counterparty asset is on Sui or Ethereum, you need a bridge between "BTC exists on Bitcoin" and "a smart contract on the other chain knows it exists."

There are two ways to build that bridge: move the BTC, or describe the BTC.

Wrapped BTC moves it. Hashi describes it.

Q2. What's actually wrong with wrapped BTC?

Wrapped BTC (WBTC, BTCB, tBTC, hBTC, etc.) is a custodial or semi-custodial IOU. You send your BTC to a custodian or threshold-signature group, and the destination chain mints a token that says "this represents 1 BTC." It's a perfectly fine instrument when the bridge is healthy. Three things make it a problem for serious counterparties:

  1. Custody risk concentrates. The bridge or multisig holds a large pooled BTC reserve. Historically, bridges are where the eight-figure exploits happen. The exploit doesn't return your BTC; it returns a worthless IOU on a chain whose ledger you didn't choose.
  2. The wrapped token is the trade asset. When you settle a swap on the destination chain, the asset that changes hands is the IOU, not the underlying BTC. If the IOU depegs (which has happened), the post-trade economics change.
  3. Reversibility is asymmetric. Unwrapping is not always available, throttled, or KYC-gated. The agent that wrapped doesn't always control the unwrap path.

For an autonomous agent treasury, "I trust this bridge" is exactly the assumption you're trying to take out of the loop.

Q3. So how does Hashlock Markets route BTC into a Sui-side trade without wrapping?

The short version: the BTC stays on Bitcoin. What moves around inside the trade is a Sui-side reference to it.

Three pieces:

  1. A vault commitment on Bitcoin. The trader (or their agent) locks the BTC under an HTLC-style script on Bitcoin itself. The script binds the BTC to a specific trade's hashlock and a specific timeout. Nothing has been wrapped; nothing has left Bitcoin.
  2. A read-only proof on Sui. Hashi (the protocol — @hashi_io) provides cryptographically-attested cross-chain state. A Sui-side contract reads "this Bitcoin UTXO is locked under hashlock H until block N" without trusting any single relayer. The proof is what makes the trade legible to a Sui-side counterparty.
  3. An HTLC on Sui. The other leg of the trade — say SUI, or any Sui-native token, or a Move-wrapped stablecoin — sits in an HTLC keyed to the same hashlock H. Two HTLCs, one secret, two chains.

Whoever reveals the preimage to claim one leg makes the other leg claimable. Whoever doesn't claim in time gets refunded. The atomicity is the same atomicity HTLCs have always given you; the new piece is a reliable cross-chain view that the BTC leg actually exists and is locked.

Q4. What does Hashi actually do here?

Hashi is the read layer. Its job is to answer the question "is the BTC leg still locked?" without asking that question of any one party.

It does that by aggregating attestations across multiple oracles and bridges and only treating a piece of cross-chain state as canonical when independent reporters agree. For a BTC → Sui trade, the Sui-side HTLC contract checks Hashi's aggregated state before honoring a claim. If Hashi says "the BTC vault is no longer in the locked state" (e.g. the timeout passed and the BTC was refunded on Bitcoin), the Sui side will not pay out. If Hashi says "the BTC vault is locked, hashlock H, timeout N," and a Sui-side claimer presents the preimage, the Sui side pays out — and that same preimage unlocks the BTC leg back on Bitcoin.

It's the same security model as a single-chain HTLC. The only added trust assumption is "more than one independent attestor would have to be lying about Bitcoin state." That's a very different shape of risk than "one bridge custodies a pile of BTC."

Q5. So is the asset that lands on Sui actually my BTC, or a representation of it?

Architecturally, the Sui-side counterparty is buying or providing a Sui-native asset (SUI, a Move stablecoin, an LST, whatever) against your locked BTC vault. They are not receiving wrapped BTC. They are receiving the right to claim BTC on Bitcoin, by virtue of revealing the preimage on Sui.

Trust-wise: the BTC sitting on Bitcoin is yours until the preimage is revealed. The preimage is revealed by your counterparty when they claim their own leg. That single reveal triggers both legs. There is no point at which someone else holds your BTC.

This is the same pattern Lightning channels use to route a payment across nodes; we are using it to route a single OTC trade across chains.

Q6. What does this actually look like for an agent treasury?

Imagine the agent's policy is something like: maintain ≥30% of NAV in native BTC; rebalance into ETH or SUI when the basis blows out; never custody a wrapped synthetic.

Today, with most stacks, the third clause is a problem. The moment the agent wants to sell BTC into an EVM-side or Sui-side asset, it has to wrap, which violates the no-synthetic rule, or sell on a CEX, which adds a custody hop and KYC.

With BTC Collateral Vaults, the agent's flow looks like:

  • Lock the slice of BTC it intends to trade into a Hashlock vault on Bitcoin (HTLC, hashlock H, timeout T).
  • Open an RFQ on Hashlock Markets for the Sui-side asset it wants. Counterparties bid sealed.
  • Best bid wins. The Sui-side leg is funded into a Sui HTLC keyed to H.
  • Either the swap completes (preimage revealed, both legs settle, atomic) or it expires (both legs refund, atomic).

The treasury never held a synthetic. The agent never gave custody to anyone. The BTC was on Bitcoin the entire time except for the moment of redemption.

Q7. What are the tradeoffs you should know about?

Three honest ones:

  1. Latency. A Bitcoin HTLC needs Bitcoin confirmations to be safe. Sui finalizes in seconds; Bitcoin doesn't. So a BTC-collateralized trade is not a sub-second trade. It's a forward / OTC instrument by nature, which is why it pairs naturally with the T+24h Forward OTC primitive Hashlock Markets shipped on the Sui side.
  2. Liquidity is bilateral. Sealed-bid RFQ means there's no order book to walk. If no counterparty quotes, no trade. For BTC → SUI in size, the counterparty universe is smaller than for, say, ETH → USDC; expect that.
  3. Hashi is a trust assumption, just a much smaller one than a bridge. You are trusting that the multi-oracle attestation network would not collude and that no single oracle compromise would flip Bitcoin state on Sui. That's a known, bounded trust surface, and it is much narrower than "one bridge holds the BTC."

Q8. How do I actually try it?

The reference deployments cover ETH, BTC, and SUI today. Roadmap chains are Base, Arbitrum, Solana, and TON. The MCP server exposes the create-RFQ / respond-RFQ / create-HTLC / withdraw / refund flow as tools any LLM-driven agent can call directly. Install in a Claude Desktop or Cursor config:

{
  "mcpServers": {
    "hashlock": {
      "command": "npx",
      "args": ["-y", "hashlock-tech/mcp"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

(The package on npm is the scoped one under hashlock-tech; calling it that way avoids accidental @-mentions in social copy.)

Fee on the deployed contracts is 7 bps, with up to a 50% rebate via the execution-rewards path, so the effective rate sits in the 3.5–7 bps band depending on settlement timeliness. That's well under the 8–10 bps OTC desks typically charge for cross-chain BTC-leg trades, and the spread reflects the difference between "we run a desk" and "the protocol runs the desk."

If you're holding native BTC inside an autonomous treasury and have been waiting for a trade path that doesn't force you to wrap, this is the primitive built for that case.

Spec, reference contracts, and the MCP integration: https://hashlock.markets/docs#btc-collateral
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Full protocol spec: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

What's the case where you'd rather hold a wrapped BTC IOU than a native-BTC vault — what does the wrapped version give you that this doesn't?

Top comments (0)