Moonwell Lending

Moonwell Lending is a Compound v2‑style, non‑custodial lending protocol deployed on Base, OP Mainnet (Optimism), and Moonbeam, with additional markets on Moonriver. Identification

• Name / Category: Moonwell (often “Moonwell Lending”); category: over‑collateralized lending/borrowing protocol, Compound v2 fork.
• Website: Commonly cited as moonwell.fi (exact URL not reproduced here).
• Docs: Hosted under a Moonwell docs site providing protocol overview and token/contract tables.
• Chains: Base, OP Mainnet (Optimism), Moonbeam, Moonriver; most recent analytics show dominant usage on Base, with smaller markets on Optimism and Moonbeam.
• Launch history: Initially built on Moonbeam (Polkadot ecosystem) and later expanded to Base and Optimism. Precise launch dates per chain are Not verifiable as of 2026‑08‑29.
• Native/governance token: WELL is the native/governance token, with multichain deployments and governance increasingly centered on Ethereum via xERC20 xWELL and a Safety Module. Key contract addresses (cross‑checked via docs + explorers + analytics)
• WELL token – Base: 0xA88594D404727625A9437C3f886C7643872296AE, documented in Moonwell docs and shown as an ERC‑20 on Base explorer.
• WELL token – OP Mainnet: Same address 0xA88594D404727625A9437C3f886C7643872296AE on Optimism explorer, matching docs.
• WELL token – Moonbeam: 0x511Ab53f793683763E5A8829738301368A2411E3 per docs and Moonbeam explorer.
• Main lending market contracts (cTokens / mTokens like mUSDC, mWETH, mOP, mwstETH) are described as Compound‑style interest‑bearing tokens, but exact market contract addresses per asset are Not verifiable as of 2026‑08‑29 from at least two independent sources in the retrieved data.
• Explorer verification: WELL token contracts above are standard ERC‑20 contracts with verified source code on their respective explorers; broader protocol markets appear verified but full coverage is Not verifiable as of 2026‑08‑29. Fork lineage & modifications
• Multiple independent sources classify Moonwell explicitly as a Compound v2 fork.
• Documented changes vs. upstream Compound v2 include:
• Borrow/supply caps per market.
• Cross‑chain deployment and governance, with WELL/xWELL and an Ethereum Safety Module coordinating markets across Base, Optimism, Moonbeam, Moonriver.
• Multi‑token reward system and consumer‑facing products (e.g., cards) layered on top of lending markets.
• Audit status of changes: Specific audits for Moonwell’s forked and modified contracts (names, dates, auditors, scope) are Not verifiable as of 2026‑08‑29 based on the retrieved data; protocol claims about audits would therefore be unverified marketing claims unless corroborated by auditor‑hosted reports.
• Malicious‑modification history in similar forks: No explicit record of Moonwell itself being a malicious fork; however, the protocol experienced $1.8M bad debt from an oracle misconfiguration, indicating operational and oracle‑risk rather than malicious code changes. Broader statistics on malicious Compound‑fork incidents in other projects are Not verifiable as of 2026‑08‑29 within the retrieved set. Contradiction check
• Several analytics platforms agree on chain coverage (Base, Optimism, Moonbeam, Moonriver) and classification as a Compound v2‑style lending protocol. Without direct on‑chain querying available, any discrepancy between on‑chain TVL/markets and these figures is Not verifiable as of 2026‑08‑29.

Moonwell Lending appears to be a real, live product rather than a pure landing page: Moonwell’s docs include a dedicated lending page and developer documentation, and third-party references describe an active app for supply/borrow actions with markets, wallet connection, and position/rate reads. The ecosystem/docs also point developers to an SDK and integrations, which suggests product maturity beyond marketing-only pages. Open API: yes, but it is best described as a developer-facing HTTP/API layer plus SDK, not a fully public consumer API catalog. The docs explicitly reference the Moonwell SDK, LLM-readable SDK docs, and an HTTP GET pattern for querying page docs; Base’s documentation also states Moonwell uses an HTTP API for reads and transaction preparation. What is verifiable from web sources: there are live docs, help pages, SDK docs, and app references for supply/borrow flows, plus support material that matches an operational lending product. What is not verifiable as of 2026-08-29: live deposits/withdrawals at this moment, broken-link rate, fake metric prevalence, or whether the current production portal still has template artifacts, because those require direct app inspection and/or on-chain verification. No web evidence in this pass indicates Moonwell is just a template landing page; instead, the source set points to an established protocol with documentation, app access, and integration surfaces.

Independent security review found 7 medium-severity issues; all were marked fixed in the report. The reported medium findings were: missing proposal-queue bypass check, inability to liquidate deprecated market, unsafe transfer()/transferFrom() use, insufficient oracle validation, missing L2 sequencer checks, owner single-point-of-failure risk, and zero-value transfer reverts.

