Trust & Limits

SubEtha is not a system without trusted parties, and this site never claims otherwise. This section states the trust model explicitly: who must trust whom, for what, what happens at each boundary when something fails, and which claims are deliberately not made. The two companion pages go deeper on privacy — what SubEtha hides and what stays public and on key handling and failure behavior.

The trust map

who	must trust	for
payer	the facilitator and provider together	that once its funds are burned, the resource is actually served — the burn is irreversible, so a payer that paid and was refused holds a receipt, not a refund
payer	the facilitator	not to publish or misuse what it necessarily sees: the facilitator observes every payment in full, including who paid which provider
provider	the facilitator	for everything money-related: it derives the offers, judges verification, executes settlement, and controls when (and whether) the mint to the treasury happens. The provider holds no settlement keys at all
both	the local zERC20 stack	the chain, contracts, indexer, and prover it settles against — on this PoC, a stack you run yourself
everyone	the operator	the facilitator is a daemon someone operates; its journal, keys, and fee configuration are under that operator’s control

Two boundaries deserve emphasis:

• The facilitator is the trusted intermediary. The correspondence between payer and provider is hidden from on-chain observers — never from the facilitator, which derives every burn address and processes every payment. A facilitator that colludes with an observer can link anything.
• The provider is minimally trusted with secrets. In the shipped configuration the provider process holds no key, not even a payout EOA’s; the payout destination lives in the facilitator’s configuration. Trusting the provider means trusting it to serve what was paid for, nothing more.

Failure boundaries

What actually happens when things go wrong, per the pinned implementation:

• Settlement fails after the handler ran (TOCTOU). Verification is point-in-time, not a settlement guarantee: a payer can move its balance between verify and settle. Then settle fails after the resource handler executed — but the buffered response is discarded and the client gets a 402. The provider loses compute, never funds; ordinary rate limiting is the stated mitigation.
• A real burn lands too late. Offers expire. If the burn’s inclusion block timestamp is after the offer’s expiry, the facilitator refuses it on every path. Whether to refund or re-invoice is explicitly a business decision for the treasury operator — nothing is automated.
• A reorg erases an accepted burn. The finalize pass re-verifies chain evidence before minting and marks the entry failed rather than minting on vanished evidence. If the resource was already served, that record is the loss event — there is no automatic compensation or re-charge.
• An outcome is unknown (timeout, lost response, restart mid-settle). The rule for every party is: re-send the same payload, never build a fresh one. Accepted payments replay idempotently and a broadcast permit burn is never double-executed; a fresh payload risks paying twice.
• The facilitator restarts. The journal restores pending mints. Running with journal = "none" is for throwaway local experiments only — a restart then abandons accepted-but-unminted payments.

Claims this site does not make

• Not production-ready. Payment acceptance is local-experiment only: the facilitator refuses to accept payments under any non-local profile, and the whole stack is a local PoC. Commercial or production use of the @zerc20/sdk dependency (BUSL-1.1) additionally requires a separate grant from the zERC20 licensor.
• No absolute concealment claims. Amounts are public; the treasury address appears at mint time; small payment volumes weaken the anonymity set to the point where timing and amount coincidences suggest links. The precise claim — correspondence-hiding against on-chain observers, with five standing caveats — is stated in full at what SubEtha hides — and what stays public.
• No claim that every party is honest-but-verifiable. The facilitator’s correct behavior is assumed, not enforced by the protocol: it holds the settlement keys and the derivation seed. The one protocol-enforced guarantee a payer gets is the fail-closed serve: no confirmed burn, no resource — and the one it must accept is the mirror image: funds burn before the resource arrives.
• No hosted demo. Nothing on this site points at a running SubEtha service, and the license posture of the dependency is part of the reason.

Where the boundaries are specified

The wire-level behavior behind each boundary is normative in the wire protocol reference; the settlement states and their gap are Accepted vs finalized; key custody, profiles, and fail-closed behavior are Security; vulnerability reporting scope is the product repository’s SECURITY.md.