Trust & limitations

What Can Fail, and What the Architecture Does About It

Removing custody and discretion removes their failure modes. It does not remove bank risk, completion risk, notary trust, irreversible mistakes, or the cost of immutability.

The taker pays before the crypto transition settles

Fiat payment and crypto release cannot be physically atomic across an external bank rail and Ethereum. After sending fiat, the taker still has to complete the notarized session, generate the evidence proof, and reach epoch inclusion before the offer expires.

The wallet must check the live rail template, bank session, launch-notary availability, remaining epoch budget, payer balance, and rail prerequisites before showing payment instructions. It cannot prevent an outage, template drift, device failure, or censorship event that begins after payment. A taker who pays and cannot prove has no protocol recourse.

The amount has two hard bounds

The expected amount uses the offer currency's integer minor unit. The observed amount must satisfy expected ≤ observed ≤ expected + Δ, where Δ is one deployment-wide overpayment cap rather than a per-offer preference. Underpayment and excess overpayment are unprovable. Recipient, offer currency, memo, claimant, rail template, and accepted final status must also match.

The protocol cannot return fiat sent in error, and no administrator exists to manufacture an exception. The upper bound limits taker loss; it does not make an irreversible mistake refundable.

Expiry is the only griefing control

Claiming consumes the open offer, so a second claim is unprovable. If a taker claims and never pays, the maker must wait until the absolute settled-epoch budget has elapsed, then authorize Expire to consume the claimed offer and return the escrowed asset.

There is no claim bond, reputation score, slashing rule, dispute path, or arbitration. A taker can lock a maker's capital for the offer window while paying only the inherited FeeV1 action fee. The architecture accepts that cost rather than introducing a judge.

The launch notary can forge a claimed payment

One self-hosted notary signs the launch attestation. If that notary colludes with a taker, they can forge the payment fact required by any claimed offer. No protocol mechanism detects or slashes the fraud. M_offer_max bounds per-offer loss, and the notary has no authority over unclaimed or ordinary wallet resources, but the trust assumption remains direct.

A later n-of-m notary deployment can reduce single-operator risk. It does not retroactively change open offers, because notary keys are immutable offer terms and the architecture is forward-only.

The proof certifies the bank interface, not reality beyond it

A rail template proves what an authenticated bank response reported. If the bank labels a reversible entry final, exposes the wrong recipient field, rewrites the memo, or changes transaction semantics, the proof can faithfully certify a bad external fact.

Every admitted template therefore needs a documented semantic contract for its completed status, stable fields, and session-time meaning, plus repeated reconciliation against production behavior. The concrete Polish profile specifies BLIK P2P, Express Elixir, and same-bank internal transfers. Every other currency/rail combination requires separate admission evidence.

A bank can become unsupported without warning

The target permits direct MPC-TLS only. A proxy mode changes the threat model and cannot activate as an automatic fallback. A TLS change, WAF rule, login challenge, response-schema change, or session deadline can make the evidence path stop working.

Rail templates are immutable protocol data. Compatibility returns through a reviewed new deployment, not a mutable parser registry or best-effort schema guess. TLSNotary's TLS-version support is an external dependency that must be tracked as a launch metric.

Banking access and Polish law are launch blockers

On-device, user-consented access minimizes disclosure; it does not decide whether automating a consumer bank session is permitted. Each template needs written Polish review covering bank terms, credential handling, payment-services regulation, privacy roles, sanctions and AML duties, and computer-misuse risk.

PayMoney offers are settlement instructions, not invoices. Businesses remain responsible for invoicing, accounting, tax, reporting, and regulatory duties independently of the protocol.

Privacy begins after deposit and ends at withdrawal

Ethereum deposits and withdrawals are public. Inside the vault, the target hides participants, amounts, destination, offer, bank transaction, and concrete rail template. Strict global-max padding is intended to hide whether Solve, Cancel, or Expire ran, at a high proving cost.

The fiat transfer remains visible to both banks and may carry legally required identity data. The notary learns the bank domain and session time plus a blinded commitment, not the payment plaintext. This is private trade-graph settlement, not anonymous banking.

Users own the data needed to spend

Keys and resource witnesses stay user-controlled. Losing either may permanently destroy liveness for the affected resource without giving anyone else control. Guardian recovery can address an authority key only if configured beforehand; it cannot recreate missing witness data.

Aggregation can delay even when it cannot forge

The solver and aggregator cannot invent valid bank evidence or account authority. They can censor or delay an action. The vault answers with a bonded aggregator set, hash-based iVRF rotation, CheckpointDemand, and ForcedInclusion. It explicitly rejects VDF rotation; L1 congestion and unavailable proof capacity can still delay everyone.

Immutability makes defects permanent until users move

There is no administrator, pause switch, upgrade key, emergency parser, or in-place migration. That removes privileged compromise from the deployed state machine and makes a bug a redeployment event. It is an advantage only when deployment identifiers, wallet discovery, asset continuity, and communication are rigorous.

Nothing here has passed the production gates yet

Production requires machine-checked completeness and offer-state models; payment commitment injectivity; MPC/AIR hash parity; branch-indistinguishability tests; audited in-circuit ECDSA; real bank TLS and rail measurements; written legal approval; measured Stwo economics and L1 gas; and an explicit privacy inventory.

A failed gate excludes the template or deployment. It does not activate a substitute path.