Blog

Bitcoin‑Native Escrow for Used ASIC Trades (Without Custody)

Used ASIC deals fail for one boring reason: settlement and shipping don’t trust each other. This primer explains Bitcoin‑native, non‑custodial escrow (multisig + PSBT) in plain terms—what it protects, what it doesn’t, and the checklist that keeps high‑value trades moving.

Yuri Yerofeyev

Yuri Yerofeyev

— 6 min read
Bitcoin‑Native Escrow for Used ASIC Trades (Without Custody)

You find a lot of used S19s at a good price. The seller has references, but they’re on the other side of the world. Wiring bitcoin first feels like walking into traffic. The seller’s view is symmetrical: shipping ten ASICs to a stranger on the promise of “I’ll pay when they arrive” is just as insane.

This is the exact niche for Bitcoin‑native escrow: a way to lock payment so neither side can unilaterally defect while the physical shipment happens.

The clean model is simple:

Use 2‑of‑3 multisig: buyer holds one key, seller holds one key, and a neutral coordinator holds one key. Funds can move only with two signatures. If the deal is smooth, the coordinator never touches the money.

1) Define the terms (so we don’t talk past each other)

Escrow is a settlement control system. It changes when money can move and who must approve the move.

For ASIC trades, a typical escrow sequence is:

  1. Buyer locks funds.
  2. Seller ships hardware.
  3. Buyer performs the agreed acceptance test.
  4. Funds release.

Escrow is not an inspection service, a warranty, or an insurance policy. It won’t magically tell you whether a hashboard was reworked or whether a unit was heat‑stressed for a year. It makes one thing boring and reliable: payment release.

2) The primitive: m‑of‑n multisig

In Bitcoin, coins are spendable only if you satisfy the conditions of a locking script. Multisignature (multisig) means the script requires m of n keys to sign.

For physical goods, the standard escrow pattern is 2‑of‑3:

  • Key A: buyer
  • Key B: seller
  • Key C: neutral third party (coordinator / arbitrator)

This pattern is old and well understood in Bitcoin. It shows up in:

  • community documentation describing “buyer–seller with escrow” as a canonical 2‑of‑3 use case, and
  • the original multisig transaction discussion (BIP‑11) as a three‑party escrow pattern.

Why 2‑of‑3 (instead of 2‑of‑2)? Because you want a pressure‑relief valve. If one side goes silent, a neutral third key can prevent funds from being stuck forever.

3) What “non‑custodial escrow” actually means

People say “non‑custodial” as marketing. Here’s the useful definition:

  • Custodial escrow: a third party holds the funds (one party can spend unilaterally). You are trusting their security and honesty.
  • Non‑custodial multisig escrow: the third party coordinates and can resolve deadlocks, but cannot move funds alone.

Non‑custodial doesn’t mean “trustless.” It means the trust is constrained:

  • In many escrow models, you still rely on the coordinator’s judgment if there’s a dispute.
  • In other models, the coordinator doesn’t judge at all — they act only on a pre‑defined verification process (e.g., a court order verified by counsel).
  • In both cases, you don’t rely on the coordinator to not steal your money, because they can’t.

That distinction is the whole point.

4) Threat model (what multisig prevents — and what it doesn’t)

Prevents / makes expensive:

  • Seller takes prepayment and never ships.
  • Buyer receives shipment and tries to stall payment indefinitely.
  • Escrow agent runs away with the funds (in the 2‑of‑3 model).

Does not prevent:

  • Bait‑and‑switch units, hidden repairs, or misrepresented condition.
  • Transit damage and carrier disputes.
  • “Gray DOA” fights when acceptance criteria are vague.

Multisig escrow is strongest when it is not asked to invent truth. That’s why acceptance criteria and evidence rules matter.

5) How a 2‑of‑3 ASIC escrow works (happy path + dispute path)

One detail dealers appreciate: multisig escrow is not a loan and not a “hold.” The buyer isn’t “sending money to the escrow guy.” The buyer is sending money into a script that neither the seller nor the coordinator can spend alone.

Step 0: Write terms before anyone generates an address

Do this first. If you can’t state what “accepted” means, you can’t resolve disputes fairly.

Minimum terms for used ASIC lots:

  • Exact list: model(s), quantity, whether PSUs are included, accessories.
  • Unit identifiers: serials when possible, or a seller “proof pack” (continuous video + labels).
  • Acceptance test: what firmware/pool, duration, and hashrate tolerance.
  • DOA window: e.g., 24–72 hours after delivery scan.
  • Shipping: method, insurance, who pays shipping and return shipping in each outcome.
  • Evidence standard: unboxing video, label photos, miner logs/pool screenshots.

Step 1: Create the multisig wallet configuration

All three parties contribute a key to a 2‑of‑3 policy.

