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](/concepts/privacy/) and on [key handling and failure behavior](/trust/security/). ## 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](/concepts/privacy/). - **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](/reference/protocol/); the settlement states and their gap are [Accepted vs finalized](/concepts/accepted-vs-finalized/); key custody, profiles, and fail-closed behavior are [Security](/trust/security/); vulnerability reporting scope is the product repository's [`SECURITY.md`](https://github.com/peaceandwhisky/SubEtha/blob/638fa1e9ca7face19a442cef43754f0d627c7705/SECURITY.md).