Skip to content

Public beta on the Base Sepolia test network. Payments use test USDC with no real value: do not send real funds. The escrow contract has not had its external security audit yet, and the terms are drafts pending legal review. What the beta means

OpenVPT

Why Digital Goods Need Escrow: A Field Guide to Common Scams

Six common scams in buying source code, SaaS licenses or websites, the limits of escrow agents, and how on-chain escrow changes who you have to trust.

Author
OpenVPT Team
Published
Reading
11 min read
Tags
  • escrow
  • scam prevention
  • digital assets
  • source code
  • on-chain
Contents

TL;DR Digital goods can be copied endlessly, can't really be "returned", and are usually traded between strangers in different countries. Private deals are risky for both sides: payment with no delivery, fake or stolen code, licenses that can't be transferred, chargebacks against sellers, and assets quietly taken back after handover. Escrow solves the "who goes first" problem by holding the money until delivery is confirmed. OpenVPT puts that escrow on-chain: the buyer's USDC sits in a smart contract, and releasing it takes signatures from any two of three parties (buyer, seller, platform). The platform can never move funds on its own.

Why digital goods are a scammer's favorite

When a physical order goes wrong, there is usually a tracking number and something you can send back. Digital assets are different:

  • They copy for free. A seller who sells you source code still has a full copy and can sell it again tomorrow.
  • Delivery is instant and irreversible. Once a file is downloaded or a license key is revealed, there is nothing to "return".
  • Value is hard to verify up front. Code quality, website traffic or the real status of a SaaS subscription often only become clear once you have them and run them.
  • The parties are anonymous and cross-border. When something goes wrong, there is rarely a practical way to recover the money.

That turns "who pays or ships first?" into a real dilemma. Pay first and the buyer carries all the risk. Deliver first and the seller does. Escrow exists so that neither side has to go first.

Six common scams

The scenarios below are generic composites of common patterns. They don't refer to any real company or person.

1. Non-delivery

The simplest and most common. Someone posts "complete source code, cheap, today only" on a forum or chat group, asks for a bank transfer or crypto up front, then disappears. Amounts are often small and the seller is anonymous, so most victims just write it off.

Warning signs: a price far below market, pressure to "pay now or I sell to someone else", and a demand for payment methods that can't be reversed.

2. Fake or stolen code

What arrives doesn't match the demo. It might be a renamed open-source project, a stripped-down build missing key modules, or code lifted from someone else. The last case is the worst: you may end up shipping infringing code without knowing it, and the original author may come after you, not the seller.

Warning signs: the seller refuses any verifiable preview before payment (a file tree, a dependency list, a live walkthrough of part of the code) or can't explain where the code came from or which licenses apply.

3. Licenses that can't be transferred

Many SaaS plans, software licenses and API tiers explicitly forbid transfer or resale in their terms of service. The seller hands over the account or key, the deal looks done, and then the vendor notices and suspends it. Your money is gone.

Warning signs: "don't change the account details", "don't contact the vendor", or no proof of the original purchase.

Whether a license can be transferred is up to the vendor's terms. No marketplace can promise that on the vendor's behalf, so check those terms yourself before you buy.

4. Chargeback abuse against sellers

Scams run both ways. A buyer pays by card or through a reversible payment service, receives the code or license, then files a dispute with their bank claiming "item not received" or "unauthorized transaction". Digital goods leave no signed delivery slip, so the seller often loses both the product and the money.

Warning signs: insistence on a specific reversible payment method, pressure to deliver early, and a brand-new account with no history.

5. Account takeover after handover

This is common with websites, domains, social accounts and SaaS admin panels. The seller hands over the login and you confirm it works. But they've kept the recovery email, the phone number, the domain registrar account or a hidden admin role, and a few days later they take the whole asset back.

Warning signs: reluctance to transfer the registrar account, the recovery email or the two-factor device as part of the handover.

6. Bait-and-switch

