Architecture
Application Logic Inside a Private Resource Vault
PayMoney is not a bespoke escrow contract. It is one FiatOfferV1 kind inside a semantics-neutral Ethereum-settled vault: the vault proves resource structure while that kind defines the asset-neutral crypto-to-fiat offer lifecycle and payment predicate.
The separation that carries the design
The vault treats every value encoding as opaque. Its universal proof layer can establish that a resource exists, was authorized, was consumed once, and appears in exactly one complete kind partition. It cannot infer that a number is a fiat minor-unit amount, that an offer is open, or that a bank status means booked.
FiatOfferV1 owns those meanings. Its immutable terms bind escrow_kind_id, asset quantity, ISO-4217 fiat currency, expected integer-minor-unit amount, recipient, rail template, launch notary key, fee policy, and expiry budget. Its sealed Open | Claimed state controls escrow release. A TLSNotary attestation is private witness data verified inline by the kind's execute predicate; it conserves nothing and therefore is not another resource kind.
Ordinary FungibleV1 resources carry the selected escrow asset. There is no PayMoney token, fiat representation, claim bond, mutable template registry, or separate L1 settlement contract.
One private action, one public boundary
Settlement combines the offer, escrow, bank evidence, account authority, fee, resource conservation, and payment replay nullifier into one action digest. The evidence is therefore not a reusable credential that can be moved to another offer or epoch.
The action is recursively aggregated with other vault activity. Ethereum observes the epoch proof, archive roots, aggregate fee data, deposits, and withdrawals. The concrete PayMoney kind and rail template stay hidden within the public external-evidence proof class.
Architecture status
Everything in this section is a target architecture, not a description of running protocol software. The repository currently presents the design and its engineering scaffold. Production deployment remains gated on formal models, audited in-circuit secp256k1 verification, real Polish bank compatibility per rail template, jurisdiction-specific legal approval, proof economics, privacy verification, and L1 benchmarks.
- Resources, Kinds and the Completeness Invariant
Why the proof layer refuses to know what a balance is, and what it checks instead.
- Accounts, Multisig and Social Recovery
An account is an authority policy, not a credential: single key, m-of-n threshold, or guardian recovery — all three curve-free.
- Security Is a Chain, Not a Label
A hash-based settlement core with three explicit classical boundaries: mailbox transport, the launch notary's ECDSA key, and the bank's own TLS authentication.
Frequently Asked Questions
Why does PayMoney use a general vault?
The vault already proves resource uniqueness, authority completeness, membership, non-membership, and complete partitioning. PayMoney adds only the domain rules for offers, claims, bounded bank facts, and terminal transitions. That keeps public settlement and application semantics separate.
Which PayMoney-specific kinds exist?
Exactly one: FiatOfferV1. Its two live states are Open and Claimed; Post, Claim, Solve, Cancel, and Expire are the complete Action set. The escrowed asset remains an ordinary FungibleV1 resource, while bank attestation data is private witness material rather than another kind.
Which assets and fiat currencies can an offer use?
FiatOfferV1 commits an escrow_kind_id naming an admitted FungibleV1 instance and an ISO-4217 fiat_currency in every offer. The kind is neutral; actual availability remains deployment-scoped because each asset identity and currency/rail template must be admitted. USDC/PLN is the Architecture of Record's concrete Polish profile and worked example.
Does Ethereum verify the bank proof directly?
No. Bank evidence is verified inside the private PayMoney action, which folds into the recursive vault epoch proof. Ethereum receives the aggregate proof and updated vault roots, not a public offer, bank record, payer, payee, amount, or PayMoney-specific function call.
Can a deployment be upgraded or paused?
No. Rail templates and application kinds are immutable commitments, and the vault contract has no administrator, pause key, or upgrade path. A schema, parameter, or rule change produces a new kind or deployment with a new identifier.