A Code4rena audit page exists for Moonwell, but the provided search result does not expose the finding counts or fix-status details needed to verify critical/high/medium totals from the snippet alone.

Audit report covers 4626 Vaults.

Audit report covers xWELLRouter, MultichainGovernor, and MultichainVoteCollection.

Audit report covers Moonwell’s Auctions contracts.

Audit report covers Moonwell’s MultiRewards contracts.

Moonwell does have an active bug bounty program as of the latest available source material: Sherlock lists the Moonwell Bug Bounty as LIVE and last updated Jul 16, 2026. The program appears to have started on Jul 16, 2026 on Sherlock, following a prior bounty run with Code4rena reported in Jan 2025. Parameters:

• Reward cap: up to $250,000 for critical issues.
• Platform: Sherlock for the current live program.
• Scope/award sizing: the GitHub bounty repo says payout sizing is determined by the maximum value of funds at risk in the impacted contract(s) at the time of report submission.
• Public-facing Moonwell docs also describe the bounty as rewarding researchers for discovering and responsibly disclosing vulnerabilities. Results:
• The available sources do not provide a clear public tally of total submissions, paid rewards, or confirmed findings from the current Sherlock program.
• Not verifiable as of 2026-08-29 whether the current program has produced any paid disclosures or successful claims. History / contradiction:
• Search results conflict on the bounty platform history: some sources describe a Code4rena bounty launch in Jan 2025, while the current live program is on Sherlock in Jul 2026.
• Some third-party commentary claims an earlier Immunefi program was removed in Feb 2025, but that is not confirmed by the higher-confidence sources provided here.

Moonwell is a multi-chain, overcollateralized lending protocol deployed on Base, Moonbeam (Polkadot ecosystem), and Optimism. Key external dependencies and counterparty risks are below. Not verifiable as of [2026-08-29] for any on-chain-specific metrics. 1. Money Market & Protocol Dependencies

• Core design is Compound-style pools using external assets (ETH, stablecoins, LSTs) as collateral; risk is inherited from each underlying token (depeg, insolvency, governance attacks).
• On Moonbeam, Moonwell historically integrated with Lido stETH, GLMR and other local assets; on Base/Optimism with WETH, USDC, stablecoins, LSTs. 2. Oracles & Price Manipulation Risk
• Moonwell states that it uses Chainlink price feeds for asset pricing and liquidation logic, with “multiple decentralized oracle networks” per asset.
• Oracle dependence creates risk if:
• Chainlink feeds fail, lag, or are attacked.
• Liquidity is thin on reference markets, enabling price manipulation.
• Protocol mentions use of supply caps, collateral factors, and isolated markets to limit oracle/manipulation blast radius, but this is an unverified marketing claim. 3. Bridges & Cross-Chain Risk
• Chain exposure:
• Base depends on Ethereum–Base bridging infra and Coinbase-operated sequencer.
• Optimism depends on Ethereum–OP bridges and Optimism sequencer/governance.
• Moonbeam depends on Polkadot XCMP and any third-party bridges used to import assets (e.g., ETH derivatives, stablecoins).
• If a bridge is exploited or a rollup halts/reorgs, Moonwell markets on that chain can become insolvent or frozen even if contracts are safe. 4. Stablecoin & LST / Restaking Exposure
• Key stablecoin risk: USDC, USDT, DAI or chain-specific stables used as collateral/borrow assets could depeg (regulatory, reserve, governance failure).
• LST risk: integration with stETH/LSTs exposes users to Ethereum staking slashing, LST depeg, or governance failures of LST protocols.
• Any restaked/LRT assets (if supported on Base/OP) add operator-set risk and EigenLayer-style rehypothecation risk (Not verifiable as of [2026-08-29]). 5. CEX / Market Maker & RWA / Custodian Exposure
• Indirect exposure via:
• Stablecoins backed by Circle, Tether and their banking/custodian chains.
• Any RWA tokens (treasuries, credit) if listed in markets: issuer/SPV default, regulatory seizure, NAV mismatch (Not verifiable as of [2026-08-29]).
• Liquidity on CEXs and major DEXs is critical; extreme volatility or MM withdrawal can cause cascading liquidations when oracles reflect rapid price moves. 6. Failure Scenarios
• Major oracle malfunction → mispriced collateral, wrongful liquidations or bad debt.
• Stablecoin/LST depeg → undercollateralization and systemic bad debt in affected pools.
• Bridge exploit or rollup downtime → frozen positions, stuck liquidations, potential insolvency.
• RWA or centralized issuer default → value collapse of associated tokens.

Moonwell is organized as a non-custodial lending protocol: users keep control of their private keys, and deposits are handled by smart contracts rather than a company wallet or intermediary. On supported markets, users supply assets into on-chain liquidity pools and receive interest-bearing mTokens that represent their position; borrowers post collateral and the protocol enforces borrowing, interest, and liquidation rules automatically through smart contracts. Governance is separate from user custody: WELL holders can vote on protocol proposals, and the protocol’s safety module can stake WELL to backstop certain shortfalls, but this does not mean Moonwell takes custody of user funds. For Moonwell’s Morpho vaults, custody is still non-custodial at the protocol level, but allocation and risk controls are delegated to a role-based setup involving the Moonwell DAO, curators, allocators, and a guardian.

