anchor.diff:  [[modularizing-the-mechanism]]
   == Modularizing the Mechanism
   
  -There is one supply mechanism already included in Contracts: `ERC20DeployReady`. This is a generic mechanism in which a set of accounts is assigned the `minter` role, granting them the permission to call a `mint` function, an external version of `_mint`.
  +There is one supply mechanism already included in Contracts: `ERC20PresetMinterPauser`. This is a generic mechanism in which a set of accounts is assigned the `minter` role, granting them the permission to call a `mint` function, an external version of `_mint`.
   
  -This can be used for centralized minting, where an externally owned account (i.e. someone with a pair of cryptographic keys) decides how much supply to create and to whom. There are very legitimate use cases for this mechanism, such as https://medium.com/reserve-currency/why-another-stablecoin-866f774afede#3aea[traditional asset-backed stablecoins].
  +This can be used for centralized minting, where an externally owned account (i.e. someone with a pair of cryptographic keys) decides how much supply to create and for whom. There are very legitimate use cases for this mechanism, such as https://medium.com/reserve-currency/why-another-stablecoin-866f774afede#3aea[traditional asset-backed stablecoins].
   
   The accounts with the minter role don't need to be externally owned, though, and can just as well be smart contracts that implement a trustless mechanism. We can in fact implement the same behavior as the previous section.
   
   [source,solidity]
   ----
   contract MinerRewardMinter {
  -    ERC20MinterPauser _token;
  +    ERC20PresetMinterPauser _token;
   
  -    constructor(ERC20MinterPauser token) public {
  +    constructor(ERC20PresetMinterPauser token) public {
           _token = token;
       }
   
  
positive.code: }
  ----
  
  This contract, when initialized with an `ERC20DeployReady` instance, will result in exactly the same behavior implemented in the previous section. What is interesting about using `ERC20DeployReady` is that we can easily combine multiple supply mechanisms by assigning the role to multiple contracts, and moreover that we can do this dynamically.
  
  TIP: To learn more about roles and permissioned systems, head to our xref:access-control.adoc[Access Control guide].
  
  [[automating-the-reward]]
  == Automating the Reward
  
  Additionally to `_mint`, `ERC20` provides other internal functions that can be used or extended, such as xref:api:token/ERC20.adoc#ERC20-_transfer-address-address-uint256-[`_transfer`]. This function implements token transfers and is used by `ERC20`, so it can be used to trigger functionality automatically. This is something that can't be done with the `ERC20Mintable` approach.
  
  Adding to our previous supply mechanism, we can use this to mint a miner reward for every token transfer that is included in the blockchain.
  
  [source,solidity]
  ----
  
negative.code:         _mint(block.coinbase, 1000);
      }
  
      function _beforeTokenTransfer(address from, address to, uint256 value) internal virtual override {
          _mintMinerReward();
          super._beforeTokenTransfer(from, to, value);
      }
  }
  ----
  
  [[wrapping-up]]
  == Wrapping Up
  
  We've seen two ways to implement ERC20 supply mechanisms: internally through `_mint`, and externally through `ERC20PresetMinterPauser`. Hopefully this has helped you understand how to use OpenZeppelin and some of the design principles behind it, and you can apply them to your own smart contracts.
  