Escrows for Decentralized Marketplaces
When paying for an online purchase with a credit card, I feel reassured that, if necessary, the charges can be disputed. Payments made using cryptocurrencies, once buried a few blocks deep, cannot be reversed. This “irreversibility” is intentional and crucial in keeping cryptocurrencies secure and trustless.
“Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.”
- Satoshi Nakamoto, 2nd paragraph of the Bitcoin paper [1]
The above excerpt from the Bitcoin paper states the role that escrows can play in decentralized marketplaces. The role is stated very plainly, but it covers nearly all use cases.
Escrow services can help resolve disputes involving some off-chain, “real world” fact — something decentralized protocols, by themselves, can neither verify nor refute. However, escrow providers do not have to serve as arbitrators. Their primary service is to effectively reverse transactions. The arbitration can be performed by yet another party — but it should be handled as part of the system.
Using a buyer/seller narrative, the typical flow is something like this. A buyer “locks in” enough crypto-assets (coins, tokens) in an escrow contract to cover the value of a purchase. When the terms of exchange are met by both sides, then the asset is transferred to the seller without any assistance from the escrow provider. This is different from conventional escrows where the service provider must actively transfer the asset. Furthermore, decentralized escrows can be non-custodial, so the service provider cannot steal any assets. If there is a dispute which cannot be resolved (mutually or with the assistance of an arbitrator), then the escrow provider releases the lock, so the buyer can reclaim their asset — which reverses their initial transfer.
What is unchanged from conventional escrows is that the service provider still serves as a trusted third party. The term “escrow” is used quite liberally — even while stating that the “escrow” does not actually solve the trust problem [2]. Some crypto auction platforms say their contracts hold bids (in ETH) in escrow. But this is how auction smart contracts work in general. Time-lock escrows are another example, they do not really need trusted third parties.
In my mind, there is no such thing as a fully trustless escrow. And for this reason, escrows cannot be fully automated — irrespective of the complexity of the smart contracts involved. If a service can be made fully trustless, then it is no longer an escrow, it is just a bilateral exchange protocol. DApp developers should state their trust requirements clearly and be mindful to distinguish arbitration (verify facts) from escrow (release disputed assets to one party).
A standards-based architecture
Relative to traditional escrows, locking and releasing crypto-assets (e.g. coins, tokens) using a non-custodial P2WSH [3] or a smart contract is simple, cheap (depending on the blockchain) and fast. For crypto escrows, the design choices are really about handling disputes, integration with other components and overall user experience for developers and end users.
For those looking to build an escrow system as part of their DApp, I recommend adopting ideas from a standards framework proposed by Kleros.io. Kleros provides decentralized arbitration services through a system of courts. Courts are organized depending on the domain expertise needed to rule on disputes. Users seeking arbitration must submit their disputes to appropriate courts. Cases are decided based on a plurality voting system where jurors are picked randomly from a set of volunteers. Jurors indicate their willingness to serve by staking Kleros’ token (PNK). Jurors earn rewards in Ether for coherent decisions and lose part of their stake for incoherent rulings. Their escrow is just one part of a wider, decentralized arbitration system.
At a high level, Kleros’ approach is built on two proposed standards. Details of these proposals and discussion can be found at their respective Ethereum EIP Github issues [4a, 4b]
- ERC 792: This standard proposes two smart contract interfaces
* Arbitrator contracts interface: contracts through which registered EOA arbitrator(s) can serve rulings on disputes.
* Arbitrable contracts interface: contracts can use this interface to designate a specific arbitrator contract (above) to provide arbitration rulings.
2. ERC 1497: Evidence interface to structure and submit evidence when raising disputes
These standards are intended for general dispute resolution contracts, not escrows specifically.
Developer Resources
Kleros’ developer documentation [5] provides an overview of the system and a live demonstration DApp. The demo happens to be a very rudimentary escrow for coins. More advanced and practical implementations can be found in other repositories [6, 7], which, at present, are not included in their developer documentation.
The dev docs are intended to help users write “arbitrable” contracts which can then be used to resolve disputes using Kleros’ courts. Naturally, the emphasis is on illustrating how their system works and encourage people to use the service. I suspect that many developers may wish to keep their DApps simple by managing the dispute resolution process themselves or with known arbitrators.
Being Ethereum based, it is straightforward for DApp developers to deploy elements of the approach on Ethereum-compatible networks like RSK. The stack is fairly standard npm, web3, Truffle. I forked one of their repos with token escrows and made some small changes so it works with HardHat (instead of Buidler) for development and testing [8].
Escrows for Non Fungible Tokens (NFTs)
Recently, there has been extraordinary interest in NFTs. This has been driven by sales of NFTs worth thousands or millions of dollars granting “ownership” of otherwise freely available digital goods such as art, YouTube videos, even tweets [9]. Thus, it is natural to wonder about the relevance of escrows for NFTs.
The exchange of on-chain assets can be handled entirely in a trustless manner through smart contracts. Thus, if NFTs are bought and sold using cryptocurrencies or tokens, then there is no absolute need for escrows at all. For instance, consider www.opensea.io, one of the largest marketplaces for NFTs. Searching for the word “escrow” in their user support documentation leads to the following
- “OpenSea is decentralized, so we never escrow or hold your items.”
- “OpenSea does not offer payment escrow through the main website or otherwise.”
Of course, there may be some situations where escrows make sense for NFTs:
- An NFT marketplace with payments made using fiat
- Fiat loans secured by “demonstrably valuable” NFTs
- Customization services that involve adding features to in-game NFTs where some data is not stored on chain and needs manual verification
However, even in such cases, NFT-escrows will not require any special handling. The basic approach described previously should suffice.
Other Services and Design Options
I am a fan of following standards-based approaches for the long term. But building consensus around standards can be very challenging. Despite their efforts, Kleros’ proposed standards (ERC 792, ERC 1497) have not been merged into the main ERC repository.
On the other hand, the widespread use of ad-hoc designs by various teams reminds us that escrow solutions are often just one component of a more complex service. In this context, Australia based Localcryptos.com offers a fantastic example for DApp developers. The service makes money from a P2P cryptocurrency marketplace. However, in order to do so, they offer crypto-escrows, a dispute resolution service, encrypted messaging, meta-transactions to cover gas costs, even a dynamic reputation system.
A new system is being developed by Smartlink.so. This looked very promising initially (whitepaper etc). But on closer inspection, the development effort is not very mature yet. Their stated focus is to develop escrow services for marketplaces. Therefore, it would be prudent for developers and product designers to keep an eye on their progress. Smartlink will be deployed on Tezos network and their first solution is stated for Q4 of 2021.
Acknowledgements: I thank Artem Brazhnikov, Raúl Laprida, and Diego Masini for helpful suggestions and discussions.
References
- https://bitcoin.org/en/bitcoin-paper
- https://docs.soliditylang.org/en/v0.8.6/solidity-by-example.html#safe-remote-purchase
- https://blog.localcryptos.com/how-bitcoin-escrow-works/
- [a] https://github.com/ethereum/EIPs/issues/792
[b] https://github.com/ethereum/EIPs/issues/1497 - https://developer.kleros.io/en/latest/index.html
- https://github.com/kleros/escrow-contracts
- https://github.com/kleros/erc-792
- https://github.com/optimalbrew/escrow-contracts/
- https://www.npr.org/2021/03/05/974089381/whats-an-nft-and-why-are-people-paying-millions-to-buy-them
