feat(protocol): improve TaikoToken, BridgedERC20, and ERC20Vault

[dantaik]

BEGIN_COMMIT_OVERRIDE refactor(protocol): merge BridgedERC20Baseinto BridgedERC20for simplicity feat(protocol): allow contract owner to mint/burn bridged ERC20 tokens (besides ERC20Vault) feat(protocol): disallow bridged token contract owner to trigger migration directly (must go through ERC20Vault) feat(protocol): disallow migration within 90 days post the previous migration feat(protoocl): make BridgedERC20 no longer inherit ERC20VotesUpgradeable feat(protocol): add BridgedTaikoToken that inherits ERC20VotesUpgradeable END_COMMIT_OVERRIDE

This is to respond this feedback from OZ

---

Tokens inheriting from the BridgedERC20Base contract can be migrated by the owner or by calling the changeMigrationStatus function of the ERC20Vault. If a migration is triggered, token owners can burn their tokens to mint the same amount of tokens on the new contract. If the migration is triggered by the bridge, old tokens are added to a blacklist and have to be migrated before being able to bridge.

However, there are multiple migration scenarios that could cause accidental user losses:

• If a new migration is triggered before some users have migrated from a previous migration, then these users would effectively lose their tokens as they would no longer be able to call mint() on the new contract nor bridge their tokens.
• If a migration is triggered by the owner instead of the ERC20Vault, the vault would no longer be able to call burn or mint on the migrated token. This would prevent users from bridging and could cause losses as the new migrated token would not be bridging to the same contract when bridging through the vault.
• If a migration happens to a token that doesn't implement the IBridgedERC20 interface, user losses could happen as well.
• If such concerns are shared, consider addressing the above instances to protect users' funds from errors during migrations. Potential solutions include adding a delay to migrations during which no new migration can be done, preventing the owner from calling changeMigrationStatus, and validating that the new token implements the IBridgedERC20 using ERC-165 during migrations.

[openzeppelin-code[bot]]

feat(protocol): improve TaikoToken, BridgedERC20, and ERC20Vault

Generated at commit: eea46ad17e8a03dfa0272872f69f8c623b9952d1

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 5 40 49
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[dantaik]

layout-2f6d3c6.txt

layout-97bc38f.txt

@davidtaikocha TaikoToken's storage layout stays the same; but bridged tokens' layout changed which I think it's OK.