Paul Vijender on Warpcast

Content pfp

0 reply

0 recast

0 reaction

Paul Vijender pfp

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. 👇

1 reply

0 recast

2 reactions

Paul Vijender pfp

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.

1 reply

0 recast

0 reaction

Paul Vijender pfp

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.

1 reply

0 recast

2 reactions

Paul Vijender pfp

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.

1 reply

0 recast

1 reaction

Paul Vijender pfp

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.

1 reply

0 recast

0 reaction

Paul Vijender pfp

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.

1 reply

0 recast

0 reaction

Paul Vijender pfp

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.

1 reply

0 recast

1 reaction

Paul Vijender pfp

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.

1 reply

0 recast

1 reaction

Paul Vijender pfp

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.

1 reply

0 recast

0 reaction

Paul Vijender pfp

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.

1 reply

0 recast

1 reaction

Paul Vijender pfp

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.

0 reply

0 recast

0 reaction