A trading agent agrees a price at 9am. Delivery is tomorrow. For the 24 hours in between, somebody is exposed: either the price moves and one side wants out, or one side simply doesn't show up to settle.
This is the oldest problem in market structure, and traditional finance solved it a long time ago — with a clearinghouse. A forward contract works because a central counterparty stands between the two parties, holds margin, and guarantees that the trade completes even if one side fails.
That solution doesn't transfer cleanly to autonomous agents. If you're building agents that trade — on top of an MCP server, inside a framework like LangChain or CrewAI, wherever — you eventually hit a case where the agent needs to commit to a trade now and settle it later. And the moment you reach for a forward, you've reintroduced exactly the trusted intermediary the rest of your stack was designed to avoid.
There's a way to get the forward without the clearinghouse. It's worth walking through, because it's a small idea with a large consequence.
What a forward actually needs
Strip a forward down to its mechanics and it asks for three things:
- A price, fixed now. Both parties agree terms today.
- A delivery window, in the future. Settlement happens at T+24h, T+48h, or whatever the two sides picked.
- A guarantee that both legs complete — or neither does. If one side vanishes, the other must not be left holding a half-finished trade.
The clearinghouse exists almost entirely to provide #3. It is a very expensive, heavily regulated answer to one question: who makes the trade whole if a counterparty fails?
For two agents on two different chains with no shared venue, that question has no good custodial answer. A centralized desk means both agents now trust the desk — and the desk can freeze, fail, or front-run. A bridge means trusting an optimistic settlement model: most bridges assume the far side will be made whole and rely on challenge windows to catch it if not. "Probably settled by tomorrow" is not a forward.
Why the naive on-chain version fails
The first instinct on-chain is to write an escrow contract. Agent A deposits the asset, the contract holds it until the delivery time, then releases it to Agent B against payment.
Look closely at "the contract holds it." Who can upgrade that contract? Who holds the admin key? Who decides what happens if the delivery oracle disagrees with one party? Every one of those questions is a custodian wearing a smart-contract costume. You haven't removed the trusted party — you've renamed it.
The fix is not a better escrow contract. It's to remove the holding step entirely.
The HTLC as a forward
A hash time-locked contract (HTLC) binds both legs of a trade to the same cryptographic secret and a timelock. The standard description of an HTLC emphasizes the atomic property: either both sides settle against the secret, or both sides refund after the timeout. No party can take one leg without releasing the other.
The piece that turns an atomic swap into a forward is the timelock itself. The timelock is not just a safety hatch — it is a programmable delivery window. Set it to 24 hours and you have described a T+24h forward in one parameter. Both legs are funded now, at the agreed price. Settlement can occur any time inside the window. If the window closes with the trade incomplete, both sides independently refund. No counterparty can be left exposed, because no counterparty was ever holding the other's asset — the contract logic was.
That gives you all three things a forward needs:
- Price fixed now — both legs are committed at agreed terms when the contract is created.
- Future delivery window — the timelock is the window.
- All-or-nothing guarantee — the atomic property, enforced by the chain, not by a clearinghouse.
The delivery deadline is the part worth dwelling on. In the clearinghouse model, the guarantee is institutional: you trust that the central counterparty has the capital and the legal standing to make you whole. In the HTLC model, the deadline is enforced by the base layer. On Ethereum mainnet, the timelock is just block timestamps and contract code. Nobody — including the protocol that wrote the contract — can extend it, skip it, or quietly settle around it.
Where this fits for agents
We call this Forward Settlement, and it's a direct extension of the primitive Hashlock Markets already runs in production: atomic settlement, live on Ethereum mainnet today. The base layer is a sealed-bid RFQ for price discovery fused with HTLC settlement, exposed to agents through a 6-tool MCP server. A forward is not a separate product bolted on — it's the same HTLC with the timelock used deliberately rather than defensively.
The reason this matters for the agent economy specifically: agents are good at committing to future actions and bad at trusting counterparties they can't inspect. A forward written as an HTLC plays to both. The agent commits today; the chain enforces the window; neither agent has to evaluate the other's solvency, because solvency was never load-bearing. The trade either completes atomically or unwinds atomically.
It also composes. Because each leg is independently refundable and bound to the same secret, a forward can be one leg of a multi-leg trade — sell BTC, buy ETH, buy SUI, all or nothing — without inheriting a clearinghouse for the whole bundle.
The honest limits
A few things this does not do, because overclaiming helps nobody:
- It does not eliminate price risk. A forward fixes a price; if the market moves, one side is worse off. That's the trade, not a bug.
- It does not give you margin or leverage. Both legs are fully funded up front. This is a delivery guarantee, not a credit facility.
- Today the production settlement layer is Ethereum mainnet. Sui contracts are deployed and CLI-tested with gateway wiring in progress; the Bitcoin P2WSH HTLC is validated on signet with mainnet still pending. Forward-dated settlement is live where atomic settlement is live — which today means Ethereum.
The underlying argument is in our working paper on SSRN, for anyone who wants the formal version rather than the blog version.
If an agent can get a forward without a clearinghouse, it's worth asking how much else in market structure was only ever a workaround for missing settlement guarantees — and how much of that an atomic primitive quietly makes optional.
Protocol: https://hashlock.markets
MCP server (canonical): https://github.com/Hashlock-Tech/hashlock-mcp