Architecture
Application Logic Inside a Private Resource Vault
PayMoney is not a bespoke escrow contract. It is an application family inside a semantics-neutral Ethereum-settled vault: the vault proves resource structure, while immutable PayMoney kinds define valid currency-specific crypto-to-fiat settlement paths.
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.
PayMoney kinds own those meanings. PayMoneyOfferV1 controls the escrow, currency-specific amount, and offer state machine. PayMoneyClaimV1 reserves an offer, derives its memo and expiry, and owns the posted bond. BankPaymentEvidenceV1 proves that an immutable adapter extracted one matching, final bank fact from a quorum of authenticated sessions.
Ordinary FungibleV1 resources carry the crypto and the claim bond. There is no PayMoney token, fiat representation, mutable adapter registry, or separate L1 settlement contract.
One private action, one public boundary
Settlement combines the offer, claim, escrow, bond, 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 bank adapter 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 hash-based notary signatures, real bank compatibility per currency and rail, 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
Hash-based settlement and notary authorization, a two-of-three quorum, and one explicit classical boundary: the bank's own TLS server 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, exact bank facts, settlement, and reclamation. That keeps public settlement and application semantics separate.
Which PayMoney-specific kinds exist?
Three families: PayMoneyOfferV1, PayMoneyClaimV1, and BankPaymentEvidenceV1. Each offer binds one admitted fiat currency and integer minor-unit amount. Escrow and claim bonds remain ordinary FungibleV1 resources, so PayMoney does not create a special token or duplicate the vault's conservation machinery.
Which crypto assets can an offer use?
Any audited FungibleV1 kind selected by the maker and recognized by the wallet's social allowlist. The protocol does not bless USDC or any other asset at genesis; an asset's canonical identity is a published social fact backed by its logic commitment and audit.
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. Bank adapters 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.