This is the Monday deep-dive — one mechanism, examined closely.

Suppose a trading agent needs to post collateral, and the asset it wants to post is Bitcoin. That is a reasonable thing to want: BTC is the deepest, most liquid collateral asset in crypto. The problem is that Bitcoin the chain cannot run the contract logic a collateralized position needs — no expressive smart contracts, no objects, no state machine watching a position over time. So the collateral lives on one chain and the obligation it backs lives on another.

The standard fix is to wrap the Bitcoin. We think there is a better-shaped one, and it is worth walking through carefully.

What wrapping actually costs you

Wrapping BTC means handing it to a custodian — or a federation, or a bridge contract — that holds the real Bitcoin and mints a token on the destination chain representing a claim on it. Once you hold the token, you can use it as collateral anywhere that chain's contracts run.

You have also done three things you may not have meant to do. You converted a bearer asset into a claim against an intermediary. You contributed to a honeypot — the locked BTC pile that backs every wrapped token is a single, standing, valuable target. And you made your collateral's integrity depend on something an agent has no good way to audit: the ongoing honesty and solvency of whoever holds the real coins.

For a trustless settlement system, that is the wrong trade. The whole point of settling without a custodian is undone the moment the collateral backing the settlement is itself custodial.

The design: keep the Bitcoin on Bitcoin

A collateral vault takes the opposite approach. The Bitcoin never moves to another chain and is never represented by a minted token. It stays as native BTC, locked in a script on the Bitcoin chain itself. What crosses chains is not the asset — it is a single piece of information: the hash of a secret.

Here is the shape of it. On Bitcoin, the collateral is locked into a P2WSH output — a pay-to-witness-script-hash output whose redeem script is a hash-time-lock. The script has two spend paths: a hashlock path, spendable by presenting the preimage of a specific hash, and a timelock path, spendable by the original depositor after a block-height deadline. This is the same HTLC construction used for atomic swaps, applied here to a longer-lived position rather than an instant exchange.

On the other chain — for us, Sui, where our Move contracts are deployed — lives the obligation the collateral backs: a forward to deliver, a loan to repay, a leg of a multi-step trade. The Sui-side contract is written so that the outcome of that obligation controls who learns the preimage, and when.

The two chains are coupled by exactly one shared value: the hash. Bitcoin Script cannot read Sui state, and Sui cannot read Bitcoin's UTXO set. But both can agree, in advance, on a hash — and the preimage of that hash becomes the single key that resolves the position on both sides at once.

The outcome paths

A vault has three ways to end, and all three are mechanical.

If the obligor performs — delivers the forward, repays the loan — the protocol releases the preimage along the agreed path, and the BTC settles to whoever the performance entitles. The pattern is reveal-to-claim: the act of claiming on one side publishes the secret that resolves the other.

If the obligor defaults, the hashlock path routes the BTC to the counterparty as the agreed remedy. The collateral does exactly what collateral is for — it makes the counterparty whole without anyone needing to chase the defaulter through courts or reputation.

If nothing happens — the position is simply abandoned — the timelock path returns the BTC to the depositor after the deadline. No counterparty, no protocol, and no custodian can hold the coins past that block height. The refund is enforced by Bitcoin consensus, not by anyone's cooperation.

In every path, the BTC was native Bitcoin the whole time, and no third party ever had the unilateral ability to move it.

What the vault deliberately does not do

A vault is not a margin account, and it is worth being blunt about that. Bitcoin Script has no access to a price feed, and we are not going to pretend otherwise by smuggling an oracle into the design. That means the vault cannot do a real-time margin call — it cannot watch a price and liquidate the instant a collateral ratio is breached. Its resolution is discrete: it triggers on performance, on default, or on a deadline, not on a continuous price.

For a large class of agent-to-agent use cases that is fine, because the obligation itself is discrete — a forward with a fixed delivery date, a fixed-term loan, a bonded commitment. For a position that genuinely needs continuous mark-to-market, a hash-time-locked vault is the wrong tool, and we would say so rather than oversell it.

Where this sits for an agent

For an autonomous agent, none of the above should be hand-managed. Watching a P2WSH output, coordinating two timelocks across chains with very different block times, constructing the witness needed to spend a hashlock path — that is exactly the kind of work that belongs behind a tool call. Our MCP server (hashlock-tech/mcp, scoped — six tools) exists so an agent reasons about the position rather than the plumbing: it commits to a hash, funds a leg, checks status, and lets the protocol handle the script-level mechanics. MCP is the open protocol Anthropic introduced for connecting models to external systems; a vault is just another set of tool calls on that surface.

The honest limits

This is a design, and it deserves a straight status report. The Bitcoin P2WSH HTLC is validated on signet — Bitcoin's test network — with mainnet still pending. The Sui contracts are deployed and CLI-tested, with gateway wiring in progress. The only place atomic settlement is live end-to-end today is Ethereum mainnet. So a BTC collateral vault is a design we are building toward, not a button you can press this morning — and we would rather state that plainly than blur it.

The tradeoffs are real even once it ships. Bitcoin's roughly ten-minute blocks make timeout windows coarse: you cannot set a tight, precise deadline the way you can on a fast chain, and the cross-chain timeout coordination — the destination chain's deadline has to sit safely inside Bitcoin's — has to be conservative by construction. Collateral is locked and idle for the life of the position. And the model assumes the hash function holds. These are the costs of removing the custodian. We think they are worth paying for the class of positions a vault is meant for. They are still costs.

The question

Wrapped BTC made Bitcoin usable everywhere by making it custodial everywhere. The bet behind a collateral vault is that you can keep most of that usefulness — Bitcoin backing an obligation on a chain that can actually reason about it — without the custodian, by moving a hash instead of the coins.

So here is the question for anyone building agent-side collateral logic: when your agent posts Bitcoin as collateral, do you know exactly who can move those coins — and is the honest answer "only the agent, and only along paths the agent agreed to in advance"?

---

Hashlock Markets — atomic settlement for the agent economy. Sealed-bid RFQ + HTLC settlement, fused into one operation. No bridges, no custodians.

• Protocol: https://hashlock.markets?utm_source=devto&utm_medium=referral&utm_campaign=2026-05-25-btc-collateral-vaults
• MCP server (source): https://github.com/Hashlock-Tech/hashlock-mcp
• The underlying mechanism design is written up in a working paper on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722