Stablecoin escrow for B2B deals splits into two mechanisms that behave very differently under the law. Multi-sig escrow is a custody arrangement; a smart-contract escrow is code that holds and releases funds based on programmed conditions. Both can hold USDC. Only one needs a serious legal wrapper to survive a US or UK enforcement test. This piece walks the mechanics, the providers, and the enforceability question deal counsel actually asks.
​

Buyer transfers USDC to an escrow address (multi-sig wallet or smart contract). The release condition is encoded (signatures from buyer + seller + arbiter, or an oracle attesting delivery). When met, funds release to the seller. If unmet within a timeout, funds return to the buyer. No bank holds the money. Settlement is final on confirmation; there is no chargeback window. The legal contract sits alongside the code, not inside it.
​

Multi-sig is the simpler shape. Funds live in a wallet that needs M-of-N signatures to move. A 2-of-3 setup with buyer, seller, and a neutral arbiter (a law firm, a service like Kleros, or an escrow agent) is the standard B2B configuration. Release requires either both counterparties signing or the arbiter siding with one. Multi-sig has no programmable logic beyond signature thresholds.
​

Smart-contract escrow encodes the release condition in code. The contract holds USDC and executes release when a specified event fires: an oracle reports shipment, both parties call a confirm function, a timeout expires, or a dispute resolution module returns a verdict. Contracts like OpenZeppelin's PaymentSplitter and custom escrow patterns from audited templates are the building blocks. Smart-contract escrow scales: the same contract can run thousands of deals in parallel with no human in the loop.
​

Tradeoff: multi-sig is legally cleaner (it is just a custody arrangement, no novel question), and smart-contract escrow is operationally cleaner (no human signs every release). Most live B2B deals in 2026 use multi-sig with a human arbiter for first-time counterparties and migrate to smart-contract escrow for repeat trade.
​

There is no federal contract law in the US. Enforceability is state law. The Harvard Law CorpGov forum and the Skadden Arps whitepaper both reach the same conclusion: a smart contract can give rise to a legally enforceable contract if the traditional elements are present. Offer, acceptance, consideration, mutual assent, capacity, and legality. The code is the performance mechanism; the contract is the agreement around it.
​

UCC Article 1 (general provisions) governs definitions and good-faith requirements across commercial transactions. It does not block smart contracts. Several states (Arizona, Tennessee, Illinois, Wyoming) have passed laws explicitly recognizing smart contracts as legally enforceable when they meet contract-law requirements. These statutes do not create a new contract category; they clarify that automation does not invalidate enforceability.
​

The practical pattern deal counsel uses: a natural-language master services agreement governs the deal, an exhibit references the specific smart-contract address and version hash that handles escrow, and a dispute fallback clause names the jurisdiction and arbitration body. The code does the work; the paper carries the legal weight if something breaks.
​

The UK Jurisdiction Taskforce issued a legal statement in November 2019 confirming that smart contracts are capable of forming legally binding contracts under English law. English contract law applies as it does to any other contract.
​

UK practice mirrors US practice. The natural-language agreement is the contract; the smart contract is the performance mechanism. The jurisdiction clause matters more than the code in a dispute.
​

Three failure modes need explicit handling. First, the smart-contract bug. If the escrow contract has a flaw and funds get stuck or stolen, the natural-language wrapper needs to specify who absorbs the loss. Most enterprise B2B contracts route this to the party that selected the contract (often the seller, who chose the rail).
​

Second, the offchain dispute. The customer claims the goods were defective. The smart contract has no way to verify quality. The wrapper specifies the dispute path: arbitration, court, or a named arbiter with multi-sig override authority. Some setups use a 2-of-3 multi-sig where the arbiter is a law firm with pre-signed authority to break ties.
​

Third, the regulatory clawback. If a counterparty is sanctioned mid-deal, the funds in escrow may need to freeze. Custodial escrow (Fireblocks, Anchorage) handles this through policy controls. Pure smart-contract escrow without an admin key cannot freeze; this is a feature or a bug depending on the deal.
​

Standard shape: 2-of-3 multi-sig on a Safe wallet on Base or Ethereum mainnet. Signers are buyer, seller, and the seller's outside counsel as arbiter. Release condition: both buyer and seller sign on delivery confirmation, or after a 30-day timeout the arbiter has authority to release based on documentary evidence. Natural-language MSA governs; jurisdiction is Delaware or New York. USDC sits in the Safe earning nothing during the hold period (a feature: no rehypothecation risk).
​

For repeat trade above 100 deals per year between the same counterparties, the same pair migrates to a smart-contract escrow with the law firm as a multi-sig admin on the contract for break-glass intervention.
​

Three questions cover most of the risk surface. What is the audit history of the contract or custody software (date, auditor, scope)? Who holds the keys to any admin or upgrade functions? What is the documented path for sanctioned-counterparty handling? If the provider cannot answer all three in writing, the deal counsel will block. As they should.
​