Security Deposit
Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.
Summary
A user deposits a certain amount of money in a smart contract. If the user behaves honestly as per the application requirements, the deposit is returned back to the user. Else, the deposit is forfeited and given to the other parties as compensation for any losses due to the dishonesty of the user.
Context
In a decentralised environment like blockchain, trust in the blockchain-based application is achieved through the interactions between participants within the network. A blockchain-based application relies on all the users rather than relying on a trusted third-party organisation to facilitate transactions.
Problem
The equal rights property of blockchain allows every participant the same ability to access and manipulate the blockchain and the decentralised applications running on the blockchain. How can a certain participant prove to others that he/she intends to behave honestly?
Forces
- Security – The security of a decentralised application relies on the behaviour of all the participants of the application.
- Incentive – In a decentralised application, participants can be incentivised to behave honestly.
Solution
Users of a decentralised application could be incentivised to make a security deposit as a way to exemplify their willingness to behave honestly. Security deposits made by each participant reduce the risk to all the participants in the network against misbehaviour, as the misbehaving party(ies) know that he/she would lose the deposit for wrongdoing. Alternatively, affected parties are also compensated to a certain extent from the forfeited security deposit.
Security deposit pattern.
Initially, the participant is required to set aside a number of tokens/cryptocurrencies as a deposit on a smart contract. Eventually, validate the honest behaviour of the user based on one or more user actions/transactions as per logic encoded into the smart contract. If the actions were determined to be honest, pay back the deposit to the participant. Otherwise, forfeit the deposit and use it to pay compensation to the other parties for any losses they may have incurred due to the dishonest behaviour of the user. Smart contract logic could also specify how to determine the compensation for each affected user.
The value of the security deposit should be sufficiently high to encourage honest behaviour against potential gains due to misbehaviour. However, it should not be too high such that no party is willing to perform a security deposit and engage in the application. Typically, a security deposit is also time-bound to ensure that the deposit is not locked away indefinitely.
Benefits
- Security – The security of the application is enhanced through the security deposit because the deposit will be paid back to the participant only if the participant behaves honestly.
Drawbacks
- Access – The security deposit is normally larger than the potential profit the participant gain from her/his dishonesty. If the required deposit is large, it restricts some participants to access the application.
- Liquidity – Locked away funds limit the liquidity of a participant.
Related patterns
- Incentive execution offers a reward (already set aside by a contract owner/manager) to the caller of a smart contract function for invoking it.
- The voting pattern can be used to resolve a dispute arising from dishonest behaviour.
Known uses
- The notion of deposits is used in Bitcoin’s contract, where the deposit is bought by a party with no reputation as proof of her trust.
- Slock.it requires the servers to pay a deposit which they would lose if they give a wrong response. Such security deposits also incentivise other servers to check each others’ responses and act as watchdogs.
- Ethereum alarm clock enables scheduling of transactions for delayed execution in the future. Before the execution window, there is a claim window when the request may be claimed by a participant for execution. To claim a request, the participant is required to put down a deposit. If the claimer fulfils their commitment to execute the request, the deposit is returned to them, otherwise, the deposit is given to someone else that executes the request as an additional reward.