Paul Vijender

@paulvijender

9 Following

28 Followers

Paul Vijender pfp

Yes, @defikaran.eth is coming in from Dubai/India.

0 reply

0 recast

1 reaction

Paul Vijender pfp

💯 I find @avalanche’s X-chain design as pretty well thought out, to solve these problems.

0 reply

0 recast

0 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

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

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

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

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

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

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

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

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

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

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

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

0 reply

0 recast

0 reaction

Paul Vijender pfp

Wallet guard is a good option, there are a plenty of other good ones as well.

0 reply

0 recast

0 reaction

Paul Vijender pfp

For all the hate inscriptions are getting, it is a free performance test for blockchains. If a chain breaks, they have work to do. 🤷🏽‍♂️

0 reply

0 recast

0 reaction

Alliance pfp

4/ Upshield reimagines web3 security as an ongoing process, rather than as a point-in-time (i.e., we will get an audit after we finish the implementation). Going beyond smart contract bugs, it covers the attack surfaces of front ends, deployment infra, and social channels.

1 reply

1 recast

1 reaction