Baris Sozen

Posted on May 9 Edited on Oct 31

FAQ: Can my Bitcoin balance settle a trade on Solana, without wrapping it?

#mcp #ai #cryptocurrency #blockchain

A short FAQ on settling a native BTC leg against SOL or an SPL token, with no wrapped token in the middle.

Update, October 2026. This post was first published in May 2026. It has been revised to match the product as it is live today: six mainnet chains (Bitcoin, Ethereum, TRON, Solana, Base, Robinhood Chain), API key authentication, and the current MCP tool set. Current reference: https://docs.hashlock.markets

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 Solana: say, sell some BTC into SOL, or into USDC on Solana. The default answer in 2025 was "wrap it." In 2026 there is a better one.

Below is the short FAQ.

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

Right. That is the whole problem.

Bitcoin Script can hold value, lock value, time-lock value, and (with an HTLC script) release value against a hash preimage. What it cannot do is reason about what is happening on another chain. So if you want to use BTC inside a trade whose counterparty asset is on Solana or Ethereum, you need some link between "BTC exists on Bitcoin" and "the other side of the trade can rely on that."

There are two ways to build that link: move the BTC, or lock the BTC under a condition the other chain can share.

Wrapped BTC moves it. An HTLC pair shares the condition.

Q2. What is actually wrong with wrapped BTC?

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

Custody risk concentrates. The bridge or multisig holds a large pooled BTC reserve. Historically, bridges are where the eight-figure exploits happen. The exploit does not return your BTC; it leaves you a worthless IOU on a chain whose ledger you did not choose.
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.
Reversibility is asymmetric. Unwrapping is not always available, is sometimes throttled, and is sometimes KYC-gated. The agent that wrapped does not always control the unwrap path.

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

Q3. So how does Hashlock Markets settle BTC against a Solana asset without wrapping?

The short version: the BTC stays on Bitcoin. Nothing representing it is minted anywhere. Instead, both legs of the trade are locked under the same hash, one on each chain.

Three pieces:

An HTLC on Bitcoin. The BTC leg is a P2WSH script address with two branches: claim with the receiver's signature plus a preimage whose OP_SHA256 matches the hashlock, or refund with the sender's signature after the timelock (OP_CHECKLOCKTIMEVERIFY). Nothing has been wrapped; nothing has left Bitcoin.
An HTLC on Solana. The other leg (SOL, or a classic SPL token such as USDC) sits in an escrow held by the Hashlock HTLC program on Solana, in a PDA derived from the agreed terms. An escrow funded on any other terms is a different address. Token-2022 mints are not supported.
One secret. Both escrows are keyed to sha256(secret), with a 32-byte secret. Bitcoin Script has OP_SHA256 but no keccak, which is why the protocol uses sha256 on every chain: one secret opens a Bitcoin P2WSH escrow and a Solana escrow alike.

Whoever reveals the preimage to claim one leg makes the other leg claimable. Whoever does not claim in time gets refunded. The atomicity is the same atomicity HTLCs have always given you. There is no oracle, no relayer and no attestation network in the middle: the only thing shared across the two chains is the hash.

Q4. Who funds first, and why does the order matter?

The timelocks are asymmetric on purpose, so nobody holds a free option on the trade.

The initiator generates the secret locally, sends only the hashlock, and funds the long leg. The counterparty funds the short leg. The initiator reveals the secret by claiming the short leg, and the counterparty then needs time to use that secret on the long leg before the initiator could refund it. If the timelocks were equal or reversed, the initiator could wait, claim at the last moment and refund their own leg.

For a BTC to Solana swap the numbers are fixed by chain: the Bitcoin leg is the long leg at 24 hours, the Solana leg is the short leg at 4 hours. Timelocks are set when the swap is created and are absolute times; swap_status shows them per leg.

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

Neither. The Solana-side counterparty is giving a Solana-native asset (SOL or an SPL token) and receiving the right to claim BTC on Bitcoin, by presenting the same preimage that was revealed on Solana. They are not receiving wrapped BTC. The BTC moves once, on Bitcoin, from your P2WSH escrow to their key.

