Conversation
| // SPDX-License-Identifier: MIT | ||
| pragma solidity 0.6.12; | ||
|
|
||
| import { FiatTokenV1 } from "../v1/FiatTokenV1.sol"; |
| totalSupply_ = totalSupply_.sub(_amount); | ||
| _setBalance(_from, balance.sub(_amount)); | ||
| emit Burn(_from, _amount); | ||
| emit Transfer(_from, address(0), _amount); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Context:
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.