Architecture note
Security Is a Chain, Not a Label
“Post-quantum” is useful only when attached to a named layer and assumption. The inherited vault uses hash-based authorization and STARK settlement. PayMoney's fiat-evidence leg adds elliptic-curve cryptography that the unqualified vault claim does not cover.
Layer-by-layer account
| Layer | Target primitive | What security depends on |
|---|---|---|
| Epoch and action proofs | Circle STARK over M31 / QM31 with Stwo | STARK soundness, ZK mode, and pinned hash parameters |
| Commitments and nullifiers | Poseidon2-M31 under separated domains | Collision and preimage resistance |
| Proof-tree commitments | Blake2s-M31 FRI mixed Merkle commitment scheme | Collision resistance; switch to Poseidon2-M31 is a measured gate |
| Account authority | Hash-preimage knowledge and hash-based thresholds | Secret knowledge, distinct shares, complete action binding |
| Aggregator selection | Hash-based indexed VRF | Hash assumptions, precommitted inputs, bonded-set liveness |
| Mailbox transport | X25519 + ChaCha20-Poly1305 | Classical confidentiality; forward migration to ML-KEM or hybrid |
| Notary authorization | ECDSA-secp256k1 under the pinned offer key | EUF-CMA unforgeability and correct in-circuit verification |
| Bank origin | The bank's TLS server-authentication stack | Whatever RSA or elliptic-curve cryptography the bank deploys |
The accurate summary is post-quantum-plausible settlement core, classically secured fiat-evidence leg. A future quantum adversary can attack the notary key and the bank's origin authentication; the mailbox curve affects confidentiality rather than settlement authority.
Why ECDSA is verified inside the M31 AIR
TLSNotary's attestation uses ECDSA-secp256k1. PayMoney deploys no separate L1 verifier contract, and the inherited vault L1 boundary remains exactly deposit, settleEpoch, and withdraw, so the FiatOfferV1 execute leaf verifies the signature in-circuit.
Both scalar-multiplication bases are fixed for an offer: the secp256k1 generator and the notary key pinned in its immutable terms. Fixed-base comb tables remove doublings; the GLV endomorphism splits scalars into roughly half-width components. Non-native modular arithmetic uses witnessed quotients and remainders plus range checks instead of in-circuit division. These are target optimizations, not measured browser-proving claims.
One launch notary is the primary trust assumption
At launch the notary is self-hosted by PayMoney. A malicious notary colluding with a throwaway taker can sign a commitment that opens to the fact a claimed offer requires and drain that offer. There is no mechanism-level mitigation and no slashing path because detecting fraud would require the dispute machinery the architecture excludes.
The exposure is scoped: the notary appears only in claimed offers, cannot authorize ordinary wallet resources, and each offer is bounded by M_offer_max. The honest launch statement is therefore “trust PayMoney not to steal from escrowed offers,” not “trustless.” A later n-of-m notary set is a forward-only new deployment whose offer instances pin several keys; it is not a launch property.
What the proof actually authenticates
The circuit proves that an admitted rail template extracted a fact from authenticated HTTP response ranges in a notarized session. It binds the range indices and lengths, request semantics, response structure, final status, recipient, offer currency, integer-minor-unit amount, memo, claimant, rail, and session time. The amount assertion is expected ≤ observed ≤ expected + Δ, with one deployment-wide Δ.
It proves what the bank interface reported. It does not prove metaphysical fiat finality. A bank that exposes a misleading status, later reverses a supposedly final transfer, rewrites the memo, or changes response structure can make a cryptographically faithful proof certify the wrong external assumption. Rail-template admission is therefore part of security, not paperwork after it.
What the notary learns
MPC-TLS secret-shares the session keys, and the payment commitment is computed inside the 2PC VM. The notary learns the bank domain, rail-template identifier, disclosed-range binding, blinded commitment, and session time. It does not learn the amount, account handles, memo, or offer from those values. Both banks still see the ordinary fiat transfer, and Ethereum deposits and withdrawals remain public.
Function privacy has a global cost
FiatOfferV1 adopts strict global-max padding. Solve runs the ECDSA verifier; Cancel and Expire keep the same constraints live with satisfying dummy witnesses, a private branch selector, and branch-independent public inputs. This hides the terminal branch but makes every co-tenant pay the large secp256k1 trace budget. The cost is deliberate and must be measured against the prover's column and FRI headroom before deployment.
Current status
None of these controls is represented here as deployed assurance. Production remains gated on the prefix-free payment commitment, MPC/AIR Poseidon2 parity, branch-indistinguishability tests, in-circuit ECDSA verification, real bank TLS and rail measurements, written legal approval, measured Stwo economics, and an explicit privacy-leakage inventory.