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 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 bounded, authenticated fiat 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 exactly two live states: Open and Claimed. Solve, Cancel, and Expire are terminal transitions that consume the offer rather than states stored after it:

1. Open → Claimed. One taker consumes the open offer and records their account plus an absolute claim-anchor epoch.
2. Open → consumed by Cancel. The maker receives the escrow. Cancel is unreachable from Claimed.
3. Claimed → consumed by Solve. Valid bank evidence releases the escrowed asset to the taker and collector.
4. Claimed → consumed by Expire. After the epoch budget, the maker receives the escrow. The offer does not reopen.

There is no Failed, Proven, Settled, or Reclaimed offer state and no evidence fallback. Invalid inputs have no witness. Preflight, payment, proof generation, and L1 inclusion are operational stages around the protocol machine, not additional state constructors.

What the evidence proves

The payer's wallet runs one direct MPC-TLS session with the launch notary. The session is tied to the intended bank host, request, authenticated response, and immutable rail template. The notary signs the server domain, template, disclosed-range binding, blinded payment commitment, and session time with its pinned secp256k1 key; the Stwo M31 AIR verifies that ECDSA signature in-circuit.

That fact must match the claim and offer exactly:

• the offer's ISO fiat currency and an observed integer-minor-unit amount satisfying expected ≤ observed ≤ expected + Δ
• committed recipient
• claim-derived PM1-… memo
• authenticated claimant account
• selected immutable rail template; the concrete Polish profile specifies BLIK P2P, Express Elixir, and same-bank transfers
• template-defined booked or final status

There is no per-offer Δ, 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, FiatOfferV1 logic, escrow, 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, local proving has a device cost, aggregation waits for an epoch, and L1 settlement inherits Ethereum confirmation. Claim expiry compares an absolute settled epoch_id, not wall-clock minutes.

Those quantities are launch measurements, not marketing estimates. A rail template 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 notary, 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 →