On Feb. 15, 2026, Moonwell incurred about $1.78M in bad debt after a governance-driven oracle configuration error mispriced cbETH on Base and Optimism; the protocol reduced the affected cbETH Core Market supply and borrow caps to 0.01 while a governance/timelock fix was prepared, and no other markets on Base or OP Mainnet were reported affected.

On Aug. 27, 2026, Moonwell’s Base Core Markets were hit by a MAMO collateral price-manipulation exploit; reports estimated losses at about $8.7M, and Moonwell responded by setting borrow caps across Base Core Markets to 1 wei, including MAMO and WELL supply caps to 1 wei, to stop further borrowing.

Moonwell’s core lending markets are organized as a non-custodial Compound v2-style system: users interact through mToken contracts for supply/borrow/repay/withdraw actions, while the Comptroller enforces collateral, account-health, and risk parameters behind the scenes. Protocol governance is token-based: WELL holders can govern via the Moonwell Artemis Governor, and proposals are queued through a timelock that ultimately affects the mToken and Comptroller contracts. For Moonwell’s Morpho vaults on Base, key management is more explicitly role-based: Moonwell DAO is the owner, Block Analitica and B.Protocol act as curator/allocator, and the Moonwell Security Council serves as guardian with veto power within a timelock period. In practical terms, this means operational control is split between onchain market contracts, governance token holders, and a security-council/timelock layer rather than a single admin key. What is not verifiable as of 2026-08-29 from the available sources is the exact current signer setup, multisig threshold, or whether any emergency admin keys differ by chain (Base, Moonbeam, OP Mainnet).

Moonwell is a cross-chain lending market using Compound-style cTokens; protocol-level safety depends heavily on admins/governance for each deployment. All on-chain specifics are Not verifiable as of 2026-08-29. ### 1. Contract ecosystem & verification

• Core components per chain:
• cToken/market contracts (per asset)
• Comptroller (risk & market config)
• Price oracle
• Interest rate model contracts
• Governance/multisig (Moonwell Apollo & Artemis deployments on Moonbeam, Base, OP)
• Public docs and explorers indicate contracts are verified on respective chains (Moonbeam, Base, OP) but full address maps and verification status for all markets are Not verifiable as of 2026-08-29. ### 2. Upgradeability / admin architecture
• Moonwell follows Compound-style architecture where Comptroller and cTokens are upgradeable via admin/governance, allowing parameter changes and market configuration. Exact proxy pattern (EIP-1967, Transparent, UUPS) per chain is Not verifiable as of 2026-08-29.
• Governance is described as community-governed via Moonwell tokens with proposals and timelocks on Moonbeam, and multisig-controlled upgrades on newer chains (Base, OP) during growth phase. Detailed timelock delays and on-chain enforcement are Not verifiable as of 2026-08-29. ### 3. Roles & powers (conceptual) Typical roles inferred from Compound-style markets and Moonwell docs:
• Admin/Governance can:
• Add/remove markets, change collateral factors, caps, reserve factors, interest rate models.
• Change oracles and pause actions (mint/borrow/repay/liquidate) via Guardian-style role.
• Upgrade implementations / migrate markets.
• Pause Guardian / Emergency roles: can quickly pause risk-sensitive actions but usually cannot seize user deposits directly. Exact guardian addresses and renounce status are Not verifiable as of 2026-08-29. ### 4. User exit, worst case & rug/freeze risk
• Users can normally redeem supplied assets as long as: their account is solvent and the market has liquidity; this does not require admin intervention per transaction.
• If admin/guardian keys are compromised, plausible worst cases (based on typical Compound forks):
• Malicious parameter changes (collateral factors, caps, reserves) causing forced liquidations or making borrows unsafe.
• Oracle replacement or config manipulation leading to mispriced collateral and mass liquidations.
• Contract upgrades to hostile implementations, including fee skimming or disabling redemption.
• Global pauses of mint/borrow/repay that indirectly freeze positions; if redemption is also pausable, funds can be frozen until governance recovers. ### 5. Architecture map (conceptual)
• User ↔ cToken (per asset) ↔ Comptroller ↔ Oracle
• Admin / Governance / Multisig / Timelock → controls Comptroller, cToken params, oracle selection and upgrades. Given missing on-chain detail and exact role addresses, Moonwell presents meaningful smart-contract and admin risk, especially around upgradability, oracle control, and pausing powers. Many specifics remain Not verifiable as of 2026-08-29.

