Smart Contract Audits
Learn to audit Smart Contract to prevent hacking vulnerabilities.
Most bugs are the result of poor business logic implementation
📄️ Testing
Outline general approach to Smart Contract testing here with links to specifc code explanations under Solidity or alternative Smart Contract language.
🗃️ Damn Vulnerable Defi
1 item
📄️ Solidity by Example
Example from Solidity by Example
📄️ Denial of Service
- Example Source Code
📄️ Honeypot
Source Code
📄️ Hacks
Consensys
📄️ Re-entrancy Attack
Consensys Definition
📄️ Ethernaut
Learn how to stop common hacks.
Core Checks
Smart Contracts cannot have vulnerabilities as they will be exploited.
- Overflow and underflow preventions
- Function visibility
- Time manipulation within a few minutes only
- Utilizing reliable and audited dependencies
- Fix warnings to avoid tricky features
- Checking external calls, such as reentrancy or short circuits and others
- Validate external or public functions
- Checking rounding errors and unexpected behaviors
- Unbounded loops preventions
- Push payments and their correct usage
- Using the latest solidity versions performing change verification
- Lowering down pseudo-randomness
- Old solidity constructs and their frequent updates
Frontrunning
The best remediation is to remove the benefit of front-running in your application, mainly by removing the importance of transaction ordering or time.
All code has the potential for bugs. Read as much code as you can to learn as much as possible from the mistakes of others.
As you develop, search related mistakes made by others for the type of contract solition to confirm you are not doing the same.
Access Control
A contract can also be the owner of another one, enabling composability to add additional layers of access control complexity. For example a 2-of-3 multisig run by your project leads.
Check for updates at samczsun.com
Tools
Auditors
Links
- secure-contracts.com
- Smart Contract Security Field Guides
- Consensys Best PracticeS
- blockthreat.io newsletter
Courses