The settlement primitive no agent tool ships yet: an atomic forward (settle at T+24h, never custody the gap)

Almost every settlement tool an AI agent can reach today does one thing: it clears the trade right now, in the next block or two. Spot swap, spot escrow, spot payment. That covers a lot of ground. It does not cover the trade that is agreed today and settled tomorrow.

That trade has a name in traditional finance: a forward. Two parties fix the terms now and complete the exchange at a future date. It is one of the oldest instruments there is, and it exists because "now" and "later" are genuinely different needs. An agent that can only settle on the spot cannot express "later" at all.

This post walks through how you build a forward on a hash-time-locked contract (HTLC), what the third knob is that spot swaps do not have, and why - through the entire waiting period - no custodian ever holds the gap.

Start from the spot swap

A cross-chain atomic swap has two control parameters.

The hashlock. One party picks a secret s and publishes H = SHA-256(s). Both legs of the trade - say an asset on Ethereum and an asset on another chain - are locked so they can only be claimed by revealing s. Because both legs bind to the same H, revealing s to claim one leg exposes it on-chain, which lets the counterparty claim the other. Either both complete or neither does. That is the atomic guarantee.

The timelock. If nobody ever reveals s, funds cannot sit locked forever. Each leg has a timeout after which the original owner can refund. Standard practice is to give the party who moves second an earlier refund deadline than the party who moves first, so the first mover cannot reveal the secret at the last second and grief the counterparty. Timeout ordering is the part people get wrong; it is worth getting right.

Those two knobs give you spot settlement: lock, reveal, claim - all inside a short window.

The third knob: a claim window that opens later

A forward keeps the hashlock and the timelock and adds one more parameter: the moment the claim becomes valid.

In a spot swap, a leg is claimable the instant it is funded. In a forward, you gate that. The withdraw path is only valid inside a window [forward_start, timeout), where forward_start is the agreed settlement date - T+24h, T+48h, whatever the two parties fixed. Before forward_start, neither side can pull the trade forward. After timeout, if settlement never happened, both sides refund.

So the lifecycle of an atomic forward is:

1. T+0 - agree and lock. Both parties fund their legs against the same H. The price is fixed here, at agreement time.
2. T+0 to T+24h - the wait. Both legs sit locked. Neither party can claim yet. Critically, neither party is holding the other's asset - each asset is held by a contract, released only by the secret, and only inside the future window.
3. T+24h - settle. The claim window opens. The party holding s reveals it to claim their leg; that reveal lets the counterparty claim theirs. Atomic, same as spot.
4. After timeout - refund. If the window passes without settlement, each side reclaims its own funds. Nobody is out anything except gas and time.

The whole design is one added constraint on an existing, well-understood primitive. That is deliberate. Forwards are valuable precisely because the underlying settlement guarantee does not change - you are still getting atomic, custodian-free settlement, just at a chosen future moment instead of immediately.

The part that matters: nobody holds the gap

In traditional finance, a forward is a credit instrument. Between agreement and settlement, one party carries counterparty risk on the other. That is why forwards are collateralized, netted, and cleared through intermediaries - somebody has to backstop the possibility that the other side does not show up.

An atomic forward removes that carry. During the entire waiting period:

• Neither party holds the counterparty's asset.
• No escrow agent holds both.
• No exchange holds the float.

Both assets are locked to the same cryptographic condition, and that condition is symmetric. If the trade settles, it settles atomically. If it does not, both sides walk away whole after the timeout. There is no window in which a compromised, malicious, or simply absent counterparty can abscond with value that was "in transit," because value is never in anyone's hands mid-flight. It is in a contract, bound to a hash, gated by time.

That is the difference between forward settlement without a custodian and a custodial desk that happens to settle later. Same economic exposure at the terms level; completely different trust model in the middle.

Why an autonomous agent specifically needs "later"

Spot-only settlement quietly assumes both sides are ready to complete the instant they agree. Agents frequently are not, for reasons that have nothing to do with mistrust:

• Waiting on a condition. Settle when a delivery confirms, an oracle updates, or an off-chain event fires.
• Waiting on a funding window. An agent's treasury rebalances on a schedule; it wants the price locked now and the cash movement aligned to that schedule.
• Multi-leg choreography. One leg of a larger sequence needs to clear before another; a forward lets an agent commit to terms without stranding capital while it waits.

An agent reasoning with a model like Anthropic's Claude can decide what to trade and when it should complete. Without a forward primitive, "when" collapses to "immediately," and any real delay has to be simulated by parking money somewhere - which reintroduces exactly the custodian the atomic model was built to remove. A forward lets the agent say "these terms, that time" and have the settlement layer enforce it, trustlessly.

Honest limitations

HTLC-based forwards are not free of tradeoffs, and pretending otherwise would be marketing, not engineering:

• Capital lockup. Both legs are locked for the full duration. A 48-hour forward ties up capital for 48 hours. That is the price of removing the custodian - you post the asset instead of posting credit.
• Timeout parameterization is load-bearing. The gap between the two legs' timeouts, and between forward_start and timeout, has to account for chain reorg depth and confirmation latency on both sides. Get it too tight and an honest party can miss its window; too loose and capital sits idle longer than necessary.
• No price adjustment. The terms are fixed at agreement. That is the point of a forward, but it means neither side benefits from a favorable move between agreement and settlement. If you want optionality, that is a different instrument.

These are real, and they are the kind of thing worth arguing about in the comments rather than papering over.

Where this sits

Ethereum mainnet is live end-to-end today. Sui contracts are deployed and CLI-tested, with gateway wiring in progress; Bitcoin is validated on signet with mainnet pending. Ethereum mainnet remains the only end-to-end live network, and we will keep saying exactly that. The forward primitive described here is a design built on the same HTLC settlement core, not a claim that every chain is live.

The academic grounding for the settlement model is in our SSRN whitepaper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722. The MCP server and tool surface an agent uses to drive settlement are documented at https://hashlock.markets/docs?utm_source=devto&utm_medium=post&utm_campaign=2026-07-13-forward-settlement.

One question I would actually like answered: what is the first agent workflow where "settle in 24 hours at today's price" beats "settle now"? Delivery-versus-payment? Scheduled treasury? Something I have not thought of? Tell me where a forward earns its keep.