How do redistribution rewards work on deflationary coins?

Question

Regarding "redistribution rewards", I'm referring to the token reward mechanics of deflationary coins such as Safemoon. This mechanism seems to have originated from an ERC-20 token called RFI (reflect.finance), so I will be referencing this token from now.

On reflect.finance's site, they claim:

RFI works by applying a 1% fee to each transaction and instantly splitting that fee among all holders of the token.

My first thought was, do they make a send to every address per transaction made? Obviously not, that'd be way too expensive of an operation to perform on a scale like that.

After further research, I found an interesting snippet on one of their blog posts:

https://reflectnetwork.org/posts/what-is-reflect-finance-rfi-duplicate-1

...Due to the token reward mechanics and the transactionless nature...

They described this mechanism as "transactionless", so that caused me to be even more intrigued. Despite having minimal knowledge on how smart contracts work, I decided to take a look at their smart contract code on github, which is located here:

https://github.com/reflectfinance/reflect-contracts/blob/main/contracts/REFLECT.sol

Due to my lack of knowledge in this domain, I managed to read through that file a dozen times and still have no idea how that feature actually works. I noticed some function names that mention "Reflection" and I assume that is how they refer to the redistribution mechanics, but that's about as far as I can get in understanding this.

Can anyone explain to me in layman's terms how this feature works?

Answer 1

Possibly someone familiar with it or able to study it more will chime in with a more detailed explanation.

They are mathematically adjusting account balances on the fly, as needed. For example, line 56 kicks off a computation instead of just returning a number lookup:

return tokenFromReflection(_rOwned[account]);

As one follows the chain of internal function calls, supply is also adjusted. This is following a style Nick Johnson called "Amortizing Work". Given the rules of the system, it's not important to do batch-like work if the result of such work can be computed when it's needed.

This is from 2017, so the syntax is outdated but the description of the pattern will help you understand this contract: https://weka.medium.com/dividend-bearing-tokens-on-ethereum-42d01c710657

As a PSA, it would be interesting to investigate the for loop near 239. "Unbounded" for loops are an anti-pattern, so I'm curious about the maximum length of the array, hopefully short.

Hope it helps.

Answer 2

It basically works as the Safemoon token's source code.

Any transfer's amount is tAmount, and then:

rAmount = tAmount.mul(currentRate);

currentRate is just rSupply/tSupply in most of cases (except for excluded addresses).

Take a look to balanceOf and tokenFromReflection functions to properly understand the reflection and how the fee sharing is done across all the addresses.

Each holder's balance in the current moment is calculated in this way:

function balanceOf(address account) public view override returns (uint256) {
    if (_isExcluded[account]) return _tOwned[account];
    return tokenFromReflection(_rOwned[account]);//=> rAmount/currentRate
}

function tokenFromReflection(uint256 rAmount) public view returns(uint256) {
    require(rAmount <= _rTotal, "Amount must be less than total reflections");
    uint256 currentRate =  _getRate();
    return rAmount.div(currentRate);
}