Smart contract security is as much about decision making as it is about knowledge and tooling. Contract developers are often faced with the following choices:

• Spend time developing new features or reviewing existing features
• Release a new version now or later
• Pay for an expensive audit, a cheaper audit or no audit at all
• Put up a bug bounty period or don't.

Security risk is also an important factor for investors, protocol politicians and other consumers of protocols who can face the following dilemmas:

• How to vote for an unaudited governance proposal
• How much to allocate for a DAO security budget
• Whether or not to invest in a promising protocol.

Drivers of smart contract security risk

The key to answering these questions lies in being able to accurately estimate security risk. Below are some questions to ask when thinking about the magnitude of risk associated with a given feature:

Level of testing

• Has the feature been audited?
• Have there been adequate unit tests?
• Have there been adequate fork tests?

Novelty and complexity

• How much new code and changes are part of this feature?
• How many libraries and external smart contracts does this feature rely on? How proven are these components?
• How many applications and other smart contracts depend on this feature?
• Does this feature represent a conceptual leap for the team developing it? For the industry in general?
• Does this feature use inherently complex primitives (assembly code, upgradability)?
• Is this feature reversible?

Process challenges

• Is the feature documented and described clearly?
• Have there been evolving scope changes?
• Has the feature been rushed (e.g., due to a governance emergency)?

People challenges

• Is the project staffed appropriately with enthusiastic and rested engineers?
• Has this feature been written by a different person from whoever wrote the original code?

‍