BSIP: 0046
Title: Escrow Concepts
Authors: taconator
Status: Accepted
Type: Informational
Created: 2018-04-16
Discussion: BSIP (https://github.com/bitshares/bsips/pull/111)
This informational BSIP describes elements of a general escrow contract, existing Graphene features that are similar to escrow contracts, concepts that are related to blockchain escrows, and possible escrow concepts to implement on BitShares.
The ability to escrow assets on BitShares is a desirable feature that could be used by many persons, services, and businesses. It permits conditional transfers between parties to occur that minimize or eliminate risks to a depositor and sender while conditions are being evaluated. Conditions for completion of a transfer can be evaluated by an escrow agent of some form such as a human and/or a software agent. If all the conditions are evaluated to be true (a positive evaluation) during the evaluation period, then assets are transferred to an intended recipient(s). If the conditions are never evaluated to be true (either due to a negative evaluation or due to the absence of an evaluation), then the assets are returned to the depositor(s).
An escrow contract is defined to have the following elements:
- parties to the escrow contract
- assets that are being escrowed
- escrow period start and end (expiry)
- conditions for escrow completion
- condition evaluators
- timing of conditions evaluation
- reporting of conditions evaluation
- what occurs when all conditions are satisfied
- what occurs when all conditions are not satisfied
- early termination of an escrow contract
- escrow agent and fee
At least two parties must be defined for an escrow contract: at least one depositor, and at least one intended recipient. Escrow agents might also be considered to be part of the escrow contract depending on the defintions.
An escrow involves a conditional transfer of ownership of at least one item from one party (a depositor) to another (an intended recipient). An escrow is used to temporarily hold some or all of these items while the conditions are being evaluated during the escrow period. Upon satisfaction of the escrow conditions, the escrowed items will be transferred to the intended recipient. If the conditions are not satisfied by the expiry then the escrowed items are to be returned to the depositor. If certain conditions are met, the escrowed items can be returned early to the depositor before the expiry with the approval of designated parties (e.g. either all participants of an escrow and/or by the escrow agent).
For definition purposes, let an item that will be transferred from Party A to Party B upon completion of the escrow conditions to be called Item AB. Let an item that will be transferred from Party B to Party A upon completion of the escrow conditions to be called Item BA.
The start of the escrow period is when the deposit of the escrow asset occurs. When the end of the escrow period arrives, any remaining asset that is still in the escrow is either automatically returned to the despositor or may be released by an escrow agent.
The conditions of an escrow contract involve events about other people, assets, and/or actions that are beyond the control of the escrow agent. One such example is the transfer of property between the parties of the contract by means which the escrow agent can at most observe. Whoever or whatever will evaluate the conditions of a contract must somehow obtain information about these events, perhaps with assistance by the escrow parties (e.g. by providing proof of this external activity), to evaluate the conditions.
The evaluators of the conditions of an escrow condition can be designated in the contract to be tiered such that if the first tier cannot reach an agreement, then the second tier will be tasked with performing the evaluation.
For example, the first tier of evaluators could consist of the escrow parties themselves (e.g. Parties A and B). If the parties agree on the evaluation, then the escrow transfer can proceed according to the designated terms (e.g. transfer of Item AB from A to B if conditions are satisfied, or return of Item AB to A if the conditions are not satisfied before the expiry). If the conditions are not satisfied by the expiry, then the escrowed items will automatically be returned to their depositors.
The timing of a condition evaluation is quite flexible and can vary from a single occurrence at near the expiry, or periodically during the escrow period, and/or triggered by certain events or activities.
Condition evaluators, such as an escrow agent, will at least signal the outcome of their evaluation of the conditions through an action such as "release". A condition evaluator might also provide a report or an off-chain link to a report that summarizes their evaluation of the conditions. This report can serve to justify their action for releasing or holding the assets in the escrow.
When all the conditions are evaluated to be satisfied, all or some of the escrowed assets are released to the intended recipient. This transfer could be automated or require human action to initiate.
If an escrow contract concludes without all the conditions being satisfied, a typical escrow contract has the remaining escrowed asset(s) being returned to the depositor. This might be an automatic process, or might require an action by the escrow agent.
When an intended recipient or escrow agent decides to terminate an escrow contract early such that the assets are returned to the depositor.
An escrow agent can be used to perform distinct services:
- to evaluate the conditions of the escrow agreement;
- to hold the escrowed asset(s) during the escrow period; if holding the assets, to transfer the escrowed assets to the appropriate parties contingent on the condition evaluation
An escrow agent is often paid a fee for these services before the escrow period begins and regardless of condition evaluation.
If an escrow will be performing condition evaluations, it should be granted reasonable amount of time to perform the condition evaluation. Furthermore, to avoid allegations of negligence, an escrow agent can benefit from the ability to demonstrate that an evaluation of the conditions(s) with a negative outcome (a negative evaluation) was performed.
An escrow contract on a blockchain can have certain qualities that are distinctive from a general escrow contract. Some of these differences are described in this section.
Off-chain escrow evaluations involves either a human(s) or an off-chain agent(s) making the evaluation regarding escrow conditions (e.g. escrow agent, Etienne, evaluates whether Bob satisfied the escrow conditions before releasing an asset from Alice to Bob). If all conditions are evaluated to be satisfied by the appropriate escrow parties or agent, then they can indicate their approval to the contract, and then the defined contract transfers will occur. If the appropriate approvals are not granted by the expiry, then the escrow deposits will be returned to the depositors.
On-chain escrow evaluations with oracles involves an escrow contract that can be evaluated by the blockchain itself by reviewing data that is submitted by a trusted party who can observe events outside of the blockchain (oracle). An example of such data could be the temperature at a location on a particular date. Such a contract would require the following:
- A contract state that consists in part on this temperature data (e.g. a decimal variable);
- a smart contract that can interpret this data;
- a trusted oracle that can submit/update this information in the contract state.
A variation on this idea is where the contract state consists of a particular asset DEX price, market condition on the DEX, and/or an account balance on the DEX so that no new data would be required. Under this variation the trusted oracles are account holders who initiate DEX transactions and the smart contract then observes those transactions.
Either evaluation involves a contract, similar in nature to the existing DEX market processing, being designed for a particular purpose.
Upon expiry of the evaluation period without all conditions being satisfied, the assets that are held by the blockchain will automatically be returned to their depositors.
With the use of a blockchain, it is possible for the blockchain to be a custodian of the escrowed asset(s) while the escrow agent merely performs the condition evaluation. (A variant of this notion is that an escrow could act as an oracle to submit raw data to the blockchain that permits the smart contract to perform the condition evaluation.) If no action is taken by the escrow agent, then all escrowed assets will be returned to their depositors. (See Automatic Transfers Upon Expiry)
When signaling that conditions were evaluated with either a positive or a negative outcome, it would likely be beneficial for the escrow parties and the escrow agent to optionally memorialize either evidence of the condition evaluation, or some sort of "link" or "hash" of the condition evaluation (e.g. see Factom's "proof of existence"). The ability to explicitly indicate a negative outcome by an escrow agent is beneficial to an escrow agent to reduce the likelihood of allegations of negligence by either of the escrow parties.
The section describes concepts related to escrow that either exist or have been proposed for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in Possible Concepts.
Explicit escrow exists on Steem when a depositor initiates an escrow. The asset is released:
- to the intended recipient if both recipient and the escrow agent approve the transfer,
- to the depositor if either the recipient or the escrow agent rejects the transfer,
- to the intended recipient if the depositor authorizes the release and the escrow is not under dispute,
- to the depositor if the depositor authorizes the release and the escrow is not under dispute,
- to either the depositor or the intended recipient by the escrow agent if the escrow is under dispute
Two behaviors in the Steem implementation are noteworthy:
- there is no automatic return to the depositor if no actions have been taken; a positive action by either the escrow agent or the intended recipient are required for the return
- partial release of funds are possible when using the "release" mechanism.
Implicit escrow exists on Peerplays when a user joins an on-chain tournament. The asset is released:
- to the depositor if the tournament is canceled,
- to the depositor if the user exits an on-chain tournament before its start, and
- to the winner of the tournament at its conclusion.
One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties (see BitShares General Whitepaper Section 4.1.4: Flexible Identity Management) and even hierarchical authorizations. This mechanism has the benefit of escrowing an asset within an account whose transactions can be authorized by different combinations of parties (e.g. either both the depositor and the intended recipient; only the escrow agent; the escrow agent and the depositor; the escrow agent and the intended recipient) and can transfer an asset towards any account.
This feature can actually satisfy the requirements for "off-chain evaluation" escrowing although it has the burden of requiring a unique account with the appropriate escrow agent and escrow participants for a specific ongoing escrow contract. One option to handle a specific contract would be to create a single-use account for this purpose. Another more technical option would be for the authorities on an account to be re-assigned to the escrow agent upon the completion or expiry of the contract, so that the escrow agent could re-use the account in a future contract by subsequently re-assigning among the agent, and future contract participants. This approach, however, is somewhat complicated, error-prone, and awkward.
One of the existing features of BitShares is the ability to have a proposed transaction that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures)(see BitShares General Whitepaper Section 5.7: Proposed Transactions). If the required authorizations are not given by the proposal expiry then no transfer will occur.
This feature alone falls short of what is needed because no asset is actually escrowed while the proposal is awaiting the necessary signatures to complete. Therefore there is no guarantee that the asset will be secured by the time that the final required signature is obtained.
The section describes concepts related to escrow that either exist or have been proposed for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in Possible Concepts.
Atomic Cross Chain Transfers (ACCT) involves the transfer of one asset (Asset A) on one chain (Chain A) from one account (A1) to another account (A2) if another asset (Asset B) on another chain (Chain B) is transferred from one account (B2) to another account (B1). Either both transfer occur or neither do. This functionality has been prototyped between two Graphene chains by the Scorum team.
This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP.
Specifications for Hash Time-Locked Contract in BitShares (BSIP 44) are being reviewed by the BitShares community at the time of this writing. The ability to securely hold tokenized assets within a Hash Time-locked contract on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants during asset transfer. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. No third-party escrow agent is required, rather the HTLC operation enforces conditions, evaluations and transfers through the BitShares consensus protocol.
The InterLedger Protocol (ILP) is a protocol for transmitting debt claims (e.g. IOUs) from one party (Alice) who controls an account on one Ledger (Ledger A) to another party (Bob) who controls an account on another Ledger (Ledger B) through at least one trusted intermediate party (Connector). A Connector must effectively control an account on at least two ledgers in order to "fulfill" the claim transfer across ledgers. Parties to the protocol are effectively only transferring debt claims between their immediate "peers" but the chain of peers enables the transfer across many participants.
The transmission of the debt claim from Alice to Bob is called a "payment". The transmission is conveyed through a "communication channel" which may be done in any form either person-to-person, by voice, by email, by blockchain, etc. The various means of transmission have different characteristics in terms of speed and guarantee of arrival therefore a part of the protocol is focused on robustly handling these communication delays and uncertainties by embedding expiration times into the protocol. Packets that are not relayed in time result in no formal claim transfer between parties. When a recipient receives the transmission, the recipient may choose to accept or reject the debt claim transfer.
Debt claim transfers may optionally be post-funded or pre-funded. With post-funded "transfers", debt claims can be settled on the ledger that is shared by any connected-peer thus canceling the debt after the conclusion of the "transfer". With pre-funded transfers, assets of some form are securely set aside as a pre-condition for the transfer. The escrowed asset is then assigned to the appropriate connected-peer when the "transfer" is concluded either successfully or unsuccessfully.
There are similarities between a conditional transfer that is escrowed on the blockchain versus an ILP transfer through the blockchain
- Both use cases involve two accounts on the blockchain.
- Both use cases involve an asset temporarily being held by the blockchain until either certain conditions are satisfied or the expiry arrives, whichever is earlier.
Nevertheless there is a crucial difference between the two use cases. In the case of a escrow contract, the condition for release to the recipient must be satisfactory to both the depositor and the recipient after the contract is created. In the case of an ILP transfer, the condition for release to the recipient is determined by only one party, the recipient, after the contract is created because the sender tacitly accepts the conditional transfer when initiating the ILP transfer.
| Concept / Technology | # of Ledgers | Does Recipient Receive Same Type of Asset that was Sent by Depostior? | Is Recipient Guaranteed to Receive Asset Upon "successful completion"? | Can Depositor halt the transfer after the deposit into escrow? | Automatic return of deposit at expiry if conditions are not satisfied? |
|---|---|---|---|---|---|
| Steem Escrow | 1 | Yes (same ledger) | Yes | Yes (by inviting escrow agent to participate) | No |
| Peerplays Escrow | 1 | Yes (same ledger) | Yes | No (smart contract is the sole adjudicator) | Yes (if tournament quorum is not reached); N/A after tournament begins |
| HTLC | 1 | Yes (same ledger) | Yes | No | Yes |
| ACCT | 2+ | No (asset is converted across ledgers) | Yes | Yes (by not accepting the reciprocal transfer on the second ledger) | Yes |
| InterLedger | 2+ | No (asset is converted across ledgers) | Depends on the Connector that is peered with the Recipient; only the transfer of a debt claim is guaranteed | No (only actions or inactions by the Connectors and recipient can halt the transfer) | Yes |
The following will describe possible escrow concepts that could be implemented in BitShares.
This concept allows the escrow agent to be invited to evaluate conditions at any time during the escrow period.
| Element | Description |
|---|---|
| Parties | Depositor and intended recipient each have an account on the blockchain |
| Escrow Assets | A quantity of an asset that exists on the blockchain |
| Escrow Period Start and End | Defined in contract |
| Conditions | Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent. |
| Condition Evaluators | The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions at least once during the escrow period; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that might be textually defined but which is not enforced by the blockchain. See Reporting on Evaluation of Conditions for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct. |
| Timing of Condition Evaluation | When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation may only be signaled on the blockchain during the escrow period. |
| Reporting on Evaluation of Conditions | Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation. |
| What Occurs when Conditions are Satisfied | When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient |
| What Occurs when Conditions are Not Satisfied | Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See Avoiding Appearance of Negligence. |
| Early Termination | The contract can be terminated early by the current condition evaluators |
| Escrow agent and fee | An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent (by whom is flexible) as a prerequisite to initiate the escrow contract. |
This concept has the following weaknesses:
- It does not clearly delineate when an escrow agent can and should become involved because it is merely described in a textual format that can and need only be interpreted by the off-chain parties and escrow agent.
- It does not guarantee a sufficient amount of time, as negotiated between the escrow parties and escrow agent, for the escrow agent to perform the condition evaluation (e.g. the off-chain party might notify the escrow agent to be perform conditions evaluations only a few seconds before the expiry which is likely to be insufficient notice to properly evaluate the conditions)
- When an escrow agent is expected to become involved might only be defined in human-readable text, if at all, and therefore introduces ambiguity and opportunities for abuse by parties and for allegations of misconduct or negligence against the escrow agent.
Although this concept contains many of the elements that are often desired of an escrow contract, its weaknesses could be addressed by enhancing the concept with features than can be handled by a blockchain.
This concept is the same as Concept A except that the escrow can only participate after being invited by either escrow party. Differences are shown with an emphasis.
| Element | Description |
|---|---|
| Parties | Depositor and intended recipient each have an account on the blockchain |
| Escrow Assets | A quantity of an asset that exists on the blockchain |
| Escrow Period Start and End | Defined in contract |
| Conditions | Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent. |
| Condition Evaluators | The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible evaluate the conditions at least once during the escrow period; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that might be textually defined but which is not enforced by the blockchain. See Reporting on Evaluation of Conditions for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct. |
| Timing of Condition Evaluation | When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation may only be signaled on the blockchain during the escrow period. |
| Reporting on Evaluation of Conditions | Whichever off-chain entities are responsible for performing the evaluation must signal a positive outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation. |
| What Occurs when Conditions are Satisfied | When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient |
| What Occurs when Conditions are Not Satisfied | Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See Avoiding Appearance of Negligence. |
| Early Termination | The contract can be terminated early by the current condition evaluators |
| Escrow agent and fee | An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract. |
This concept improves on Concept A in the following ways:
- clearly delineates that an escrow agent should only become involved as the sole condition evaluator after being invited by either of the escrow parties
- the escrow agent can record the outcome of a single condition evaluation on the blockchain and thereby avoid the obvious appearance of negligence
This concept has the following weaknesses:
- The escrow agent can only record a single outcome of a single condition evaluation on the blockchain. (A postive outcome only requires one signaling on the blockchain. In contrast, multiple negative outcomes cannot be recorded.)
- Neither the condition evaluation itself (e.g. the escrow agent looked at a bank statement on January 1 and found no record of a transfer, etc.) nor a proof of a condition evaluation is being recorded on the blockchain.
- It does not guarantee a sufficient amount of time for the escrow agent to perform the condition evaluation (e.g. the off-chain party might notify the escrow agent to be perform conditions evaluations only a few seconds before the expiry which is likely to be insufficient notice to properly evaluate the conditions)
- An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain. See Reporting on Evaluation of Conditions for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.
An approach similar to Steem Escrow is a good candidate for technical implementation.
This concept is the same as Concept A except for where the emphasis is added.
| Element | Description |
|---|---|
| Parties | Depositor and intended recipient each have an account on the blockchain |
| Escrow Assets | A quantity of an asset that exists on the blockchain |
| Escrow Period Start and End | Defined in contract; an additional deadline (invitation deadline) must be specified within the escrow period that defines by when an escrow agent may be invited by either escrow party to begin conditions evaluation |
| Conditions | Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent. |
| Condition Evaluators | The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved by the invitation deadline. At that point, the escrow agent should |
| Timing of Condition Evaluation | When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation may only be signaled on the blockchain during the escrow period. If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry. |
| Reporting on Evaluation of Conditions | Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation. Off-chain entities may optionally provide supplemental information about their evaluations multiple times throughout the escrow period. |
| What Occurs when Conditions are Satisfied | When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient |
| What Occurs when Conditions are Not Satisfied | Escrowed assets are automatically returned to the depositors without any action by the escrow agent. If an escrow agent is invited to participate, an escrow agent should report at least one condition evaluation on the blockchain to avoid appearance of negligence. |
| Early Termination | The contract can be terminated early by the current condition evaluators |
| Escrow agent and fee | An escrow agent has an account on the blockchain. The fee is defined and escrowed for the escrow agent by the blockchain [by whom is TBD] as a prerequisite to initiate the escrow contract. The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has not been requested to participate by the invitation deadline, or (b) the escrow agent has been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation |
This concept improves on Concept B yet has the following weaknesses:
- The quality of a condition evaluations report by an escrow agent might be variable yet would be sufficient to ensure itself of receiving the escrow fee from the blockchain
- If an escrow agent is invited, only a single report is required of the escrow agent by the blockchain for the agent receive the escrow fee.
This escrow concept is very similar to pre-funded blockchain ILP transfers and Hashed Time-Lock Contracts except that this Concept requires acceptance or rejection by both the depositor and the recipient for full release of the funds prior to expiry; otherwise the full funds are released to the depositor upon expiry. This concept is the same as Concept C except for where the emphasis is added.
| Element | Description |
|---|---|
| Parties | Depositor and intended recipient each have an account on the blockchain |
| Escrow Assets | A quantity of an asset(s) that exists on the blockchain |
| Escrow Period Start and End | Period start is when the escrow process is submitted to the blockchain. End period is defined in the smart contract. |
| Conditions | Acceptance or rejection is signaled by both the depositor and the recipient. |
| Condition Evaluators | Depositor and/or the recipient |
| Timing of Condition Evaluation | Evaluated when (a) an acceptance is signaled by both depositor and recipient, (b) a rejection is signaled by both depositor and recipient, or (c) the escrow expires |
| Reporting on Evaluation of Conditions | None |
| What Occurs when Conditions are Satisfied | If the depositor and intended recipient signal acceptance, then the escrowed assets are released to the recipient. If a rejection is signaled, then the escrowed assets are released to the depositor. |
| What Occurs when Conditions are Not Satisfied | All of the escrowed assets are released to the depositor. |
| Early Termination | The contract can be terminated early by agreement of the depositor and recipient |
| Escrow agent and fee | The blockchain only acts as the custodian during the escrow. The custodian fee is paid when the escrow is created. |
This concept simplifies Concept C by eliminating the introduction of an escrow agent. Off-chain conditions are evaluated by the depositor and the recipient and signaled on the blockchain.
The approach is simpler than Concept C in that the entire deposit is either released to the recipient or returned to the depositor. Early termination of the escrow contract is only possible with a rejection by the recipient.
The weakness of this Concept in contrast to Concept C is that are there is no third-party ajudicator to resolve a disagreement.
An escrow agent could publish either a report or a proof of a report on the blockchain to demonstrate the evaluation of conditions.
A related feature could be that an escrow agent does not even receive payment until this reporting occurs at least once.
To avoid the appearance of negligence, an escrow agent can report when conditions were evaluated and the outcome of that evaluation even when the outcome is negative in order to demonstrate alertness and avoid the appearance of being negligent as an escrow.
A helpful though separation discussion pertains to the rating or evaluation of escrow agents themselves. Such a rating could be as simple as word of mouth, or performed by a third-party, or evaluated by the the parties to previous escrow contracts themselves and memorialized on a some system such as a website or a blockchain.
A similar argument could be made for evaluating the parties themselves.
Escrow contracts involve transfers from one party to another that are contingent on certain events being observed. A variation on this idea is for a transfer to occur if certain events are not observed. An example of this is a "dead-man switch" wherein a transfer will occur unless a party signals activity before the expiry. Such an example bears all the same characteristics as an escrow contract except for how to handle the absence of a condition evaluation. For a blockchain escrow contract, the assets are returned to their depositors if no positive indication is given (see Automatic Transfers Upon Expiry). For a dead-man contract, the assets are delivered to the intended recipients if no positive indication is given by the expiry. Some of the work towards blockchain escrow might be reusable or generalizable for dead-man switch use cases (e.g. life insurance, posthumous asset transfers, etc).
This BSIP summarized various elements that are common to different escrow concepts, and related features and concepts that are available in other blockchains. Multiple possible concepts in BitShares were surveyed and a high-level comparison of the various concepts are summarized below.
| Concept Name | Summary | Strengths | Weaknesses |
|---|---|---|---|
| Concept A | Deposit held by blockchain with optional invitation of an escrow agent. Terms and conditions of involvement by escrow agent are textually described. |
Automatic return of blockchain asset to depositor if conditions are not satisfied. | Ambiguous designation of an escrow agent. No guarantee of sufficient evaluation time for an evaluation of conditions by an escrow. Ambiguous involvement by an escrow agent. |
| Concept B | Deposit held by blockchain with optional invitation of an escrow agent. Terms and conditions of involvement by escrow agent are more explicit than in Concept A. Escrow agent can report and record the outcome of condition evaluation a single time. |
All the benefits of Concept A. Escrow agent becomes involved when invited by either the depositor or recipient. Escrow agent can record the outcome of a single condition evaluation and thereby avoid the obvious appearance of negligence. |
Escrow agent can only record the outcome of a single evaluation of the escrow conditions. Neither the evaluation nor proof of the evaluation is recorded on the blockchain. No guarantee of sufficient evaluation time for an evaluation of conditions by an escrow. An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain. |
| Concept C | Deposit held by blockchain with optional invitation of an escrow agent. Terms and conditions of involvement by escrow agent are more explicit than in Concept A. Escrow agent should have sufficient time to properly evaluate on conditions. Escrow agent can report and record the outcome of a condition evaluation multiple times. | All the benefits of Concept B. A deadline for inviting an escrow agent can ensure sufficient time for evaluation by an escrow agent. Escrow agent can both indicate the outcome of condition evaluations and report on the condition evaluations multiple times. |
Quality of evaluations report by escrow agent might be variable. Only a single report by escrow agent is required for escrow to receive payment for services. |
| Concept D | Deposit held by blockchain and released upon agreement by depositor and recipient, or expiry. Entire deposit is either delivered or returned. Similar to pre-funded HTLC ILP transfers and HTLC except for the required consent by both depositor and recipient after the process has begun. No third-party escrow agent. |
All the benefits of Concept A | There is no escrow agent to resolve a disagreement between the depositor and the recipient. |
This document is placed in the public domain.