Trust & Economics

The trust model, layer by layer

Froglet separates three kinds of trust. Mixing them up is how marketplaces overclaim, so the protocol is explicit about which layer each guarantee lives in:

Checkable evidence	Operator policy (hosted marketplace)	Not guaranteed by the protocol
Artifact signatures (BIP340)	Listing and indexing	Execution correctness
SHA-256 hashes and the chain	Suspension via the arbiter	Provider competence
Lightning settlement state (payment preimage)	Complaint handling	Refund of the base fee on failure
Signing-key continuity (not proof of the same person)	Identity attestation (DNS / OAuth domain claims)	Future behavior of any key

Trust signals today

The marketplace API defines a receipt-derived trust summary per provider: success count, failure count, rejected/canceled count, and total settled value, computed from the signed receipts the indexer has verified. Two honest caveats:

Receipt history can be self-dealt. A provider can run deals against itself to inflate counts. Counts and reported settled totals do not prove independent buyers or a real economic cost, especially for free or test deals. Weigh history together with other evidence.
Attestation supplies context, not quality assurance. A verified domain claim links a key to control of that domain. It does not prove a unique person, good results, or a meaningful cost to creating another identity.

Disputes today: the arbiter

The hosted marketplace’s documented arbiter accepts complaints with evidence; operator verdicts can suspend a provider from marketplace listings. This is an external service, whose availability must be checked with its operator.

The protocol itself requires no trusted registry — you can verify any provider’s artifacts and run deals against it directly, marketplace or not. The hosted marketplace and arbiter are convenience layers run by an operator, and they are described here as exactly that.

What a receipt proves — and what it doesn’t

A valid receipt signature establishes that the provider key signed that reported outcome and result hash. Checking the chain also requires the linked artifacts, their signatures, and their hash bindings; a receipt alone is not the whole chain. For Lightning, a matching preimage is settlement evidence when checked against the deal’s bound payment hash and invoice.

A receipt does not prove the result is correct. Verifying execution correctness without re-running the work is an open research problem (re-execution, trusted hardware, zero-knowledge proofs). Froglet’s position: the receipt makes outcomes attributable and auditable — a provider that signs wrong results signs the evidence against itself — but detection still requires someone to check. For deterministic workloads, spot-check by re-running a sample on a second provider.

Practical buyer guidance

Keep individual deal sizes small relative to the trust evidence you have.
Configure your node’s requester spend caps so a runaway agent can’t drain a wallet (see Configuration).
In the two-leg Lightning model, the base fee is non-refundable if execution fails — that is the provider’s compensation for reserved resources. Only the success fee is conditional. Size base fees accordingly when you buy.
Lightning payments are irreversible; Stripe payments follow card-network dispute rules. Pick the rail that matches your recourse expectations.

Design roadmap: staked identity

The long-term design adds a fourth trust signal: a non-refundable identity cost, called stake in the roadmap. The intended signal is a verifiable payment associated with a provider key. Losing a listing could make that investment less useful. This is not a refundable bond, a guarantee of honest behavior, or a way to invalidate the provider’s signed artifacts.

The design only works if three assumptions hold, and we state them plainly:

Cheating must be detectable and publicly provable. For “provider never delivered,” receipts and deadlines make this checkable. For “provider returned a wrong result,” it requires re-execution or verifiable compute — see the receipt caveat above.
Someone must adjudicate. An identity cost cannot detect cheating or decide a dispute. Today the adjudicator would be the marketplace operator; any panel-based mechanism is future work.
Exposure is concurrent. A cheating provider can run many deals in parallel before detection propagates, so per-deal arithmetic alone understates risk. The relevant comparison is stake versus total concurrent exposure within the detection window, which is why deal-size caps and small-first defaults matter even with stake.

With those assumptions, a requester heuristic falls out: require stake / exposure > k for a risk threshold k of your choosing — where exposure is everything you have outstanding with that provider, not just this deal.

Interactive: trust threshold check (design preview)

Set your risk threshold and see which deals pass

Adjust k to see which example stake-to-exposure ratios satisfy stake / exposure > k. Passing this illustrative threshold does not establish safety.

risk threshold k: 1.0

Loading…

Each bar represents an example deal. Bar length = stake/exposure ratio. The dashed line marks your threshold k. Design preview — stake is not live yet.

Design note: the deal as a game

This simplified model describes two-leg Lightning settlement, not every payment rail. It assumes risk-neutral participants, a provider cost for every admitted attempt, and no extra transaction costs. Here, is the probability of an accepted successful outcome. It combines execution and requester acceptance; it is not an independently measured quality score. See Settlement for implementation maturity.

Definitions

Let be the set of all froglet nodes. Each node has a secp256k1 keypair where .

A service is characterized by:

where is the base fee, is the success fee, and is the execution limit vector (time, memory, fuel).

A deal between requester and provider is a two-player sequential game:

Payoffs

Let be the value to the requester, the provider’s cost, the total price.

Outcome	Requester	Provider
Success
Failure
No deal

Note the failure row: the requester eats the base fee. That is deliberate (it compensates reserved resources and deters free-riding) and it is why the base fee should stay small relative to the success fee.

Participation constraints

Using expected payoffs, the requester participates when , and the provider when . Positive expected gains from trade require . At , these reduce to the familiar successful-deal bounds.

Two-leg settlement analysis

Let be the probability of the accepted success defined above.

Requester expected payoff:

Provider expected payoff:

Incentive compatibility

Holding cost and all other terms fixed, a positive success fee increases expected revenue as increases:

This is a marginal revenue incentive, not an equilibrium or honesty proof. If improving reliability also increases cost, that cost must be included.

Interactive: provider profit vs quality

Move the fees and watch the incentive line change

The slope of provider profit with respect to quality is the success fee. That is why the green line gets steeper when success fees rise.

base fee: 3 sat success fee: 5 sat cost: 2 sat

1.0 satprovider payoff at q = 0

6.0 satprovider payoff at q = 1

0.00break-even quality threshold

X = provider quality (q). Green = provider profit. Blue = requester payoff with requester value fixed at 10 sat.

What a fee split can guarantee

There is no unique optimal split from these assumptions alone. Breaking even on every failed attempt requires:

Breaking even in expectation requires . A smaller base fee shifts more failure risk to the provider. For example, with sat, sat, sat, and , expected provider profit is sat, but each failed attempt loses sat. These are different guarantees.

Network economics

Marketplace viability

Suppose a marketplace charges per search. With query rate and indexed providers:

Viable when . (The current hosted marketplace charges nothing — this models how an operator could sustain one.)

Provider discovery value

A provider’s expected value from marketplace registration:

Here is the number of additional admitted deals from discovery in the period, with the same per-attempt cost assumption. Registration has a positive expected return when .

Network effects

As a possible model of cross-side network effects, a steady state would satisfy:

Even if and are increasing, the existence and number of equilibria depend on their shape and boundary conditions. Growth is not guaranteed by the protocol.

Welfare analysis

Total welfare:

Within this model, fees are transfers between participants. Potential benefits must outweigh execution and transaction costs. The design aims to help through:

Reducing information asymmetry — signed receipts make outcomes attributable
Reducing counterparty risk on settlement — two-leg Lightning binds the success fee to acceptance
Reducing search costs — the marketplace aggregates information
Enabling price discovery — comparable terms can help buyers compare providers

Market size alone does not imply cost-level prices or improved welfare.