Moonwell appears to have a real operating team rather than an anonymous, purely web-front project. Public sources consistently identify Luke Youngblood as the founder; Moonwell docs say the protocol is supported by Lunar Labs founding contributors, including Youngblood, and describe him as a former Coinbase Sr. Staff Engineer and AWS Principal Engineer, with work on Coinbase staking rewards, Tezos validator infrastructure, and the Coinbase price oracle. LinkedIn and secondary profiles also place Youngblood in the San Francisco Bay Area and list him as CEO/founder of Lunar Labs / Moonwell. The main credibility signal is that the team has named contributors and visible engineering history, not an anonymous dev set. The main caution is that several of the strongest business-identity claims are *not fully verifiable here*: one analytics listing says Moonwell was founded in 2021 and headquartered in Finland, while a Kraken-linked statement says the Moonwell Foundation is registered in the Cayman Islands. That combination suggests an offshore legal structure may exist, but the exact corporate setup is not verifiable as of 2026-08-29. There is also a meaningful risk-history signal: independent coverage in 2026 reported a Moonwell exploit tied to vulnerable oracle/pricing code, and other coverage describes prior hack incidents, which indicates the protocol has had operational failures rather than only marketing presence. I could not verify a real office location or onshore operating base from reliable primary sources, so that remains Not verifiable as of 2026-08-29. Reality check: Moonwell looks like a substantive DeFi business with identifiable founders and engineering contributors, but its legal domicile and physical-office footprint are unclear from the sources available; treat the protocol as a real operating project with documented hack risk, not as a trustless black box, and not as a fully transparent onshore company.

Moonwell Lending currently has a moderate-risk but generally positive reputation, characterized by multiple audits and credible backers, alongside a recent oracle-related bad‑debt incident that remains a key concern. Founders, team, and investors

• The project is led by founder Luke Youngblood, with the operating entity Moonwell Foundation registered in the Cayman Islands.
• Founding contributors include Lunar Labs (Youngblood and other engineers), plus risk and technical partners Gauntlet, Warden Finance, Rome Blockchain Labs, and VectorDAO.
• Advisors include 0xMaki (SushiSwap co‑founder) and others with prior Coinbase and infrastructure backgrounds.
• Moonwell reportedly raised $10M from funds such as Arrington XRP Capital, Mirana Ventures, Lemniscap, Woodstock, Robot Ventures, Signum Capital, and others, plus $13M via a public ICO on Tokensoft. Audits and security posture
• Independent risk review sites note Moonwell has multiple audits (claims of 11 audits vs. 2 referenced by other analytics, indicating some inconsistency in count).
• Auditors and reviewers include Halborn, code4rena, and independent researcher 0xVolodya, among others.
• The July 2023 code4rena audit found 17 medium-severity and numerous low/non‑critical issues, with no high‑severity findings, which aligns with a reasonably mature but not flawless codebase.
• 0xVolodya’s report highlighted centralization risks (single‑owner, oracle validation, sequencer checks), which were reportedly addressed. Incidents, criticisms, and sentiment
• In February 2026, Moonwell incurred about $1.78M–$1.8M in bad debt due to an oracle misconfiguration that mispriced cbETH on Base, causing mass liquidations; this is widely cited in crypto security summaries.
• Risk assessment outlets rate Moonwell as moderate risk (e.g., “BBB / 69/100”), reflecting protocol complexity, governance design, and cross‑chain mechanisms.
• External risk commentary flags governance centralization, bridge dependence (Wormhole‑based cross‑chain governance), and oracle/configuration risk as ongoing areas to monitor. Fraud/rug/insolvency, legal and sanctions
• There are no public allegations of fraud, rug pull, or deliberate malfeasance tied to Moonwell or its founders in the reviewed material.
• No references were found to regulatory enforcement actions, sanctions listings, or insolvency proceedings specific to Moonwell.
• On-chain verification of ownership structures, treasury, or cross‑chain exposures is Not verifiable as of 2026-08-29. Unresolved concerns
• Key unresolved reputational risks:
• Demonstrated oracle/config mis‑risk (cbETH incident) and potential recurrence if processes are not tightened.
• Governance centralization and bridge reliance remain structural concerns despite audits and multisig setups.
• Audit-count discrepancy (11 vs. 2 referenced) suggests documentation and transparency around security reviews could be improved.

Moonwell Lending’s reserves/treasury are not fully verifiable from the provided sources, and I cannot confirm a single protocol treasury size, custody setup, or reserve-policy balance sheet across Base, Moonbeam, and OP Mainnet. The only directly relevant, non-protocol source here is a report that cites a cbETH reserve/repayment plan for Moonwell, but it is about a specific bad-debt episode rather than a complete treasury disclosure. What can be said with confidence is limited:

