ERC20.sol private variables with no setters

Support Contracts
5

Thanks for the swift reply!

Sure. This is the _mint function of ERC20Upgradeable.sol

function _mint(address account, uint256 amount) internal virtual {
    require(account != address(0), "ERC20: mint to the zero address");

    _beforeTokenTransfer(address(0), account, amount);

    _totalSupply += amount;
    _balances[account] += amount;
    emit Transfer(address(0), account, amount);

    _afterTokenTransfer(address(0), account, amount);
}

Using a shared scenario, an implementation of "Rewarding Miners" https://docs.openzeppelin.com/contracts/4.x/erc20-supply#automating-the-reward

We have on the table the usage of transfer hooks, that let us validate conditions or even mutate local and external state, before token balances are edited.

Let's say this works well. But if in addition, my logic states that
a) If the miners balance is higher than 5% of supply, they won't be rewarded on mint operations
b) lost rewards can be tracked on another field (implemented on the deriving/child contract, still and ERC20), and these rewards have a different time-decay-based logic (hence not materialised balances)

Suddenly a big step back needs to be taken.

Here's where I see the conflicts with a) and b)

a) requires a different _mint logic where _beforeTokenTransfer may or may not happen or happen in a different shape (but we still need to apply the basic +=s to totalSupply and balances)
b) requires to perform another assignment, based on the result of the "_beforeTokenMint" (made up name, based on the premise above)

I'd highlight the nuances being that while _mint is internal :heavy_check_mark: and virtual :heavy_check_mark:, the main fields are private which does constrain the extensibility.

Agree on that forking is an option - I was curious to see what else was possible. Lastly I'm eager to learn, from the best practices perspective, what are the main drivers for it to be a comfortable solution. Before replying I did scan the forum and found this here:

This is to increase encapsulation, to be able to reason better about the code.

Is there anything beyond? Other benefits outweighing the cons?

Thanks again :+1: