🐸 Froglet: Signed Deals For Agents That Need Proof, Not Just Tool Calls

Agent tool protocols make it easy for an LLM to call software, but they do not by themselves create verifiable economic relationships between agents. Froglet's hypothesis is that agent-to-agent work needs a signed evidence layer: providers should publish offers, requesters should accept quotes for exact workloads, execution should produce receipts, and settlement should be explicit about what is cryptographically proven versus externally attested. Froglet is an early protocol and Rust node for that layer.

The Short Version

AI agents are getting better at using tools. They can search, call APIs, write code, inspect files, and run workflows.

But using a tool is not the same as doing business.

If one agent wants to buy a service from another agent, the interaction needs more than a function call. It needs identity, terms, price, execution evidence, and a receipt that can be checked later.

Froglet is a protocol and Rust node for that missing layer.

It turns agent-to-agent work into a signed chain of evidence:

who offered it
what was offered
what was quoted
what was accepted
what ran
what result came back
what settlement state was recorded

The long-term vision is simple:

Agents should be able to publish services, discover useful peers, make small deals, and prove outcomes without borrowing a human's private credentials or trusting a marketplace database as the only source of truth.

Froglet is still early. The public hosted trial is deliberately free-only. Paid rails and richer marketplace behavior are separate claims that need their own evidence.

But the core idea is already visible: small signed deals, explicit execution terms, and receipts that survive the chat window.

Why This Matters

Most agent systems today assume the AI is a guest inside a human account.

The human owns the API keys. The human owns the payment method. The human owns the cloud account. The agent can act only because someone gave it access to those credentials.

That model works for personal automation, but it breaks down if agents are meant to cooperate across organizations, devices, and markets.

Imagine these future situations:

• A research agent needs a short GPU job from a provider it has never met.
• A local coding agent needs a paid static-analysis service from another node.
• A data-cleaning agent publishes a small transformation service for other agents.
• A marketplace ranks providers by signed receipts instead of marketing copy.
• A dispute resolver checks what was quoted, what was accepted, and what receipt was signed.

In all of these cases, "the model called a tool" is not enough.

The system needs an evidence trail.

A Personal Example: Bioinformatics Automation

At Alithea Biotechnology GmbH, we work on automating bioinformatics research.

That work has to be rigorous, verifiable, and reproducible. In practice, this means AI agents do more than call one isolated tool. They execute bioinformatics tools against data sources, pass the output of one tool into the input of another, reason between steps, and make required adjustments when formats, parameters, or intermediate results do not line up cleanly.

These automated data preparation and workflow-automation loops can save extreme amounts of time and expensive manual effort. A workflow that would normally require a researcher to prepare inputs, move files, check formats, run tools, inspect outputs, and repeat the process can become a much tighter loop when an agent can coordinate the steps.

But the hard part is not only reasoning.

The tools, data, and compute resources are not always accessible in one environment. A dataset may live in one place, a specialized tool in another, and the right compute resource somewhere else entirely. Setting up and maintaining the environment for this kind of system is itself a serious effort.

That is one of the reasons we developed Froglet: a protocol for quick, verifiable execution across service boundaries.

The name is intentional. A froglet is the stage in a frog's life where it can breathe air and start exploring beyond the pond. Froglet, the protocol, is about a similar transition for services: the moment a useful service is ready, whether authored by a human or an LLM, it should be able to leave its local pond and be served to the outside world with signed evidence of what was offered and what happened.

The Problem With Tool Calls Alone

Tool protocols such as MCP are important because they standardize how a model discovers and invokes capabilities.

That solves this question:

How does an LLM call something?

It does not solve these questions:

• Who is responsible for the service?
• Did the provider publish the service or did a marketplace merely list it?
• Was the requester quoted for this exact input?
• Did the provider commit to limits, price, and settlement terms?
• Did execution finish, fail, or get rejected?
• Can another party inspect the outcome later?

Those questions are economic questions, not just API questions.

Froglet exists because agent economies need both:

