Frequently Asked Questions

A privacy-preserving, non-custodial crypto-to-fiat settlement protocol designed as an application inside an Ethereum-settled resource vault. Its sole function is to release escrowed crypto when a payer proves an exactly matching, booked fiat payment through an approved bank adapter.

No. It provides no order book, dynamic quote, exchange-rate oracle, bank account, fiat custody, wrapped fiat, invoice, chargeback process, arbitration desk, or manual release. The maker fixes the offer; the protocol evaluates one payment predicate.

USD, EUR, GBP, and PLN. Each offer commits exactly one currency and an unsigned integer amount in that currency's minor units. Cross-currency conversion and floating-point money remain outside the target: the protocol compares the committed currency and amount exactly.

Any audited FungibleV1 kind selected by the maker and recognized by a wallet's published social allowlist. The PayMoney application is asset-neutral; it does not hard-code USDC as the only trade asset.

The maker commits one exact crypto quantity, fiat currency, and integer minor-unit amount before the offer opens. The maker may consult any off-chain source beforehand, but the protocol contains no market price, slippage, repricing rule, or rate feed after commitment.

Settlement becomes unprovable. The bank currency and integer minor-unit amount must equal the offer exactly; there is no tolerance band, at-least rule, partial settlement, or fiat refund path. The same exactness applies to recipient, memo, claimant, rail, adapter, transaction ID, and final status.

Claiming consumes the open offer, selects a permitted rail and adapter, derives one exact payment memo and expiry root, and posts a mandatory fungible bond. Only one active claim can exist because a second claim would have to consume the same offer twice.

After the claim's settled-epoch lifetime, a reclamation proof reopens the offer, keeps the crypto under the new open offer, and pays the bond to the maker. The bond prices locked liquidity; it does not make denial of service impossible for a wealthy attacker.

The payer's wallet runs separate direct MPC-TLS sessions with three independent notaries. A zero-knowledge evidence proof accepts at least two matching attestations and proves exact field extraction, final status, claim binding, and transaction non-reuse without publishing the bank record.

Not under the target quorum. Two of three pinned notaries must attest the same normalized fact. Two colluding or jointly compromised operators can still forge, so independence of hosting, credentials, administration, and signing state is a launch requirement.

No. The bank evidence is checked inside the private action, which folds into the vault's recursive epoch proof. Ethereum sees the aggregate proof and state roots, not the payer, payee, offer, amount, bank, memo, transaction identifier, or concrete adapter.

Deposits and withdrawals are public, and the proof shape reveals that an external-evidence-class action occurred in an epoch. Both banks see the ordinary fiat transfer. Privacy covers the post-deposit vault transition and bank proof, not anonymous banking or invisible L1 entry and exit.

The target vault proofs, commitments, account authorization, notary signatures, and aggregator selection rely on hashes rather than RSA or elliptic-curve authorization. Bank origin authenticity still inherits the bank's classical TLS certificate and handshake. The system must not be described as end-to-end quantum safe.

Support is adapter-, rail-, currency-, and jurisdiction-specific rather than universal. A concrete bank path is admitted only after production TLS, WAF, schema, status, finality, privacy, performance, and applicable legal gates pass. No bank list is promised before that evidence exists.

The taker bears completion risk after sending irreversible fiat. Before showing payment instructions, the wallet must check the direct MPC route, account session, adapter, notary quorum, remaining epoch lifetime, balance, and rail prerequisites. Preflight reduces known failure; it is not settlement evidence and cannot prevent a later outage.

Neither has a defensible production figure yet. Direct MPC bandwidth, quorum sessions, proving, epoch inclusion, Ethereum confirmation, claim lifetime, bond policy, and fee policy must be measured and bound in a deployment manifest. Published estimates before those gates pass would be guesses.

No. The architecture has no administrator, pause switch, upgrade key, force-release command, or dispute transition. An open maker can cancel; a valid claimed offer can settle; an expired claim can be reclaimed. Fixes require a new immutable kind or deployment.

Not yet. Every bank adapter requires written local review of terms, automated access, credential handling, payment-services rules, privacy roles, sanctions and AML obligations, and computer-misuse risk. A PayMoney offer is not an invoice; business users remain responsible for local tax, accounting, reporting, and other legal duties.

No. This site presents an architecture of record. The protocol, notary network, bank adapters, production wallet, audits, legal approvals, performance measurements, and deployment gates are not represented as complete. Treat each mechanism as a target specification.