Building a secure P2P cryptocurrency exchange: escrow and rating

Why a P2P crypto exchange loses users over disputes

A classic failure in a P2P exchange looks like this: the buyer sent a transfer, the seller does not see the incoming payment or sees it late, and the transaction hangs between payment and confirmation.

The countdown expires, both parties open a dispute, and the coins remain locked in the escrow wallet until the arbitrator's decision. Then begins the most expensive part — manual dispute resolution.

The arbitrator has no single source of truth: the buyer's receipt, the seller's statement, and the blockchain record live in different systems and are not reconciled automatically.

The average transaction waits hours for a verdict, and during peak hours — days, and all this time the locked funds tie up the seller's working capital.

The more open disputes there are, the less liquidity on the marketplace and the higher the chance that the next buyer simply will not find an offer.

Meanwhile, the exchange's arbitration sprawls: similar cases are handled differently, rating stops reflecting real reputation, and high-volume sellers leave for places where the dispute outcome is predictable.

User churn does not happen after a loud conflict, but earlier — after the first stuck transaction that was not explained within ten minutes. In this model, counterparty reputation is built on support emotions rather than verifiable data.

We break down how this point of failure is closed at the logic level: deterministic escrow rules, automatic payment reconciliation by details and amounts, limits on the volume of stuck funds, and a rating calculated from confirmed transactions rather than reviews.

What escrow logic delivers: measurable results for the platform

Escrow logic is not "holding funds until confirmation" but a set of rules the platform enforces itself.

Each order state — deposit, confirmation, release, return by timelock — is recorded as a separate event on the Ethereum network, and the entire transaction history is reconstructed from these events. Hence the effect is measured in numbers, not promises.

Automatic dispute resolution

Manual arbitration remains only where the parties fail to agree before the timelock expires. Everything else is closed automatically: confirmation by the second party, amount reconciliation, expiry of the dispute window. Support requests for disputed transactions drop severalfold.

Transaction time

Fixed confirmation windows and timelocks eliminate stuck orders: both parties know when the funds will be released or returned. The interval from order opening to settlement shrinks because no one waits for an operator's response.

Share of completed transactions

Waiting for manual review is the main reason for cancellations at the payment stage. When the scenario is deterministic and order status is visible in the interface, the share of completed transactions grows without increasing team workload.

Repeat transactions

The rating is tied to an address and backed by settlement history, so it cannot be inflated with a new profile. A user with a clean history finds a counterparty faster and returns to the platform on their own.

Comparison of settlement models: escrow, manual arbitration, hybrid

The settlement model determines who holds the funds at the moment of the transaction and how a dispute is resolved. The choice is dictated by flow volume, the share of disputed transactions, and the team's readiness for round-the-clock support. Below are three working alternatives and their honest boundaries.

Limitations matter more than strengths. A model selected for the current flow breaks when that flow triples — so the transition point to another scheme is planned in advance. What this looks like in code and regulations — we break down further.

Implementation stages: from scenario audit to handover of regulations

A transaction in a P2P exchange is driven not by the interface but by a finite state machine: money and cryptocurrency change owners on transitions between states. An error in one transition — and funds get stuck in escrow, and the dispute has to be resolved manually using logs. That is why implementation starts with a scheme, not with screen layout.

1. Transaction scenario audit. We break down all branches: full and partial payment, cancellation by one party, dispute, offer expiry, repeated attempt to open the same order. The output is a risk matrix: for each branch, it is recorded who moves the funds and on what basis.
2. State and transition scheme. We describe the finite state machine in full: states, allowed transitions, conditions and timeframes for each. Dead-end and unreachable branches are cut off at the scheme stage — so they do not surface in live transactions, when fixing them costs more than designing.
3. Escrow setup. Fund locking, signatures of the parties and the arbitrator, automatic release upon expiry if a participant is silent. We separately verify that no transition allows funds to be withdrawn twice or the lock to be bypassed.
4. Rating and reputation. Accrual rules, weight of completed transactions, protection against inflation through self-trades and fresh accounts. Reputation must reflect real history, not the number of registrations.
5. Test transactions. We run scenarios on the staging environment: node failure, connection loss mid-transition, double signature, repeated release request. We calculate the share of paths covered by checks and cover those left untested.
6. Handover of regulations. We provide instructions for dispute resolution, checklists for stuck transactions, rollback procedures for failures, and interface documentation for integrations. The client's team then runs the exchange without us.

What remains with you: configurations, roles, dispute regulations

Handover is not server access or a repository, but a set of artifacts by which your team runs the exchange without our involvement. Each document is tied to working code: if there is a limit in the configuration, it is described; if there is a role, it is specified. Below is what you receive.

• Fund flow diagrams — the transaction path from deposit to withdrawal after confirmation by both parties, with marked points where escrow logic triggers, where freezing is possible, and where the operator makes the decision.
• Access policies — a matrix of roles and rights: who changes limits, who signs escrow operations, who has access to keys, logs, and the dispute panel. The principle of least privilege is fixed separately from the code.
• Operator roles — areas of responsibility for the arbitrator, ad moderator, risk analyst, and incident on-call, with authority boundaries and points where a second confirmation is required.
• Dispute resolution regulations — a step-by-step procedure: response times, what evidence is requested (timestamps, transfer hashes, correspondence), and under what conditions a decision is executed automatically.
• Support instructions — response scenarios for typical requests: stuck transaction, incorrect amount, suspected fraud, repeated verification.
• Environment configurations — node parameters, risk-scoring thresholds, rules for accruing and deducting rating points, limit reference books.
• Incident runbook — procedures for node unavailability, stuck escrow, or mass complaints, including the manual intervention procedure and its logging.

