DEV Community: Vaultion

Accept USDT and USDC on a custom site without a payment processor account

Vaultion — Wed, 14 Oct 2026 18:09:23 +0000

Most ways to take crypto on a custom website start with a sign-up: create a processor account, pass business verification, generate an API key, store it somewhere safe, and let the processor collect your payments into a balance you withdraw later.

If you just want USDT and USDC paid to your own wallet, there's a lighter shape. This post walks through it with one server-side request and no API key.

The request

Your server creates a checkout with the price and the wallets you want to be paid in. escrow: 'off' means direct payments only:

// Server only. Browser calls from other sites are refused.
import { randomBytes } from 'node:crypto';

const res = await fetch('https://checkout.vaultion.org/v1/stores/sessions', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    store: { url: 'https://yourshop.com', name: 'Your Shop' },
    orderRef: `order-${order.id}-${randomBytes(4).toString('hex')}`, // same ref = same checkout
    name: order.title,
    priceMinor: order.totalCents,          // US cents
    escrow: 'off',                         // direct payments only
    receiving: {
      evm: '0xYourEvmWallet',              // Base, Ethereum, Arbitrum, Polygon, BNB Smart Chain
      tron: 'TYourTronWallet',             // USDT and TRX on TRON
      solana: 'YourSolanaWallet',          // USDC, USDT and SOL on Solana
    },
    feePayer: 'merchant',                  // or 'buyer' to add the 0.75% fee on top
    returnUrl: `https://yourshop.com/orders/${order.id}`,
  }),
});
const { sessionId, checkoutPath } = await res.json();
// redirect the buyer to 'https://checkout.vaultion.org' + checkoutPath

Store orderRef before redirecting: the same orderRef returns the same checkout, so a timed-out request is safe to retry. Keep the random part, so nobody can guess it and open that checkout first.

The buyer sees a hosted checkout with every network you sent an address for, and pays from their own wallet.

Where the money goes

On EVM networks, Solana and TRON, the buyer's wallet sends one transaction that pays your share to your address and the 0.75% fee to the fee address, both inside the same transaction. You're paid when it confirms, and there is no balance to withdraw.

Bitcoin and Litecoin work differently: a standard payment link names one address, so those payments go to a per-order deposit address and are forwarded to you after confirmation. That's a short period of custody, and it's worth knowing which of your coins work which way.

Marking the order paid

Read the status from your server:

const { status } = await fetch(
  `https://checkout.vaultion.org/v1/stores/sessions/${sessionId}`
).then((r) => r.json());

if (status === 'paid')     { /* confirmed on chain: fulfil the order */ }
if (status === 'reverted') { /* reversed by a chain reorganization: hold the order */ }

A status changes only from a confirmed on-chain receipt. Don't mark an order paid because the buyer came back to your returnUrl or pasted a transaction hash: both are claims, not proof.

Optional: offer escrow on big orders

A confirmed crypto payment can't be charged back, which is good for you and a reason some buyers hesitate to pay a shop they don't know. Set escrow: 'choice' and the checkout offers both: pay directly, or pay into an escrow contract that holds the money until the buyer confirms delivery. The buyer pays the escrow fee (4% below 500 USDC, 3% from 500, 2% from 5,000), escrow is offered from $50, and disputes go to a Vaultion reviewer, which is not decentralized: you are trusting Vaultion's reviewers.

What to know first

Prices are in US dollars (priceMinor is US cents).
Call it from your server; browser calls from other origins are refused.
There's no sandbox and no webhooks yet: test with a small real payment and poll the status.
Only send addresses you control. A payment to a mistyped address can't be recovered.

Field reference, every status, and samples in Node, PHP and cURL: accept crypto payments with one API call. The same walkthrough, with the custody note for each coin, is on the site: accept USDC and USDT without a processor account.

Disclosure: I work on Vaultion, the API used here. This post was drafted with AI assistance.

Adding escrow to a freelance platform with one API call

Vaultion — Wed, 14 Oct 2026 18:07:57 +0000

Freelance platforms live and die on one moment: the client has to pay before the work is done, and the freelancer has to start work before they've been paid. Every platform solves it the same way in principle: hold the money in the middle until the work is delivered.

This post shows how to do that with an escrow contract instead of your own balance, using one API call per milestone. No account, no API key, and your platform never holds the funds.

The flow

The client accepts a proposal. Your server creates an escrow checkout for the milestone.
The client funds it from their own wallet. The money locks in a smart contract.
You see the milestone as funded, and the freelancer starts.
The client approves the work and releases, or the freelancer claims once the review period ends. If they disagree, either side opens a dispute.

Step 1: create the checkout

Call this from your server when a milestone is accepted. Each request carries that freelancer's wallet, so every milestone pays its own freelancer.

// Server only. Browser calls from other sites are refused.
import { randomBytes } from 'node:crypto';

const orderRef = `ms-${milestone.id}-${randomBytes(4).toString('hex')}`; // keep a random part

