Arbitrum MIMv2 Migration

The AbraOFTUpgradeableExisting contract inherits from SenderWithFees, which overrides the default behavior of _lzSend. Unlike the standard implementation where msg.value must match the quoted fee.nativeFee, the override allows msg.value to be any amount. This introduces several issues:

• Excess funds are not refunded – If a user sends more than required, the excess remains stuck in the AbraOFTUpgradeableExisting contract.
• Users can bypass fee payments – If the contract has a balance of native tokens, users can send transactions with msg.value == 0, causing the contract to cover their fees.

Modify the overridden _lzSend to validate that msg.value == nativeFee + protocolNativeFee.

Guardian: The quoteNativeFee function accepts the _fee.nativeFee and _fee.lzTokenFee parameters from the user-supplied MessagingFee. However, the msgValue is disjoint from the MessagingFee since there is no validation that they must match as in LayeroZero’s default _lzSend.

Depending on the FeeHandler implementation, it would be possible for a user to pass a zero’d MessagingFee so that they are not charged protocolNativeFees, yet still pass a normal amount of msg.value for the OFT transfer to succeed, ultimately bypassing the protocol fee.

Recommendation Ensure that FeeHandlers do not rely on the user-supplied MessagingFee.

For mint and burn functionality to be permissible on the AnyswapV5 MIM token, which is necessary for debit/credit to facilitate cross-chain transfers, the AbraOFTUpgradeableExisting OFT needs to be set as a minter such that isMinter = true. However, calling setMinter and applyMinter from the Vault contract would not work on Kava, Base, Linea, Blast since MintableBurnableERC20 token is used instead of AnyswapV5ERC20.

Furthermore, the current migration plan is to set the AbraOFTUpgradeableExisting OFT as an operator on the ElevatedMintedBurner, which would not allow bridging since the AbraOFTUpgradeableExisting contract interacts with the MIM token directly e.g. token_.mint(_to, _amountLD);

Modifiy AbraOFTUpgradeableExisting’s _debit and _credit functions such that the ElevatedMintedBurner’s mint and burn functions are used instead of interacting with the token directly.

The listed test commands such as forge test --fork-url https://arb1.arbitrum.io/rpc --mc AbraForkTests are no longer applicable since the contract has been renamed to AbraForkTestBase.

Adjust the testing documentation.

When the newly minted Arbitrum OFT totalSupply is bridged to mainnet, some dust remains due to the conversion from local to shared decimals, division by 1e10 in this case. Consequently, a small amount of dust will not be bridged over and will be unbacked since slightly less is received on mainnet. Furthermore, the totalSupply of the Arbitrum OFT afterwards will be slightly greater than it was prior to the “Mint Total Arbitrum Supply” migration step.

Clearly document this behavior or account for the dust with a privileged mint.

User who have sent their funds before the bridges were closed are at risk of not receiving their funds. Consider the following example:

(1) Bob sends 50 MIM to Arbitrum from Mainnet, the packet is sent but unexecuted yet. (2) Abracadabra begins migration and closes the bridges by disabling minting/burning. (3) Bob’s message to transfer 50 MIM cannot be executed as lzReceive would revert. (4) Bob ultimately loses his funds as the LayerZeroV1 OFT’s are no longer operational and the funds will be stuck in the LayerZeroV1 Proxy on mainnet.

Note that this also applies to cross-chain transfers between the other bridges.

Clearly document this risk to users during the migration process. Furthermore, ensure users are informed that mainnet will allow lzSend even if the altchain OFT’s are disabled.

Users are able to burn their own AnyswapV5ERC20** **tokens when _vaultOnly is false by using function Swapout. If the migration precalculates the supply that needs to be minted, a user can frontrun to burn some MIM. Consequently, the wrong amount of MIM would be minted and a greater amount of MIM would be extracted from the LZV1 OFT than exists on Arbitrum. However, this is not a large issue since the LZV2 adapter will still hold enough backing tokens, and the excess amount that was sent is effectively burnt.

Consider setting _vaultOnly to true or clearly document this behavior.

The current listed KAVA OFT address is 0x6e858b0DD9a9Dcdf710B28C236292E30ba079728 but that address has no contract on Kava. In fact, that is the address of the Moonriver ElevatedMinterBurner. The proper address should be 0xc7a161cfd0e133d289b13692b636b8e8b5cd8d8c The current listed Arbitrum MinterBurner address is 0x957A8Af7894E76e16DB17c2A913496a4E60B7090 but that is really the OFT’s address. Instead it should be address 0x26F20d6Dee51ad59AF339BEdF9f721113D01b6b3

The current listed BSC MinterBurner address is 0x41D5A04B4e03dC27dC1f5C5A576Ad2187bc601Af but that is really the OFT’s address. Instead it should be address 0x79533F85479e04d2214305638B6586b724beC951 (Figure. See the PDF report.)