The demo shows the full-featured version. What you receive is an older build, a crippled build or different code altogether. With websites, the classic version is inflated traffic screenshots and invented revenue reports.

Warning signs: you can only watch a video or look at screenshots, never try it yourself, and none of the numbers can be checked in a third-party analytics tool.

The problem with traditional escrow agents

The usual fix has been a third-party escrow agent: the buyer pays the agent, the agent confirms delivery and pays the seller. That's far safer than a private deal, but it has trade-offs:

  • It's custodial. Your money sits in the agent's account. You have to trust them not to run off with it, not to go bust, and not to send it to the wrong person by mistake.
  • It's slow. International wires, manual review and banking hours can stretch one deal over several days.
  • Minimums and fees. Many traditional escrow services set minimum amounts that make smaller digital deals uneconomical.
  • It's opaque. You only know when money arrived or left because the agent tells you. Nobody outside can check.

In short, traditional escrow swaps "trust the other party" for "trust the agent". That's an improvement, but the trust still sits with one party.

How on-chain escrow changes the trust model

OpenVPT holds funds in a smart contract, VPTEscrow, and writes the rule for who can release them into the contract itself rather than into a terms-of-service page.

How the money moves

  1. Order. The buyer creates an order from a listing. The platform issues a signed "create order" authorization (an EIP-712 signature) that locks the seller address, amount and fee, so the buyer can't alter them. The authorization is valid for at most 15 minutes, and a fresh one is fetched right before payment.
  2. Funding. The buyer deposits USDC into the VPTEscrow contract on Base. There's a 24-hour payment window after the order is created.
  3. Delivery. The seller delivers within the listing's delivery window (3 days by default) by uploading a file or submitting a license key. Uploaded files have their SHA-256 hash recorded, and license keys are stored encrypted.
  4. Inspection. Delivery starts the inspection window (set per listing, 3 days by default). The buyer can confirm, or open a dispute before the window closes. If the window ends with no dispute, the order moves to payout.
  5. Settlement. Releasing funds takes a "settle" signature, and the contract only accepts signatures from two different parties out of buyer, seller and platform. Once both are in, the payout executes on-chain.

What the platform can't do

This is the real difference from a traditional agent. Under the VPTEscrow contract:

  • The platform can't move funds alone. It's one of three possible signers and always needs the buyer or the seller to agree.
  • The contract owner can't settle or withdraw either. The owner can pause new funding, rotate the platform's signing key, and set the allowed tokens and the fee recipient address. No function lets it settle an order or pull escrowed funds out.
  • The math is enforced. At settlement, the seller, buyer and platform amounts must add up exactly to the escrowed amount, and the platform's cut can't be below its pro-rata minimum.
  • Everything is verifiable. Funding and settlement emit on-chain events that anyone can check independently.

If a seller misses the delivery deadline, the system starts a full refund to the buyer. And if an order is cancelled while the buyer's funding transaction still lands on-chain, a refund path makes sure the USDC doesn't get stuck in the contract.

How the fee works

OpenVPT's default platform fee is 5%, taken pro-rata from the seller's share. The buyer pays nothing extra.

Example 1: a completed 1,200 USDC order

ItemAmount
Buyer deposits into escrow1,200 USDC
Platform fee (5%)60 USDC
Seller receives1,140 USDC
Refunded to buyer0 USDC

Example 2: a 1,200 USDC dispute ruled 30% to the seller

Rulings are expressed as a split, and the fee applies only to the seller's portion:

  • Seller's gross share: 1,200 × 30% = 360 USDC
  • Platform fee: 60 × 360 ÷ 1,200 = 18 USDC
  • Seller receives: 360 − 18 = 342 USDC
  • Buyer is refunded: 1,200 − 360 = 840 USDC

342 + 840 + 18 = 1,200 USDC, exactly the escrowed amount. On a full refund to the buyer, the platform takes no fee.