const res = await fetch('https://checkout.vaultion.org/v1/stores/sessions', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    store: {
      url: 'https://yourplatform.com',
      name: 'Your Platform',
      email: freelancer.email,              // the freelancer gets the escrow emails
    },
    orderRef,
    name: `Milestone ${milestone.number}: ${project.title}`.slice(0, 128),
    priceMinor: milestone.amountCents,       // US cents; escrow needs at least 5000 ($50)
    escrow: 'required',                      // escrow only
    receiving: { evm: freelancer.wallet },   // one EVM address covers Base, Ethereum, Arbitrum, BNB Smart Chain
    returnUrl: `https://yourplatform.com/projects/${project.id}`,
  }),
});
const session = await res.json();
if (!res.ok) throw new Error(session.error);
await db.milestones.update(milestone.id, { orderRef, sessionId: session.sessionId });
// redirect the client to 'https://checkout.vaultion.org' + session.checkoutPath

Two details worth getting right:

Store the orderRef before you redirect. The same orderRef returns the same checkout, so a timed-out request can be retried without opening a second escrow.
Keep a random part in it. Someone who knows your store settings and a guessable orderRef could open that checkout first, and yours would then fail with order_ref_conflict.

Step 2: turn statuses into project states

Your backend reads the session status and maps it to what your UI shows:

status	What it means	Your project state
`unpaid`	No confirmed payment yet	Awaiting payment
`escrow_funded`	Money is locked in the contract	Work can start
`escrow_disputed`	A dispute is open	Paused
`escrow_pending`	A ruling was given and its challenge window is running	Paused, outcome pending
`escrow_released`	The freelancer was paid (or can claim it)	Paid
`escrow_refunded`	The client was refunded (or can claim it)	Refunded
`escrow_closed`	The amount was split between both sides	Settled
`escrow_late`	Funded after the price deadline	Review before starting

Step 3: poll, don't wait for a webhook

There are no webhooks yet, so read the status from a job. Poll every 30 to 60 seconds while the client is on the checkout, then every few minutes until the escrow resolves:

async function syncMilestone(m) {
  const r = await fetch(`https://checkout.vaultion.org/v1/stores/sessions/${m.sessionId}`);
  if (!r.ok) return;                          // try again next run
  const { status } = await r.json();
  if (status !== m.status) {
    await db.milestones.update(m.id, { status });
    await notifyProjectParticipants(m, status); // your own in-app notifications
  }
}

A status changes only from a confirmed on-chain receipt. A client landing back on your returnUrl proves nothing on its own, so don't mark anything funded from the redirect.

What you don't have to build

Custody. The contract holds the money and can only pay the client or that milestone's freelancer.
Escrow emails. Both sides are emailed when the escrow is funded, when a dispute opens, when a ruling is given, before the review period ends, and when it completes.
Dispute handling. Either side opens a dispute and submits evidence, and a Vaultion reviewer rules at no charge. That is not decentralized: you are trusting Vaultion's reviewers. A separate guardian can pause a ruling but never redirect funds.

The limits, so you can decide

Clients pay in USDC or USDT on one of six networks, so this sits next to card payments rather than replacing them.
$50 minimum per escrow, so very small milestones don't fit.
No sandbox: integrate against production with a real $50 escrow.
No platform commission inside the escrow. The only fee in it is Vaultion's, paid by the client (4% below 500 USDC, 3% from 500, 2% from 5,000), so charge your platform fee separately.

The full field reference, every status and code samples in Node, PHP and cURL are in the escrow API docs. A longer version of this walkthrough, with every status mapped, is on the site: escrow for freelance platforms.

Disclosure: I work on Vaultion, the escrow API used here. This post was drafted with AI assistance.

Holding marketplace funds until delivery: Stripe Connect vs an escrow contract

Vaultion — Wed, 14 Oct 2026 05:25:14 +0000

Every marketplace hits the same question in its first month: between "the buyer paid" and "the seller delivered", who is holding the money?

If the seller is paid immediately, the buyer carries all the risk and your support inbox fills up. If the platform holds it, you are now the one holding other people's money, with everything that implies. This post walks through the two ways developers usually solve it, with code, and the constraints that only show up once you are in production.

Option A: hold funds with Stripe Connect

Start with what Stripe itself says. Its Connect docs state that escrow has a precise legal definition and that Stripe doesn't provide escrow services or support escrow accounts. Escrow services also appear on Stripe's restricted-businesses list. What Connect does give you is control over when money moves.

The usual pattern is separate charges and transfers: the buyer pays the platform, and the seller's share is transferred once delivery is confirmed.

// 1. The buyer pays your platform
const intent = await stripe.paymentIntents.create({
  amount: 25000,               // $250.00
  currency: 'usd',
  transfer_group: 'order-1042',
});

// ...the seller ships, the buyer confirms...

// 2. Move the seller's share to their connected account
await stripe.transfers.create({
  amount: 22500,               // your commission stays on the platform
  currency: 'usd',
  destination: 'acct_seller123',
  transfer_group: 'order-1042',
  source_transaction: chargeId, // waits until the charge's funds are available
});

The alternative is to transfer straight away and use manual payouts on the connected account, so the money sits in the seller's Stripe balance until you release the payout.

The constraints that matter:

How long you can hold. Manual payouts can be delayed up to 90 days in most countries (two years in the US, 10 days in Thailand). A plain card authorization lasts 7 days for online payments, and extended authorization (about 30 days) needs IC+ pricing and is generally meant for cases where the final amount isn't known.
It's still your balance. With separate charges and transfers, the funds are in your platform's Stripe balance. Stripe recommends this charge type only when you are responsible for connected accounts' negative balances.
Chargebacks outlive delivery. Stripe notes that cardholders can typically dispute within 120 days, and with destination charges or separate charges and transfers your platform balance is debited for the disputed amount and fee. A buyer can dispute after the seller has delivered and been paid.
Stripe's own guidance is to hold funds only with a clear purpose and a commitment to release them when a condition is met, and to talk to a legal advisor rather than hold funds arbitrarily.

None of that makes Connect wrong. For card payments with short fulfilment it is the obvious choice. But you are building escrow-like behaviour on a platform that tells you it isn't escrow, and your balance is the shock absorber.

Option B: let a contract hold the money

If your buyers can pay in stablecoins, the holding can move off your books entirely: the payment locks in a smart contract that can only pay the buyer or that order's seller. Here is the same order through the Vaultion escrow API, which takes no account or API key and is called from your server:

// Runs on your server. Never in the browser.
const res = await fetch('https://checkout.vaultion.org/v1/stores/sessions', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    store: { url: 'https://yourplatform.com', name: 'Your Platform', email: 'seller@example.com' },
    orderRef: 'order-1042-k7f3q9',   // same ref returns the same checkout, so retries are safe; keep a random part so nobody can guess it
    name: 'Logo design: final files',
    priceMinor: 25000,               // $250.00
    escrow: 'required',              // escrow only for this order
    receiving: { evm: '0xSellerWalletAddress' }, // this order's seller
    returnUrl: 'https://yourplatform.com/orders/1042',
  }),
});
const session = await res.json();
// Redirect the buyer to 'https://checkout.vaultion.org' + session.checkoutPath

The buyer funds the escrow from their own wallet on a hosted page. Your backend then treats the order as a small state machine by reading the session status:

const { status } = await fetch(
  'https://checkout.vaultion.org/v1/stores/sessions/' + session.sessionId
).then((r) => r.json());

switch (status) {
  case 'escrow_funded':   /* money is locked: tell the seller to ship */ break;
  case 'escrow_disputed': /* hold fulfilment until it is ruled */        break;
  case 'escrow_released': /* the seller is paid */                        break;
  case 'escrow_refunded': /* the buyer got the money back */              break;
}

The seller is paid when the buyer releases, or can claim it once the review period ends, so a buyer who goes silent doesn't strand the money. A confirmed on-chain payment can't be charged back.

What you give up, honestly:

Buyers need crypto. USDC or USDT on one of six networks. It is a second rail next to cards, not a replacement for them.
No webhooks yet. You poll the status (every 30 to 60 seconds while the buyer is on the checkout, then every few minutes).
No sandbox, and a $50 minimum per escrow.
No platform commission inside the escrow. The only fee in it is Vaultion's, paid by the buyer (4% below 500 USDC, 3% from 500, 2% from 5,000), so you charge your own fee separately.
Disputes go to a Vaultion reviewer. It's free, but it's not decentralized: you are trusting Vaultion's reviewers. A separate guardian can pause a ruling but never redirect funds.

Side by side

	Stripe Connect hold	Escrow contract
Who holds the money	Your platform's or the seller's Stripe balance	A smart contract
Longest hold	7-day auth; payouts up to 90 days (most countries)	Until release or the review period ends
Buyer reversal after payout	Card disputes, typically up to 120 days	None; disputes are settled before release
Platform commission	Built in (transfer less than you charged)	Charged separately
Payment methods	Cards and local methods	USDC and USDT
Integration	Charges, transfers, payouts, webhooks	One POST per order, poll the status

Which one

Card buyers and delivery inside a week: authorize and capture. Card buyers and longer fulfilment: Connect with separate charges and transfers or manual payouts, plus legal advice and a chargeback plan. Buyers who pay in crypto, cross-border deals, or high-ticket orders between strangers: let a contract hold it. A lot of marketplaces will end up running both.

If you want the second route, the flow, pricing and limits are on the escrow for marketplaces page, with a link through to the API reference.

Disclosure: I work on Vaultion, the escrow API in Option B. Stripe details are from Stripe's own documentation as of October 2026; check the current docs before you build. This post was drafted with AI assistance.

A WooCommerce crypto checkout with no API key: where "paid" should come from

Vaultion — Wed, 14 Oct 2026 03:33:47 +0000

Most crypto payment plugins for WooCommerce start the same way: create an account with the processor, generate an API key, paste it into the plugin settings, and wait for a webhook to tell your store an order is paid.

That design has two weak points that have nothing to do with crypto. The API key is a secret sitting in your WordPress database, and the webhook is a message from someone else's server that your store has to believe. In 2026 several merchants learned a third weak point: when the processor changes course, the plugin goes with it. Coinbase Commerce's official WooCommerce plugin was closed on WordPress.org on 5 October 2026, and Cryptomus's was closed in April 2025.

So here is a different question to design around: what is the minimum a store needs to know, and where should "this order is paid" actually come from?