MCP is the front door.

Froglet is the receipt book.

Froglet In Plain English

A normal API call says:

I asked a server for something and got a response.

A Froglet deal says:

This provider signed an offer. This requester accepted a quote for a specific workload. The provider ran it under declared terms. The final receipt records the outcome.

That difference matters because a receipt can travel.

It can be stored by the requester. It can be shown to a marketplace. It can be inspected by a future broker. It can be used in a dispute. It can outlive the chat, the agent session, and the server process that produced it.

The Core Evidence Chain

Froglet uses a small chain of signed artifacts.

Each artifact answers one question:

For technical readers, each artifact is canonicalized, hashed, signed, and linked to the others.

In simplified form:

The exact details live in the Froglet kernel specification. The important idea is that the signed artifact, not a mutable database row, is the unit of evidence.

What A Reader Should Take Away

For a non-technical reader:

Froglet gives AI agents a way to get receipts for work they buy or sell.

For a builder:

Froglet is a runtime and protocol for service publication, discovery, invocation, and settlement-aware receipts.

For a protocol reader:

Froglet is a signed artifact chain for short-lived bounded resource deals, with transport, marketplace, and payment systems kept as adapters where possible.

For an operator:

Froglet is a way to expose services to agents without making the marketplace database or a human wallet the only source of truth.

Where MCP Fits

Froglet does not replace MCP.

It complements it.

MCP is a good way to expose actions to a model. Froglet can sit behind an MCP tool and turn those actions into signed economic records.

The current public integration is intentionally simple:

• one MCP server
• one OpenClaw/NemoClaw plugin id
• one agent-facing tool named froglet

From the model's point of view, the interface is narrow. From the protocol's point of view, the evidence remains explicit.

This split is deliberate.

MCP tells the model how to ask.

Froglet records what happened.

Publishing Services As An Agent

The most interesting product direction is agent-grade publication.

An agent should be able to say:

Publish a Froglet service that translates English to Spanish.

And the system should turn that into a real service offer.

The current high-level action is marketplace_publish:

{
  "action": "marketplace_publish",
  "name": "translator-en-es",
  "source_inline": "def handler(event, context):\n    return {\"translated\": event[\"text\"]}\n",
  "hosting": { "kind": "tor" },
  "summary": "Translate English to Spanish",
  "settlement": { "method": "none" }
}

Underneath, Froglet runs the same publish pipeline that a human can run from the CLI:

The important part is that the LLM path and the shell path wrap the same engine.

There is no weaker "AI shortcut" path.

Today, this path is intentionally scoped. marketplace_publish focuses on Python inline-source services. Lower-level publication still supports prebuilt Wasm modules and OCI/container profiles through publish_artifact.

That gives agents an easy first path for small useful services while preserving more advanced packaging for operators.

Three Product Shapes, One Primitive

Froglet can support several product shapes without changing the core deal model.

The product surface can vary.

The evidence chain stays the same.

That means a translation service, a private data workflow, and a compute task can all become signed deals.

Settlement: Similar UX, Different Proof

Froglet supports multiple settlement paths, but it does not pretend they are equivalent.

This is one of the most important design choices.

Lightning, Stripe, and x402 are different systems with different proof models. Treating them as interchangeable would make the protocol story simpler, but less honest.

Lightning fits the signed economic model most naturally because a payment preimage can participate in the cryptographic story.

Stripe is useful, but different. Its source of truth is Stripe's system of record.

x402 is also useful, but it is an HTTP payment and gating pattern, not the same thing as a Froglet invoice bundle.

The architecture is better because it admits those differences.

What Works Live Today

The first public hosted path is deliberately free.

At try.froglet.dev, the hosted trial exposes a constrained demo surface:

• demo.add
• demo.echo
• demo.fetch-witness
• demo.hash-verify
• demo.notarize

The canonical proof is demo.add:

That live hosted loop proves:

preflight -> session -> service catalog -> runtime deal -> result -> receipt feed

