Bonfire token with auto burn feature

Support Contracts
22

There are 2 types of burn:

  1. Reduce total supply
  2. reduce just circulating supply

In that code the type is the n. 2 ofr the only reason it has been asked in this way. Nothing else.

2 Likes
23

Is there a function that reduces the total supply?

function burn(address account, uint256 amount) internal {
        require(account != address(0), "ERC20: burn from the zero address");

        uint256 accountBalance = _balances[account];
        require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
        unchecked {
            _balances[account] = accountBalance - amount;
        }
        _totalSupply -= amount;

        emit Transfer(account, address(0), amount);
    }

can we integrate this function into it

and if we make the 0x0 address here another address, will it decrease the total supply again, even if the circulation does not decrease?

24

I didn't understand this part

25

I didn't understand either. @TRicarus_Online ... you want to call your function instead of

_transferStandard(sender, address(0), burnAmt);

@FreezyEx, what would the solution be to reduce total supply instead of circulating supply? How does reducing circulating supply affect the token price? I think that if you reduce total supply, the price should go up. Or am I wrong? Shouldn't circulating supply be handled when creating the token? Where do users see that the circulating supply has been reduced?

Another thing. Has this contract been used to deploy a token? If so, can you share it with us? Just curious to see how it worked out.

26

I mean reducing the total supply when burn manually

27

Best thing would be to burn automatically. Maybe @FreezyEx will help us out.

1 Like
28

Not sure if this is how it's supposed to be done, but right after the burn transfer I changed the total supply.
I would appreciate any feedback on this.

//burn
        _transferStandard(sender, address(0), burnAmt);
        _tTotal = _tTotal.sub(burnAmt);

Seems to work. As you can see here, the total supply went down.

This is the transaction that made it happen:

1 Like
29

You should reduce tOwned,rOwned, rTotal too.
As you can see you got this:

image
image1424×372 18.5 KB

1 Like
30

I solved the problems, it works fine now Ty

image
My last question is why nothing is sent to these two addresses and what function are the addresses in?

31

mmm, those are not address but fees,
Btw the taxFee represent the reflection and liqudiity fee will be shown as tokens sent to contract address

1 Like
32

image

Does liquidity fee do this?
Will taxfee be the sum of all taxes?

sample:

_taxfee= 6;
_liquidity = 2;
_burn = 2;
_reward = 2;
33

As I already explained in the answer before, _taxFee represents the reflection fee, not the sum of all the fees

1 Like
34

Hi @FreezyEx . Thanks for replying. So ... what are these three exactly? Would you mind explaining why they need to be reduced?

Do I just do this?

        //burn
        _transferStandard(sender, address(0), burnAmt);
        _tTotal = _tTotal.sub(burnAmt);
        _rTotal = (MAX - (MAX % _tTotal.sub(burnAmt)));

I don't know how to set _tOwned and _rOwned

35

This fee reflects on my holders

36

this is how i did it and the total supply is decreasing

37

@TRicarus_Online You copied my line of code? That's good. But @FreezyEx is saying that there are more changes needed.

39

Also found this https://reflect-contract-doc.netlify.app/

Might help.

1 Like
40

why do you need this much variability, that way the aggregate supply goes down

41

tTotal , rTotal , tOwned and rOwned are used in safemoon contract to calculate the balance of the users and the reflections they should get ( more details here https://reflect-contract-doc.netlify.app/, be careful : may contain complicated maths) . I'd STRONGLY recommend not messing around too much with those values unless you know what you're doing, because you can really well end up completely fucking up the way the contract calculates the users balances, and having it producing complete nonsense results, which would definitely be the case with your code as it is right now (you're modifying tTotal without touching rTotal , meaning that the total supply and the number used to calculate reflections will be slowly drifting out of sync with each transactions, and you'll end up giving as reflections tokens that doesnt exist).

1 Like
42

Any help on this? Anyone?