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 payment model in one sentence: the payer burns tokens to a one-time address derived for that payment; after the payment is accepted, the facilitator later drives a proof-gated mint to the configured treasury or FeeSplit recipient.

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 payment evidence in the SettleResponse, not a refund; see Accepted vs finalized
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 zERC20 stack	the chain, contracts, indexer, and prover it settles against
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 externally owned account (EOA) key; the payout destination lives in the facilitator’s configuration. Trusting the provider means trusting it to serve what was paid for, nothing more.

Two settlement states recur below: accepted is the synchronous request-path settlement state, and finalized is the later proof-gated mint landing at the treasury. The gap between them is explained in Accepted vs finalized.

Failure boundaries

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

• Settlement fails after the handler ran (time-of-check-to-time-of-use, 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" abandons accepted-but-unminted payments on restart.

Current acceptance scope

In the current release, payment acceptance is enabled only when the deployment explicitly uses profile = "local". This is current release scope, not a permanent protocol limitation. Non-local acceptance remains gated until the per-profile confirmation/finality policy is implemented and tested.

Loopback binding, loopback RPC, and chain 31337 are separate safety predicates for using the well-known Anvil development keys; they are not additional conditions on every local deployment. A non-loopback local deployment requires the configured admin token and must follow the operator security checks.

Claims this site does not make

• 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 its 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 protocol-enforced provider-side guarantee is fail-closed serving: no confirmed burn, no resource. The payer-side trade-off is the mirror image it must accept: funds burn before the resource arrives.

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.