Trust-wise: the BTC sitting on Bitcoin is yours until the secret is revealed. Once it is, the claim pays only the fixed recipient, and the refund pays only the funder after the timelock. 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; here it routes 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: keep at least 30 percent of NAV in native BTC; rebalance into SOL or USDC on Solana 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 a Solana-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 Hashlock Markets, the agent's flow looks like:

Post an RFQ: give BTC@bitcoin, want USDC@solana (or SOL@solana). Makers answer with sealed quotes; no public price book.
Agree terms in the negotiation thread. As the initiator, the agent sends its hashlock with the accept.
Set a settlement address per leg. On the Bitcoin leg this is a compressed public key; the server derives the P2WSH once both keys are set. On the Solana leg it is a Solana address.
Fund the Bitcoin leg (the long leg). It counts as funded after 3 confirmations, roughly 30 minutes. The maker funds the Solana leg after that; it counts after finalized commitment, about 15 seconds.
Claim the Solana leg with the secret. The maker claims the Bitcoin leg with the same secret and their own signature. Either both legs settle, or both refund after their timelocks.

The treasury never held a synthetic. The agent never gave custody to anyone. The BTC was on Bitcoin the entire time.

Q7. What are the tradeoffs you should know about?

Three honest ones:

Latency. A Bitcoin HTLC needs Bitcoin confirmations to be safe. Solana finalizes in seconds; Bitcoin does not. So a BTC-leg trade is not a sub-second trade. Expect the Bitcoin funding to take three blocks, each about ten minutes on average and sometimes much longer. It is an OTC instrument by nature.
Liquidity is bilateral. Sealed RFQ means there is no order book to walk. If no counterparty quotes, no trade. For BTC to SOL in size, the counterparty universe is smaller than for, say, ETH to USDC; expect that.
Bitcoin claims are manual. On Solana, and on every other non-Bitcoin chain, Hashlock's keeper claims the leg to its fixed recipient once the secret is public, so the receiver does not have to. A Bitcoin claim needs the receiver's own signature, so whoever receives BTC must claim it themselves, within the timelock. ## Q8. How do I actually try it?

Hashlock Markets is live on mainnet across Bitcoin, Ethereum, TRON, Solana, Base and Robinhood Chain. The MCP server exposes the whole loop (RFQ, quote, negotiate, address, fund, claim, refund) as tools any LLM-driven agent can call.

Hosted: add one URL to your MCP client and approve with a wallet signature over OAuth; the server returns unsigned transactions and you keep the preimage.

https://hashlock.markets/mcp

Clients that do not speak OAuth send Authorization: Bearer hk_live_... (keys expire after 90 days).

Local, for an agent that signs and settles on its own with its own keys:

{
  "mcpServers": {
    "hashlock": {
      "command": "npx",
      "args": ["-y", "@hashlock-tech/mcp"],
      "env": {
        "HASHLOCK_API_URL": "https://hashlock.markets/api",
        "HASHLOCK_EVM_KEY": "0x<agent EVM key>",
        "HASHLOCK_TRON_KEY": "<agent TRON key, 64-hex (optional)>",
        "HASHLOCK_BTC_KEY": "<agent BTC WIF (optional)>",
        "HASHLOCK_SOLANA_KEY": "<agent Solana key, base58 (optional)>"
      }
    }
  }
}

For a BTC to Solana swap, set HASHLOCK_BTC_KEY and HASHLOCK_SOLANA_KEY. With a key for each chain a swap touches, the agent can run the whole loop with no human: create_rfq / respond_to_rfq, negotiate (accept), set_settlement_address, fund_leg, claim_leg.

The taker pays a protocol fee on top of the leg it funds, in that leg's asset; it is shown before you commit and the maker never pays.

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

Docs, settlement details per chain, and the MCP integration: https://docs.hashlock.markets
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Full protocol spec: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

What is the case where you would rather hold a wrapped BTC IOU than a native BTC leg in an atomic swap? What does the wrapped version give you that this does not?

DEV Community