Disputes — filing and evidence

Who can dispute a P2P trade and when, what the eight reasons mean, how priority is assigned, the two windows that decide whether a dispute is possible at all, and what happens to the escrow while one is open.

5 min readUpdated 3 August 2026disputes, escrow, evidence

A dispute is what happens when the two parties disagree about whether the fiat leg actually happened. The platform cannot see a bank transfer, so it does the only thing it can: freeze the crypto and hand the decision to a human.

Resolving one is on Resolving a dispute. This page is what the two traders experience and what your support desk will be asked about.

When a trade can be disputed

That follows from the trade state machine: PAYMENT_SENT is the only status with DISPUTED as a legal successor.

  • A PENDING trade cannot be disputed — nothing has been claimed yet. The buyer cancels, or lets it expire.
  • A COMPLETED trade cannot be disputed. COMPLETED is terminal.
  • A CANCELLED or EXPIRED trade cannot be disputed.

So the window is: from the moment the buyer presses "I have paid" until the seller releases. In practice that is the whole period the money is actually at risk, which is the point.

The code still carries a seven-day post-completion check. It is unreachable today, because the transition table refuses COMPLETED → DISPUTED first. Complaints about a completed trade are a support matter and, where warranted, a manual ledger adjustment — there is no button that undoes a release, and there must not be, because a second payout would be drawn from whatever else the seller was holding.

The safety net that files for you

A trade left in PAYMENT_SENT for more than 24 hours is automatically moved to DISPUTED by the one-minute cron, with a HIGH priority dispute filed in the buyer's name against the seller. Its stated reason is that the seller did not release funds within the allowed timeframe.

This exists because the buyer has already sent money and has no other lever. The 24 hours are counted from paymentConfirmedAt — the instant payment was declared — not from when the row was last touched, so a seller who keeps chatting cannot reset the clock and hold the escrow indefinitely.

The escrow stays held. An admin settles it.

Filing one

Either party can file. The form needs two things.

A reason, one of eight:

Reason Filed by, typically
PAYMENT_NOT_RECEIVED the seller — the buyer declared payment that never arrived
PAYMENT_INCORRECT_AMOUNT the seller — short, or in the wrong currency
CRYPTO_NOT_RELEASED the buyer — paid, and the seller is sitting on the escrow
SELLER_UNRESPONSIVE the buyer
BUYER_UNRESPONSIVE the seller
FRAUDULENT_ACTIVITY either — chargeback, third-party payment, impersonation
TERMS_VIOLATION either — the offer's written terms were not followed
OTHER anything else

A description, between 20 and 1000 characters. Twenty is a deliberate floor: "he scammed me" is not something an arbitrator can act on. Up to five pieces of evidence may be attached at filing (screenshot, document or text).

Rate limit: 3 disputes per 24 hours per user. Somebody hitting that ceiling is either being systematically defrauded or is themselves the problem; both are worth a look.

What happens the moment it is filed

In one transaction:

  • A p2p_disputes row is written — the trade, the amount, who filed, who it is against, the reason, the details, the evidence, status: PENDING and a computed priority.
  • The trade moves to DISPUTED and disputedAt is stamped.
  • A DISPUTE_OPENED entry is appended to the trade timeline.
  • An activity log entry is written.

After the commit both parties are notified, and the trade room receives a WebSocket DISPUTE event so the status changes in front of whoever has it open.

The escrow does not move. It stays HELD on the trade. Neither party can cancel a disputed trade — the escrow is contested and belongs to the resolution flow, and letting either side cancel would close the dispute unilaterally and settle the money in their own favour.

Priority

Assigned automatically at filing:

Condition Priority
reason is FRAUDULENT_ACTIVITY or PAYMENT_NOT_RECEIVED HIGH
trade amount above 1000 HIGH
trade amount above 100 MEDIUM
otherwise LOW

An admin cannot re-prioritise a dispute directly; the field is set once. Sort the queue by priority and by filedOn, and use the notes field to record where you are with each case.

While the dispute is open

The trade room stays live for both parties. They can keep talking, and they can keep attaching images — which is usually where the useful evidence appears, because a bank screenshot posted in the chat is easier for both sides than the evidence form.

An admin can post into that same conversation. Those messages are flagged as admin messages, appear in the trade timeline, are broadcast over the WebSocket, and generate a notification to both parties. Internal admin notes are a separate thing and are never shown to users.

A dispute has three statuses:

Status Meaning
PENDING filed, nobody has picked it up
IN_PROGRESS an admin is working it
RESOLVED ruled on, and the escrow has been settled

Moving to IN_PROGRESS changes nothing about the money. It is a queue signal, and it is worth using on a busy desk — otherwise two admins will work the same case and only one ruling will stick.

Outcomes, from the trader's point of view

An admin picks one of four. What each does to the money is covered in detail on Resolving a dispute; what the trader sees is:

Outcome Trade ends as Buyer gets Seller gets
BUYER_WINS COMPLETED the escrow, less the platform fee nothing
SELLER_WINS CANCELLED nothing the escrow back, no fee
SPLIT COMPLETED the agreed share, less fee on that share the remainder
CANCELLED CANCELLED nothing the escrow back, no fee

SELLER_WINS and CANCELLED also restore the offer's advertised capacity, so the seller's offer goes back to selling what it can still cover.

Both parties are notified with the actual figures. Where nothing was left to settle — because the escrow had already been paid out by another door — the ruling is recorded and the response says so explicitly rather than reporting a payout that never happened.

What to tell users, in advance

The /p2p/learn pages carry this, but support will still be asked. The three things that prevent most disputes:

"Pending" in a banking app is not received. Reversible methods — card payments, some instant-transfer rails, anything with a chargeback window — can be pulled back days later, long after the crypto has gone. A seller who releases on a pending screenshot has no recourse: the trade is COMPLETED and terminal.

Third-party payments are the single most common reason a legitimate-looking trade turns into a fraud case. The payment details shown on the trade are a snapshot taken when the trade opened — pay those, not something sent in the chat afterwards.

The chat is the evidence. An arbitrator reads the timeline: what was agreed, when payment was declared, what each side said afterwards. A conversation that happened over email or a messaging app is invisible to them, and a case argued from screenshots of it is much weaker than one argued from the record.