Mamo Contracts - Moonwell

A variety of contracts throughout the codebase (e.g., Mamo.sol, Mamo2.sol, MamoStrategyRegistry.sol, ConfigurablePauseGuardian.sol) rely on role-based or ownership-based access control for critical functions. Examples include:

• MamoStrategyRegistry.sol: whitelistImplementation(), addStrategy(), upgradeStrategy(), restricted by onlyRole(DEFAULT_ADMIN_ROLE) or onlyRole(BACKEND_ROLE).

• ConfigurablePauseGuardian.sol: pause(), unpause(), restricted by a designated pause guardian.

• Mamo.sol: Administrative functions (setBufferCap(), addBridges(), etc.) guarded by onlyOwner.

While these controls are standard for protocol management, they also centralize power in specific addresses or roles.

In case these privileged accounts be compromised or behave maliciously, they could alter system parameters, pause the protocol, or upgrade implementations in ways that deviate from user interests.

Multi-Sig Governance: Assign critical roles to multi-signature wallets with transparent signing thresholds to reduce single-key compromise risk.

Time-Locked Upgrades: If feasible, subject major changes (e.g., upgrades) to a timelock, allowing users to exit or react to unexpected modifications.

Auditable Roles: Publicly document and track all role assignments. Make it easy for community members to verify who holds which privileges.

Regular Key Security Audits: Ensure that guardians, admins, and owners use hardened security practices (hardware wallets, multi-factor, minimal hot-key usage).

ACKNOWLEDGED: The Moonwell team has acknowledged this finding.

In some locations throughout the codebase, addresses are assigned to state variables without verifying that they are non-zero. For example, when setting roles, updating guardians, or configuring critical contract addresses, there is no explicit require(newAddress != address(0)) check.

If an unintentional zero address is used, it may disrupt the intended functionality—particularly for calls that assume a valid contract or EOA (e.g., ERC20 or bridging adapters).

Found in:

- Base Strategy (Line: 99)

- ConfigurablePauseGuardian (Line: 86)

- WormholeBridgeAdapter (Line: 91)

- xERC20BridgeAdapter (Line: 55)

Whenever assigning an address to a state variable (especially for roles, ownership, or bridging logic), use confirm that the parameter passed to the setter is not the address(0).

ACKNOWLEDGED: The Moonwell team has acknowledged this finding.

In the Mamo.sol contract, there is a function named crossChainMint allowing the SUPERCHAIN_TOKEN_BRIDGE address to mint tokens by directly calling _mint. Unlike the normal mint function (which goes through xERC20.mint and enforces rate limits and a maxSupply check), crossChainMint does not apply these constraints.

As a result, if the sequencer mis-behaves, could exceed the intended cap of “1 billion tokens,” bypassing both:

• Rate-limit enforced by the MintLimits system.

• maxSupply check that normally prevents minting above a certain threshold.

This creates a discrepancy between the declared maximum supply and the actual token logic, undermining claims of a hard supply cap and subverting protections that limit inflation.

Route through Standard mint: Modify crossChainMint and crossChainBurn to invoke xERC20.mint (or super.mint) and xERC20.burn (or super.burn) so it inherits all rate-limit and max-supply checks.

Add Check: If a direct call is necessary, at least replicate the checks inside mint/burn functions, verifying (totalSupply + amount <= maxSupply) and calling depleteBuffer() for the SUPERCHAIN_TOKEN_BRIDGE address.

Document Intended Behavior: If you truly want to allow unlimited cross-chain minting for certain bridges, explicitly state this in the docs. However, that negates the premise of a “fixed supply.”

ACKNOWLEDGED: The Moonwell team has acknowledged the risk related to this finding, documenting that there is no rate limiting when minting on the sequencer itself, as it is trusted to be non-malicious.

The ERC20MoonwellMorphoStrategy.sol contract contains two instances of misleading or incorrect NatSpec documentation that contradict the actual implementation of the functions:

• In the setFeeRecipient function (line ~300), the NatSpec comment states:

  // @dev Only callable by the strategy owner

However, the function implements the onlyBackend modifier instead, allowing only the backend address to update the fee recipient, not the strategy owner.

• In the deposit function (line ~342), the NatSpec comment states:

     * Only callable by the user who owns this strategy

However, the function has no access control modifier, making it callable by any external address, not just the strategy owner.

It is recommended to update the NatSpec comments to accurately reflect the actual implementation.

ACKNOWLEDGED: The Moonwell team has acknowledged this finding.