• No on-chain reserve/balance audit is verifiable as of 2026-08-29 because Dune/on-chain tooling is unavailable in this run, so treasury addresses and balances cannot be checked.
• The available reporting indicates a cbETH shortfall on Base and a proposed reserve allocation that left $0 for cbETH repayment, implying that reserves were insufficient or earmarked elsewhere for that market, but it does not establish the protocol’s total treasury composition.
• DefiLlama shows Moonwell’s TVL is multi-chain, with exposure concentrated on Base, then OP Mainnet and Moonbeam; however, TVL is not the same as treasury and should not be treated as reserve assets. Because the question asks for size, addresses, composition, custody, on-chain balances, control, reserve policy, and attestations, the unresolved items are Not verifiable as of 2026-08-29: reserve wallet addresses, treasury controllers/multisigs, reserve asset composition, chain-by-chain balances, and any external attestations or proof-of-reserves statement.

Moonwell does have a native token, but with different tokens per chain:

• Moonbeam: native token WELL (ERC‑20 on Moonbeam)
• Base & OP Mainnet: native token MFAM (Moonwell Artemis) On-chain verification
• Direct on-chain checks via Dune MCP are Not verifiable as of 2026‑08‑29.
• All supply, holders and unlock execution status below rely on aggregators and explorers, not raw chain. ### Token identifiers MFAM (Base, OP)
• Ticker: MFAM.
• Base contract (per explorer/aggregators, cross-referenced to Moonwell docs): Not verifiable as of 2026‑08‑29 (exact checksum address cannot be confirmed without on-chain tools). WELL (Moonbeam)
• Ticker: WELL.
• Moonbeam contract: Not verifiable as of 2026‑08‑29 (explorer data cannot be cross‑checked with Dune). ### Supply, market cap, FDV Because this run has no Dune and price aggregators are the only source:
• Total and circulating supply, market cap, FDV for WELL and MFAM: Not verifiable as of 2026‑08‑29. Any figures shown on CoinGecko/CoinMarketCap or DeFiLlama are aggregator estimates, not on‑chain verified. ### Utility and governance From Moonwell docs and independent reviews (treated as *unverified marketing claims* unless matched to code):
• WELL/MFAM are governance tokens used for protocol voting and risk parameter decisions.
• Tokens are used as liquidity mining rewards for lenders/borrowers in Moonwell markets.
• Staking/locking in governance modules may earn protocol incentive rewards, but exact APRs and mechanisms are Not verifiable as of 2026‑08‑29. ### Revenue share, buybacks, burns
• No credible independent evidence of systematic revenue share, buyback, or burn mechanisms tied to WELL/MFAM beyond potential discretionary treasury actions.
• If mentioned in Moonwell marketing, treat as unverified marketing claim. ### Emissions & unlocks
• Emissions schedules, vesting, and unlock calendars shown in tokenomics charts are unverified marketing claims unless tied to on‑chain vesting contracts, which cannot be inspected via Dune here.
• Whether historical unlocks (team/investor) actually executed on-chain is Not verifiable as of 2026‑08‑29. ### Allocations & holders
• Claimed allocations (team, investors, community, treasury) exist in tokenomics diagrams in Moonwell docs, but remain unverified marketing claims.
• Top-holder concentration, insider wallets, and their share cannot be reliably assessed without on-chain holder distribution queries: Not verifiable as of 2026‑08‑29. ### Contract controls & risk levers
• Presence of mint, blacklist, or fee-switch functions and their controllers can only be confirmed by reading verified contract source and ABI; without Dune/contract inspection, this is Not verifiable as of 2026‑08‑29. ### DEX liquidity & listings
• WELL and MFAM are reported listed on major DEXs on their respective chains (Base, Moonbeam, OP) and some CEXs, but depth, pools, and pair dominance are Not verifiable as of 2026‑08‑29 from raw on-chain data. Given these tooling constraints, any numeric tokenomics figures you see off-chain must be treated as aggregator estimates or unverified marketing claims, not on‑chain facts.

A BTC drop below $10,000 would likely stress Moonwell through wrong-way risk on BTC-linked collateral and liquidity pressure on BTC-heavy markets, but the exact solvency impact is not verifiable as of 2026-08-29 from the available sources. Moonwell’s own forum risk note says collateral is “overwhelmingly crypto-native,” especially ETH and BTC derivatives, and that these assets are “liquid and low-stress but structurally exposed to wrong-way risk during BTC price declines.” The most relevant public evidence of protocol fragility is past oracle-driven stress: Moonwell reported about $1.78M in bad debt after a cbETH pricing configuration error caused liquidations at a wildly distorted price, and another Moonwell incident reported about $8.7M lost when a Base token was mispriced upward, allowing excessive borrowing. Those events show that in a severe BTC crash, the main failure mode would be oracle mispricing + rapid liquidations, not just ordinary market volatility. For the three requested chains, the available sources do not provide chain-by-chain exposure or current collateral composition for Base, Moonbeam, and OP Mainnet in a way that is directly verifiable here. Therefore, the % of exposure per chain is not verifiable as of 2026-08-29. Moonwell’s risk discussion also notes that borrowing is concentrated in stablecoin markets, which can amplify stress if BTC collateral falls and borrowers are forced toward liquidation. Practical stress interpretation:

• Base: likely highest near-term risk if BTC-backed collateral is concentrated there, because prior bad-debt events on Moonwell’s Base market show fast liquidation cascades can outpace protections.
• Moonbeam: stress depends on whether BTC derivatives are material collateral there; no chain-specific exposure was verifiable from the provided sources.
• OP Mainnet: same limitation; no chain-specific BTC exposure or reserve data was verifiable here. Because on-chain verification is unavailable in this run, the conservative institutional view is that a BTC print below $10k would be a high-severity stress event for Moonwell, with the key questions being oracle integrity, collateral concentration, and whether liquidations can be executed before bad debt forms.

Moonwell’s own docs define the collateral factor as the maximum percentage of an asset’s value that can be borrowed against it, and note that a 0% collateral factor disables borrowing for that asset. In the current stress scenario, if the largest collateral asset depegs by 20%, the immediate effect is a 20% mark-to-market loss on that collateral’s value before any liquidation dynamics are considered. For a clean worst-case readout, the protocol-level loss is concentrated in positions that are already highly levered against that asset. If the affected collateral is the largest one by dollar exposure, then the protocol faces elevated liquidation risk because Moonwell’s risk guidance ties safe operation to collateral factor headroom versus drawdown and liquidation costs, including the liquidation incentive. Moonwell has also experienced a real-world oracle-driven bad debt event on cbETH, showing that price shocks can translate into unrecoverable debt when liquidations cannot clear fast enough. By chain, the largest collateral depeg exposure is not verifiable as of 2026-08-29 from the provided sources alone, because no up-to-date chain-by-chain collateral composition or TVL breakdown was included. Therefore, the stressed bad-debt amount from a 20% depeg is also not verifiable as of 2026-08-29 without the current collateral inventory, per-chain exposure, and live borrow/liq data. What can be stated conservatively is:

• 20% depeg on the largest collateral implies at least a 20% value haircut on that collateral.
• If the collateral factor is near the asset’s current risk limit, the depeg can push many accounts toward liquidation or underwater status.
• Whether that becomes protocol bad debt depends on liquidation speed, market liquidity, oracle quality, and reserves; Moonwell’s governance discussion and past cbETH incident show those variables matter materially. If you want, I can turn this into a per-chain stress template for Base, Moonbeam, and OP Mainnet using the exact collateral asset once you provide the largest-collateral name or a current market snapshot.

Moonwell Lending’s insolvent-top-counterparty loss path is primarily a borrower-default / bad-debt path, not an automatic socialized-loss mechanism. If a top counterparty becomes insolvent, liquidators first attempt to seize collateral through liquidation; Moonwell’s docs describe a 7% liquidator bonus and 3% reserve allocation, with liquidations intended to maintain solvency. If collateral value is insufficient, the shortfall becomes bad debt. Who absorbs the loss:

• First: the insolvent borrower loses collateral and position value through liquidation.
• Second: if the liquidation does not fully cover the debt, the protocol’s reserves are the primary backstop.
• Third: if reserves are insufficient, governance can approve use of additional reserves or a debt-repayment / write-off process; Moonwell’s remediation materials describe repaying bad debt with reserves or user-supplied cash, and writing off remaining debt so interest stops accruing. Compensation path:
• Liquidators are compensated with the liquidation bonus, and a portion of liquidation incentive accrues to protocol reserves.
• In prior bad-debt remediations, governance proposals used protocol reserves to repay affected positions and, where possible, compensate impacted users. Smart-contract impact path:
• The borrow enters liquidation once collateral coverage fails; the liquidation flow repays debt and transfers collateral.
• If the account remains undercollateralized after liquidation, the residual debt sits as bad debt and can be resolved by reserve-funded repayment or write-off.
• Moonwell’s Compound V2-style contracts therefore rely on liquidation mechanics + reserves + governance remediation rather than insurer-style third-party coverage. Chain-specific exposure:
• The sources found show incidents and remediation proposals on Base most clearly; for Moonbeam and OP Mainnet, chain-specific bad-debt exposure is Not verifiable as of 2026-08-30 from the gathered sources.

For the stress scenario “committed fraud by the DAO or owners,” Moonwell does not have clear public evidence of a proven DAO/owner fraud case in the materials reviewed. The strongest available records instead show governance-risk and malicious-proposal concerns: a reported governance attack on Moonwell nearly advanced a proposal that could have granted control over core contracts, but it was described as a thwarted attack rather than executed fraud. A separate Medium post alleges Moonwell and Frax planned to misappropriate user assets through a DAO vote, but this is an unverified allegation from a single partisan source and is not corroborated by independent reporting or official/legal findings in the provided results. By contrast, other incidents involving Moonwell in the results are oracle/configuration failures or bridge-related collateral issues, not committed fraud by the DAO or owners. Risk interpretation: for this specific stress scenario, the appropriate assessment is not verifiable as of 2026-08-29. If you need a model input, I would treat this as low-confidence / unconfirmed rather than a confirmed fraud scenario, with the main concern being governance capture or malicious proposal execution, not established fraud.

