Atomic settlement is not just for tokens: shipping compute-capacity MCP tools this week

An agent that cannot pay for its own compute is a stranded asset. It can reason; it cannot continue reasoning. That sentence sounds glib until you start wiring an autonomous agent and realise the boring constraint underneath every interesting behaviour is the same: can this agent acquire the next block of compute it needs, on its own, without a human in the loop?

This week, two PRs in hashlock-mcp merged that take a small but meaningful step toward that constraint becoming first-class on our MCP surface. This is a product update, not a manifesto. The point is to write down exactly what shipped, what the mechanism is, and what it lets an agent do that it could not do on Monday.

What shipped

Two PRs in Hashlock-Tech/hashlock-mcp:

• PR #8 (feat(compute): MCP create_compute_capacity_listing tool (PR2.1b)) — merged 2026-05-26.
• PR #9 (feat/compute-pr2.2-mcp-tool) — merged 2026-05-27.

Together they introduce a tool path on the MCP server for treating a block of compute — GPU hours, inference credits, model-access windows, whatever the provider chooses to denominate — as something an agent can list, discover, and settle against using the same primitive the server already uses for token swaps. The effective MCP tool count on the server moves from six to eight.

The npm package @hashlock-tech/mcp is still sitting at 0.4.0 as I write this — the new tool surface is in the repo and live in the running server; the version cut to publish those tools downstream is the next step in our release pipeline this week. We are being deliberate about not bumping the published package version until the tool docs and examples land in /docs together. If you are tracking the version, that is why it has been sticky.

Why compute is the obvious next thing to settle atomically

The honest framing: there is nothing magical about tokens that makes them the canonical thing two agents exchange. Tokens are well-defined, transferrable on-chain, and easy to lock. That is why every cross-chain settlement primitive in existence — bridges, intent protocols, atomic swaps — started with token-for-token.

But if you ask what an autonomous agent actually consumes in order to act in the world, the list is short and tokens are not at the top of it. The list is compute, data, model access, and storage. The thing an agent runs out of first is usually not money; it is the resource that money was a placeholder for.

A few specific examples to make this concrete.

A research agent has a budget in USDC and a long-running task that needs a few hours of GPU time. The agent does not want to open an account at a cloud provider, hold a credit card on file, and sign a usage agreement. It wants to spot-buy a block of GPU hours from whoever is offering them right now, settle atomically, get a credential it can use, and move on.

An inference-routing agent picks between model providers per call. Today it does this through pre-paid accounts at each provider, which means it carries N counterparty exposures and N reconciliation problems. With atomic settlement of inference credits, it can buy a small block from a provider at the moment of use, with the same trust-minimised guarantee a token swap gives it: pay and receive, or nothing happens.

A training agent has spare capacity on a machine it controls and wants to sell that capacity into the open market when it is idle. Today this requires a custodial marketplace that takes a cut and holds both sides' assets between match and settle. With an atomic settlement primitive, the seller posts an HTLC-keyed listing, the buyer locks payment on the other side, both legs resolve or neither does, and no marketplace ever touches either asset.

These are not exotic flows. They are what an agent doing useful work is going to need to do thousands of times. The settlement primitive that already works for tokens is, by construction, also the right primitive for compute — because the primitive does not care what the leg is denominated in, only that both legs have a hash, a timelock, and a refund path.

The mechanism, written out

The shape of a compute-capacity settlement using the new MCP tools is structurally identical to a token settlement. The reason we are excited about this week's PRs is precisely that it did not need to be a new primitive. The same HTLC + sealed-bid RFQ flow does the job; we are just extending what the listing leg is allowed to describe.