The store only needs an address

To receive a payment you need one thing: where the money should go. A receiving address is public by definition. If the plugin stores only that, there is nothing in the database worth stealing. No key to leak in a backup, no secret to rotate when a contractor leaves.

That pushes all the trust into one place: deciding when an order is paid.

Things that must never mark an order paid

// 1. The thank-you redirect
add_action( 'woocommerce_thankyou', function ( $order_id ) {
    wc_get_order( $order_id )->payment_complete(); // anyone can load this URL
} );

// 2. A transaction hash the buyer pastes in
if ( looks_like_tx_hash( $_POST['tx'] ) ) {
    $order->payment_complete(); // a real hash, for a different payment
}

// 3. An unsigned or unverified callback
$order->payment_complete(); // because a POST arrived

Each one trusts a claim instead of checking a fact. The redirect is a URL. The pasted hash may be real but belong to someone else's payment, or to this buyer's payment for a different order. The callback is a message from a server.

The only thing that should: a confirmed receipt

A blockchain transaction receipt is a fact anyone can check. A verifier that marks an order paid should confirm, on its own node or RPC, that:

The transaction succeeded and has the confirmations you require for that chain.
It is on the expected chain. The same address exists on Ethereum, Base and Arbitrum. A USDC transfer on the wrong one is not your payment.
The right token moved. Check the token contract address, not the symbol. Anyone can deploy a token called "USDC".
The right recipient got the right amount or more, read from the transfer itself, not from what the transaction claims it did.
It is bound to this order. One transaction must not be able to pay two orders, so the payment has to carry something committed to the order it is for.
It hasn't already been counted.

Only after all six does the store flip the order. Everything else the buyer or the browser says is a hint about where to look, never the evidence.

Taking a fee without taking custody

If the service charges a percentage, the usual answer is custody: the buyer pays the processor, the processor keeps its fee and pays the merchant later. That is where balances, payout schedules and frozen accounts come from.

On EVM networks, Solana and TRON there is another way. The buyer's wallet sends a single transaction that pays the merchant's share to the merchant's address and the fee to the fee address, both inside the same transaction. The merchant is paid the moment it confirms, and there is no balance anywhere to withdraw.

Bitcoin and Litecoin are harder. A transaction can have several outputs, but a standard bitcoin: payment link (BIP21) names one address and one amount, and that is all most wallets will pay from a QR code. So the practical design is a per-order deposit address that is forwarded after confirmation. That is a short period of custody, and an honest checkout should say so instead of calling the whole thing "non-custodial".

Where it leaves the buyer

A confirmed crypto payment cannot be charged back. Merchants like that; buyers paying a store they don't know may not. For high-value orders, the fix is not a chargeback but escrow: the payment is locked in a contract until the buyer confirms delivery or a review period ends, and the merchant can see the funds are there before shipping.

What we built

This is the design behind Vaultion Payments, a free WooCommerce plugin on WordPress.org: you paste receiving addresses and the checkout is live, with no account and no API key in the plugin. Orders are marked paid only from a confirmed on-chain receipt verified on the server. Direct payments on EVM networks, Solana and TRON split the merchant's amount and a 0.75% fee in the buyer's own transaction; Bitcoin, Litecoin and a "send to address" ETH option go through a deposit address and are forwarded after confirmation. Escrow in USDC or USDT is optional per store. The details, coin list and requirements are on the crypto payments for WooCommerce page.

Disclosure: I work on Vaultion. Escrow disputes on it go to Vaultion-assisted human arbitration, which is not decentralized: you are trusting Vaultion's reviewers. This post was drafted with AI assistance.

Selling a $5,000 Pokémon card to a stranger: what escrow solves, and what it can't

Vaultion — Fri, 09 Oct 2026 06:32:16 +0000

High-value trading cards have a trust problem that most payment tools were never built for. A PSA 10 Charizard, a sealed booster box or a vintage sports rookie can be worth thousands, the buyer and seller are usually strangers from a forum or a Discord, and the classic deal goes like this: one side sends first and hopes.

This post breaks down where card deals actually go wrong, which of those risks an escrow can remove, and which ones no escrow can touch, so you know what still has to be checked by a human.

The four ways a card deal fails

Payment, no card. The buyer pays first and the seller disappears. "Friends and family" payments and bank transfers usually leave no way to claw the money back.
Card, no payment. The seller ships first and the buyer disputes the payment afterwards, or the payment was never real.
Wrong card. A swapped slab, a lower grade, a raw card that was "near mint" in photos and isn't in hand, or a counterfeit.
Damaged or missing in transit. The box arrives crushed, empty, or not at all.

These are different problems. It helps to be precise about which one a tool actually fixes.

What escrow fixes: the payment side

An escrow holds the buyer's payment until the deal is done. With a smart-contract escrow the money sits in a contract rather than with a company, and the rules are fixed at creation:

buyer funds  ->  contract holds payment  ->  seller ships
                                         ->  buyer receives, checks, releases
                                         ->  or either side disputes, a ruling decides
                                         ->  or the review window ends and the seller can claim

That removes failures 1 and 2 outright:

