The Token is designed to inherit the following implementations from the OpenZeppelin library (V2):
ERC20(docs) The ERC20 standard as implemented in the OpenZeppelin library.ERC20Detailed(docs) This extension allows for the storing of a name, symbol and explicit decimal.ERC20Capped(docs) This extension allows for an explicit cap on the number of tokens that can ever be in existence simultaneously .ERC20Mintable(docs) This extension allows users with theMintablerole to mint tokens freely. This is included to allow for future compatibility with a bonding curve.ERC20Burnable(docs) This allows a user to burn tokens, as well as allows approved addresses to burn tokens on the users behalf. This again is included for future compatibility. Note that this functionally has been modified in order to have theburnandburnFromfunctionally protected by theminterRole.
The full interface of publicly callable functions for the Token contract can be found here.
The Token contract inherits the above contracts as follows:
contract Token is ERC20Detailed, ERC20Capped, ERC20Burnable {
As you can see, it seems as if all the contracts are not there. But when we dig a bit deeper, we can see all the contracts are in fact, present.
Detailed imports the IERC20 interface:
contract ERC20Detailed is IERC20 {
Capped is Mintable, meaning that by inheriting capped we are inheriting mintable.
contract ERC20Capped is ERC20Mintable {
Burnable inherits from ERC20, so we fully implement the interface imported by Detailed, meaning the contract is not abstract and all ERC20 functionality is present.
contract ERC20Burnable is Context, ERC20 {
The modifications the the burnable functionality look as follows:
/**
* @dev Destroys `amount` tokens from the caller.
*
* See {ERC20-_burn}.
*/
function burn(uint256 amount) public onlyMinter {
_burn(_msgSender(), amount);
}
/**
* @dev See {ERC20-_burnFrom}.
*/
function burnFrom(address account, uint256 amount) public onlyMinter {
_burnFrom(account, amount);
}
The onlyMinter modifier has been added to both functions. This is done to protect users against accidentally burning their tokens. For more information see admin permissions and risks: MinterRole
Below we can see the inheritance (simply) laid out in order. Here we are only looking at the first level of inheritance, i.e we are not looking at what the inherited contracts inherit.
This simple diagram shows how all the required extensions are inherited.
For the full inheritance structure, please see the below diagram
