Bilateral collateral escrow is a proposed arrangement in which both parties to an exchange lock collateral, normally a dollar stablecoin, in a smart contract before either of them makes the payment they have promised. The collateral is not the money being exchanged. It is a security deposit that is returned when both sides perform and can be paid to the injured side when one of them defaults. The term is a practitioner label rather than settled industry vocabulary: it was set out by payments adviser Faisal Khan in 2026 as a way for strangers to complete off-chain currency swaps without having to trust each other.
The design targets trades in which both payment legs run outside a blockchain, for example a dollar transfer in the United States against a naira transfer in Nigeria. Because the two legs travel over separate banking systems, they cannot settle at the same instant, which creates the classic execution risk of who pays first. The model is related to, but different from, a plain stablecoin escrow, which holds the trade amount itself, and to a performance bond, which it closely resembles.
Bilateral collateral escrow in plain terms
Think of two people swapping concert tickets by post. Neither wants to post first, so each hands a friend a deposit worth more than the tickets. When both tickets arrive, the friend gives the deposits back. If one person never posts, the other keeps that person's deposit and ends up better off than if the swap had simply been honoured.
Bilateral collateral escrow replaces the friend with a piece of software that holds the deposits and follows fixed rules. Each trader gives up something only if they cheat, and the amount they would lose is bigger than anything they could gain. That turns honesty into the cheapest option, even between people who have never met.
How the arrangement works
In the version described in 2026, the process runs in a fixed order:
- Both parties deposit collateral, for example 1,000 USDC or Tether (USDT) each, into the contract, which locks it for the life of the trade.
- The contract authorises an off-chain trade worth only part of each deposit, such as 80%, so the maximum trade is 800 dollars and each side is covered at 125%.
- Each party sends its leg through its own bank, for instance a dollar transfer to an account in New York and the agreed amount of Nigerian naira to an account in Lagos.
- Both parties confirm receipt within a deadline, and the contract releases both deposits.
- If either party claims non-payment, the deposits stay locked while the dispute is decided, and the contract then pays out according to the decision.
The 125% cover is a form of overcollateralization: a party trying to steal 800 dollars risks losing 1,000. The same deposit can be reused for many trades in sequence, so a trader's throughput during a day can be far larger than the collateral, while open exposure at any moment stays within a fixed exposure limit.
What the smart contract cannot verify
A contract on a blockchain can see deposits, balances, timestamps and confirmations submitted to it. It cannot see a bank account. Whether a domestic transfer really arrived, whether a receipt is genuine or whether a payment was later reversed are facts from outside the chain, which is the blockchain oracle problem. Proposals therefore rely on signed confirmations, banking application programming interfaces (APIs) or human review of evidence.
When the parties disagree, someone has to decide what happened. That role is arbitration, not arbitrage, and it sits within a wider dispute resolution process. The adjudicator does not handle the payments and only acts when a trade goes wrong; the contract then enforces its ruling by releasing or reallocating the locked funds. For this reason the design does not claim to be a fully trustless system. It moves trust from the counterparty to a defined process.
Design questions and risks
The concept raises practical questions that decide whether it can work:
- Control of the contract. Whoever holds an admin key able to upgrade or pause the contract could move or lock the collateral.
- Issuer powers. Major fiat-backed stablecoins can be frozen by their issuers, so stablecoin freezing could trap deposits in the contract.
- Reversals and fraud. A bank payment recalled after the collateral is released, or a transfer sent from a mule account, leaves the honest party exposed.
- Reputation traps. A confidence scam often starts with many small honest trades, which is why the design keeps every trade collateralised regardless of history.
The approach also depends on the quality of the stablecoin collateral itself: a depeg during an open trade would weaken the cover.
Placing collateral in software does not take the activity outside financial regulation. Depending on who controls the contract, matches the traders and earns fees, an operator could be treated as a money transmitter, a foreign-exchange dealer, an escrow agent or a virtual-asset service provider, with know your customer (KYC) and sanctions screening duties. Cross-currency swaps of this kind can also breach local currency controls.
The design sits alongside other ways of handling counterparty risk: payment versus payment (PvP) systems link two currency legs inside regulated infrastructure, atomic swaps do the same for two on-chain assets, and platform escrow on P2P trading venues holds the crypto side while the fiat leg is paid. Bilateral collateral escrow aims at the gap none of these covers: two off-chain legs between people who do not trust each other, a market that peer-to-peer FX traders already serve informally.