The seller can ship knowing the money exists and is committed. It cannot vanish mid-deal.
The buyer is not trusting the seller with the money. Nothing moves to the seller until the buyer releases or a dispute is ruled.
Neither side can quietly take the funds and walk away.

Paying in a stablecoin such as USDC or USDT also means the price does not swing while the card is in the mail.

What escrow cannot fix: the card itself

This is the part a lot of "safe trading" advice glosses over. An escrow secures the payment, not the card. No contract can open a box, look at a slab or tell a real hologram from a fake. Failures 3 and 4 are still decided by evidence, and if there is a dispute, whoever rules can only rule on what they are shown.

So the job before funding is to make the card verifiable:

Agree the exact card in writing. Set, number, grade, and for a graded slab the certificate number. For a raw card, agree the condition and use the listing photos as the reference.
Check the cert yourself. PSA, Beckett (BGS) and CGC all run public certificate lookups. Confirm the cert number exists and matches the card, grade and label in the photos. Counterfeit slabs exist, so compare the label details, not just the number.
Ship tracked and insured, with a signature for high values. Delivery is the natural release trigger, and the tracking record is evidence.
Film the unboxing. One continuous video from sealed package to slab in hand is the strongest evidence a buyer can have if something is wrong.
Pick a review window that fits. It needs to cover shipping time plus a day or two to inspect. Too short and the buyer is rushed; too long and the seller waits for no reason.

Scams to watch for

Fake escrow sites. A "trusted middleman" link sent by the other party is a classic setup. Use an escrow you chose yourself, and with a smart-contract escrow you can check the contract address on a block explorer before sending anything.
Send-first pressure. "My last buyer flaked, I need payment today" is a script. A real seller who is willing to use escrow loses nothing by it.
Off-platform switches. Moving the conversation somewhere with no record removes your evidence.

Putting it together

For a high-value card, the safest version of the deal is: agree the card and cert number, verify the cert, fund an escrow, ship tracked and insured, film the unboxing, then release, or open a dispute with the evidence if it is not what was agreed. The escrow handles the money; the cert, the tracking and the video handle the card.

If you want to see how that flow works in practice for graded slabs, sealed product and vintage singles, we wrote up how trading card escrow works with stablecoins, including what happens in a dispute and what it costs.

Disclosure: I work on Vaultion, a non-custodial smart-contract escrow. Vaultion does not authenticate cards. This post was drafted with AI assistance.

Multisig, hold invoices and smart contracts: how non-custodial P2P escrow actually holds your coins

Vaultion — Fri, 09 Oct 2026 04:52:16 +0000

"Non-custodial" is the most overused word in peer-to-peer crypto trading. Every platform claims it. But the platforms that genuinely earn it do so in very different ways, and the mechanism decides what can go wrong, who can stall a trade, and what happens if the platform disappears.

This post compares the four escrow designs you will run into when looking at HODL HODL and the platforms people compare it with: a 2-of-3 multisig, Lightning hold invoices, security deposits with mediation, and smart contracts.

The test for "non-custodial"

A useful one-line test: if a support employee could move the funds on their own, it is custodial. Real non-custodial escrow means the money sits under rules that no single party, including the platform, can override. Trades settle to your own wallet, not to an internal balance.

Everything below passes that test. They just pass it differently.

1. A 2-of-3 multisig (HODL HODL)

HODL HODL locks each Bitcoin trade in a 2-of-3 multisig address. Three keys exist; any two can move the coins:

OP_2 <buyer> <seller> <escrow_agent> OP_3 OP_CHECKMULTISIG

Buyer and seller agree: two signatures, the coins move, nobody else is involved.
They disagree: the third key signs with whichever side the dispute process favours.

Strengths: plain Bitcoin script, nothing exotic, and the coins sit on-chain where anyone can see them.

Trade-offs: on-chain fees and confirmation times, Bitcoin only, and no built-in clock. If one side goes silent, someone still has to act on the dispute.

2. Lightning hold invoices (RoboSats)

RoboSats does escrow without an on-chain address at all. The seller pays a Lightning hold invoice: the payment is locked in-flight, not settled. The preimage that would settle it is only revealed once the buyer confirms the fiat payment, and if the trade fails, the invoice is cancelled and the sats return to the seller.

Strengths: fast, cheap, private (it runs over Tor with no registration), and nothing ever lands in a long-lived escrow address.

Trade-offs: hold invoices tie up liquidity along the route while they are open, so trade sizes are modest by design, and you need a Lightning wallet ready.

3. Security deposits and mediation (Bisq)

Bisq is desktop software rather than a website, with trades negotiated peer-to-peer over Tor and no central order book server. Both traders post security deposits alongside the trade amount, so each side has something to lose by misbehaving, and a mediation process handles disputes.

Strengths: no company acting as coordinator, strong privacy, and a deposit that makes stalling expensive.

Trade-offs: a heavier setup than a web signup, thinner liquidity, and deposits that raise the capital you need to trade.

4. Smart contracts

The fourth design moves the rules into a contract. Funds are locked in a contract that releases them on explicit conditions:

