Project thesis

Architecture Before Product Claims

PayMoney begins with one question: can a bounded, authenticated fiat payment authorize release of an escrowed fungible asset without giving a platform custody or discretion? The published architecture answers with a fixed offer, resource-owned escrow, one TLSNotary attestation, and one private vault transition.

It is a design under evaluation, not a live financial service. That distinction governs every page on this site.

The rule behind the project

An invalid outcome should have no valid witness. A payment either satisfies the deployment-wide two-sided amount bound and matches the offer's currency, recipient, memo, claimant, rail template, and final status, or it does not. The protocol does not ask a reviewer or add a fallback state.

That rule removes operational discretion and makes failure sharper. A bank incompatibility stops a rail template. A mistaken payment cannot be refunded by the protocol. A defect requires a new immutable kind or deployment. Those are costs of the architecture, not details to discover after launch.

A settlement layer, not a platform

PayMoney's sole protocol function is to release an escrowed fungible asset against proof of a bounded booked fiat payment. It does not provide:

• an exchange-rate oracle, order book, or dynamic quote
• a bank account, fiat custody service, or wrapped fiat balance
• an invoicing, accounting, or tax-compliance system
• an arbitration desk, manual release, chargeback, or administrative recovery path
• a reputation network or mutable bank-parser registry
• a separate PayMoney smart contract on Ethereum

The product boundary is narrow so the proof predicate can be narrow.

Built from existing ideas, composed for one target

The underlying resource model follows the lineage of predicate-controlled resources and private note systems. Native account policies take the account-abstraction idea seriously. Stwo supplies the circle-STARK proof family. TLSNotary supplies the direct MPC-TLS session model. Immutable rail-template commitments turn bank-specific semantics into reviewable protocol inputs rather than runtime guesses.

PayMoney's contribution is the composition: one FiatOfferV1 kind inside a shared privacy vault, with self-owned escrow, a TLSNotary payment fact, and aggregate Ethereum settlement.

The principles and their costs

1. Two-sided amount bound. Underpayment and overpayment beyond global Δ are unprovable. Cost: the protocol still cannot refund an irreversible fiat mistake.
2. Proof-only release. The maker cannot withhold crypto after payment. Cost: the taker must complete the proof path before expiry.
3. Expiry-only griefing control. A claimed offer eventually returns escrow to the maker. Cost: a taker can lock capital for the offer window without posting a bond.
4. One launch notary. Fiat evidence has one explicit operator. Cost: a colluding notary and taker can drain a claimed offer, bounded only by scope and the per-offer cap.
5. Immutable logic. A compromised administrator cannot rewrite settled rules. Cost: fixes and bank changes require new identifiers and deliberate user movement.
6. Private actions, public edges. Bank facts and trade details stay inside proofs. Cost: deposits, withdrawals, and external-evidence-class activity remain visible.

What counts as progress

Progress is evidence against the launch gates: formal transition models, test vectors, audited cryptography, crash-safe notary state, bank compatibility measurements, written local legal approval, proof-cost and L1 benchmarks, and a verified privacy inventory.

A polished interface, a list of banks, or a promised transaction time is not a substitute for any of them. Until those gates pass, every protocol statement on this site should be read as a target specification.

Read the uncomfortable part first

The trust and risk register explains where the architecture still depends on banks, notaries, devices, operators, and law. The settlement lifecycle then shows how the happy path and reclamation path fit together.