We separately hand over the rating model: how a seller's weight is formed, what reduces it, and how it is recalculated on appeal. The set is completed by a recording of disputed case reviews — your support team learns from them to make decisions the same way we did.

Case study: how we removed manual dispute resolution on a platform

The P2P exchange platform came with fully manual dispute processing: an operator opened the request, the parties corresponded in support, the decision was recorded manually and manually unlocked the assets.

With several thousand transactions per day, the share of disputed transactions held around 4%, the average review took three days, and the seller waited for withdrawal of funds all that time.

We moved the basic scenarios into an escrow contract using audited OpenZeppelin libraries: the asset is locked for the duration of the transaction and released upon confirmation by both parties.

We configured confirmation windows, automatic return if a party does not confirm the transaction on time, and a security deposit for the party delaying the operation. Only what is not resolved automatically goes to the operator.

The rating was tied to confirmed transaction volume rather than the number of reviews, so account inflation stopped working.

In arbitration, the operator sees the full transaction trail: status history, transaction hashes, correspondence between the parties — the review proceeds by facts, not screenshots.

Result

A quarter later, the share of disputed transactions fell from 4% to 1.2%, the average review — from three days to four hours, and the share of completed operations grew from 92% to 99.3%. Withdrawal after network confirmation takes minutes instead of waiting for an operator's verdict.

How escrow differs from manual arbitration and when to choose what

Both models solve one task — to conduct a transaction between strangers who do not trust each other. The difference is who holds control at the moment of the dispute and how formalizable the dispute is at all. Choosing a settlement model is a question of the predictability of your scenarios, not taste.

Escrow leaves control to rules: the parties describe in advance the recipient's confirmation, timeframes, cancellation, and the transaction closes without a human.

Hence the speed — a standard exchange fits into minutes, and the "seller disappeared" scenario is handled by a timeout, not by waiting for an administrator. The price for this is rigidity: only what is written is executed, and any step outside the rules hangs.

Manual arbitration is needed where evidence cannot be verified automatically. A transfer from a third party, a forged receipt, a payment return — rules do not distinguish these events, and the arbitrator reviews them using documents and transaction history.

The price is time and subjectivity: the review takes hours, and the result depends on regulations and the reviewer's competence.

In practice, the model is chosen by the share of disputed transactions and the cost of error. If ambiguous cases are a few percent — hybrid: automation on the entire standard path, manual control only on deviation.

If the share of manual checks is large, full automation breeds stuck transactions, and arbitration becomes the primary loop.

Technical concerns: limits, liquidity, refunds

Concerns about transactions are usually the same: how turnover is limited, what prevents bypassing the rules, and who gets the disputed amount. Below is how these points are closed in the exchange logic.

How are multi-accounts filtered out?

One verified profile — one participant: accounts are linked by devices, payment details, payout addresses, and behavioral matches. A cluster is counted as one subject, so the tenth profile gives neither additional limits nor additional rating weight.

Can the rating be inflated?

A review is tied to a completed transaction where both parties confirmed settlement via escrow — there are no standalone reviews. Weight depends on confirmed volume and profile age, and fresh clusters with identical attributes weigh almost zero. On anomalies, the rating is recalculated and transactions go to manual review.

In what order are funds returned?

Funds are locked in an address with signatures of the buyer, seller, and arbitrator. If payment is not confirmed within the allotted window, the transaction closes by timeout and the amount is returned to the buyer. A dispute is reviewed by the arbitrator.

Each state transition is written to a log, and operations are idempotent — a repeated request does not create a second payout.

Let's discuss your exchange: implementation plan and timeline estimate

To come back with an implementation plan and timeline estimate rather than general considerations, we need a minimum of inputs about the product and transaction rules. Below is what we will request when we discuss the task.

• Transaction model: who the participants are, what roles exist in the exchange, where the platform's responsibility ends and the parties' responsibility begins.
• Escrow logic: at what point funds are locked, what counts as payment confirmation, who can initiate a return and on what basis.
• Rating and reputation: what events change the score, how reviews are formed, what we show to new participants without transaction history.
• Disputes: who reviews the conflict, within what timeframes, what evidence is accepted, whether there are amount limits, and who has the right to the final decision.
• Payment and assets: which fiat channels and networks we connect at the start, what limits and fees we set, and who is responsible for liquidity.
• User verification and regional requirements: what is mandatory, what we leave for the second stage, and who owns the accounts and access.
• Current work in progress: whether there is code, design, escrow rules in documents — so as not to redesign what already works.

From this we assemble the scope of work, break it into stages with a clear result at each, and come back with an implementation plan and timelines. If some points are still open — come as you are; we will review the ambiguous points together and fix them in the plan.