Field note
TLSNotary: Prove the Bank Response Without Publishing It
Ethereum cannot observe whether a bank booked a transfer, and PayMoney deliberately does not represent fiat as an on-chain asset. The fiat leg enters the resource machine as an authenticated fact produced from one live banking session.
The payer and the launch notary run a direct two-party TLS session to the intended bank host. The payer retains credentials and plaintext response fields. Inside the joint computation, selected ranges are encoded into a blinded Poseidon2-M31 commitment. The notary signs the server domain, request/template binding, disclosed-range binding, commitment, and session time.
What the notary is meant to learn
The notary participates in TLS computation but is not meant to receive the payment amount, bank handles, memo, offer identity, or plaintext record. The proof later opens the commitment privately and shows that the authenticated bank response satisfies the immutable rail template.
The template defines where to find and how to normalize:
- the ISO currency committed in the offer;
- observed integer minor units under that currency's template;
- committed recipient;
- the claim-derived
PM1-…memo; - authenticated claimant account;
- a booked or final status admitted by that rail.
The observed amount must satisfy expected ≤ observed ≤ expected + Δ, with one global Δ. A pending, ambiguous, stale, mismatched, underpaid, or excessively overpaid response has no valid witness.
Why ECDSA is inside the proof
The launch notary signs with a pinned ECDSA-secp256k1 key. The L1 contract verifies only the recursive Stwo epoch proof, so the ECDSA check must run inside FiatOfferV1's M31 AIR. That requires non-native limb arithmetic, fixed-base scalar multiplication, quotient hints, and strict range checks.
The trust assumption is not hidden
A malicious launch notary colluding with a taker can attest to a false payment and drain a claimed offer. It cannot move unrelated wallet resources, and a per-offer escrow cap bounds each exposure, but there is no slashing or detection mechanism that makes the launch path trustless.
A later n-of-m notary design is a new deployment. Open offers remain bound to the key and rules they committed when created.
Finally, proof generation can fail after fiat has moved. Preflight tests the live host, template, session, notary, device, and remaining epoch budget before showing payment instructions, but it cannot insure an outage that starts later. This buyer-side completion risk is part of the protocol's honest boundary.