3

With the recent increase in deflationary 'meme tokens', which I won't name on here, I've noticed that whilst holding these tokens not only is the total supply increasing but a percentage of the fee, appears to be appended to all token holder balances based upon the % of total supply held by a wallet. In essence, my wallets token balance is increased whenever someone sells a token.

This was the first time I was exposed to something like this beyond the typical staking/withdrawal method described by Bogdan Batog, et al. in "Scalable Reward Distribution on the Ethereum Blockchain", which was my first thought for network fee redistribution/discount to network users who hold a token supply.

As I'm looking to redistribute network fees to my token holders I've been trying to chase down how this works exactly, not sure if it's related to the UniswapV2 interface, or if it's to do with increasing the allowance all token holders are able to spend upon the owners behalf, and during this time these tokens are held in escrow by the owner/contract? However, when I attempted to call and fetch my allowance, at least from the contracts balance I could not see that, nor did I see any references within the contract.

It seems that a raw call to blanaceOf(address holder) will always show the most up to date balance for that holder, and the contracts I have seen which enable this ability to append fees to balance do not appear to be appending the result of allowance(...) to the wallet's balance. Therefore I can only assume they are actually appending the balance of wallets from within the contract?

If someone in the know could point me in the right direction I'd really appreciate it. I understand I'm simply describing in text, if you feel it's helpful for me to further elaborate please let me know.

2

An idea is to have an external balance and an internal one, at the beginning the relation will be 1:1. Burned fees will change the relationship increasing holders balance slightly.

Lets's suppose the supply is 1000 tokens, and we have 10 user each with 100 tokens. One user makes an operation that burns 1 token.

Users with 100 token will have a balance of 100 * 1000 / 999 = 100.10 and the one that operated will have 99 * 1000 / 999 = 99.099.

contract Fuzz {

    uint256 totalSupply;
    uint256 totalAvailable;

    mapping (address => uint256) balances;

    function mint(address user, uint256 amount) public {
        balances[user] += amount;

        if (totalSupply == 0) {
            // Start with a 1 : 1 relation
            totalSupply = amount;
            totalAvailable = amount;
        } else {
            // Keep relation totalSupply : totalAvailable constant
            uint originalSupply = totalSupply;
            totalSupply += amount;
            totalAvailable += totalAvailable * totalSupply / originalSupply;
        }
    }

    function burn(uint fees) public {
        balances[msg.sender] -= fees;
        totalAvailable -= fees;
    }

    function balanceOf(address user) public view returns (uint256) {
       return balances[user] * totalSupply / totalAvailable;
    }
}

This is just a proof of concept, probably it doesn't work like you expected. It has several flaws like missing error checking. I don't have time to fix it.

4
  • The sum of 100 * 1000 / 999 * 10 + 99 * 1000 / 999 = 1000, this means no token is effectively burned. Can you please explain this contradiction?
    – Maxareo
    May 25 at 11:18
  • @Maxareo There's no contradiction, it is just the math in my example: the total supply is never modified so it is always constant, total available is decremented.
    – Ismael
    May 25 at 15:27
  • So a burned token is not really burned, it's just made unavaiable, correct? Can it be made avaiable again?
    – Maxareo
    May 27 at 8:31
  • @Maxareo In my example it isn't burned but distributed to other participants. The question was more about redistribution, but it shouldn't be too hard to modify to burn a part and redistribute the rest.
    – Ismael
    May 27 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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