IERC7802 Support

The mint function is no longer overridden in the TetherTokenOFTExtension and ArbitrumExtensionV2 contracts, as a result the owner permissioned mint function from the base TetherToken contract is available to call.

Consider if this is expected. Be aware that this mint function should never be called under normal circumstances, as the minted USDT0 would not have backing USDT in the OAdapter contract on Ethereum.

When upgrading the OFT and Token contracts to include the IERC7802 support, care should be taken to upgrade both contracts in rapid succession and ideally atomically in the same transaction.

If the receipt transaction of a USDT0 bridge were to occur in a state where only one of the OFT and Token contracts have been upgraded, then the bridge receipt would fail and would be required to be retried through the EndpointV2 contract by calling the lzReceive function.

Consider deploying the upgrades with a multicall so that it is impossible to disrupt any active bridges.

In the ArbitrumExtensionV2 and TetherTokenOFTExtension contracts the supportsInterface function indicates that the IERC7802 and IERC165 interfaces are supported by the contract.

The contracts do support several other ERC standards which are not indicated by the supportsInterface function:

• ERC20
• ERC2612
• ERC3009

However none of the EIPs associated with these ERCs require or mention inclusion with IERC165, therefore it is not necessary to list them in the supportsInterface function.

This finding serves only to document this fact, be aware of this behavior and consider if it is as intended.

The upgrade of existing USDT0 token contracts to include IERC7802 support may introduce unexpected changes to the existing deployments.

For example, the TetherTokenOFTExtension contract currently deployed on Ink does not have the _EIP712NameHash override which currently exists in the latest version of this contract.

If the returned value of the name() function were different than the name used in the original _EIP712NameHash value, then such an upgrade would invalidate signatures that were made in the past under the previous domain.

This is however not the case for the Ink deployment as the name() result is the same as the name hash used in the _EIP712NameHash function.

Changes like this may be unexpected and should be carefully examined for each chain on which an upgrade is performed.

Be aware of potentially unexpected code changes that may be introduced during upgrades for IERC7802 support.