The Anatomy of a P2P Trade: From Offer to Settlement

By Inveil Research · Updated October 22, 2024

A P2P trade looks simple from the outside — you pay, you get crypto — but underneath it's a precise sequence of on-chain actions, each one closing a specific risk. An offer becomes a funded order, collateral and crypto lock into escrow, the fiat leg settles off-chain, and the contract releases funds atomically once conditions are met. Walking through the anatomy shows exactly where your protections kick in and why each step exists.

Step 1: The offer

A trader posts an offer — buy or sell, an amount, a price, and accepted fiat rails. On an on-chain platform this offer lives as contract state, not a row in a private database, so it's publicly visible and discoverable directly from the chain. Posting an offer typically requires a small listing cost, which exists to stop spam offers from flooding the market. At this stage nothing is committed between two parties yet — it's an open invitation.

Step 2: Taking the offer → an order is created

When a counterparty accepts, the offer becomes an order: a specific trade between two specific addresses. This is the moment the trade's terms freeze. A well-designed contract snapshots the rules — fees, arbitration cost, timeouts — onto the order itself, so no later change by the operator can reach back and alter a deal already underway. The order now has a defined lifecycle the contract will enforce.

Step 3: Funding → escrow locks

Both sides commit funds into smart-contract escrow. The seller locks the crypto being sold plus a stake; the buyer locks their stake. This is what makes the trade self-enforcing: with collateral on both sides, cheating costs more than completing honestly. The funds are now held by code, not by either party or the operator — neither side can grab both legs.

The lifecycle at a glance

Stage	On-chain action	What it protects
Offer	Offer posted as contract state	Public, discoverable, spam-resistant
Order	Offer taken, terms snapshotted	Terms can't change mid-trade
Funding	Crypto + stakes locked in escrow	Neither side can take both legs
Fiat leg	Off-chain payment sent	(Off-chain — the risk surface)
Confirmation	Receiver marks payment received	Triggers release conditions
Settlement	Contract releases atomically	All-or-nothing, no stuck state

Step 4: The fiat leg

Now the off-chain payment happens — a bank transfer or cash. This is the only step the blockchain can't see, and therefore the one that carries real risk. The buyer sends fiat; the seller waits for it to genuinely settle. Everything the contract does around this step exists because this step is unverifiable on-chain.

Step 5: Confirmation

The party receiving fiat confirms receipt on-chain once the money has truly, irreversibly arrived — not when it merely shows as pending. This confirmation is what tells the contract the off-chain leg is done. Confirming too early is the classic costly mistake; the contract trusts the confirmation, so it has to be real.

Step 6: Settlement (or timeout, or dispute)

With conditions met, the contract settles: it releases the crypto to the buyer and returns the stakes, all in one atomic operation — the trade either completes fully or not at all, with no half-finished state where funds get stuck. Two alternate paths exist if the happy path doesn't hold:

• Timeout — if a party goes silent, timeout rules prevent funds being held hostage, resolving the order without the unresponsive party.
• Dispute — if the two sides disagree about the fiat leg, the order routes to on-chain arbitration, where evidence decides the outcome and the contract enforces it.

Why mapping the anatomy matters

Each step closes a specific risk: the offer is public so it can't be faked privately; the order freezes terms so they can't shift; escrow locks both legs so neither can be stolen; confirmation gates release on real payment; settlement is atomic so nothing gets stranded; and timeout and dispute paths handle the cases where the happy path breaks. When you can see the whole sequence, you understand exactly what protects you and where your own judgment — confirming only on real settlement — is the irreplaceable part.

Bottom line

A P2P trade is a state machine: offer → order → funded → fiat → confirmed → settled, with timeout and dispute as escape hatches. The contract enforces every on-chain transition; the one step it can't enforce is the fiat leg, which is precisely why escrow, snapshots, timeouts, and arbitration are built around it. Knowing the anatomy turns "I hope this works" into "I know what each step is doing."

FAQ

What happens to my funds at each stage of a P2P trade?

They move through defined states: uncommitted at the offer stage, locked in escrow once the order is funded, and released atomically at settlement. Between funding and settlement, neither you, the counterparty, nor the operator can take the funds — they're held by the contract and only move when release conditions, a timeout, or a dispute ruling are met.

When are the terms of a P2P trade locked in?

At the moment the offer is taken and the order is created. A well-designed contract snapshots the fees, arbitration cost, and timeouts onto the order itself, so any later change the operator makes applies only to future trades — not the one already underway. Your deal's terms are frozen at the start.

What's the riskiest step in a P2P trade?

The fiat leg — the off-chain bank transfer or cash payment — because it's the one step the blockchain can't verify. Everything else is enforced by code, but the contract has to trust the receiver's confirmation that the money arrived. That's why you should confirm only when funds are genuinely irreversible.

What if the other party stops responding mid-trade?

Timeout rules handle it. If a counterparty goes silent after a defined window, the contract resolves the order without them so your funds aren't held hostage by inaction. If instead both sides actively disagree about the fiat payment, the order goes to on-chain arbitration, where evidence decides and the contract enforces the result.