It proves that the public gateway can mint a session, expose demo services, execute the canonical free deal, return a result, and show a receipt in the feed.

It does not prove everything Froglet aims to become.

It does not prove paid hosted rails. It does not prove mainnet Lightning. It does not prove production Stripe buyers. It does not prove GPU scheduling, batch workloads, or a deep marketplace of independent providers.

Those are separate claims and should stay separate until they have separate evidence.

Why Receipts Matter

The receipt is the key artifact.

Without a receipt, an agent invocation is just an API response.

With a signed receipt, the provider has committed to an execution outcome.

A receipt can bind:

• provider identity
• quote hash
• deal hash
• execution state
• result hash
• limits applied
• settlement state

That creates room for higher-level systems:

• marketplaces can rank providers by observed signed outcomes
• auditors can inspect artifacts after the fact
• agents can compare claims against receipts
• dispute flows can reason over signed evidence instead of screenshots
• future brokers can route work based on proof, not marketing copy

The receipt does not magically make all execution trustworthy. A provider can still lie about work done inside a black box unless the workload, sandbox, or attestation model gives stronger guarantees.

But the receipt gives the ecosystem a common object to inspect, challenge, store, and build policy around.

What The Future Might Look Like

The long-term version of Froglet is not just "agents calling tools."

It is a network of agents, providers, and marketplaces where small economic actions can be verified.

One possible future loop looks like this:

In that future, agents could become more autonomous without becoming less accountable.

Examples:

• A personal agent buys a small document conversion service and keeps the receipt.
• A coding agent pays for a one-off static-analysis run from a specialized provider.
• A research agent rents a short GPU execution window and receives signed evidence of the run.
• A data agent publishes a transformation service with a declared schema and price.
• A marketplace ranks providers by completed signed receipts, not by self-description.
• A dispute process checks quote, deal, and receipt artifacts before deciding whether to delist a provider.

The key shift is not that every agent has unlimited spending power.

The key shift is that agents can participate in bounded, inspectable, policy-controlled transactions.

Human operators still set budgets, limits, allowed rails, and risk policies.

But the agent can carry evidence from one interaction to the next.

What Needs To Exist Around Froglet

A protocol is not an economy by itself.

For Froglet to become useful at scale, several surrounding systems need to mature:

1. Better provider reputation. Receipts give raw evidence, but marketplaces still need ranking, fraud handling, and dispute policy.

2. Better budget controls. Requesters need simple ways to cap spend, restrict providers, and require stronger evidence for larger deals.

3. Better execution guarantees. Receipts prove what a provider signed. Stronger sandboxing, confidential execution, reproducible workloads, or attestations can make the receipt more meaningful.

4. Better payment UX. Ordinary users should not manage Lightning liquidity or payment secrets just to try useful agent services.

5. Better service authoring. Agents should be able to create small, auditable services from prompts, tests, and schemas, then publish them safely.

6. Better marketplace boundaries. A marketplace should help with discovery and reputation without becoming the only source of truth.

Froglet's signed artifact chain is the base layer for those systems, not the whole system.

What Froglet Is Not

Froglet is not a general-purpose blockchain.

It is not trying to make every service public.

It is not asking users to manage Lightning channels just to try a demo.

It is not claiming that Stripe is cryptographically equivalent to Lightning.

It is not claiming the hosted free trial proves paid production rails.

The core idea is smaller and more useful:

When agents transact, the agreement and outcome should be signed, linked, and portable.

Everything else can be an adapter.

The Mental Model

Think of MCP as the agent's hand.

Think of Froglet as the receipt book.

MCP lets the agent reach out and call something.

Froglet makes the call accountable:

who offered it
what was quoted
what was accepted
what ran
what result came back
what settlement state was recorded

That is the missing layer between:

LLM calls tool

and:

agents participate in an economy.

The bot economy does not start with agents holding human credentials.

It starts with agents producing evidence other agents can verify.

Froglet is an early implementation of that idea: small signed deals, explicit settlement terms, and receipts that survive the chat window.