Sub-Millisecond Operators: Bringing Tollbooth-DPYC to Akamai WebAssembly Fermyon

In the Tollbooth-DPYC™ (Don't Pester Your Customer) economy, an Operator is a merchant. It offers the subjective value of its MCP tools to autonomous agents and settles each call in Bitcoin, over the Lightning Network, with no intermediary standing between the buyer and the seller.

Where commerce is concerned, friction is the adversary — and one residual friction has nagged at us for months: the cold-start latency of the hosting beneath our Operators. This is a report on an effort to remove it.

Serendipity at the AI World Fair 2026

At the AI Engineer World's Fair in San Francisco this summer, I attended a talk by Thorsten Hans on Fermyon's Spin platform and its WebAssembly runtime. The metric that caught my attention was the per-request, cold-start time: four tenths of a millisecond 0.4 ms.

A WebAssembly module carries no container and no virtual machine to raise, so each invocation meets an effectively warm function. Fermyon was acquired by Akamai late last year, and the technology now surfaces as Akamai Functions, running WebAssembly globally across Akamai's network. A subsequent conversation with a principal engineer at Akamai persuaded me that the pairing was worth serious study.

The question was straightforward. Tollbooth DPYC Operators presently run as Python services beneath a serverless host, and the startup delay sits squarely on the request path that a patron must wait upon. If an Operator could instead run as a WebAssembly component at the edge, that delay would very nearly vanish, and the tool call, from the agent's vantage, would become instantaneous.

Design Principle: reuse, do not rewrite

The temptation, when adopting a new runtime, is to reimplement. That temptation had to be refused.

The whole of the Tollbooth-DPYC protocol — proof verification, the credit ledger, pricing, the encrypted vault, and the metering that debits a patron upon each successful call — resides in a single Python library that every Operator imports. To fork that logic for the edge would violate the most basic economy of engineering and invite the two copies to drift apart. The rule for the exercise was therefore fixed at the outset: reuse the library untouched, and change only the thin server layer that presents the tools together with the manner of deployment.

A skeptical inspection of the library produced a welcome result. It already imports cleanly in a runtime stripped of native extensions, and its persistence layer already speaks to its database over HTTP rather than through a compiled driver. The commercial hot path — verify the patron's cached proof, confirm a positive balance, serve the tool, debit the ledger — proved to be plain Python throughout. The foundation, in other words, was already suited to the edge.

Three Gaps between CPython and the WebAsm edge

Suitability is not the same as sufficiency. The WebAssembly build of Python omits three faculties that an Operator quietly relies upon, and the engineering of this proof of concept consisted largely of closing those gaps without altering a byte of the shared library:

• Transport security. The edge host terminates TLS on the component's behalf, so the standard secure-socket module is supplied as a light stand-in, and outbound requests are routed through the platform's own HTTP capability.
• Cryptography. The library's signature and encryption routines ordinarily depend on compiled code. In their place we compose a small, purpose-built cryptography component — written in Rust and speaking the WebAssembly component interface — that performs the elliptic-curve and symmetric operations the protocol requires.
• Relay contact. An Operator receives its credentials through an Authority-signed, encrypted event on the Nostr network, and Nostr relays speak only over persistent WebSocket connections, which the edge host does not offer. A small, stateless bridge — holding no secrets and seeing only ciphertext — relays that single message so that the component may decrypt and verify it in place.

Trust-minimal by Construction

One property of the design deserves emphasis, for it is the reason the whole arrangement is safe to run at the edge at all. An Operator's sole secret is its own Nostr key.

Everything else it requires — the location of its records and the key that encrypts them — is delivered to it at runtime in a message that only its Authority could have signed and only it can decrypt. Its records rest as ciphertext; the Authority's signature is verified within the WebAssembly sandbox itself; and the bridge that carries the credential message never holds anything but an opaque payload. The edge gains speed without being granted trust.

The Goal is almost Scored

The vehicle for the proof of concept is a modest one: a weather Operator, mirroring our reference sample, offering three paid tools with their interfaces preserved exactly, so that a patron's existing credentials continue to function against the new runtime without alteration. That proof is now nearly complete.

What remains is deployment to Akamai's network and a formal measurement of cold-start and tail latency against the incumbent host — the figures that will tell us how much friction we have in fact removed.

The larger point is not about any one weather service. It is that a sovereign, Bitcoin-settled unit of commerce — an Operator that answers to no payment processor and discloses no beneficial owner — can be made to run as swiftly as the network itself will permit, and to do so without surrendering the very sovereignty that recommends it. Sound money favors low time preference; sound infrastructure ought to favor low latency. This work is an attempt to honor both.

---

References: Akamai Functions; Akamai's acquisition of Fermyon (Network World); the Tollbooth-DPYC project; the tollbooth-fermyon proof-of-concept source.