Moonwell Lending’s primary yield source is the base APY earned by supplying assets into its money markets; Moonwell’s docs describe supply APY as made up of Base APY + Rewards, with Base APY being the automatically compounding interest paid to lenders. In a negative 30-day stress scenario, the primary yield source would be negative or near-zero base APY, meaning supply-side yield from lending activity is insufficient to offset protocol mechanics and may be further reduced by any absent or lower rewards component.

Moonwell is formally governed by WELL and MFAM token holders via the Moonwell DAO and Moonwell Apollo DAO, using a mix of on‑chain and Snapshot voting; however, the actual distribution of voting power, top holders, and voting concentration is Not verifiable as of 2026-08-29 due to lack of on‑chain analytics access. ### Governance structure & control

• Protocols covered: WELL governs Moonwell on Base, OP Mainnet, Moonbeam; MFAM governs Moonwell Apollo on Moonriver.
• DAO constitutions: The Moonwell DAO and Moonwell Apollo DAO constitutions define tokenholder control over protocol authorization and management, positioning DAOs as the primary decision-makers.
• Proposal process: Token holders (or their delegates) submit Moonwell Improvement Proposals (MIPs); proposals are discussed in the Moonwell Governance Forum and then voted on via the gov.moonwell.fi portal (on‑chain) or Snapshot.
• Delegation: WELL can be delegated, giving governance power to representatives; 1 WELL generally equals 1 vote, including held, staked, or delegated amounts. ### Cross‑chain / Temporal governance
• Governance is implemented via a multichain governor architecture: a main governor contract (historically on Moonbeam) plus vote‑collection contracts on other chains.
• The newer Temporal Governance framework uses Wormhole messaging to “teleport” approved proposals from the governance hub chain to Base and other deployments for execution, aiming to keep control with the DAO while enabling cross‑chain upgrades.
• In 2026, governance was migrated to be anchored to Ethereum mainnet, with WELL staked in a Safety Module yielding stkWELL for voting and rewards, and decisions executed across Base, Optimism, and Moonbeam lending markets. ### Multisig, timelocks, and operational control
• Specific details on timelock durations, multisig addresses, signer identities, thresholds, and what powers remain with multisigs vs. direct DAO execution are Not verifiable as of 2026-08-29.
• The docs and grant materials emphasize “fully open and decentralized” governance and community control, but this is an unverified marketing claim pending on‑chain review of multisig roles and timelocks. ### Company / legal entity and frontend control
• References to “Moonwell” and “Moonwell Labs” exist in media and ecosystem docs, but concrete data on any incorporated entity (jurisdiction, registration number, directors), as well as who controls the frontend domains and branding, are Not verifiable as of 2026-08-29. ### Voting concentration & large holders
• Distribution of WELL/MFAM, top holders, delegation patterns, and effective voting concentration across Base, Moonbeam, OP Mainnet, and Moonriver are Not verifiable as of 2026-08-29. ### Governance robustness
• Governance attack coverage in 2026 indicates governance-sensitive risk, especially on Moonriver where MFAM is the voting asset, confirming that practical control can be contested via token accumulation.

Moonwell is a permissionless, non‑custodial lending protocol deployed on Base, Moonbeam, Optimism (OP Mainnet) and Moonriver; users interact directly with smart contracts and retain control of their assets. Not verifiable as of 2026‑08‑29: exact legal entities, jurisdictions of incorporation, and any formal regulatory licenses. ### Legal structure & governance vs. user risk

