Production Contract Security — Part 1
Congratulations! You just deployed your first smart contract to the mainnet and your platform launch is imminent. As you unlace your Air Jordans after the release party there is a nagging thought in the back of your mind.
There are two main aspects of smart contract security. The first and probably most important is the code itself and its adherence to secure coding standards that have been painfully learned through the many exploits over the years. Another key aspect is that of smart contract ownership which will be the focus of this article.
As I have been working in the space, I have noticed an issue with many projects in how they handle the ownership and transaction management of their contracts. This is the first part of a series of articles on securing your smart contract deployments using industry best practices. This article will focus on the use of multisigs and why they are important to the safety and credibility of a project.
Like a good Presbyterian, I will submit 3 key risks that a multisig helps to solve
- Ownership Risk — The risk that your organization will lose access to the contract.
- Asset Risk — The risk that your contract is insecure and the assets owned by the contract can be taken.
- Reputational Risk — The risk that your project will be viewed in a negative light
What is a Multisig
A multisig is a smart contract wallet deployed to the blockchain that can own other contracts and execute functions with elevated access as their owner. As the name implies, it requires the coordination of other accounts giving the green light, or signing before it will execute given transaction. Multisigs have been in use for a while and have themselves been the target of attacks as well — especially the Parity multisig — which has been hacked multiple times for millions. There are several multisigs on the market today, but the standout is Gnosis Safe.
In a future article we will explore the Gnosis Safe offering, but for now we are just dealing in concepts.
Lets say that you are developing an NFT project and you have written all your tests and feel that the code is secure and ready to ship. You deploy the code through your favorite means(hardhat, truffle, etc) and you’re now ready for your mint.
- What happens if you or someone else accidentally commits/pushes the deployment private key to your repo? This has happened a lot — more than you think.
- You deploy the contract with a deployment account and transfer ownership to a ledger owned by the company. What if that person leaves, loses their ledger, or worse — the seed phase for it?
A multisig allows for a trusted consortium of signers to interact with sensitive functions on your NFT such as changing the baseURI or other specifics. The basic idea here is to give ownership of the NFT contract to the multisig and create proposals to the other signers that they can cryptographically sign. The multisig will have a configurable minimum of signers and once that is reached, the proposed transaction will be executed by the multisig itself. This means that no one person has ownership of the NFT and it plays well with governance in that the proposal is public for the whole world to see.
The best coders in the world make mistakes. On top of this, all contracts are public, so there are many eyes on their code. Some viewers are curious, wanting to invest, or malicious. In the case of a malicious viewer, they will be looking to exploit your contract to extract value or simply break your project. If your contract receives funds, as in the case of most NFT or defi projects, you will be presenting a honeypot to a potential attacker. Whether it’s an orchestrated attack on an oracle and flash loan attack, or a simple reentrancy hack, it does not make sense to leave a large amount of funds on a contract with a large surface area for attack.
The multisig can provide a safe-haven for your onchain funds as it is built with that in mind. Many custom smart contracts we write are built support an application or feature and not with security in mind. There is nothing wrong with this, but the more complex the smart contract is, the more its attack surface grows. As an owner of the application or NFT contract, the multisig can withdraw excess funds and keep them safe until they need to be deployed.
Not everyone looks at the underlying contract code, but there are quite a few pseudo-security social influencers that can tank your project before it even gets off the ground. If one of these experts looks at your contract and notices that it is not owned by a multisig but rather an address that has a history of Shiba buys and random tx, they will fud you. It’s not personal, it’s how they get engagement. And honestly, you should know better.
Here are some other pointers to help with reputational risk with your public contract
- Use a multisig
- Use ENS to map the multisig to your organization — ie. coolnfts.eth
- Add at least 3 signers to your multisig with a majority required for a proposal to pass
- Use ENS subdomains for your organization’s signers — ie. bill.coolnfts.eth
- Involve trusted third-party signers — Some people rightly don’t trust a multisig with only internal company signers
Note that we will explore ENS(Ethereum Name Service) and how to use them in a future article.
I hope that this article was a good summary of what multisigs can do for you to reduce risk in your project. In upcoming articles we will explore an example project and walk through everything step by step and introduce some tooling to make things simpler. If you understood the concepts in this article, there is nothing preventing you from playing around on Rinkeby and proving these out. Happy trails!