Disputes — filing and 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

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:

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.

A ruling is not the only way out, though. The trader who filed the dispute can withdraw it, and only that trader — the accused cannot close a case brought against them. The door is open only while the dispute is still PENDING: once an admin has moved it to IN_PROGRESS somebody is already reading the evidence and it can no longer be pulled. A short note may be attached, and it is what later answers an operator asking why a case vanished from the queue.

Withdrawing unwinds nothing, because opening a dispute moved nothing. The trade goes back to the status the timeline recorded when the dispute was opened — in practice always PAYMENT_SENT, the only status a trade can reach DISPUTED from — both parties are notified, and the dispute closes as RESOLVED with its outcome recorded as WITHDRAWN. That is the one RESOLVED dispute where no escrow was settled. It is also not a one-way door: the "already under dispute" check counts only unresolved disputes, so the same trader can file again if the matter turns out not to be settled after all.

Priority

Assigned automatically at filing:

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:

Moving to IN_PROGRESS changes nothing about the money, but it is not only a queue signal. While a dispute is still PENDING the trader who filed it can withdraw it, and the trade goes back to the status it held before; the first admin to pick the case up closes that door, and from then on only a ruling ends it. So it is worth using on a busy desk twice over — otherwise two admins work the same case and only one ruling sticks, and the trader can pull the case out from under whoever is reading it.

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:

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: