add OptimismMintableFiatTokenV2_2

[alvrs]

Context:

• Optimism's L2StandardBridge expects the IOptimismMintableERC20 interface on ERC20 tokens being bridged from L1 to L2
  • Docs: https://docs.optimism.io/builders/app-developers/bridging/standard-bridge#bridged-tokens
  • Relevant piece of code in the bridge: https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/StandardBridge.sol#L267

For normal ERC20 tokens we could use Optimism's ERC20 factory, but for USDC we need to follow the Bridged USDC Standard in order to have the option to eventually migrate the contract to a native Circle issued USDC, instead of ending up with two USDC variants on the L2.

[karooolis]

Unused import, can remove

[karooolis]

I wonder if emit Transfer makes sense here? We are not transferring tokens to address(0) as far as I can tell, just decreasing totalSupply and user's balance.

[holic]

this follows the pattern in common ERC20 contracts:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L232
https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC20.sol#L204

[alvrs]

This method is taken from FiatTokenV1, only change is the _from param instead of using msg.sender:

stablecoin-evm/contracts/v1/FiatTokenV1.sol

Lines 354 to 374 in 2af605e

	/**
	* @notice Allows a minter to burn some of its own tokens.
	* @dev The caller must be a minter, must not be blacklisted, and the amount to burn
	* should be less than or equal to the account's balance.
	* @param _amount the amount of tokens to be burned.
	*/
	function burn(uint256 _amount)
	external
	whenNotPaused
	onlyMinters
	notBlacklisted(msg.sender)
	{
	uint256 balance = _balanceOf(msg.sender);
	require(_amount > 0, "FiatToken: burn amount not greater than 0");
	require(balance >= _amount, "FiatToken: burn amount exceeds balance");
	totalSupply_ = totalSupply_.sub(_amount);
	_setBalance(msg.sender, balance.sub(_amount));
	emit Burn(msg.sender, _amount);
	emit Transfer(msg.sender, address(0), _amount);
	}

[karooolis]

In the OpenZeppelin example though there is an _update function that increases the balance of address(0) - https://github.com/OpenZeppelin/openzeppelin-contracts/blob/e3786e63e6def6f3b71ce7b4b30906123bffe67c/contracts/token/ERC20/ERC20.sol#L206 so it makes sense to emit Transfer to address(0).

Although I see in Solmate's case the balance is also not increased. And also was not aware of such pattern. I suppose it's useful if you want to monitor for burned tokens, fair enough.