6

If I'm building a rebase token that has a difference of 1 wei sometimes (pre/post rebase) between the totalSupply and the sum of the balances of all holders, does that pose an attack risk within the system?

balanceAlice = 33014939898026519691;
balanceBob = 33014939898026519691;

totalSupply = 66029879796053039381

balanceAlice + balanceBob = 66029879796053039382
delta between totalSupply and balanceAlice + balanceBob = 1; 

Thanks!

1
  • 1
    You should share more details. For example, it's clear that if you never use totalSupply there's no attack risk ...
    – 0xSanson
    Commented Apr 16 at 12:23

2 Answers 2

3
+50

This is most likely a rounding error.

To avoid them, you should use some padding before you do your maths and then remove it, this way you will avoid lost precision.

some_number_in_wei * 1e18; another_number_in_wei * 1e18;

do your magic here.

the_result_in_wei / 1e18;

What we did here is that we moved your delta to a position that will not affect the result. You will still have a delta of 1 but instead of

0000000000000000001

your will get

0000000000000000000000000000000000001

So when you do

0000000000000000000000000000000000001 / 1e18

You will get

000000000000000000

because you made the imprecision much smaller.

This is a technique that is used in a lot a DEFI protocols to deal with rounding. Look at Compound and AAVE yield calculation for instance.

0
2

Introduction

Like most things in security, the answer is "it depends." However, I'd lean towards "yes, this will likely cause issues."

Issues internally

Heading over to Solodit we can see a LOT of issues arise by just searching for issues with totalSupply. These issues can come up depending on a multitude of factors:

  1. Total Supply affecting reward payout
  2. Total Supply being used in rebase calculations
  3. Total Supply being used for insert anything here

Issues externally

Now, maybe you don't use the total supply anywhere else internally, and it's just "a vanity metric." By doing so, your token technically no longer follows the ERC 20 Token Standard because you've now broken an invariant of the ERC20.

  • The totalSupply function must return the sum of all account balances.

By doing so, you'll exclude your token from being compatible with many other dapps in the web3 ecosystem, and your token will be added to the list of weird ERC20s that have incompatibilities and issues if used in web3 apps like Aave, Uniswap, etc.

You could of course, "not care" but it would seem odd to me to build a token just to have it not work with the rest of DeFi.

Summary

Technically, suppose your totalSupply doesn't reflect the totalSupply. In that case, your ERC20 is technically no longer an ERC20, and should be excluded from integration with DeFi applications because this could cause unintended side effects of those protocols.

And finally, yes, this could (and likely does) cause issues inside your protocol as well, because its quite likely your rebasing token uses the totalSupply in some type of internal calculation.

And finally, if you're concerned, please contact a security specialist to conduct a security review or smart contract audit.

1
  • Great answer but the other one gave me a solution to my problem.
    – dNyrM
    Commented Apr 18 at 20:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.