Redefining Trust: Smart Escrow Contracts

Blockchain smart contracts enable trust-minimizing escrow agreements, where value can be received, held, and remitted pursuant to objective conditions and triggers.

Defining Escrow

The traditional escrow agreement is an arrangement between adverse parties where the timing mismatch of performance and payment is rectified by placing any combination of value, documents, assets, signatures, and other conditions or actions with a third-party escrow agent.

Generally, when all required conditions to a transaction’s closing are complete or satisfied, the escrow agent releases funds along with signed and dated documents to close the deal. A title company or other specialized trade or regional entity may act as an escrow agent; occasionally, larger institutions such as banks or law firms might take on the escrow role.

When third-party entities execute these agreements on behalf of the contracting parties, the risks of security or contractual breach and other unintended actions augment the transaction expenses to the already complicated conditions of the contract.

By replacing third-party escrow agents with blockchain smart contracts, value can be received, held, and remitted under a predetermined set of objective conditions without requiring trust in a third-party entity or individual. Smart escrow contracts leverage the security of thousands of independent nodes running automatically executing code which can also leverage “off-chain” data (i.e. not blockchain-native data, such as data fed by web APIs) by using off-chain-to-onchain translation software known as an “oracle.”

An oracle receives data requests from blockchain smart contracts (such as the smart escrow contract suggested here), reads the traditional API, and returns the data in a readable format for blockchains.

By using oracles as a gateway for traditional data to blockchains, smart contract escrow can be expressly contingent and automatically execute upon objective external data or conditions like e-signature events, payment messages, financial data, or internet-of-things (“IoT”) data.

With Airnode, API3 is dedicated to ensuring that each oracle is a first-party oracle (i.e. data provider-run) to minimize vulnerability in the objective data needed for such executions.

When escrow agents are brought into contractual agreements to simply conduct bilateral value transfers, trustless automation presents a breadth of disruptive potential. Traditional escrow agreements tend to suffer from inefficiencies and issues such as:

• Restriction to the working hours of the parties and escrow agent, especially when international parties face different time zones, which may cause delays and additional costs, including:

  
  

1. Opening and utilizing an intermediary account or escrow agent for closings outside of local banking hours;
2. Interest rate slippage, foreign exchange adjustments, swap/break costs, repricing transaction costs if delayed;
3. Accommodating concerns for temporary time zone overlap, pertinent asset location or condition affecting legal or tax favorability, etc.;
4. Tax or funding timing (such as expiry of the fiscal or calendar year, incentive period, stipend, etc.); and
5. Expediting satisfaction of other conditions precedent in order to meet such deadlines may carry additional costs and risks.

• High fees for merely receiving, holding, and transferring funds;

• Legal and accounting fees for negotiating the escrow agent’s agreement mechanics and payment waterfalls;

• Prolonging negotiation and deal process to accommodate escrow parameters, which usually permits an escrow agent’s resignation and substitution with unilateral notice;

• Using an escrow agent often requires a unique additional set of know-your-customer requirements to comply with anti-money laundering regulations; and

• Relying on the trust of a centralized third party presents an additional layer of security risk and potentially misaligned incentives including access to otherwise confidential information;

  
  

  1. Clauses absolving the escrow agent of liability for human error, for example: “for any error in judgment made in good faith by an officer or employee of the escrow agent unless proven that the escrow agent was grossly negligent in ascertaining the pertinent facts or acted intentionally in bad faith”[1]; and

  
  

  2. Auto-compliance clauses leave the agent’s processing of funds at the whims of pending litigation or arbitration. In some circumstances, funds are frozen during investigations,[2] regardless of relation to the transaction at hand.

Many of these problems give smart contracts an opportunity to disrupt the traditional escrow agreement. By placing funds or other digital consents into smart escrow contracts, transacting parties may effectively eliminate several of the above-mentioned problems.

Such forms of digital consent can include things like funds converted to cryptocurrency, stablecoins or tokens[3]; e-signatures; or rights to ownership or title via non-fungible tokens. Trustless and ownerless smart contracts can act as the “escrow agent” with respect to value transfer and closing evidence.

They can also widen the programmatic possibilities of agreement, including addition of hard-coded trustless dispute resolution mechanisms[4], or even choosing to have escrowed funds earn permissionless yield while the deal is pending.

The escrowed funds may be programmatically released and the deal may close at any time 24/7 by onchain signature of the parties or by using rich external data as evidence of objective quantifiable conditions (see the Appendix for a step-by-step example). The programmed conditions for closing and constructing the smart escrow contract may be stipulated in the transaction’s core legal documents, such as a sale or financing contract.

The external data used to validate such conditions would be fed by oracle software such as the Airnode to the smart escrow contract. Such oracle-fed conditions may include: a commodity or security price point; an agreed level of interest rate or other exchange benchmark or volatility limit (which might also provide an automatic termination or renegotiation threshold); the coordinates of a movable asset by tracking API, GPS or IoT data transmission; or fulfilled e-signature events.

As with any off-chain escrow agreement, on-chain contracts will need to be handled with similar care. It is imperative to use security-audited smart escrow contracts and ensure the smart contract reflects the intention of the parties including any intended actions in relation to off-chain legal agreements.

The parties should also consider a time-limited expiry or other condition to return escrowed funds (minus any agreed non-refundable deposit) in the event the transaction is not ultimately consummated. This prevents a lockup of funds should conflict between the transacting parties or other unexpected conditions arise.

Appendix: Smart Escrow Step-by-Step Example[5]

1. Parties negotiate commercial terms of the deal, agree on off-chain documentation and process, and closing parameters/processes.

2. Parties sign any relevant pre-closing documents and arrange subjective and off-chain conditions to closing.

3. Smart escrow contract is deployed — typical parameters might include deal/asset description or identifier, deposit and/or purchase price, token payment method (i.e., stablecoin address), time until expiry, parties’ addresses, oracle interface for off-chain objective conditions, and anything else set forth in deal documentation.

4. Buyer indicates it is ready to close by calling a function and depositing funds to the smart escrow contract. This deposit may be done directly, or by using a fiat-crypto API or another interface.[6]

5. Seller checks deposit is in escrow contract’s address and indicates it is ready to close by calling a function.

6. Now that both buyer and seller are ready to close and funds are in escrow, either may call the function to close the deal and pay seller-provided any other objective conditions are satisfied. If such an objective closing condition is queried through the oracle and is not yet satisfied, the function may be called until the objective condition is satisfied (as reported by the oracle) and the deal may close, or until expiry.

Similar to the deposit process, the seller may choose to “off-ramp” the received tokens to a traditional bank account by fiat-crypto API or by another interface.

7. When the deal closes, the objective conditions, details, and timing of closing will be emitted as events and are trustless-ly verifiable on-chain. Parties could also choose to include an encrypted reference to where the deal’s documentation is stored, such as on IPFS.

By Erich Dylus (Legal Engineer at API3 and contributor to LexDAO) and Emily Cockley (Operations and Process Analyst at API3)