1. Provider lists capacity. The provider calls create_compute_capacity_listing and describes what they are offering: a quantity of compute (a unit the provider defines — e.g. N GPU-hours of class X, N inference calls against model Y, N storage-GB-months), a price denominated in some chain-native asset, a delivery commitment (how the credential is handed over once settlement clears), and a timelock window.
2. Consumer agent discovers and quotes. The same RFQ discovery path that already exists for token pairs returns capacity listings. The consumer agent inspects them, picks one, and submits a sealed bid against it.
3. Both sides lock. The consumer locks payment in an HTLC on its chain, keyed to a hash h. The provider, having seen the consumer's lock with matching hash, amount, and timelock, locks the credential commitment in a corresponding HTLC on the chain where the credential will be claimed.
4. Atomic settle or refund. The consumer reveals the preimage of h to claim the credential. That same preimage, now public, lets the provider claim payment. If anything stalls — bad lock, missing reveal, expired timelock — both sides refund. No third party ever held either asset.

The asymmetry to be honest about: the credential leg of a compute trade is not as clean as a token leg. A token, once transferred, is unambiguously yours. A credential — an API key, an access token, a signed authorisation — is a capability. The provider has to commit to honouring it after the preimage is revealed, and the consumer has to be able to verify the credential is what it says it is. We handle this today by binding the credential cryptographically into the HTLC commit so that revealing the preimage reveals the credential, and by requiring the provider to publish a verifiable specification of what the credential entitles the holder to before any consumer locks against it.

This is the part of the design we are most actively iterating on, and the part where the next PRs after #8 and #9 will land. We would rather state that plainly than oversell.

Honest chain status

The chain-status section every Hashlock post carries, exactly as it ought to read this week:

• Ethereum mainnet is live end-to-end today. Token settlement and now compute-capacity listings.
• Bitcoin HTLC is signet-validated, mainnet pending. Compute-capacity listings priced in BTC therefore work on signet and not yet on mainnet.
• Sui contracts are deployed and CLI-tested, with gateway wiring in progress. The compute-capacity tool path is plumbed through the same gateway; capacity listings on Sui follow the gateway timeline.
• Roadmap still names Base, Arbitrum, Solana, TON.
• npm @hashlock-tech/mcp is at 0.4.0 (sticky since 19 May); the new tool surface is live on the server, the package version bump to ship those tools downstream is the next pipeline step.

The MCP server is hashlock-tech/mcp (scoped). The MCP — Model Context Protocol — is the open protocol Anthropic introduced for connecting models to external systems; it is the contract our six (now eight) tools speak.

What this lets an agent do that it could not do on Monday

Two specific things.

It lets an agent treat compute as a thing it trades, not a service it subscribes to. The mental model shifts from "I have accounts at three providers" to "there is a market in GPU-hours, I check the depth, I lock and settle when the price is right." That changes what an agent can plan, because it can hold a budget in tokens and convert to compute at the moment of use, not in advance.

It lets the providers selling that compute do so without a custodial marketplace in the middle. A small lab with spare GPU capacity can list it. A specialised model host can sell direct access. There is no platform fee for the matching, because the matching is the MCP server's discovery surface, and there is no float held between match and settle, because settlement is atomic on both legs.

We do not yet have an agent in production buying compute via these tools — the listing tool merged two days ago. What we have is the primitive, and the open question of who is going to use it first. If you are building an agent that runs into the compute-acquisition problem in the way we described above, we would like to hear from you in the comments — both what is missing in the current tool surface and what would make this a path you would actually wire your agent to.

What to read

• Code: Hashlock-Tech/hashlock-mcp, specifically the PR #8 and PR #9 diffs for the new tool.
• npm: @hashlock-tech/mcp (scoped).
• Tool docs: hashlock.markets/docs — compute-capacity tool reference lands here as the docs publish.
• Methodology: hashlock.markets/methodology.
• Whitepaper (SSRN): the underlying mechanism design.

The question

We are interested in the part we cannot answer from the protocol side: if your agent could spot-buy a block of compute from another agent, atomically settled, with no custodian and no platform in between — what would it spend on first? GPU hours for a training run? Inference credits for a model you do not have a contract with? Something we have not thought of?