
MACH402
MACH402 — rent GPUs by the second on Hedera via x402. No API keys. Built for agents too.
Demo
About
MACH402 is a peer-to-peer GPU rental marketplace where payment itself is the only credential anyone ever needs. A provider with an idle GPU runs a lightweight daemon that turns their machine into an x402 resource server; a renter — a person at a terminal, or an autonomous AI agent — pays that node directly, by the second, for a live container on it, and gets back whatever credit they didn't use. There are no accounts to create, no API keys to issue, and no subscription to manage. The HTTP 402 Payment Required status code, largely unused since the early web, becomes the actual authentication and authorization mechanism: a renter's signed payment transaction is their access grant. Every session is metered rather than prepaid in a lump sum. A renter buys a small chunk of credit up front; the provider node burns that credit continuously while the container runs and automatically refunds whatever's unused the moment the session stops — paid back from the node's own operator account, with no separate escrow contract holding funds in between. What makes that trustworthy rather than a blind promise is that every provider publishes a running "what I currently owe this renter" figure to its own Hedera Consensus Service (HCS) audit topic every fifteen seconds while a session is live — a continuously signed, publicly verifiable trail that exists before any dispute ever could. The marketplace has four cleanly separated parties. The renter holds a Hedera key and pays. The provider node runs the x402 resource server, verifies and settles payments through the Blocky402 facilitator, and runs the rented container — but it never holds a Hedera private key or links a Hedera SDK itself; all cryptographic signing lives in TypeScript using @x402/hedera, the reference implementation of Hedera's exact payment scheme. A discovery registry tracks which nodes are online via 30-second heartbeats but never touches money — it's pure metadata. And the shared Blocky402 facilitator co-signs as fee payer and submits transactions to Hedera testnet. Security is treated as load-bearing, not incidental. A rented container gets a real root shell (so pip install works) but sits on an internal-only Docker network with no route off the host except through a purpose-built egress proxy that denies every destination by default and allowlists only package and model registries. Access is granted by a short-lived SSH certificate signed by the node's own certificate authority — never a shared key — so revocation is simply letting the certificate expire. Renters can connect two ways. A website lets a person browse listed nodes, pick one, and pay directly from their own connected wallet. For autonomous use, we built and published mach402-mcp-server on npm — a standalone Model Context Protocol server that exposes the identical rent flow (search nodes, get a price quote, open a session, top up credit, stop and collect a refund) as tools any MCP-capable AI agent can call on its own, complete with configurable daily spending caps and a confirmation gate for payments above a threshold. Providers also get an on-chain ERC-8004 identity and a live terminal dashboard showing real-time earnings, GPU utilization, and session state.
How it's made
The stack splits cleanly along one rule: whichever side needs to sign a Hedera transaction is written in TypeScript, and nothing else is. The provider daemon (agent/) is a single static Go binary — deliberately, since a provider should be able to drop one file onto a stranger's GPU box and run it. It's the x402 resource server: it builds price challenges, calls the Blocky402 facilitator's /verify and /settle endpoints, runs and meters Docker containers, and serves the whole /v1/ HTTP API. It talks to Docker over its raw HTTP API on the unix socket rather than linking the Docker SDK, to keep the binary small and dependency-light. The interesting constraint: Go has no mature Hedera SDK, and hand-rolling frozen TransferTransaction bytes was out of scope. So the Go daemon never holds a private key and never imports a Hedera SDK at all — every signed transaction it needs (HCS topic submissions, ERC-8004 registration, session refunds) is produced by shelling out to a small TypeScript sidecar (hederakit/, invoked as the cleargate-hedera binary) that reads a node-local operator key, signs one transaction, and prints JSON back over stdout. This is the same pattern used for ssh-keygen (the node's own SSH certificate authority) and cloudflared (NAT traversal via Cloudflare quick tunnels) — trusted external binaries doing one job, invoked as child processes, rather than reimplemented or linked in. All renter-side payment signing lives in TypeScript using @x402/hedera, the reference implementation of Hedera's exact payment scheme — there's no second implementation to drift out of sync with the spec. That same signing logic is vendored into a fully standalone MCP server package (packages/mcp-server, published on npm as mach402-mcp-server) with zero dependency on the rest of the monorepo, so an AI agent host can npx it with nothing but Node.js. packages/types re-exports the x402 SDK's own wire types rather than redeclaring them, so a facilitator update surfaces as a compile error instead of a silent runtime mismatch. Money is handled as strings and BigInt end to end — tinybars, never floats — because floating-point arithmetic on currency is a bug waiting to happen. A golden-fixture test pins the Go challenge builder's output byte-for-byte against a captured response from the official @x402/express reference server, so any accidental protocol drift fails CI immediately rather than surfacing as a mysterious client-side rejection weeks later. The sandbox is the most deliberately over-engineered part: a rented container needs a real root shell (so pip install works), which rules out --network=none. Instead it sits on a Docker network with Internal: true and no route off the host at all, except through cleargate-egress — a deny-by-default proxy we built from source specifically for this project, matched on domain boundaries so notgithub.com can't pass as github.com. The discovery registry (Fastify + Postgres) and website (Next.js) are conventional on purpose — discovery isn't where the interesting engineering need to happen. The genuinely hacky bit, in the good sense: settlement only ever happens after the container is proven reachable through its tunnel, not after payment verification — so a session that never actually comes up costs the renter nothing, at the cost of doing container startup, cert signing, and a tunnel health check all inside the payment payload's 300-second expiry window.