DEV Community

Baris Sozen
Baris Sozen

Posted on

Forward OTC settlement for agent treasuries: T+24h trades that don't depend on trust

In the last three weeks the agent-payments stack added a fifth shipped standard. Pay.sh launched on Solana with Google Cloud. Coinbase's x402 crossed 167M cumulative transactions. OKX Agent Payments Protocol added wallet+SDK+broker. ERC-8183 graduated to BNB Chain mainnet. Coinbase's Agent.market opened a seven-category app store.

All five share one property: they settle at T+0.

That's exactly what they should do. If your agent is calling Vertex AI or paying for a Perplexity query, you want sub-second finality. Pay.sh, x402, and OKX APP are very good at being a payments rail. You shouldn't ask a payments rail to do anything else.

But agent treasuries don't only pay for tools. Increasingly, they trade. And trades are not payments.

The dimension agent payment rails skip

A trade has at least two sides, often more than two assets, and almost always a settlement window that isn't zero.

Consider three real workflows that already exist in production today, run by humans, and that an autonomous agent will be asked to run tomorrow:

  1. Treasury rebalancing. A DAO holds 60% ETH, 30% BTC, 10% SUI and the policy says rebalance weekly. The agent doesn't want to slam every leg through a pool at the same instant — that's a slippage tax. It wants to RFQ each leg, lock prices at the same time, and clear them as a group. Some legs naturally take longer than others.
  2. Scheduled buybacks. A protocol commits to buy back its token every Friday at noon UTC against revenue collected the prior week. The buy and the sell should be linked, not sequential. The agent has to commit on Wednesday but deliver on Friday.
  3. Cross-asset hedge unwinds. An agent shorts a pair via a perp on one venue and offsets in spot on another. The unwind needs to be atomic across venues. Forward windows, sometimes 24 hours, sometimes 48, are how human desks already do this.

None of these are payment-rail problems. All three are settlement problems.

How OTC desks do it today, and what's missing

If you call a crypto OTC desk and ask for a forward, here's what happens. They quote you. You agree on a price. You agree on a delivery window — T+24h, T+48h, sometimes T+5. You sign a confirmation by email. Twenty-four hours later, both sides wire.

Two assumptions are loaded in there. The first is that the desk honors the forward at the agreed price even if the market moves five percent against them. The second is that you honor it back. The history of OTC is full of cases where the second assumption broke and the desk ate the loss, and a smaller history of cases where the first one broke and the customer did.

This is counterparty risk in its purest form. It's the reason 1-in-10 OTC trades reportedly fail at the human desk level, and the reason every autonomous-economy paper this year has flagged "trust between agents" as the unsolved layer.

You can solve trust between agents with reputation. ERC-8004 is a clean attempt at that. You can also solve it with collateral. Hashlock takes the collateral path because reputation has a bootstrapping problem and collateral does not.

Forward OTC, mechanically

A Forward OTC trade on Hashlock Markets is a sealed-bid RFQ followed by a hashed-timelock contract on each leg, with a delivery window measured in real chain time.

The flow looks like this:

  1. RFQ. The taker (agent or human) creates an RFQ specifying the pair, the size, and a delivery window — say, "I'll deliver 1 BTC against 21.5 ETH, settlement window T+24h." Multiple makers respond with sealed bids. The taker picks one.
  2. Lock. Both parties post HTLC bonds on their respective chains. The maker locks 21.5 ETH on Ethereum, hashed to a preimage held by the taker. The taker locks 1 BTC on Bitcoin, hashed to the same preimage. Each lock has a timelock equal to the delivery window plus a small grace period.
  3. Reveal. Inside the window, the taker reveals the preimage to claim the maker's ETH. The act of claiming on Ethereum publishes the preimage on-chain, which the maker's relayer picks up and uses to claim the BTC on Bitcoin. Two reveals, one preimage, atomic across two chains.
  4. Refund. If either side fails to act before the timelock expires, the locks unwind. Both bonds return to their original owners. No partial settlement is possible.

The clock is the smart contract. There is no broker holding both sides of the trade. There is no escrow custodian who could be subpoenaed, hacked, or rugged. The only thing each party trusts is that math holds, that the chain finalizes, and that the timer counts down.

Why Sui makes this primitive cleaner

Hashlock Markets runs on three chains as of this week: Ethereum, Bitcoin, and Sui. Sui mainnet support went live on May 1 and that matters more than it sounds.

Bitcoin doesn't speak smart contracts in the EVM sense. To use BTC as collateral on a Sui-native trade, you need a way to hold it that isn't "wrap it into a custodial token and pray." We use Hashi for this — a Sui-native bridging primitive that holds BTC against a verifiable proof without minting a wrapped token, and that emits an object on Sui you can lock into an HTLC.

Sui's object model is the reason this works. Instead of hashlock state being a balance entry inside a giant shared mapping (the Ethereum approach, which forces every claim/refund to contend with every other claim/refund), each Forward OTC bond is its own object with its own owner and its own lifecycle. Claims on different trades don't queue behind each other. The bonds compose with other Sui primitives (sponsored transactions, programmable transaction blocks, gas pools) the same way any other object does.

This is the part of the stack that wasn't possible six months ago. It is now.

The 7 bps detail

Hashlock charges 7 basis points on settled volume in current reference deployments, with up to a 50% rebate via Execution Rewards for makers who settle inside their committed window. Effective fee for a reliable maker: 3.5 bps. Effective fee for a maker who refunds: 7 bps. Compare to typical CEX OTC desks at 8–10 bps and ask what the desk is actually doing for the spread.

We are deliberately calling these "reference deployments" rather than "production" — we are still pre-audit, contracts are immutable on V1, and the volume floor is small. The fee schedule is not an aspirational marketing number, it is what the contract takes.

Try it

Today, if you point Claude Desktop at the hashlock-tech/mcp package (scoped) and call create_rfq with settlement_window=86400 (24 hours, in seconds), you can submit a real Forward OTC RFQ on testnet against ETH, BTC, or SUI. The MCP exposes six tools: create_rfq, respond_rfq, create_htlc, withdraw_htlc, refund_htlc, get_htlc. Forward windows are a parameter on the first call.

We're publishing the full Forward OTC mechanics walkthrough at https://hashlock.markets/docs. The protocol spec, including the timelock derivation and the cross-chain claim graph, is in the SSRN paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722.

Hashlock Markets, public canonical: https://hashlock.markets. GitHub: https://github.com/Hashlock-Tech/hashlock-mcp.

What forward-settlement window does your agent treasury actually need — T+0, T+24h, or T+48h? And which workflow first forced you to think about it?

Top comments (0)