Use case - a 1,500 USDC freelance project paid by stages

Freelance is the classic situation where both sides take a risk. The client fears paying in advance and getting nothing. The contractor fears doing the work and not being paid. Escrow removes both fears. Let us show with a live example what it looks like. For the general deal scheme see the lifecycle.

The participants

• Anna - owner of a small online shop, the client.
• Dmitri - a web developer from another country, the contractor.
• Igor - an independent technical expert whom both chose as guarantor (how to choose).

The task: develop the shop's payment-system integration and a personal account area. The budget is 1,500 USDC. The network is Base, because fees there are low (why).

Step 1. Split the project into stages

One big payment = big risk for both sides. It is better to make three deals:

Now each side's maximum risk is 500 USDC, not 1,500.

Step 2. Write the terms

For stage 1 Anna and Dmitri write the text (principles):

Subject: integration of payment system X into the online shop (repository: link).
Result: paying for an order by card in test mode, receiving the webhook and changing the order status.
Acceptance: the 5 test scenarios from the document (link) pass; the code is on branch main with run instructions.
Revisions: 1 round within 3 days after delivery.
Deadline: 7 days from acceptance of the offer.
Contact: the project chat, reply within 24 hours.

The service computes the hash of this text and fixes it in the contract (why).

Step 3. Create the deal

Anna creates the offer as the buyer: 500 USDC, counterparty - Dmitri, guarantor - Igor, rates 2% base and 8% in a dispute, term 7 days. Since USDC is an ERC-20 token, she first needs to give the contract an allowance for 500 USDC (what approve is), then create the offer. The money goes into the contract.

Dmitri sees that 500 USDC is already reserved and cannot be spent by anyone except by the contract's rules. He checks the terms and accepts the offer. From this moment the 7-day term runs.

Step 4. Performance and delivery

Dmitri works and on time sends a link to the branch and a description. Anna checks the 5 scenarios. Everything works.

Step 5. Confirmation

Anna presses "Confirm receipt". The contract distributes the 500 USDC:

Then the same steps repeat for stages 2 and 3. In total Dmitri receives about 1,455.30 USDC (3 × 485.10), and the "cost of safety" is roughly 3% of the budget (detailed calculation).

An alternative scenario: a partial dispute

At stage 2 Dmitri delivers the personal account, but Anna thinks the order history works wrongly: some orders do not show. Dmitri objects: it is a quirk of the test data. They failed to agree, and Anna opens a dispute.

1. Both send Igor their evidence: the terms, screenshots, screen recordings, links to commits (how to prepare).
2. Igor studies the materials and finds that the bug exists but can be fixed within a few hours, while the rest of the functionality works.
3. He issues a partial ruling: 30% to Anna, 70% to Dmitri.

The calculation (the guarantor's dispute rate is 8%):

Result: the parties shared the cost of the dispute proportionally. Anna gets money for the shortfall, Dmitri for the part he completed.

What this scenario teaches

1. Stages limit risk. The smaller the amount at each step, the safer both sides are.
2. Clear acceptance criteria let the guarantor decide on facts.
3. A dispute is not always "all or nothing". The guarantor can issue a partial ruling.
4. Evidence matters. Whoever collected it is in a strong position.
5. The guarantor must be neutral and available: otherwise the emergency exit will split the money 50/50.

What to read next

See other scenarios: physical goods with delivery and a domain and digital goods. Or return to the overall picture: where escrow is used.