Frequently Asked Questions

A privacy-preserving, non-custodial crypto-to-fiat settlement design implemented as one asset-neutral FiatOfferV1 kind inside an Ethereum-settled resource vault. Its job is to release self-owned fungible escrow when a taker proves the required bank payment.

No. It provides no order book, rate oracle, bank account, fiat custody, invoice, chargeback process, arbitration desk, or manual release. The maker fixes one offer and the proof evaluates its payment predicate.

Yes. Each offer commits an escrow_kind_id naming an admitted FungibleV1 instance and an ISO-4217 fiat_currency. That schema capability is broader than any one deployment's admitted assets and rail templates. USDC/PLN is the concrete Polish profile and worked example, not a hardcoded application boundary.

The maker commits an asset kind and quantity plus an expected fiat amount in that currency's integer minor unit before posting. The protocol contains no market price, slippage, repricing rule, or rate feed.

The observed amount must satisfy expected <= observed <= expected + Delta. Delta is one global deployment policy, not a per-offer tolerance. Underpayment or excess overpayment is unprovable, and the protocol cannot refund fiat already sent.

Claim consumes the Open offer and creates Claimed with the taker's account and an absolute claim-anchor epoch. Consuming Open gives claim exclusivity: a second claim has no witness. There is no claim bond.

Once the epoch budget has elapsed, the maker authorizes Expire. It consumes the Claimed offer and returns the escrowed asset to the maker. The offer does not reopen; expiry is the only protocol griefing control.

The payer runs MPC-TLS with one self-hosted launch notary. The notary signs a blinded, range-bound payment commitment with ECDSA-secp256k1, and FiatOfferV1 verifies that signature and the opened payment fact inside the Stwo M31 AIR.

Yes, if it colludes with a taker. That pair can drain a claimed offer. The notary cannot move ordinary wallet resources, and a per-offer cap bounds exposure, but there is no protocol detection or slashing path. A later quorum requires a new deployment.

BLIK P2P, Express Elixir, and same-bank internal transfers. Each admitted bank flow needs an immutable, reviewed rail template that binds the exact request and response ranges. Other currencies and rails require their own admitted templates; neutrality is not an availability promise.

Exactly Open and Claimed. Solve, Cancel, and Expire consume the offer and are terminal transitions, not stored states. Post, Claim, Solve, Cancel, and Expire are the five Action shapes.

Deposits, withdrawals, and the fiat transfer remain public to their normal observers. Inside the vault, commitments, nullifiers, and global-max-padded proofs hide the trade graph and terminal branch. This is private settlement, not anonymous banking.

The vault settlement core uses hashes, Shamir sharing, and Stwo STARKs. PayMoney's launch notary uses secp256k1 ECDSA, the mailbox uses X25519, and the bank TLS stack is classical. Therefore the honest claim is a post-quantum-plausible settlement core with a classical fiat-evidence leg.

No. It uses the vault's immutable deposit, settleEpoch, and withdraw boundary. Offer semantics live in FiatOfferV1 proofs, and there is no PayMoney admin, pause, or upgrade key.

No. This site publishes a pre-production architecture. Formal verification, circuits, in-circuit ECDSA, bank compatibility, legal review, proving economics, privacy testing, and L1 measurements remain launch gates.