Moonwell Bug Bounty Program

Moonwell is an open lending, borrowing, and decentralized finance protocol built on Base, Optimism, Moonbeam and Moonriver. Moonwell's multichain design brings the world onchain with simple, yet powerful financial tools. This bug bounty program is focused on their smart contracts.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Conditions. The combination of these factors determines the severity and guides the reward amount.

Severity Levels

Vulnerabilities will be classified according to the following severity levels:

• Critical
  • Direct theft of user funds without limitations of external conditions. The loss must exceed 10% of the affected party's funds and 100 USD.
  • Permanent freezing of user funds
  • Protocol insolvency
  • Unauthorized minting of tokens (>100 USD worth of tokens can be minted).
  • Permanent modification of protocol parameters leading to a significant loss
• High
  • Direct theft of user funds with moderate conditions. The loss must exceed 1% of the affected party's funds and 100 USD.
  • Temporary freezing of user funds (>7 days)
  • Theft of unclaimed yield (>100 USD at risk)
  • Permanent freezing of unclaimed yield
• Medium
  • Loss of funds requiring specific, extensive conditions. The loss must exceed 0.01% of the affected party's funds and 100 USD.
  • Smart contracts are inoperable due to a lock of funds
  • Griefing attacks
  • Incorrect interest rate calculations affecting protocol economics
• Web2
  • Issues leading to the domain takeover.

Impact Assessment

The severity level of a vulnerability will be determined based on both its impact and conditions:

• Impact Factors
  • Amount of funds at risk
  • Number of users affected
  • Duration of the vulnerability's effect
  • Complexity of exploitation
  • Requirement for privileged access
• Conditional Factors
  • Technical complexity of the exploit
  • Required preconditions for exploitation
  • Opportunity window for exploitation

Reward Structure

Reward Amounts

Rewards will be paid in USD-pegged stablecoins according to the following structure:

Severity Level	Reward Range
Critical	20,000 USD - 250,000 USD
High	10,000 USD - 20,000 USD
Medium	1,000 USD - 5,000 USD Gratuity range
Web2	1,000 USD - 5,000 USD

The payout for smart contract vulnerabilities depends on the amount of funds at risk due to the vulnerability. This, will be determined by the maximum value of funds at risk in the impacted contract(s) at the time of report submission

The following ratio will apply to the smart contract vulnerabilities payouts:

• Less than $5,000,000 - 10% of bounty for that category
• Between $5,000,000 and$10,000,000 - 25%
• Between $10,000,000 and$50,000,000 - 50%
• Between $50,000,000 and$250,000,000 - 75%
• Above $250,000,000 - 100%

Each reward level has a minimum reward that will be awarded to incentivise security researchers against withholding bug reports:

• Critical - 20,000 USD
• High - 15,000 USD
• Medium - 1,000 USD
• Web2 - 1,000 USD

General Notes

• Sherlock's Criteria for Issue Validity guide can be a helpful resource for more context on out-of-scope issues, etc. but nothing in the guide should overrule the definitions above
• A coded Proof of Concept (POC) with instructions to run the POC is required
• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage

Platform Rules

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Scope

For Web2 side, the websites moonwell.fi and mamo.bot are considered in scope.

Out of scope

• Chainlink feeds are assumed to operate correctly, remain available, and not deviate from expected behaviour. Incorrect data or pricing information supplied by third-party oracles is out of scope.
• Vulnerabilities that have already been reported or are known to the protocol team
• Issues that have been identified in previous audits and are pending fixes
• Vulnerabilities in the blockchain itself
• Issues in third-party libraries or dependencies not developed by the protocol team
• Theoretical vulnerabilities without a working proof of concept
• Issues requiring privileged access (e.g., governance or admin keys)
• Economic or tokenomic vulnerabilities that do not result in direct loss of funds
• Gas optimization issues without security implications
• Centralization risks inherent to the protocol design
• UI/UX issues that do not impact security
• Documentation errors or inconsistencies
• Spelling or grammar mistakes
• A one-block DOS — where the attacker causes a transaction to revert in a single block, but it can be successfully re-executed in the next block — is evaluated based on that single occurrence only, even if the attack is theoretically repeatable. Such an issue is presumed not to repeat. It qualifies as valid only if the affected functionality is clearly time-sensitive.

Known Issues

• Bug in Base Safety Module allows some users to claim the full reward budget from MIP-X28
• Borrowing rewards for markets where a reward speed is not set do not accrue without a user calling claim (or someone calling claimBehalf).
• When setting reward speed = 0 and turning it back on for a market, rewards will accrue as if the new rate was always on.
• Assets which are supplied which a user hasn’t called ‘enterMarkets’ for can still be seized. This is working as designed.
• New markets must be added with no collateral factor, and some small amount of the collateral token supply must be burned in order to avoid market manipulation. This is a known issue.
• Wormhole dependency: If wormhole goes offline, or pauses their relayer or wormhole core contracts, the Multichain Governor and Vote Collector will not be able to function. This is because the Multichain Governor passes messages to the Wormhole contract, and the Vote Collector receives messages from the Wormhole Relayer. If Wormhole is offline, on either chain, the system is considered broken and will not function.
• If users have proposals in flight, and the max user live proposals variable is updated to be less than its current value, the system invariant live proposals <= maxUserLiveProposals can be temporarily violated.
• Quorum can be updated to zero, and if it is, then a proposal with a single for
  vote can pass.
