OFT Updates

In the FeeHandler contract the latestAnswer on the configured aggregator contract is queried without checking the latestRoundData result with the updated time. Furthermore for FeeHandlers on L2s with sequencers like Arbitrum there is no check to ensure that the sequencer is active. This means the price used to denominate the native asset can be inaccurate beyond the allowed threshold if the aggregator feed is stale. It may instead be better to fallback to the fixed native fee in instances where the oracle price has not been updated as expected.

Consider using the fixed native fee as a fallback in the event that the aggregator price is stale or the sequencer is down.

In the FeeHandler contract the feeTo address may be assigned to the zero address in the setFeeTo function. However there is no check to see if the feeTo address is the zero address when sending the fee to the feeTo address in the SenderWithFees._lzSend function.

Consider either validating that the feeTo is not address(0) in the setFeeTo function or include logic to skip the fee handler fee if the feeTo is address(0) in the SenderWithFees contract.

In the AbraOFTAdapterUpgradeable and AbraOFTUpgradeable contracts the constructors do not include calls to _disableInitializers to disable the initializer functions from being called on the implementation contract directly. This is not a significant risk as the upgradeable contracts are not UUPS proxies, however it is a best practice to disable the initializers for upgradeable contracts.

Consider including a call to the _disableInitializers function in the constructor for the AbraOFTAdapterUpgradeable and AbraOFTUpgradeable contracts.

The _lzSend function in the OAppSenderUpgradeable contract performs validation on the msg.value to ensure that it matches the provided _fee.nativeFee with the _payNative function. This validation is however missing from the _lzSend implementation in the SenderWithFees contract. As a result users may accidentally provide a msg.value that exceeds the _fee.nativeFee specified and this amount will be lost to the caller and credited to the next user who calls the _lzSend function.

Consider including the _payNative validation in the _lzSend function in the SenderWithFees contract.