M Portal Lite

The original intent for the M token was to be permissionless, allowing anyone to hold it. However, based on recent discussions with the M0 team, the model has changed:

• New intent: Only selected role holders are allowed to handle the native M token directly.
• Regular users should instead interact with M extensions (wrapped versions of M) for DeFi and other use

cases.

However, the current Portal implementation does not reflect this new intent. If the destination token in a spoke/hub transfer is set to the native M token address, the Portal will issue or transfer native M tokens directly.

• The swapInM function in the Swap Facility only allows approved swappers to swap native M into wrapped

M.

• This means users who receive native M cannot wrap it themselves.
• Since wrapped M is the expected token for DeFi integrations, users would be stuck holding the native token,

unable to use it in the intended ecosystem.

Under M0’s original (permissionless) deployment assumptions, this flow was fine. But with the new restricted model, this scenario can occur even in the happy path.

Example:

• On Mainnet Hub (0x36f586A30502AE3afb555b8aA4dCc05d233c2ecE), the destination token for Linea is

currently set to native M.

• As a result, if a user calls transfer on the Portal, they receive native M on Linea instead of the wrapped

version.

Set the default destination token to the wrapped M (wM) instead of native M, so that by default:

• The Portal wraps into wM before delivering to the user.
• If a different extension specified, wrap into that instead.

M0 Team: Acknowledged. This is acceptable behavior and will be addresses by configuration of approved bridging paths for Portals.

When a user makes a cross chain transfer with a M extension token the flow looks like this:

• On the source chain the swapOutM function is called to convert the M extension tokens to $M

tokens

• The $M tokens are transferred to the destination chain
• On the destination chain the system tries to wrap the $M tokens to M extension tokens with the

swapInM function

• But in case the swapInM call fails the user just receives the $M tokens instead

This is problematic as normal users should never receive $M tokens and as a normal user is not able to use the swapInM function the user might not be able to do anything with these tokens.

A malicious actor might also be able to do this on purpose (in case the actor sees any benefit of doing so).

For example if the M extension token has a minimum amount restriction for the wrap function of $100 the user could perform multiple $99.99 cross chain transfers to load himself up with $M tokens.

Consider leaving the tokens inside the contract or transferring them to another one and let an admin handle the situation if this edge case occurs.

M0 Team: Acknowledged. This is acceptable behavior for now.

The comment above the _revertIfUnsupportedDestinationChain function on line 128 of SpokePortal contract is incorrect. It should be: "Reverts if the destination chain is not the Hub chain".

Update the comment.

M0 Team: Acknowledged. Will fix.

The _isEarningEnabled function is implemented as:

function _isEarningEnabled() internal view returns (bool) {
    return wasEarningEnabled & disableEarningIndex = IndexingMath.EXP_SCALED_ONE;
}

Given this logic:

Once disableEarningIndex is set to current Index in disableEarning, earning can not be enabled again.

Be aware of this constraint.

M0 Team: Acceptable behavior.