Project thesis

Architecture Before Product Claims

PayMoney begins with one question: can a precisely matching bank payment authorize crypto release without giving a platform custody or discretion? The published architecture answers with a fixed offer, resource-owned escrow, a bonded claim, quorum-attested bank evidence, 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 matches the offer's committed fiat currency, integer minor-unit amount, recipient, memo, claimant, rail, adapter, unique transaction, and final status or it does not. The protocol does not interpret “close enough,” ask a reviewer, or add a fallback state.

That rule removes operational discretion and makes failure sharper. A bank incompatibility stops an adapter. 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 escrowed crypto against proof of an exact 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 adapter commitments turn bank-specific semantics into reviewable protocol inputs rather than runtime guesses.

PayMoney's contribution is the composition: exact currency-specific fiat offers and bonded claims inside a shared privacy vault, with two-of-three hash-based notary authorization and aggregate Ethereum settlement.

The principles and their costs

1. Exact equality. No overpayment tolerance or refund semantics. Cost: any mismatch is unprovable after an irreversible fiat transfer.
2. Proof-only release. The maker cannot withhold crypto after payment. Cost: the taker must complete the proof path before expiry.
3. Bonded claims. Reserving liquidity has an explicit price. Cost: griefing is bounded, not eliminated.
4. Two-of-three notaries. One compromised operator cannot forge settlement. Cost: three independent direct MPC sessions increase bandwidth and operational complexity.
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.