When there's a dispute

  1. The buyer opens a dispute within the inspection window. Both sides can submit text, links or files as evidence.
  2. The dispute is assigned to an arbitrator, who can't be a party to the order.
  3. The arbitrator rules with a split, for example 30% seller / 70% buyer.
  4. The platform signs a settlement matching the ruling. The buyer or the seller (usually the side receiving funds) adds the second signature, and the platform relays the transaction on-chain.

This is where the recorded SHA-256 hash pays off: it pins down exactly which file the seller delivered, which leaves much less room to argue in a bait-and-switch case. Under the current process the ruling is final. There is no appeal step yet.

Other safeguards

  • Seller requirements. Sellers must pass KYC and verify their wallet with SIWE (Sign-In with Ethereum), and listings are reviewed before they go live.
  • Chat risk warnings. If an order chat contains an email address, phone number, Telegram, WhatsApp or WeChat handle, or an off-platform payment link, the message is flagged with a warning. It isn't blocked, but you'll know.
  • Banned accounts. Banned users can't take any action. Their open orders aren't frozen: they keep moving through the counterparty, scheduled system jobs and arbitration, and the few settlements that need the banned party's own signature are handled manually.

On contract security: an independent third-party audit of the contract is planned before public launch, and a bug bounty program is also planned. Neither has happened yet. Until then, start with amounts you're comfortable with.

Private deal vs. escrow agent vs. OpenVPT

Private dealTraditional escrow agentOpenVPT on-chain escrow
Who holds the moneyThe other partyThe agent's accountA smart contract
Can one party take the funds alone?The recipient canThe agent canNo, it takes 2 of 3 signatures
Can you verify where money went?NoOnly via the agentPublic on-chain record
Delivery recordChat screenshotsDepends on the agentSHA-256 hash of the file
Dispute handlingNoneAgent's manual processAssigned arbitrator, split ruling
Chargeback risk for sellersHigh (depends on payment method)Depends on payment methodUSDC settles on-chain with no card chargeback
Cost to the buyerNoneOften charged separatelyNone; fee comes from the seller's share
SpeedInstant, but no protectionOften several business daysExecutes on-chain once signatures are in

Red-flag checklist

Go through this before any deal. Any single item is a reason to slow down:

  • They want you to leave the platform and pay by DM, a messaging app or a direct transfer.
  • The price is well below comparable listings, and they keep pushing you to decide fast.
  • They'll only use untraceable or reversible payment methods (which one is the red flag depends on whether you're buying or selling).
  • The "demo" is screenshots or a video only, with no verifiable check allowed before payment.
  • They can't explain where the code came from, which open-source licenses apply, or what it depends on.
  • They tell you not to contact the vendor or not to change the account details.
  • They won't hand over the domain registrar account, the recovery email or two-factor access.
  • Traffic or revenue figures can't be checked in any third-party tool.
  • A brand-new account with no reviews is selling something expensive.
  • A OpenVPT order chat shows a warning about contact details or off-platform payment.

What to do during the inspection window

The inspection window is the buyer's most important protection. Before you confirm, at minimum:

  1. Check the delivered files against the listing, and actually build, deploy or run them once.
  2. Review license files and third-party dependencies for anything that can't be transferred.
  3. For websites and accounts, change every password, the recovery email, the two-factor device and the registrar login before you confirm.
  4. If something's wrong, open a dispute inside the window and keep your evidence. Once you confirm, the funds are released and can't be pulled back.

The bottom line

The risk in digital deals comes down to one side having to trust the other first. A private deal dumps that risk on whoever moves first. A traditional agent concentrates the trust in the middleman. On-chain escrow writes the payout rules into a public contract, so no single party, including the platform, can decide where the money goes. It won't remove every risk (vendor license terms and your own security hygiene after handover are still on you), but it sharply reduces your exposure to the most common scams.

This article is general information only and is not legal, tax or investment advice. Digital assets and cryptocurrencies carry risk. Make your own judgement and consult a qualified professional where appropriate.

Next steps

Related reading