Most explanations of atomic swaps stop at the spot case: two parties lock funds, one reveals a secret, both legs clear in the same short window. Clean, but it quietly assumes the trade settles right now.

A lot of real agent activity isn't spot. It's a forward: two agents agree on terms today - asset pair, size, price - and settle at some future point, T+24h or T+48h. Procurement agents pre-committing to a delivery. A treasury agent locking tomorrow's FX-equivalent rate. A market-making agent quoting a forward to offload inventory risk. The economics are old; what's new is that the counterparties are anonymous software that will never meet.

That raises a question spot swaps don't have to answer: what holds the trade together in the gap between agreement and settlement?

In traditional markets the answer is a chain of intermediaries - a clearing house, posted margin, a credit desk that decides whether your counterparty is good for it. Strip those away, as you must in a market of anonymous agents, and the naive version of a forward collapses. If nothing binds the trade, either side can simply not show up when the price has moved against them. That's counterparty risk, and it's exactly the thing a forward is supposed to manage.

This post is about how the HTLC primitive - the same hashlock plus timelock most people only associate with same-block atomic swaps - can encode a forward obligation that's binding without anyone custodying the funds in between.

The timelock is doing more work than you think

Recall the two parameters of a hash-time-lock contract:

• Hashlock: funds can only be claimed by revealing a preimage s such that hash(s) == H. The same H is used on both legs, so the act of claiming one leg reveals the secret that unlocks the other. That's what makes the swap atomic - both clear or neither does.
• Timelock: if the preimage isn't revealed before a deadline, the funds refund to their original owner. No third party decides this; the contract enforces it.

In the spot case the timelock is just a safety hatch - a short window so a stuck swap doesn't trap funds forever. In a forward, the timelock stops being a safety hatch and becomes the instrument itself.

The move is simple to state: commit the funds now, but make the claim valid only inside a future settlement window. The lock exists from the moment both legs are funded. Neither party can withdraw their committed asset during the term - it's not in a custodian's account, it's in a contract whose only two exits are "clear" or "refund." When the settlement window opens, both sides settle against the shared preimage and both legs clear at once. If the window closes with no settlement, the timelock refunds both sides to their original owners.

That gives you the three properties a forward needs, with none of the intermediaries:

1. Binding. Once funded, the obligation is locked for the term. Walking away isn't a unilateral option; the funds are already committed to the contract.
2. No custody. During the entire term, no counterparty and no platform holds the other side's money. The contract is the escrow, and the contract can only ever clear-or-refund.
3. No margin call, no credit check. There's no "is my counterparty good for it" question, because settlement is collateralized by the locked legs themselves, not by a promise. Default isn't a loss event; it's just a refund.

Worked example

Two agents, A and B. A wants asset X tomorrow; B wants asset Y tomorrow; they agree the rate today.

• t = 0 (agreement): A funds an HTLC locking X against hash H; B funds an HTLC locking Y against the same H. Settlement window is defined as roughly T+24h, with a refund deadline after it. Both legs are now committed. Neither agent can pull their asset.
• During the term: nothing custodial happens. The price of X/Y can move. Neither agent can act on that by withdrawing, because withdrawal isn't an available transition - only clear (inside the window) or refund (after the deadline) are.
• t = T (settlement window opens): the party holding the preimage claims their leg, which publishes s on-chain. That same s immediately unlocks the other leg. Both clear atomically against one secret.
• Failure path: if the window closes with no claim - one agent went dark, infra failed, whatever - the timelock refunds both legs to their original owners. Nobody is out anything except a locked-capital window. The worst case is a wasted term, never a theft.

Notice what's absent: no clearing house, no posted variation margin, no counterparty credit assessment, no wrapped IOU minted on a destination chain, no bridge multisig holding value. The forward is enforced by two contracts and one shared secret.

Why agents specifically need this

You could argue humans got by with clearing houses for a century, so why change it. The answer is that the agent setting breaks the assumptions clearing houses rely on. Clearing depends on identity and recourse: known members, legal agreements, the ability to pursue a defaulter. Anonymous agents transacting across chains have none of that. There's no membership committee, no jurisdiction, no one to sue. In that environment the only enforceable forward is one where enforcement is mechanical - in the contract - rather than institutional.

This is also why "payment rails are enough" undersells the problem. This week made the point cleanly: x402 added Injective as a chain and crossed 160M cumulative payments. That's genuine adoption, and it's worth taking seriously. But a payment rail moves one known asset, one direction, at the moment of payment. It is structurally a spot, one-legged instrument. It can't bind a two-sided, cross-asset trade that settles later without smuggling a custodian back in to hold the gap. Volume on the payment layer is not the same thing as settlement, and a forward is the cleanest example of a trade the rail can't express.

Where this sits in Hashlock

Forward settlement is one of the primitives we build on top of sealed-bid RFQ plus HTLC atomic settlement - the same machinery that powers spot swaps, reused so the timelock encodes a future obligation instead of an immediate one. No bridges, no custodians; both legs clear or both refund.

To be precise about chain status, because it matters: Ethereum mainnet is live end-to-end; Bitcoin is signet-validated; Sui is deployed and CLI-tested. Forward mechanics live in the docs, and there's an academic treatment of the settlement model in the whitepaper if you want the formal version.

• Docs: https://hashlock.markets/docs?utm_source=devto&utm_medium=post&utm_campaign=2026-06-15-forward-settlement
• MCP server (6 tools): hashlock-tech/mcp (scoped) on npm
• Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

If you're designing forward or deferred-settlement flows for agents today, what's holding the trade together between agreement and settlement in your design - a balance sheet, or a contract that can only clear-or-refund? Curious how others are handling the term-risk gap.