The private key to a smart contract is the master key that allows to change a smart contract and transfer funds from it to a different address.
The ability for the smart contract creator to do that can be very worrying for its users; therefore, several ways of limiting the power of the smart contract creator have been offered.
In this article, I am going to speak in detail about them all and how you can protect your smart contract against the threats associated with malicious use of private keys.
You can guard against outside threats coming from hackers by doing audits of smart contracts. However, the threat of inside malefaction also exists. It is called inside jobs. By the term we understand that members of the team get hold of the private key and use it to steal the funds from the contract.
In order to prevent this from happening, you can use a multi-signature for the smart contract. The multi-signature is a number of private keys that are required to sign a single transaction. All of these keys are owned by different individuals, e.g. team members, and the contract normally requires two thirds of the signatures or more to produce a transaction. Therefore, no one will have the authority to make changes to the smart contract single-handedly.
The second way to prevent an inside job is to use the DAO model in which the voting power is a way to decentralise decision making regarding changes to the smart contract. The voting power can be represented by the project’s token, which can be distributed among the members of the project. In this way, any changes to the smart contract will require the community’s consent.
The community will have to approve of the transaction through a vote, in which they will use their tokens to vote with. If the tokens are fairly distributed, with the team not having the majority of the voting power, the project’s team or any of its members will not be able to perform a so-called ‘rug pull’.
The third option you can use against an inside job is to use smart contracts with delayed transaction minting/mining. Such smart contracts have a mechanism in their code that will notify the users of the transaction that will be made and will delay its execution by a certain period of time. In this time, the users can withdraw their funds if they understand that their funds can be stolen. This will increase the security level of the protocol and can be used together with the above listed techniques.
If none of these measures are implemented in a protocol, the investors run serious risks. Therefore, it is necessary to clarify how much control the team has over the smart contract of the protocol. Otherwise, it can go the way it went with the SQUID token that was initially created to expropriate the liquidity from the smart contract.
There are several ways to store private keys. The most secure one is a mechanical wallet like the ones manufactured by Trezor and Ledger. Such wallets are not connected to the Internet and hold the keys in an encrypted form in their memory. They have proven to be unbreakable over the years.
There are also program wallets like Trust Wallet for mobile devices and the Metamask wallet for web browsers on desktop devices. These wallets are open source, so everyone can verify their code for vulnerabilities. So, the community behind these wallets guarantees their security as more people are more likely to find potential exploits than fewer. However, if there is a vulnerability in the device itself, the key can still be stolen.
The least reliable option is web wallets that need seed phrases to enter the wallet. If you enter the seed phrase to your wallet on a phishing site, it can be used to access your wallet by a third party who set up the phishing attack.
In order to gain the community’s trust with cryptofinancial projects, nowadays it is a must to decentralise control over the smart contract of the project. It can be done via a multi-signature or a DAO. In addition to that, a smart contract system with delayed transaction execution can be used.
It is also necessary to follow security protocols inside the team so that private keys remain safe and do not escape to any third party. Therefore, security protocols should be established and adhered to.
Gleb Zykov, co-founder and CTO of HashEx
Gleb began his career in software development in a research institute, where he gained a strong technical and programming background, developing different types of robots for the Russian Ministry of Emergency Situations.