// simplified
function release() external onlyBuyer { _pay(seller); }
function claimAfterTimeout() external onlySeller {
    require(block.timestamp >= deadline, "review window open");
    _pay(seller);
}
function rule(uint8 ruling) external onlyArbitrator {
    ruling == 1 ? _pay(seller) : _pay(buyer);
}

Strengths: timeouts are part of the contract, so a silent counterparty cannot block the other side forever. It works with stablecoins, which removes the incentive to stall a dispute while the price moves. And the arbitrator can be a decentralized court such as Kleros instead of a single person.

Trade-offs: you are trusting the contract code, so it needs to be open source and verified on a block explorer. And a contract on its own is not a marketplace: it settles a deal, it does not find you a counterparty.

Side by side

	Multisig (HODL HODL)	Hold invoice (RoboSats)	Deposits (Bisq)	Smart contract
Where funds sit	On-chain 2-of-3 address	In-flight Lightning payment	On-chain, with deposits	Contract you can inspect
Silent counterparty	Needs the dispute key	Invoice expires or is cancelled	Mediation	Built-in timeout
Assets	BTC	BTC (Lightning)	BTC and others	Stablecoins and tokens
Finds you a trader	Yes	Yes	Yes	No

The question to ask first

The most useful question is not "which is best" but "do I need a marketplace, or do I need escrow?" If you want to be matched with strangers to buy or sell Bitcoin for fiat, you need a marketplace, and the first three designs are built for that. If you have already agreed a deal with one specific person (an OTC trade, a freelance milestone, a domain sale), the order book is overhead and a plain escrow contract is the narrower tool.

For a fuller comparison of the platforms themselves, including which ones have shut down and which fake "revived" versions to avoid, see our write-up of Hodl Hodl alternatives, which covers Bisq, RoboSats, Peach and LocalCoinSwap in more depth.

Disclosure: I work on Vaultion, a non-custodial smart-contract escrow, which is the fourth design above. Platform details change, so check current rules on any service before trading. This post was drafted with AI assistance.

From Bitrated's 2-of-3 multisig to smart-contract escrow: how trustless escrow actually works

Vaultion — Fri, 09 Oct 2026 04:46:21 +0000

Back in 2014, Bitrated did something clever: it let two strangers trade Bitcoin without either of them, or the platform, holding the money. A decade later the site is widely described as inactive, but the design problem it solved hasn't gone anywhere. Freelancers, OTC traders and domain buyers still need a way to say "I'll pay, but only when you deliver" without trusting a middleman with the funds.

This post walks through how Bitrated's model worked at the protocol level, where it broke down in practice, and how the same idea looks when you move it from a Bitcoin multisig script into a smart contract.

How Bitrated escrow worked: a 2-of-3 multisig

Bitrated never held coins. Each trade created a pay-to-script-hash (P2SH) address controlled by three keys:

the buyer
the seller
an arbitrator the two parties chose from a marketplace

The redeem script looked roughly like this:

OP_2 <buyer_pubkey> <seller_pubkey> <arbitrator_pubkey> OP_3 OP_CHECKMULTISIG

Any two of the three signatures could spend the output. That gives you three paths:

Happy path: buyer and seller both sign, and the funds go to the seller. The arbitrator never sees the trade.
Buyer wins a dispute: buyer and arbitrator sign a refund.
Seller wins a dispute: seller and arbitrator sign the release.

The elegant part is that the platform is not in the signing set at all. Even if Bitrated disappeared, the coins would still sit in a standard multisig address on the Bitcoin blockchain, recoverable by any two key holders with a wallet that can import the redeem script (Sparrow and Electrum both can).

Where the model struggled

The cryptography was fine. The problems were operational:

Finding an arbitrator. The 2-of-3 design only works if the third key belongs to someone who is still around and still responsive when the dispute happens. As the marketplace thinned out, that stopped being a safe assumption.
Volatility during disputes. A trade priced in BTC can move 10% while two people argue over a delivery. Whoever benefits from the price move has a reason to stall.
No programmable exits. A multisig has no clock. If the buyer simply goes silent, the seller needs the arbitrator to act; there is no built-in "release after N days" rule.
Bitcoin only. No stablecoins, so every deal carried price risk by default.

The same idea as a smart contract

A smart-contract escrow keeps the core property, that no operator holds the funds, but replaces "any two of three keys" with explicit rules in code. A minimal version is a small state machine:

enum State { Funded, Released, Refunded, Disputed, Resolved }

function release() external onlyBuyer inState(State.Funded) {
    state = State.Released;
    token.transfer(seller, amount);
}

function claimAfterTimeout() external onlySeller inState(State.Funded) {
    require(block.timestamp >= deadline, "review window still open");
    state = State.Released;
    token.transfer(seller, amount);
}

function raiseDispute() external onlyParty inState(State.Funded) {
    state = State.Disputed;
    // hand the case to an arbitration venue
}

function rule(uint256 ruling) external onlyArbitrator inState(State.Disputed) {
    state = State.Resolved;
    // ruling 1 = pay seller, ruling 2 = refund buyer
}

(Simplified for illustration: a production contract also needs reentrancy protection, a pull-payment ledger instead of direct transfers, and careful handling of fees.)

Compared with the multisig, three things change:

