A Technical Whitepaper for Reflect Contracts

I wrote a technical whitepaper for Reflect Contracts. ↓

In short, reflect contracts are tokens that have auto-staking mechanism built in. Safemoon, Octa, Lunarswap tokens, are some examples.

I decided to write the technical paper because there wasn’t one. In fact, if you look at the program , it is very hard to read and understand. I spent some time digging it to the program, tried to understand how it works, and then finally wrote the paper.

I think there are some grammar mistakes and some of the equations may be wrong.
Any feedback is welcome! And feel free to make Pull Request!

Sneak peak:

Source code: https://github.com/REGO350/reflect-contract-doc
PDF version: https://www.keepandshare.com/doc15/24269/reflect-technical-paper-pdf-822k?da=y


Thank you for taking time to write this paper. It really helped me to understand reflect algo. On your paper, you mentioned

RFI contracts has one fundamental issue over including users into staking. The conversion rate between
t-values and r-values is calculated using equa!on (5). Here, it is excluding non-stakers out of equa!on in
order to fully reward the stakers. However, when a new user gets included into staking, the rate updates,
thereby changing all stakers balance. Using this feature, it can be used to rug-pull rewards from stakers
by including a whale.

Could you elaborate more and give an example how rug-pull can happen? Thanks

What happens is that, when you include a user to staking (exclude from excludeStaking mapping), the conversion rate between t-value and r-value changes (look at equation 5). This results in distributing the reward also to the new user because stakers balance is calculated like this: balance[user] = rOwned[user] / rate. If you include a whale (maybe dev wallet), you will be able to take most of users' reward.

I'll try to make example code when I have time.

1 Like

Thank you for taking time to write this article,
In reflect contact there is a function called reflect:

function reflect(uint256 tAmount) public {
        address sender = _msgSender();
        require(!_isExcluded[sender], "Excluded addresses cannot call this function");
        (uint256 rAmount,,,,) = _getValues(tAmount);
        _rOwned[sender] = _rOwned[sender].sub(rAmount);
        _rTotal = _rTotal.sub(rAmount);
        _tFeeTotal = _tFeeTotal.add(tAmount);

Can you please help me to understand why they calculate _rTotal like this:

_rTotal = _rTotal.sub(rAmount);

Another question is, In your paper, You assume that tTotal is constant, What if we want to burn some portion of fees like Safemoon (I meen real burn, Not like Safemoon that transfers burn portion to the address that receives profits from transaction fees), Should we subtract burn fees from tTotal in equation no. 4?

Sorry for the late reply. @AmirHossein484

I don't really know why this function exists. Because it's not being called anywhere from the reflect contract code.
But looking at the code, it distributes tAmount of tokens to other holders from the sender.

_rTotal = _rTotal.sub(rAmount) is same as _rTotal -= rAmount, it's just that they are using safemath library. But you don't need to write it like this if you are using solidity >=0.8

If you want to burn tokens, you should also subtract from tTotal because tTotal is basically the total supply.

1 Like

Enjoyed reading your technical white paper. Trying to follow your 'Deflationary mechanism' mathematical equations. Does it prove mathematically that assigning _rTotal = _rTotal.sub(rFee) during every transfer would theoretically never reach 0?

It's not a full mathematical proof but we can assume that rTotal will never go to 0 if you look at equation (4). rTotal is always multiplied by a number that is bigger than 0 and smaller than 1.

Great contribution! Very clear and easy to understand.