Ensure to update the migration document with the proper addresses.

Currently Step 2 of the migration is not specified to be atomic. If this step is not atomic, the following scenario could arise:

(1) 150 AnyswapV5 MIM tokens are sitting on Arbitrum, 50 AnyswapV5 MIM tokens are sitting on Fantom, 200 MIM within ETH LzProxyOFTV2

(2) Once minting is allowed, 150 MIM are minted and bridged to ETH. ETH LzProxyOFTV2 now only holds 50 MIM and new adapter contract holds the 150 MIM.

(3) 50 MIM from FTM is received by the Arbitrum OFT, for example a prior failed message is retried. Now Arbitrum has 200 MIM, but 50 of those are backed by the LayerZero V1 contracts.

(4) Because the LayerZero V1 OFT connections are then disabled, those 50 MIM sitting within ETH LzProxyOFTV2 cannot be retrieved, and the Arbitrum MIM does not have proper backing.

(Figure. See the PDF report.)

Perform this step atomically for all chains and document this in the migration plan.

The migration is for OFT’s across multiple altchains, however connections are only configured for the new Arbitrum OFT. This may be unexpected for users who desire to have cross-chain functionality from their new OFT’s on chains such as Fantom, Polygon, etc. (Figure. See the PDF report.)

Ensure pathways are configured between all new LayerZero V2 OFT’s.

Currently the migration steps would mint and bridge even if a chain has zero MIM supply. Although this is an extremely rare case, gas can be saved on not attempting these actions.

Consider skipping mint and bridge if there is zero supply or document this.

The AnyswapV5ERC20 MIM contract does not allow transfers to itself (the MIM contract). However, in the AbraOFTUpgradeableExisting contract, there is no validation preventing users from initiating cross-chain composed messages which would send tokens to the destination chain MIM token contract. As a result any initiated transfers with the to address as the MIM token on the destination chain will be un-executable.

This may be resolved by storing the address of the MIM token contract on each corresponding dstEid in a mapping and validating that the to address is not the destination’s MIM contract by overriding the send function. Alternatively, the _lzReceive function could include logic to send the bridged tokens to a trusted holding address if the to address is the MIM token contract. If no code changes should be implemented for this issue, be sure to clearly document and warn users of this risk.

The LzProxyOFTV2 on Mainnet performs a plain transfer to the recipient. Before bridging from altchains is disabled, a user can send a transfer to mainnet with the address(0) recipient. This message will never execute, and consequently these funds will forever be locked in the LzProxyOFTV2 contract. Note that this isn’t an attack vector, since these funds are effectively “burnt” by the user from the altchain and hence should not be represented in the backing of the new LayerZeroV2 OFT. Also note that the latest Adapter OFT on mainnet also does not redirect zero address transfers.

Be aware of this behavior.

During the MIM V2 migration, it is critical to lock the total supply of MIM. Throughout the altchains, MIM may have more than a single operator. For example, on altchains that use the Anyswap token, in contrast to Kava, Linea, Base and Blast which use MintableBurnableERC20, the Anyswap router should be removed as an operator during the migration process. Furthermore, the Moonriver MIM contract had duplicate minter rights granted to Multichain, therefore steps should be taken to revoke all of them.

For all chains remove any unnecessary operators to prevent supply changes during the migration process. Ensure only trusted contracts retain minting control during the migration process.

For mint and burn functionality to be permissible on the AnyswapV5 MIM token, which is necessary for debit/credit to facilitate cross-chain transfers, the AbraOFTUpgradeableExisting OFT needs to be set as a minter such that isMinter = true. However, calling setMinter and applyMinter from the Vault contract would not work on Kava, Base, Linea, Blast since MintableBurnableERC20 token is used instead of AnyswapV5ERC20.

Furthermore, the current migration plan is to set the AbraOFTUpgradeableExisting OFT as an operator on the ElevatedMintedBurner, which would not allow bridging since the AbraOFTUpgradeableExisting contract interacts with the MIM token directly e.g. token_.mint(_to, _amountLD);

Modifiy AbraOFTUpgradeableExisting’s _debit and _credit functions such that the ElevatedMintedBurner’s mint and burn functions are used instead of interacting with the token directly.

If users specify msg.value in the message execution options, this value will be passed by the executor while calling lzReceive on the destination chain. The value will be lost as it just ends up as a balance of AbraOFTUpgradeableExisting or AbraOFTAdapterUpgradeable with no way of retrieving it.

The balance of AbraOFTUpgradeableExisting or AbraOFTAdapterUpgradeable can be retrieved by adding an admin function to transfer the balance to the owner. Otherwise, make sure to document this behavior in the docs.

Currently Step 2 of the migration is not specified to be atomic. If this step is not atomic, the following scenario could arise:

(1) 150 AnyswapV5 MIM tokens are sitting on Arbitrum, 50 AnyswapV5 MIM tokens are sitting on Fantom, 200 MIM within ETH LzProxyOFTV2

(2) Once minting is allowed, 150 MIM are minted and bridged to ETH. ETH LzProxyOFTV2 now only holds 50 MIM and new adapter contract holds the 150 MIM.

(3) 50 MIM from FTM is received by the Arbitrum OFT, for example a prior failed message is retried. Now Arbitrum has 200 MIM, but 50 of those are backed by the LayerZero V1 contracts.

(4) Because the LayerZero V1 OFT connections are then disabled, those 50 MIM sitting within ETH LzProxyOFTV2 cannot be retrieved, and the Arbitrum MIM does not have proper backing.

(Figure. See the PDF report.)

Perform this step atomically for all chains and document this in the migration plan.

During the migration, step 3 to activate the MIM bridges should be performed after the messages from step 2 are successfully received and the adapter properly backs the MIMV2 OFT on the altchains. This is necessary because if a user transfers their MIM from an altchain to Mainnet before step 2 messages are fulfilled, the message receipt will either revert or consume the backing of other chains such as Bera.

Document this in the migration plan.

Certain chains are susceptible to block re-orgs such as Polygon. In the case of a block re-org, the transaction for step 2 may end up being executed before the transaction for step 1. This may lead the total supply to be minted and bridged when pre-crime is still enabled, which is expected to be turned off according to the migration plan. Furthermore, if step 2 executes before step 1, a user may seize the opportunity to execute their pending message payload since the OFT would not be disabled as an operator yet. This could lead to too little MIM being bridged over to Mainnet when step 2 executes with a stale total supply, leaving a portion of funds unbacked from the mainnet v2 adapter.

Be aware of this case or consider waiting for sufficient confirmations before proceeding with the next step.

LayerZeroV1 OFT’s rely on function sendFrom for crosschain transfers, while LayerZeroV2 OFT’s use function send. Consequently, any existing protocols that rely on function sendFrom will experience reverts.

Ensure protocols are aware of the migration, that their operations may be affected, and will need to update their calls to use send

Throughout the altchains, MIM may have more than a single operator. For example, on altchains that use the Anyswap token, in contrast to Kava, Linea, Base and Blast which use MintableBurnableERC20, the Anyswap router should be removed as an operator during the migration process.

For all chains remove any unnecessary operators to prevent supply changes during the migration process.

The LzProxyOFTV2 on Mainnet performs a plain transfer to the recipient. Before bridging from altchains is disabled, a user can send a transfer to mainnet with the address(0) recipient. This message will never execute, and consequently these funds will forever be locked in the LzProxyOFTV2 contract. Note that this isn’t an attack vector, since these funds are effectively “burnt” by the user from the altchain and hence should not be represented in the backing of the new LayerZeroV2 OFT. Also note that the latest Adapter OFT on mainnet also does not redirect zero address transfers.

Be aware of this behavior and document this for users.

AbraOFTUpgradeableExisting.sol is currently set to be deployed on Arbitrum with 0xE66BE95FE4E3889a66925d996AF3E4dC173754a2 as the FeeHandler. The issue is that this FeeHandler does not support the new quoteNativeFee() interface without parameters, which will lead to a revert when sending any cross-chain transfer.

Deploy the updated FeeHandler and then update the deploy/MIMOFT.ts script to use the new address.

During the migration to the MIM v2 token standard, the setOperator(<OFT>, false) function is called on all alternate chains (alt-chains) to revoke operator permissions. However, due to the asynchronous nature of blockchain networks, these calls cannot be executed simultaneously across all chains. This creates a timing window where cross-chain bridging fails, leading to inaccurate token supply tracking. As part of the migration process, the setOperator(<OFT>, false) function is invoked on each alt-chain to disable operator permissions for the Omnichain Fungible Token (OFT) contract. For example:

• On Arbitrum, this call occurs at timestamp 1000.
• On Optimism (and potentially other alt-chains), it’s delayed, occurring at timestamp 1020 due to network differences. If a user bridges MIM tokens from Optimism to Arbitrum at timestamp 1007, after Arbitrum’s operator is revoked but before Optimism’s, the transaction fails:
• On Optimism, the tokens are locked or burned to initiate the transfer.
• On Arbitrum, the lzReceive function reverts because the operator permissions were revoked at timestamp 1000, blocking the minting of tokens. This results in:

1. The transfer doesn’t complete.
2. Arbitrum’s totalSupply doesn’t reflect the pending tokens, as they aren’t minted.
3. The MIM v2 Mainnet Adapter (AbraOFTAdapterUpgradeable) fails to fully back alt-chains if these pending tokens remain unprocessed. Pending messages can be retried later, but until they are, the supply on Arbitrum (and potentially other alt-chains) remains understated.