Timeouts are first-class. A silent buyer can no longer block the seller forever. The deadline is written into the contract when the escrow is created, so both sides know the rules up front.
Stablecoins by default. Escrowing USDC or USDT removes the volatility incentive to stall a dispute.
The arbitrator can be a protocol instead of a person. Instead of a single third key, a dispute can be routed to a decentralized court such as Kleros, where jurors are drawn at random and stake tokens on their rulings. Some services also offer a human review panel as an alternative venue; the trade-off there is that you are trusting that panel rather than a jury, so it is worth checking what the panel can and cannot do with the funds.

What to check before you trust any escrow contract

Whether you are picking a service or writing your own, the checklist is short:

Is it actually non-custodial? The funds should sit in a contract you can inspect, not in a company wallet.
Is the source verified on the block explorer? You should be able to read the release, refund and timeout logic yourself.
What happens if one side goes silent? Look for an explicit deadline path, not "contact support".
Who can rule on a dispute, and what can they do? The ideal answer is "pay the buyer or the seller, and nothing else". No party, including the operator, should be able to send the funds anywhere else.
What does it settle in? For anything that takes more than a day, stablecoins are the safer default.

Wrapping up

Bitrated proved that escrow doesn't need a custodian. Smart contracts keep that property and fix the parts that wore down over time: timeouts replace absent arbitrators, stablecoins remove the incentive to stall, and decentralized courts replace a marketplace you had to hope was still alive.

If you are moving an old Bitrated trade off the platform, or comparing what replaced it, we put together a longer guide to Bitrated alternatives that covers multisig wallets, smart-contract escrow, custodial services and P2P marketplaces, plus a step-by-step migration playbook for recovering funds from an existing Bitrated multisig.

Disclosure: I work on Vaultion, a non-custodial smart-contract escrow. This post was drafted with AI assistance and reviewed before publishing.

Escrow.com doesn't process crypto — here's the honest alternative

Vaultion — Sun, 12 Jul 2026 18:59:37 +0000

If you've gone looking for an "escrow.com alternative" because your deal is in crypto, there's a fact worth knowing up front: escrow.com is a fiat escrow service, and its own currency documentation states that it doesn't process cryptocurrency. That's not a knock on escrow.com — it's excellent at what it does — it just means a crypto-denominated deal needs a different kind of tool. Here's an honest comparison and where the crypto-native options fit.

What escrow.com is genuinely good at

Escrow.com has been the default online escrow service since 1999. It's licensed and regulated, holds funds in a regulated account, verifies both parties with KYC, and runs a formal dispute process with a real team and legal recourse behind it. For buying a domain, a vehicle, a business, or settling a high-value services deal in dollars, euros, pounds, or Australian dollars, it's about as trusted and battle-tested as online escrow gets.

None of that is in question. If your transaction is in fiat — especially a large or traditional-asset deal where you want a regulated company and a paper trail — escrow.com or a comparable licensed service is very likely the right answer. A crypto-native tool is not automatically better just because it's newer.

Why people look for a crypto alternative

The catch is currency. Escrow.com's documentation lists the currencies it handles — US dollars, Australian dollars, euros, and British pounds — and states plainly that anything not listed, including any cryptocurrency, cannot be processed. So if your deal is denominated in Bitcoin, a stablecoin, or any other crypto asset, escrow.com simply isn't built to hold it, no matter how trusted it is for fiat.

On top of that, its model is account-based, KYC-gated, and settles over bank rails. That's the right design for regulated fiat, but a poor match for a wallet-to-wallet crypto deal where both sides expect to move on-chain in minutes without onboarding to a financial institution. No crypto support, plus a fiat-shaped workflow, is what sends crypto users looking elsewhere.

The three shapes of crypto escrow

Within crypto escrow there are really three models, and they map to different priorities:

Licensed custodial crypto-escrow — the closest in spirit to escrow.com. A regulated company holds the crypto, requires KYC, and handles disputes with a team. Good if you specifically want a company to call and formal recourse on a large crypto deal.
Non-custodial smart-contract escrow — the opposite end. Funds live in an on-chain contract no company controls, released on agreed conditions, with disputes routed to a decentralized court rather than an employee. You hold no account and can verify everything yourself.
P2P marketplace escrow — escrow bundled into trade-matching. Better for crypto-for-fiat trades than for arbitrary deals.

The honest trade-off between the first two is the important one: a regulated custodian gives you institutional recourse and a legal department; a non-custodial contract gives you verifiable proof that no company — including the operator — can move the funds outside the contract's rules. Those are different risk models: institutional protection versus on-chain verifiability. Neither is universally safer; it depends on what you're guarding against.

How to choose

The decision is mostly about what your deal is denominated in:

Fiat — a domain, a vehicle, a business, a services contract in dollars or euros — use escrow.com or a comparable licensed service. That's what they're for.
Crypto, and you want a company holding the funds with KYC and formal recourse — look at a licensed custodial crypto-escrow service.
Crypto, and you'd rather hold no account, keep custody out of any company's hands, and verify the whole thing on-chain — a non-custodial smart-contract escrow fits.

There's no single winner here. Escrow.com and a non-custodial crypto escrow are solving different problems; the mistake is forcing one to do the other's job.

