Celo XAUT0 Upgrade and USAT Deployment

The onlyFeeWrapper modifier in CeloExtension.sol:27 permits calls from both address(0) (the VM) and the feeCurrencyWrapper. The name onlyFeeWrapper suggests only the fee wrapper is authorized, omitting the fact that the VM (address(0)) is also an allowed caller. Location: CeloExtension.sol:27-30 modifier onlyFeeWrapper() { require(msg.sender == address(0) || msg.sender == feeCurrencyWrapper, "Only VM can call"); _; }

Rename the modifier to onlyFeeWrapperOrVM (or onlyVMOrFeeWrapper) to accurately describe both permitted callers.

The require statement's revert string is "Only VM can call", but the condition also allows feeCurrencyWrapper. If a call reverts, the error message misleads the caller into thinking only the VM is authorized, when in reality the fee currency wrapper is also a valid caller. Location: CeloExtension.sol:28 require(msg.sender == address(0) || msg.sender == feeCurrencyWrapper, "Only VM can call");

Update the error message to reflect both allowed callers, e.g.: "Only VM or FeeCurrencyWrapper can call"

The creditGasFees function in CeloExtension.sol:52-72 uses the old 8-parameter signature (with the unused gatewayFeeRecipient and gatewayFeeAmount parameters). Celo's fee-currency-example repository indicates they are moving to a simplified signature that removes these legacy gateway fee parameters. This comment is ~2 years old, and the timeline for enforcement is unclear. If Celo proceeds with this change at the protocol level, contracts using the old signature may break or become incompatible with the fee currency system. Location: CeloExtension.sol:52-72 function creditGasFees( address refundRecipient, address tipRecipient, address , // gateWayFeeRecipient is not used anymore address baseFeeRecipient, uint256 refundAmount, uint256 tipAmount, uint256 , uint256 baseFeeAmount ) external onlyFeeWrapper {

Confirm with the Celo team whether and when they plan to enforce the new creditGasFees signature at the protocol level. If the migration is imminent, consider adopting the new interface for USDT/USAT now (since these are fresh deployments), while keeping backward compatibility for already-deployed contracts like XAUT0. If the timeline is distant or uncertain, the current approach is acceptable but should be revisited before Celo's migration goes live.