• Setting too high of a quorum also means that a proposal is unlikely to ever be able to pass. This is because the system will not be able to reach quorum, and all proposals will go to the Defeated state.
• Gas limit can be updated through a governance proposal, and if an external chain has their opcodes repriced higher, and the governance contract does not update its gas limit, then the system can be broken. This is because the system will not be able to process any transactions on the external chain, and the system will be unable to process any governance proposals. To mitigate this, the governor would use the break glass guardian to recover system ownership. Alternatively, a governance proposal could occur on Moonbeam to update the gas limit. However, users on Base would not be able to participate until this vote passed and the proposal was bridged to Base.
• Because the governance system straddles three chains, it is important that the timestamps on all chains are within one minute of each other to prevent issues around double voting. If an external chain has timestamps more than one minute behind Moonbeam, then a user could propose a change on Moonbeam, and then bridge their tokens to the external chain. This would mean once voting opened up, it would look like this user has double the voting power than they should have. This is because the system would register their votes on both Moonbeam and the external chain as valid.
• if the Pause Guardian is malicious, they could wait for a governance proposal to grant another guardian the ability to pause the contract, then pause the contract, clearing this proposal from the active set of proposals. Then the community would need to wait 30 days before they could create, vote on and pass another proposal again.
• if the vote collection contracts on other chains are malicious, they could prevent the Multichain Governor from executing proposals, or pass proposals that are failing by registering incorrect vote counts.
• if Wormhole is paused or offline, the Multichain Governor will still be able to execute and pass proposals, however, users on other chains will not be able to submit or have their votes collected.
• if Wormhole becomes malicious, it could register incorrect vote counts or prevent the Multichain Governor from executing proposals.
• Approved calldata is correctly set for the Break Glass Guardian. Incorrect calldata could allow the Break Glass Guardian to call any function on any contract. Side effects of incorrect configuration include but are not limited to:
  - complete loss of governance abilities on both Base, Optimism, and or Moonbeam deployments
  - setting of incorrect oracle data
  - arbitrary changes to governance parameters
• The block timestamp does not differ by more than 45 seconds between Moonbeam and the external chain:
  - at a larger time difference than 45 seconds, the vote collection contract is at risk of allowing users to register double votes by first voting on Moonbeam, and then bridging to and voting on an external chain.
• The Wormhole bridge is live and working properly.
• if Wormhole becomes malicious, it could prevent the Vote Collection contract from collecting votes by blocking a new valid proposal from being registered.
• if Wormhole is paused or offline, the Vote Collection contract will still be able to collect votes, however, votes will not be able to be sent to the Multichain Governor.
• No bounties will be paid for issues that arise from a governor turning malicious. Instead, the researcher must demonstrate how the code is vulnerable without using known issues and provide a working PoC of the exploit to demonstrate this vulnerability.
• Temporal Governor on Base cannot receive raw ether as it has no payable fallback function. This means reserves cannot be sent to it from the ETH market. This is a known issue.
• All issues reported in past audits are out of scope.

Disclosure Policy

All vulnerabilities must be reported exclusively through the Sherlock platform and must not be disclosed publicly until:

1. The vulnerability has been verified by the protocol team
2. A fix has been implemented and deployed
3. The protocol team has granted explicit permission for public disclosure
   Premature public disclosure can result in disqualification from the reward.

Testing

When testing for vulnerabilities:

• Do not test on public mainnet deployments
• Use local test environments or testnets for all testing
• Do not attempt to access or modify other users' data
• Do not perform any actions that could disrupt the normal operation of the protocol
• Do not use automated scanning tools without manual verification

Prohibited actions

The following actions are strictly prohibited:

• Attempting to access private user data
• Social engineering or phishing attacks
• Denial of service attacks
• Physical or electronic attempts to access protocol's infrastructure
• Any testing that violates applicable laws or regulations
• Threatening or harassing behavior
• Current and past contractors or employees of Lunar Labs, Solidity Labs, and Moonwell Foundation are not eligible for any rewards from this bug bounty program.

Additional Context

Chains in scope

Ethereum mainnet, Base, Optimisim, Moonbeam

Trusted protocol roles

The only trusted roles on Moonwell smart contracts are for the governor or DAO (admin/owner), pause guardian roles for the Moonwell security council, borrow and supply cap guardian roles, which are operated by the protocol's risk manager, and a Governance guardian role that can pause governance in the event of a bridge compromise.

Tokens

WETH, cbBTC, USDC, USDT, OP, wstETH, rETH, wBTC, DAI, cbETH, WELL.

Design choices

• We intentionally do not use Chainlink's L2 sequencer liveness oracle to pause liquidations. This is intentional to avoid creating additional risk of bad debt or insolvencies during sequencer outages.

Protocol Resources

• Moonwell Documentation
• Previous audits
• Website
• Moonwell's Public Repos