Where a non-custodial option fits

For the crypto-denominated deal escrow.com can't take, Vaultion is one non-custodial smart-contract option: funds lock in a published, open-source contract — not held by Vaultion — and release by the buyer, by a timeout, or by a ruling from Kleros, an independent decentralized court. It settles in stablecoins, needs no account, and lets you read the contract and the arbitrator on a block explorer before you commit anything.

The honest scope matters, though. Vaultion is not a licensed, regulated, fiat escrow — that's precisely escrow.com's territory, and if you need a regulated institution or fiat settlement, escrow.com remains the better choice. And like any escrow, it secures the payment side of a deal, not the counterparty — your own due diligence on the other person still applies. What a non-custodial design offers is the one thing a fiat service structurally can't: verifiable, self-custodied escrow for a crypto deal, with no operator able to touch the funds.

Written by the team at Vaultion, a non-custodial crypto escrow for stablecoin deals. Not a licensed or regulated institution — the model is verify-on-chain rather than trust-a-company.

The honest limits of crypto escrow (and when it isn't worth the fee)

Vaultion — Sun, 12 Jul 2026 18:53:10 +0000

Most articles about crypto escrow only list the upsides. This one does the opposite, because knowing where a tool stops working is what lets you use it well. Escrow is genuinely useful, but it is not a magic guarantee, and treating it like one is how people still lose money with it. Here's what crypto escrow actually can't do, where the trade-offs bite, and how to decide whether it's worth paying for on a given deal.

It secures the payment, not the counterparty

Escrow guarantees the money is handled by rules both sides agreed to. It says nothing about whether the person on the other end is honest, or whether what they deliver is any good. If a seller ships something that doesn't match the description, escrow can't turn it into what you wanted — what it can do is hold the funds so the disagreement goes to a dispute instead of the money simply being gone.

That distinction matters before you start. Escrow closes the "who goes first" risk and the "middleman runs off with the money" risk. It does not vouch for quality, identity, or intent. Due diligence on the counterparty is still on you.

Crypto is final — there's no chargeback

Once an escrow releases funds on-chain, that's the end of it. No bank to call, no card issuer to reverse the charge, no chargeback window. That finality is the feature: nobody can claw a payment back from you the way they can with a card. But it's also the hard limit — if you release too early, or you get a dispute ruling you disagree with, there is no undo.

This is exactly why escrow holds funds until conditions are met instead of paying out directly: the protection is built in up front, not bolted on afterward. Confirm the other side actually delivered before you approve, because approval is a one-way door.

Disputes take time, and they rule on the evidence

A dispute is not instant. There's a window to submit evidence, the arbitrator reviews it, and only then does the contract carry out the result. For a small, time-sensitive deal, that wait can be frustrating — and anyone advertising an "instant" resolution is misrepresenting how arbitration works.

Just as important: the arbitrator rules on the evidence each side submits, not on a physical inspection. A clear, well-documented case can win; a true-but-poorly-presented one can lose. Keep your records — the agreed terms, proof of delivery, the transaction hashes — because that is what a ruling is built on.

It costs money, and it isn't always worth it

Escrow isn't free, and it isn't automatically the cheapest way to transact. There's a platform fee (on most non-custodial services, a small percentage of the deal taken once), network gas on top, and — if a dispute is raised — a separate arbitration fee. None of it is hidden, but it adds up, and it changes the math on small deals.

The honest rule of thumb: escrow is worth it when the cost of being stiffed clearly exceeds the fee. On a $50 deal, the fee can outweigh the risk it covers. On a $500-plus deal with someone you don't know, it usually pays for itself. For a tiny amount, or a counterparty you already trust, escrow may just be friction you don't need.

The mistakes that cause most avoidable losses

A few habits account for most of the losses escrow should have prevented:

Releasing early. "I'll release now as a gesture of good faith" is how people get burned. Approval is one-way; wait for delivery.
Drifting off the agreed flow. If a counterparty pushes you into a side channel or changes the deal, change the escrow terms — don't improvise around them.
Vague terms. "A logo" is a dispute waiting to happen; "three concepts, two revisions, final files in SVG and PNG" is something an arbitrator can actually rule on.

None of this is unique to crypto — it's the discipline any escrow demands. The difference on-chain is that the rules are fixed in code, so the clearer your terms and the better your records, the more the system behaves the way you expect.

When it's actually worth it

Escrow earns its fee when you're dealing with a stranger, when the handover is hard to reverse, or when there's no practical legal recourse if things go wrong — the situations where going first is a real risk. For everyday purchases from an established merchant with its own buyer protection, it's usually overkill.

And if you do use one, the detail that matters most is who holds the money. A non-custodial design — where funds sit in an open-source smart contract that no company controls, and you can read the contract and the arbitrator on a block explorer before committing — is easier to trust than a service asking you to rely on an account you can't see. Escrow isn't a guarantee; it's a tool whose limits and rules you can verify for yourself up front. For how to tell a real escrow service from a fake one, this guide covers the red flags.

Written by the team at Vaultion, a non-custodial crypto escrow for stablecoin deals — funds lock in an open-source smart contract and release on agreement or by an independent dispute ruling.