In a peer-to-peer deal between strangers, every clock in the contract is a lever. Set it wrong and you have built a contract where one side can win simply by going quiet. This post walks through the four timing decisions that matter and the failure each one prevents.

The naive contract and how it fails

function deposit() external payable onlyBuyer { funded = true; }
function release() external onlyBuyer { _pay(seller); }
function refund() external onlySeller { _pay(buyer); }

Read it from each side's point of view:

• The seller ships and the buyer disappears. Only the buyer can release. The money is stuck forever.

• The buyer pays and the seller never ships. Only the seller can refund. Same problem in reverse.

Neither party can force an outcome, so the person who is happy with a deadlock (usually the one who already has what they wanted) holds all the leverage. Every fix below is about removing that leverage.

Decision 1: a review window that ends in the seller's favour

The buyer needs time to inspect what they received. The seller needs to know the money will not be held hostage. A review window resolves both:

uint64 public reviewDeadline; // set when the seller marks the deal delivered

function claimAfterReview() external onlySeller {
    require(state == State.Delivered, "not delivered");
    require(block.timestamp >= reviewDeadline, "review window open");
    _pay(seller);
}

The key choice is what happens when the window closes with no action. If silence means "pay the seller", a buyer who received the goods cannot block payment by ignoring the deal. A buyer with a real problem still has the whole window to object.

How long? Long enough to cover shipping plus a genuine inspection. A digital file needs hours; a graded collectible shipped internationally needs days. Fix it per deal at creation, and never let either party change it afterwards.

Decision 2: a delivery deadline that ends in the buyer's favour

The mirror image covers the seller who takes the deal and never delivers:

uint64 public deliveryDeadline; // set at creation

function refundAfterNoDelivery() external onlyBuyer {
    require(state == State.Funded, "already delivered");
    require(block.timestamp >= deliveryDeadline, "seller still has time");
    _pay(buyer);
}

Now silence costs each side something. A seller who does nothing loses the sale; a buyer who does nothing after delivery loses the ability to object. That symmetry is the whole point.

Decision 3: disputes must freeze the clock

A buyer who receives the wrong item needs a way to stop the review window from running out. Opening a dispute should move the deal into a state where neither timeout path works:

function openDispute() external onlyParty {
    require(state == State.Funded || state == State.Delivered, "cannot dispute");
    require(state != State.Delivered || block.timestamp < reviewDeadline, "window closed");
    state = State.Disputed; // claimAfterReview and refundAfterNoDelivery now revert
}

Two details matter here:

• The dispute has to be opened inside the window. Otherwise a buyer could wait a month and then dispute a deal that was already settled in practice.

• A dispute should cost the disputer something, or be ruled quickly. If opening a dispute is free and resolution is slow, disputes become a stalling tool of their own. Decentralized courts such as Kleros handle this with arbitration fees paid by the party raising the dispute; a reviewed model handles it with a clear ruling deadline.

Decision 4: what the arbitrator is allowed to do

The last lever is the one people forget to constrain. Whoever rules on a dispute should be able to pick between exactly two outcomes and nothing else:

function rule(uint8 ruling) external onlyArbitrator {
    require(state == State.Disputed, "no dispute");
    state = State.Resolved;
    if (ruling == 1) _pay(seller);
    else _pay(buyer);
}

No sweep(), no setRecipient(), no admin path to move funds anywhere except to one of the two parties. If you want an emergency control, make it a pause that can delay a ruling for review, not a key that can redirect money. "Can delay, can never redirect" is a property users can actually check on a block explorer.

Bonus: settle in a stablecoin

Every clock above interacts with price. If the escrow holds a volatile asset, a review window becomes an option: a counterparty can stall while they watch the price, and act only when it moves in their favour. Escrowing USDC or USDT removes that incentive entirely, which is why stablecoins are the sensible default for anything that takes more than a few hours.

Checklist

When you write (or audit) a P2P escrow contract, check that:

1. A silent buyer cannot block payment after delivery (review window ends in the seller's favour).

2. A silent seller cannot keep the money without delivering (delivery deadline ends in the buyer's favour).

3. Opening a dispute freezes both timeout paths, and can only happen inside the window.

4. Disputes have a cost or a deadline, so they are not a free stalling tool.

5. The arbitrator can only pay the buyer or the seller.

6. No party can change the deadlines after funding.

If you would rather see these choices made in a deployed product than build them yourself, we run a non-custodial P2P crypto escrow built around the same ideas, with open-source contracts you can read on the block explorer.

Disclosure: I work on Vaultion. The snippets above are simplified for illustration and are not Vaultion's production contract; a real contract also needs reentrancy protection, a pull-payment ledger and careful fee handling. This post was drafted with AI assistance.