Settlement lifecycle
How One Settlement Works
One path from an open offer to settlement, with the failure boundary shown at every stage. This is the target architecture, not running software.
The unique settlement path
The maker fixes the entire offer
The maker selects an audited crypto kind, crypto quantity, one admitted fiat currency, exact integer minor-unit amount, approved rails and adapters, destination commitment, claim lifetime, and minimum bond. The offer resource owns the escrow; PayMoney does not.
If it fails · An open offer can be cancelled by its maker. Cancellation returns the escrow and is impossible after a claim exists.
The taker reserves it with a bond
Claiming consumes the open offer, posts a mandatory fungible bond, selects one permitted rail and adapter, and derives the exact PM1 payment memo. Only one active claim can exist for an offer.
If it fails · If the claim expires unsettled, the offer reopens and the bond goes to the maker. Capital locking therefore has an explicit cost.
The unique proof path is checked first
Before showing payment instructions, the wallet checks the direct MPC-TLS route, authenticated account, adapter, two reachable notaries, remaining epoch lifetime, payer balance, and any rail-specific prerequisites.
If it fails · A failed preflight never authorizes settlement and never asks the taker to pay. It is a safety check, not substitute evidence.
Exact payment becomes private evidence
The taker sends the exact committed fiat amount and memo. Three independent TLSNotary sessions bind the authenticated bank response; a zero-knowledge proof requires two matching attestations and exact recipient, amount, currency, memo, claimant, rail, adapter, transaction, and final status.
If it fails · Any mismatch, unsupported schema, pending status, notary disagreement, or reused transaction identifier makes settlement unprovable.
The action settles inside a vault epoch
The PayMoney action folds into the vault's recursive STARK. Ethereum verifies the aggregate epoch transition rather than a public PayMoney trade: crypto and the claim bond move to the taker while the fiat remains with the maker.
If it fails · After the settled-epoch deadline, a reclamation proof reopens the offer and pays the bond to the maker. There is no wall-clock expiry or manual dispute branch.
The question PayMoney answers
A crypto-to-fiat trade eventually asks whether the fiat payment really happened. Custodial exchanges answer by holding both sides. P2P marketplaces often answer with a reviewer, a screenshot, or a dispute process. PayMoney's target is narrower: produce a cryptographic proof of one exact, authenticated bank fact and let that fact authorize one vault transition.
The fiat transfer and crypto release are not physically simultaneous. After paying and before producing a valid proof, the taker carries real completion risk. The architecture reduces that risk with a mandatory preflight; it does not pretend to eliminate it.
The state machine
The offer has two non-terminal states and four legal transitions:
- Open → Claimed. A taker posts the required bond and reserves the offer.
- Open → Cancelled. The maker cancels before any claim and receives the escrow back.
- Claimed → Settled. Exact bank evidence releases crypto and returns the taker's bond.
- Claimed → Reclaimed. After the settled-epoch deadline, the offer reopens and the bond pays the maker for locked liquidity.
There is no Failed state and no evidence fallback. Invalid inputs have no witness. Cancelled and Reclaimed are ownership transitions that prevent value from becoming trapped, not alternative ways to approve a payment.
What the evidence proves
The payer's wallet runs separate direct MPC-TLS sessions with three independent notaries. Each session is tied to the intended bank host, request, authenticated response, immutable bank adapter, and one notary signing index. The evidence circuit accepts at least two attestations only when they resolve to the same normalized payment fact.
That fact must match the claim and offer exactly:
- one admitted fiat currency (USD, EUR, GBP, or PLN) and unsigned integer amount in its minor units
- committed recipient
- claim-derived
PM1-…memo - authenticated claimant account
- selected instant rail and immutable adapter
- adapter-approved booked or final status
- unique bank transaction identifier that has never settled before
There is no tolerance, Unicode guess, fuzzy recipient match, optional field, pending-state interpretation, or floating-point arithmetic.
What Ethereum verifies
PayMoney does not add a public settlement function to Ethereum. The evidence proof, offer logic, claim logic, escrow, bond, account authority, fee, and resource-conservation checks become one private action. Actions are recursively aggregated into the vault's epoch proof.
The existing vault contract accepts the aggregate proof and new authenticated roots through its settleEpoch boundary. It does not receive the offer, payer, payee, bank, memo, fiat amount, or transaction identifier as public PayMoney calldata.
What determines completion time
The protocol does not promise a wall-clock duration. Direct MPC-TLS is bandwidth-sensitive, a two-of-three quorum needs independent sessions, local proving has a device cost, aggregation waits for an epoch, and L1 settlement inherits Ethereum confirmation. Claim expiry is measured in settled roots, not minutes.
Those quantities are launch measurements, not marketing estimates. A bank adapter is excluded if the complete path cannot meet its measured safety budget on real consumer networks.
Where the path stops
A bank schema change, WAF, login challenge, TLS incompatibility, unstable transaction record, ambiguous status, unavailable quorum, device failure, or expired claim can stop proof generation. Preflight catches conditions already present before payment; it cannot cure an outage that begins after payment.
Read the trust and risk register → · Inspect the vault architecture →