• Moonwell is governed by a Moonwell DAO with a published DAO Constitution that sets out roles, governance process, and conduct rules.
• A separate Moonwell Foundation administers some off‑chain processes (e.g., grants, KYC/AML for proposers), indicating at least one formal legal entity, but its jurisdiction is not specified in the retrieved documents.
• Governance decisions (e.g., risk parameters, treasury grants) can materially affect protocol solvency and user positions, yet tokenholders and delegates are not regulated fiduciaries. ### KYC/AML and user access restrictions
• The core lending/borrowing interface is described as open, decentralized, permissionless, with no mention of end‑user KYC/AML in the docs reviewed; this strongly suggests no KYC for ordinary protocol users (wallets interacting with smart contracts).
• In contrast, the DAO grants process explicitly requires KYC/AML: proposers whose governance proposal passes on‑chain and Security Council review must complete KYC and AML verification administered by the Moonwell Foundation before treasury funds are disbursed.
• The DAO Constitution requires participants to comply with “Applicable Laws and regulations” and to avoid illegal activity or facilitating it through the DAO. This shifts compliance obligations to users/participants rather than Moonwell offering regulated onboarding. ### Terms, disclaimers, and classification
• The DAO Constitution functions as a quasi‑ToS for governance participants, emphasizing:
• Self‑custody and protocol‑level risk (liquidations, parameter changes, and smart‑contract risk are implicit in documentation about collateral factors and liquidations).
• No explicit representation that Moonwell is a regulated financial service; it is framed as a DeFi protocol enabling over‑collateralized lending and borrowing.
• Kraken’s UK crypto‑asset statement describes WELL as a governance token for a decentralized lending protocol spanning multiple chains, positioning it as a crypto‑asset used for protocol governance and incentives, not as a claim on a legal entity’s assets or returns. ### Regulatory actions, warnings, sanctions, data protection
• No public regulator warnings, enforcement actions, or sanctions specific to Moonwell, the Moonwell DAO, or the Moonwell Foundation were identified in the retrieved materials. Not verifiable as of 2026‑08‑29 whether any exist in non‑indexed or paywalled registries.
• No explicit privacy policy or data‑protection framework surfaced; as a smart‑contract protocol, user activity appears limited to on‑chain addresses, but front‑ends may collect web analytics or other data. Not verifiable as of 2026‑08‑29. ### Observed governance / operational risk with legal implications
• Moonwell has faced both a governance attack attempt (unverified proposal warning on Moonriver) and price‑manipulation driven incident on Base (MAMO) leading to a temporary halt of new lending. These show the protocol is operationally adjustable by governance and risk managers, but they also highlight market‑manipulation and governance‑capture risks that are not covered by traditional investor protections or deposit insurance.

Yes—but the stablecoin depeg angle is only clearly verifiable for Moonbeam, not for Moonwell’s Base/OP Mainnet markets from the provided sources. On Moonbeam, Moonwell documentation/reporting says that after the Nomad bridge hack on August 1, 2022, bridged assets such as USDC.mad lost their peg, and Moonwell paused deposits and borrows to limit bad debt. That source does not quantify the depeg percentage, and from the available results it is not verifiable as of 2026-08-29 how many separate stablecoin depeg events Moonwell itself experienced across Base, Moonbeam, and OP Mainnet, or what the exact last depeg percentage was. What is verifiable from the results is:

• At least one depeg event affecting a stablecoin used in Moonwell’s ecosystem occurred on Moonbeam on 2022-08-01 (USDC.mad and other bridged assets lost peg after the Nomad exploit).
• The provided sources do not establish any additional, clearly documented stablecoin depeg events for Moonwell on Base or OP Mainnet.
• The results that do mention Moonwell’s more recent incidents describe oracle misconfigurations / bad debt events, not stablecoin depegs. If you want, I can next separate this by chain and list the exact stablecoin/bridged-asset used on each Moonwell market, but the depeg count and last depeg % remain not verifiable from the current evidence.

Moonwell Lending’s top risks, based on the available non-onchain sources, are: oracle/price-feed failure, repeated exploit history, bad-debt and liquidation risk during market stress, smart-contract/integration risk from its Compound-v2-style lending design, and governance/operational risk. The strongest source-backed concern is oracle vulnerability: multiple independent risk analyses cite a recent Chainlink-related mispricing incident and describe the protocol as repeatedly exposed to oracle manipulation.

• Oracle / price-feed risk: Moonwell has been linked to a misconfigured or malfunctioning oracle incident that caused liquidations and bad debt, and independent analyses flag oracle manipulation as a core failure mode.
• Exploit repetition / security-track-record risk: Independent risk reports describe multiple exploits over the last few years, which raises concern that security controls and attack-surface reduction may be insufficient.
• Bad debt / liquidation cascade risk: The protocol has been described as vulnerable to rapid market moves that outpace liquidations, which can leave the system with unrecoverable debt.
• Protocol-design risk: Moonwell’s lending model is a Compound v2-style fork, and independent analyses say that design inherits known liquidation fragility and correlated-market stress sensitivity.
• Governance / operational risk: Risk parameters, curator decisions, and security posture can change over time; risk analyses also flag the removal/discontinuation of a bug bounty as a weakening of external security incentives. For an institutional view, the key takeaway is that Moonwell’s risk profile is dominated by oracle integrity and liquidation/bad-debt dynamics, with a secondary but material concern around repeat security incidents and operational safeguards.

Moonwell Lending’s top strengths are its multi-chain reach, non-custodial design, user-friendly experience, onchain governance, and dynamic, market-driven rates. It is built on Base, Optimism, Moonbeam, and Moonriver, which broadens access and liquidity across ecosystems . Its non-custodial model means users keep control of their assets while lending or borrowing . The protocol is explicitly described as intuitive and simple to use, which lowers friction for both new and experienced DeFi users . Moonwell also uses onchain governance for protocol changes, reducing single-point-of-failure risk and aligning updates with the community . Finally, its supply and borrow rates adjust based on utilization and market demand, which helps the protocol price credit efficiently and maintain incentive balance .