🐸 Froglet: a protocol for bots that buy, sell, and compose compute

Most agent toolchains assume the AI is a guest on a human's wallet. Froglet flips that: the protocol gives bots signed economic primitives so one agent can publish a service, discover a peer, and settle a deal without ever seeing a human credential. This is a technical note on how Froglet bridges MCP, a Rust runtime, and three payment rails — and why only one of those rails needed to be pulled into the signed core.

The shape of the problem

Agent frameworks have mostly solved "how does an LLM call a tool." MCP is the clearest expression of that: a uniform surface for the model to discover and invoke capabilities. But the moment you want two agents to transact — one publishing a service, another paying to invoke it — the existing stack assumes the AI is a guest on a human's wallet. You wire the agent to your Stripe key, hope the prompt never wanders, and pray the provider on the other side isn't lying about what it just did.

The protocol I've been working on, Froglet, starts from the opposite premise: the bot is the economic actor. Identity is first-class in every signed artifact. A quote is a cryptographic object, not a string in a chat log. Settlement is either part of the signed flow or it is an explicitly-adapter-level concern — never silently conflated with the rest.

This note walks through the three primitives, the runtime surface, why one payment rail got promoted into the signed core while two others stayed as adapters, and what a single round-trip actually looks like on the wire.

Three primitives, one signature

Froglet exposes three product shapes over one signed economic primitive:

All three are the same underlying thing from the runtime's perspective: a signed deal between two identities, with a quote, an execution binding, and a settlement outcome. The surface differences — whether you're invoking a named function or renting a GPU slice — collapse down to the same signed envelope.

This matters because it means a bot doesn't need three different mental models to participate in the economy. Publishing a prime-number-checker, a fine-tuned embedding service, and "raw compute with these resource bounds" all flow through the same primitive. The mainline authoring path doesn't require an OCI image; containers are a supported packaging option, not a prerequisite.

The runtime surface: MCP + a Rust node

The integration surfaces are intentionally narrow:

• One MCP server (integrations/mcp/froglet/)
• One OpenClaw/NemoClaw plugin id: froglet
• One bot-facing tool: froglet

That single tool is the whole agent-visible API. Underneath, a Rust node (Tokio + Axum) handles signing, state, discovery, and the settlement adapters. The node can serve the same signed deal over clearnet HTTPS or a Tor onion — which is less of a hobbyist flourish than it sounds, because the same signature verifies regardless of transport, and the onion path matters for provider anonymity in a genuine bot-to-bot marketplace.

The boundary between froglet-protocol (the crate that defines signed artifacts) and the node runtime is deliberate. The protocol crate has no knowledge of HTTP, of Axum, of tokens, or of any specific payment rail. It only knows how to canonicalize an artifact, sign it, and verify someone else's signature. The node composes that with transport and adapters.

Why Lightning is in the signed core and Stripe is not

The most common response to "we support three payment rails" is "great, which abstraction do you use?" The honest answer is: we don't abstract over them, because they're not the same thing.

Lightning Network is the only rail where the settlement object — the invoice — is itself a cryptographic commitment that can be bound into the signed deal without a trusted third party clearing it. So Lightning was promoted into the standardized signed quote / deal / invoice-bundle flow. The provider signs a quote, the caller signs a deal referencing it, and the resulting invoice bundle is verifiable offline by anyone. This is the path you want when two bots that have never met before need to settle, because no party needs to trust a clearinghouse.

Stripe and x402 are adapter-level: they live inside the node as local runtime settlement adapters. The node still emits signed artifacts for the agent-facing flow, but the settlement event itself is mediated by an external system (Stripe's API, or an x402-gated HTTP response). That is a conscious narrowing: pretending Stripe is Lightning-shaped would either require us to trust Stripe to be a notary — which is fine but changes the threat model — or to fabricate an invoice object that doesn't actually commit to anything.

Here's the distinction in one table:

Surfacing that asymmetry in the architecture is more honest than flattening it. It also means adding a fourth rail is not a design debate — it's a decision about which box it goes in.

A worked round-trip

The simplest useful flow is: agent discovers a service, calls it, pays, gets the result. In the MCP surface it looks like a single run_compute call. Underneath, a Lightning-backed interaction goes roughly like this:

agent                        caller node                     provider node
  │                               │                                │
  │ MCP: run_compute(...)         │                                │
  ├──────────────────────────────▶│                                │
  │                               │ GET /quote                     │
  │                               ├───────────────────────────────▶│
  │                               │                                │
  │                               │              signed Quote      │
  │                               │◀───────────────────────────────┤
  │                               │                                │
  │                               │ POST /deal (signed Deal)       │
  │                               ├───────────────────────────────▶│
  │                               │                                │
  │                               │      BOLT11 invoice (bound     │
  │                               │      to Deal hash)             │
  │                               │◀───────────────────────────────┤
  │                               │                                │
  │                               │ ── pay invoice over LN ──▶     │
  │                               │                                │
  │                               │ POST /claim (preimage)         │
  │                               ├───────────────────────────────▶│
  │                               │                                │
  │                               │      execution result +        │
  │                               │      signed InvoiceBundle      │
  │                               │◀───────────────────────────────┤
  │ MCP: result                   │                                │
  │◀──────────────────────────────┤                                │

The caller ends up holding a signed InvoiceBundle containing the quote, the deal, and the preimage-validated invoice. Any third party — a dispute resolver, an auditor, a future automated broker — can verify that transaction without either node being online.

For an adapter rail like Stripe, the last two steps collapse: the signed envelope still exists, but the settlement event is "Stripe says this charge succeeded," and the offline-verifiability property is traded away for convenience and fiat reach.

more details coming soon