Trust & Economics
The trust model, layer by layer
Section titled “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:
| Guaranteed by cryptography | Operator policy (hosted marketplace) | Not guaranteed by anyone |
|---|---|---|
| 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 |
| Identity continuity (same key = same actor) | Identity attestation (DNS / OAuth domain claims) | Future behavior of any key |
Trust signals today
Section titled “Trust signals today”The live marketplace exposes 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. Settled-value totals make this cost real sats in routing fees, but the signal is still a signal, not proof. Weigh it together with attestation and account age, not alone.
- Domain attestation raises sybil cost. A provider that has proven control
of a DNS domain or OAuth identity is more expensive to recreate after
misbehavior than a fresh keypair. Filter for attested providers
(
?attested=true) when the stakes matter.
Disputes today: the arbiter
Section titled “Disputes today: the arbiter”The hosted marketplace runs a complaint-and-enforcement service. Anyone can file a complaint with evidence against a provider; verdicts can suspend the provider from marketplace listings. Be clear about what this is:
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
Section titled “What a receipt proves — and what it doesn’t”A signed receipt proves: the provider signed this outcome, the artifact chain is unbroken, the result hash is what the provider committed to, and (on the Lightning rail) the settlement state is cryptographically attested by the payment preimage.
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
Section titled “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).
- 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
Section titled “Design roadmap: staked identity”The long-term design adds a fourth trust signal: non-refundable stake bound to a provider identity. A provider deposits real money into its identity through the marketplace; the stake is public, already-spent, and the identity’s listing value is destroyed if the operator (or, post-MVP, an adjudication mechanism) upholds cheating against it. Self-dealing cannot inflate this signal, because only non-refundable deposits move it.
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. Stake is a bond, not a mechanism. Today the adjudicator would be the marketplace operator; making adjudication stake-backed and panel-based is the post-MVP path.
- 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)
Section titled “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. Green bars pass the safety check, red bars fail.
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
Section titled “Design note: the deal as a game”The fee structure is live today and worth understanding formally. One modeling assumption applies throughout: outcomes are taken from signed receipts and requester acceptance. The model prices reliability incentives; it does not prove correctness (see above).
Definitions
Section titled “Definitions”Let
A service
where
A deal between requester
Payoffs
Section titled “Payoffs”Let
| 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
Section titled “Participation constraints”Requester participates if
Two-leg settlement analysis
Section titled “Two-leg settlement analysis”Let
Requester expected payoff:
Provider expected payoff:
Incentive compatibility
Section titled “Incentive compatibility”The provider is incentivized to maximize
The success fee acts as the provider’s marginal incentive for reliability.
Higher
Interactive: provider profit vs quality
Section titled “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.
X = provider quality (q). Green = provider profit. Blue = requester payoff with requester value fixed at 10 sat.
Optimal fee structure
Section titled “Optimal fee structure”With total price
This ensures the provider breaks even on failed executions while the success fee captures the surplus.
Network economics
Section titled “Network economics”Marketplace viability
Section titled “Marketplace viability”The marketplace charges
Viable when
Provider discovery value
Section titled “Provider discovery value”A provider’s expected value from marketplace registration:
Rational when
Network effects
Section titled “Network effects”The marketplace exhibits cross-side network effects. Steady-state:
where
Welfare analysis
Section titled “Welfare analysis”Total welfare:
The protocol pushes
- Reducing information asymmetry — signed receipts make outcomes attributable
- Reducing counterparty risk on settlement — HTLCs bind payment to acceptance
- Reducing search costs — the marketplace aggregates information
- Enabling price discovery — competition drives prices toward cost
In the limit of a large market: