Web3 Security

Top 5 - DeFi Attack Vectors of 2024 so far

🔑 Stolen Private Keys - 5 - $27.2m
🛞 Rounding Errors - 4 - $11.7m
💹 Price Oracle Manipulation - 4 - $8.1m
📞 Arbitrary External Calls - 4 - $3.5m
🔍 Function Parameter Validation - 1 - $3.3m

H/t :  blocktheat

Attack vector #2 on this list -  Rounding errors. 
Rounding errors can be a tricky pitfall for developers. Some best practices and guidance below to avoid attacks stemming from these errors. 👇

2/ First up: Understanding the problem. Solidity doesn't handle decimals like traditional programming languages. Instead, it uses fixed-point math, meaning we need to think differently about arithmetic operations to avoid precision loss.

3/ Use SafeMath, ABDK and FixedPoint libraries. While Solidity 0.8.x auto-prevents overflow and underflow, SafeMath can still help with explicit rounding control. It's a must for versions before 0.8 and a good practice for clarity and explicitness in your code.

4/ Stick to integers for monetary amounts. Represent values in the smallest unit (like wei in Ethereum) and only convert to larger units when necessary. This helps maintain precision and avoid rounding errors.

6/ Understand the order of operations. In Solidity, as in other languages, the order in which you perform arithmetic operations matters. Plan your calculations to minimize the impact of rounding.

7/ When downcasting from one type to another, Solidity will not revert but overflow, resulting in unexpected behavior and exploitable bugs. When downcasting developers should consider using OpenZeppelin's SafeCast library which reverts if downcasting would overflow.

8/ Rounding on buying, selling, withdraw, redeem, deposits & protocol fee calculations should always favor the protocol. Round down should be used in calculation of amount you have to send out of contract (eg: withdraw function) Round up should be used in calculation of amount you have to deposit/receive into contract.

9/ Use a higher internal precision to represent numbers. For instance, instead of representing 1.23 as 123, represent it as 12300 or even 1230000, thus reducing the chances of truncation errors.

10/ Test thoroughly. Use frameworks like Hardhat or Foundry to write and run tests that simulate rounding scenarios. This can catch potential errors before your contract goes live.

11/ Finally, Consider the user experience. When displaying balances or transaction amounts in your dApp, make sure to format the output in a way that's readable, using appropriate rounding for the display, not for the logic.

5/ When division is unavoidable, multiply before you divide. If you need to calculate a percentage, for instance, rearrange your equation to do the multiplication first. This minimizes loss of precision.