Smart contract features | Risk description | Source |
1. Transparency |
|
|
1.1. Transactions are traceable and permanently recorded | In light of corporate governance, it is a risk if the transactions are not traceable. | [1] , [15] , [17] |
1.2. Privacy | Accidental human interference or hacking information is an exposure risk and might have liabilities consequences. | [15] [21] [24] |
1.3. Lack of consensus or collaboration | If consensus or collaboration is only partially achieved, then it might cause conflicts during the smart contract lifetime. | [1] [14] |
2. IT security |
|
|
2.1. Network administrator | Having a network administrator in the private environment becomes a focus of hacking attacks. | [3] [4] |
2.2. Immutability of code | Blockchain protocol can be changed through a hard fork, but in the private environment, it only happens through common consensus of the stakeholders | [3] [15] [19] |
2.3. Vulnerability of code | Is the risk perception of how easy it is to invade the code and to modify it. | [16] [17] [18] [20] |
3. Automation |
|
|
3.1. Performance issues | Regarding the speed of transactions in private smart contracts and the requirement to perform the number of transactions. Additionally, the risk of downtime due to performance issues. In addition, the desirable system automation level which can be: 1) fully automated, 2) semiautomated and 3) slightly automated. | [1] [16] |
4. Legality |
|
|
4.1. Codifying smart contract | Complexity to translate the contract’s paper-based terms and conditions to programming code. | [14] [16] [23] |
4.2. Framework of code in consensus | If the set of laws and rules are not common to all stakeholders, then there is a clear risk of compliance and can imply legal consequences. | [1] [23] [24] |
4.3. Jurisdiction conflicts | If the smart contract does not encompass all required laws and rules, it might have conflicts with governments. | [3] [23] [24] [25] [39] |
4.4. Immutability of the code | The immutability and consequently the automated transaction might not follow the civil jurisdiction where the business is established. | [15] [22] [23] |
4.5. Termination of smart contract | The risk is the lack of proper evaluation of this possibility. | [23] [24] |
5. Software risk management |
|
|
5.1. Inadequate smart contract verification | Regarding testing before deployment which can impact or influence one group, partial groups or all groups cited above. | [6] [7] [8] |
5.2. Lack of maturity | Intrinsic to actual smart contract infancy. | [4] [11] [21] |
5.3. Human skills | Inherent in the programmer’s ability to write, codify, and identify risks and its potential consequences. Innumerable threats can be associated with it. | [14] |
5.4. Software quality | Risk that is intrinsic to the selected programming code such as the differences among Solidity in Ethereum, NEO and LISK. In conjunction with the human skills related to developing the smart contract on such programming codes. | [11] [13] [14] |