How a Settlement Works
One trade, end to end, with no step glossed over. This describes the design, not running software.
The escrow state machine
Offer opened, escrow owned
The seller publishes an offer and moves USDC into an escrow that the offer itself owns — not a platform wallet, not a shared account. The offer is the only thing that can ever release it, and only along one of three paths.
If it fails · Nothing is committed until a buyer takes the offer. An untaken offer can be cancelled by its creator at any moment, and the USDC never left the seller's control.
Bank transfer from the buyer's own bank
The buyer sends the agreed amount from their own bank in PLN, EUR or USD, quoting the offer's reference. PayMoney never touches the money and the bank is never asked to integrate anything.
If it fails · Underpay and there is no proof to make. Overpay past the agreed band and there is no proof either — which is why the exact figure is shown before you send.
The session is notarised, then proven
The buyer's browser runs the bank session jointly with an independent notary, which co-signs the encrypted transcript without being able to read it. A zero-knowledge proof then shows that transcript contains the right reference and an amount inside the band — and discloses nothing else.
If it fails · No valid proof, no release. The escrow stays exactly where it is until a proof arrives or the window closes; there is no state in between.
Settled in the next epoch
Proofs accumulate, fold into a single recursive STARK, and land as one Ethereum transaction. The escrow moves to the buyer. If the operator stalls or censors, anyone can force the settlement through from Ethereum itself.
If it fails · If the window closes with no proof, the offer expires and the escrow returns to the seller. Every path ends on its own — none of them ends in a queue.
The problem it solves
The homepage states the framing: a bank payment has to be believed by someone. The answer it does not mention is the one most people actually use — a custodial exchange, which does not solve the verification problem so much as exchange it for a counterparty problem. You stop having to prove the payment because someone else holds both sides of it.
This design replaces the judgement call with evidence a contract can check. What follows is the whole of it.
The five stages
Escrow. The seller locks the asset into a contract that encodes the trade's terms up front — how long the window lasts, what proof releases the funds, and what happens if that proof never arrives. Nothing afterwards depends on the seller's continued cooperation.
The fiat payment. The buyer pays in złoty from their own bank account, over the transfer rail they already use. Nothing about the payment changes; what changes is what happens to the evidence of it.
The attestation. As the buyer views the confirmation in their online banking, a notary co-observes that TLS session and signs an attestation covering what was transmitted. It runs as multi-party computation over the live session, so the notary learns only what the protocol discloses — not the buyer's credentials, and not their balance.
Verification inside a proof. A STARK proof establishes that the attestation is genuine and that the payment it covers matches the trade: the right recipient, the right reference, and an amount at least what was agreed. The proof reveals none of the session itself, only that these conditions hold.
Release. The contract checks the proof and releases the escrow. No queue, no reviewer, no discretion. If the proof never arrives before the window closes, the escrow returns to the seller automatically — the same rule, not an exception to it.
What it costs in time
No stage is instant, and the honest shape of the cost is worth more than a number:
- The attestation is the slow part, and it is bound by bandwidth rather than computation. On a fast connection it is seconds; on a slow one considerably worse, because a large volume of cryptographic material crosses the wire before the bank session even begins.
- Proving adds its own time, dominated by one step — verifying the notary's signature inside the proof, which is the single largest component of the circuit.
- Settlement is batched into epochs and confirmed on Ethereum, so it inherits an L1 confirmation.
Anyone quoting a wall-clock number for this is guessing. The claim is not speed; it is that no human decides.
Where it stops working
Two constraints decide whether a given trade settles at all: one is a bank-side dependency that can retire a bank overnight, and the other is a detail of the amount check that costs money if you miss it. Both belong with the rest of the failure modes rather than as a footnote here — the risks page states them, and everything else, without softening. The protocol section documents the vault this settles on.