At this stage, the real risk isn’t “Bitcoin is hard.” The real risk is setup tampering and configuration drift:

  • swapped or missing keys (you think you’re in the multisig; you’re not)
  • wrong threshold (1‑of‑3 masquerading as 2‑of‑3)
  • incompatible script/derivation details (everyone derives a different address)

This is why multisig has standardization work focused specifically on exchanging/verifying configuration (e.g., BSMS / BIP‑129), and why deterministic key sorting (BIP‑67) exists: fewer foot‑guns, fewer “address mismatch” disasters, and a smaller surface for substitution attacks.

Step 2: Verify the deposit address (don’t trust a chat message)

The buyer should fund only an address that they can verify is derived from the agreed policy.

Practical rule:

  • If the deposit address arrives as “here’s the address,” treat it as untrusted input.
  • Verify it using the wallet’s multisig configuration view (or via a standardized config export) and, ideally, confirm it out‑of‑band.

Step 3: Buyer funds escrow; seller waits for confirmations

Seller waits for confirmations appropriate to the amount and risk. (For high‑value lots, be conservative.) Only after that should the seller ship.

Step 4: Seller ships; buyer tests within the agreed window

The buyer should document the condition at delivery and run the acceptance test promptly. The goal is to avoid indefinite “escrow limbo.”

Step 5: Release funds with PSBT

This is where modern multisig becomes practical.

PSBT (Partially Signed Bitcoin Transactions, BIP‑174) is the standard format for passing an unsigned/partially signed spend transaction between multiple signers (including offline signers). It exists specifically so different wallets and devices can cooperate without bespoke formats.

If you’ve ever used Nunchuk (or similar collaborative wallets), this will feel familiar: one signer produces a PSBT, the next signer adds a signature, and you “chain” the PSBT along until it has enough signatures to broadcast.

In the happy path:

  • One party (often the seller or coordinator) prepares a spend transaction paying the seller.
  • They export it as a PSBT.
  • Buyer and seller each sign.
  • Once two signatures are present, the fully signed transaction is broadcast.

In the dispute path, there are two common approaches:

  • Arbitration model: the coordinator reviews the pre‑agreed evidence bundle and co‑signs with the party that wins under the deal terms.
  • Non‑arbitration model: the coordinator does not judge facts; they co‑sign only after a defined external process (for example, a court order that is verified by counsel).

6) Two misconceptions that kill deals

  1. “Escrow replaces due diligence.” It doesn’t. Escrow controls settlement; it doesn’t verify identity, inventory, or condition.
  2. “Any escrow is fine.” Custodial escrow is easy to impersonate and easy to rug. Non‑custodial multisig escrow is safer only if everyone verifies the multisig policy and deposit address.

7) A dealer‑friendly runbook (copy/paste)

Before funding

  • [ ] Terms written: price, hardware list, shipping, DOA window, acceptance test
  • [ ] Counterparty verified: references + consistent identity
  • [ ] Multisig policy verified: 2‑of‑3, correct participants/keys
  • [ ] Deposit address verified: derived from that policy (not “sent in chat”)

After funding

  • [ ] Confirmations reached (amount‑appropriate)
  • [ ] Seller ships: trackable method + insured if agreed

On delivery (within window)

  • [ ] Unboxing video starts before cutting tape
  • [ ] Labels/serial evidence captured
  • [ ] Acceptance test performed (hashrate stability, temps, missing boards)

Release

  • [ ] Payout PSBT reviewed (outputs + fees) and signed by the right parties
  • [ ] Txid saved with the deal record

8) Where Tetrapolar fits

Tetrapolar is a non‑custodial Bitcoin escrow coordinator for high‑value ASIC trades.

At a high level it looks like the multisig model described above (terms off‑platform, lock funds, release via collaborative signing), but with two important specifics:

  • Two‑branch Miniscript: the escrow script is structured as two spending paths — a cooperative 2‑of‑2 path first (buyer+seller), and a fallback 2‑of‑3 path that becomes available only after a timelock expires.
  • No “judging” disputes: Tetrapolar does not arbitrate hardware condition. In the fallback path, signing is based on an external verification process (e.g., a court order verified by a third‑party law firm), rather than an internal decision.

Design principle: deals should be portable. The configuration and spend flow should be expressible in standard wallet formats so users are not trapped in one service.

Closing

Escrow isn’t romance. It’s plumbing.

If you’re moving serious value across borders for used mining hardware, the objective isn’t to eliminate risk. It’s to make honest trades easy and make dishonest behavior expensive — while keeping the mechanism legible and hard to scam.

A Bitcoin‑native 2‑of‑3 multisig escrow, executed with PSBT and verified configuration, is the most boring way to do that. Which is exactly why it works.

References

Read more