When the new MIM amount to send to the MIM v2 Mainnet Adapter is calculated, do consider the MIM that is part of these failed/pending messages to guarantee that the alt chain supply is fully backed.

With the token_ of AbraOFTUpgradeableExisting being the ElevatedMinterBurner on chains using the Anyswap MIM token, the token() function may return misleading results to integrators.

Clearly document this behavior.

The live version of the Mainnet LZ adapter as well as the Berachain OFT use SenderWithFees where msg.value in excess of the MessagingFee is not refunded and will remain in the contract. This may lead to loss of funds for unsuspecting users who expect a typical refund or validation that they did not send too much or too little native tokens for a cross-chain transfer.

Clearly document this behavior for the existing LayerZero V2 OFT’s.

The FeeHandler on Optimism 0x0B79A169bF618bDD2a73698Fc8ec4A451182a012 (deployed on February 20, 2025) does not have a quoteNativeFee function without parameters. Consequently, FeeHandler Calls Bricked will apply on this chain if it was set as the FeeHandler.** **

Deploy a new FeeHandler with the updated quoteNativeFee function and only then set it for the OFT.

The 0x29d2fEC890B037B2d34f061F9a50f76F85ddBcAE BERA/USD feed on Berachain is unverified. Furthermore, it has zero activity.

Furthermore, safe address on Optimism is 0xCbb86ffF0F8094C370cdDb76C7F270C832a8C7C0 but the address has limited activity.

Ensure the above addresses are Abra controlled and valid.

The optimism-mainnet config currently has a TODO as the safeUrl which may impact LayerZero wiring operations.

Be aware of this and ensure it is updated.

Berachain employs a "single slot finality" mechanism, as outlined in its documentation and glossary. This means that once a block is produced in a slot, it is immediately considered final and transactions within it are irrevocably settled without requiring additional confirmations. This instant finality ensures that confirmed transactions cannot be altered or reversed, providing a high level of assurance right away. However, in the LayerZero configuration script for Abracadabra's MIM token (abracadabra-oft-v2-existing-token-oft/layerzero.mim.config.ts), the confirmation requirement for messages sent from Berachain to other chains, such as Ethereum and Arbitrum, is set to 20 blocks. This is evident in the configuration:

const connections = await generateConnectionsConfig([
    [ethereumContract, beraContract, [['LayerZero Labs', 'MIM'], []], [15, 20], [EVM_ENFORCED_OPTIONS, EVM_ENFORCED_OPTIONS]],
    [ethereumContract, arbitrumContract, [['LayerZero Labs', 'MIM'], []], [15, 20], [EVM_ENFORCED_OPTIONS, EVM_ENFORCED_OPTIONS]],
    [arbitrumContract, beraContract, [['LayerZero Labs', 'MIM'], []], [20, 20], [EVM_ENFORCED_OPTIONS, EVM_ENFORCED_OPTIONS]],
]) as OmniEdgeHardhat<OAppEdgeConfig>[];

Here, the [15, 20] for [ethereumContract, beraContract] indicates 15 confirmations for messages from Ethereum to Berachain and 20 confirmations for messages from Berachain to Ethereum. Similarly, [20, 20] for [arbitrumContract, beraContract] sets 20 confirmations for messages from Berachain to Arbitrum (and vice versa). This setting of 20 confirmations for messages originating from Berachain appears overly conservative given its instant finality.

Merely informative. If higher bridging speed is required, be aware that the confirmation requirement for messages sent from Berachain to other chains can be reduced, leveraging Berachain's single slot finality.

The setFeeTo function in the contract is designed to set an address (feeTo) that receives protocol fees in the form of native assets (e.g., Ether) during cross-chain operations. However, it lacks proper validation to ensure the specified feeTo address can actually receive these native assets. As the protocol relies on a low-level call in the _lzSend function to transfer fees, if the feeTo address can not receive native assets (i.e. if it doesn’t implement a receive function) the bridging would be totally blocked:

(bool success, ) = IFeeHandler(feeHandler).feeTo().call{ value: protocolNativeFees }("");

Consider adding a check in setFeeTo function that performs a zero-value transfer to the proposed feeTo address. This ensures the address can receive native assets without requiring the contract to hold funds.

The configuration file layerzero.mim.config.ts lacks a connection definition for Optimism, and potentially other alt-chains, despite evidence in the deployment script (MIMOFT.ts) that these chains are intended to be supported. Without these connections, cross-chain bridging between Mainnet and Optimism (or other alt-chains) cannot occur, as LayerZero relies on explicitly defined pathways to facilitate messaging and token transfers.

Update layerzero.mim.config.ts to include Optimism and other intended alt-chains in the generateConnectionsConfig array. Use appropriate confirmation numbers and options based on chain characteristics (e.g., Optimism’s finality).