Moonwell

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

Bug reports for web or app issues must include a PoC to be eligible for a reward. In the case of smart contract bugs, a PoC is necessary to confirm the bug's existence and calculate the potential impact if exploited.

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%

All web/app bug reports must come with a PoC with an end-effect impacting an asset-in-scope in order to be considered for a reward. Explanations and statements are not accepted as PoC and code is required. An invoice is required for payment to be made.

The Moonwell Foundation requires KYC and a sanctions screening to be completed by all researchers submitting a report before a bounty can be paid.

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.

• All issues reported in past audits are out of scope: https://docs.moonwell.fi/moonwell/protocol-information/audits

The following are known issues and therefore are out of scope:

• 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 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 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.
  • if Wormhole becomes malicious, it could prevent the Vote Collection contract from collecting votes by blocking a new valid proposal from being registered.
• 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.
• 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. Reports for critical and high severity issues will require the researcher to write a PoC to receive a payout on all critical or high severity issues.

Rewards for critical smart contract vulnerabilities are further capped at 10% of economic damage, with the main consideration being the funds affected in addition to PR and brand considerations, at the discretion of the team. However, there is a minimum reward of USD 100 000 for Critical bug reports.

Payouts are handled by the Moonwell team directly and are denominated in USD. Payouts will be done in USDC or USDT, at the discretion of the team.