Welcome to Moonwell's bug bounty repo

Smart Contracts:

Website & Applications

All web/app bug reports must include 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 are required. An invoice is required for the payment to be made.

Quick Links:

• Judging for C4 Bug Bounties
• Criteria for C4 Bug Bounties

Background on Moonwell

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, website and app with a focus on preventing:

• Loss of protocol or user funds
• Smart contract vulnerabilities
• Denial of service issues
• Infrastructure vulnerabilities
• Social media administrative control breaches

Further Technical Resources & Links

• Moonwell Docs: Our system documentation, subject to change. Link
• Moonwell Previous Audits: Our previous audits - Link
• Moonwell Website: Link
• Twitter: @MoonwellDefi
• Discord: https://discord.gg/moonwellfii

Scope & Severity Criteria

Websites and Applications

• Domain takeover for moonwell.fi

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%

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table.

Smart Contracts in Scope

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 made in USDC or USDT at the team's discretion.

Out-of-Scope

Known Issues

Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk. Every issue opened in the repo, closed PRs, previous contests and audits are out of scope.

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 thethis governance system straddles threetwo chains, it is important that the timestamps on allboth 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.

Previous Audits

All issues reported in past audits are out of scope and are not eligible for a reward https://docs.moonwell.fi/moonwell/protocol-information/audits.

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.
Known issues are out of scope, such as double voting assuming block timestamps between chains drift far enough apart

Specific Types of Issues

The following vulnerabilities are excluded from the rewards for this bug bounty program:

• Attacks that the reporter has already exploited themselves, leading to damage
• Attacks requiring access to leaked keys/credentials
• Attacks requiring access to privileged addresses (governance, strategist)
• 3rd party services (AWS, Datadog, etc)

Websites and Apps

• Theoretical vulnerabilities without any proof or demonstration
• Captcha bypass using OCR
• CSRF with no security impact (logout CSRF, change language, etc.)
• Missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”)
• Server-side information disclosure such as IPs, server names, and most stack traces
• Vulnerabilities used to enumerate or confirm the existence of users or tenants
• Vulnerabilities requiring unlikely user actions
• URL Redirects (unless combined with another vulnerability to produce a more severe vulnerability)
• Lack of SSL/TLS best practices
• DDoS vulnerabilities
• Attacks requiring privileged access from within the organization
• Feature requests
• Best practices

The following activities are prohibited by this bug bounty program:

• Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
• Any testing with pricing oracles or third party smart contracts
• Attempting phishing or other social engineering attacks against our employees and/or customers
• Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
• Any denial of service attacks
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty

Additional Context

Trusted 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, and a Governance guardian role that can pause governance in the event of a bridge compromise.

Miscellaneous

The Moonwell Foundation requires all researchers submitting a report to complete KYC and a sanctions screening 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.