Maple

Maple (Maple Finance) is an institutional DeFi credit / lending protocol on Ethereum, providing primarily undercollateralized and secured loans to institutional borrowers funded by stablecoin depositors. Identification

• Name: Maple Finance (often just Maple; ecosystem now centered on SYRUP token).
• Category: On-chain institutional credit / lending marketplace (fixed-income yield, under/overcollateralized loans, cash management vault).
• Website: maplefinance.org and maple.finance (same protocol branding).
• Docs: Hosted at docs.maple.finance.
• Chains (DeFi deployment):
• Ethereum mainnet (primary and earliest deployment).
• Also referenced on Solana / “Solana-compatible environments”, but your scope is Ethereum only.
• Launch date (Ethereum): Protocol live since 2021; Ethereum mainnet launch cited as 12 May 2021.
• Native / governance token:
• Originally Maple (MPL), an ERC-20 + ERC-2222 governance/utility token on Ethereum.
• Contract commonly referenced as 0x33349B282065b0284d756F0577FB39c158F935e6 (MPL on Ethereum), cross-checked by multiple analytics and CEX sources.
• Project has since rebranded to Syrup (SYRUP) and migrated from the old MPL contract to a new token contract (exact new address not independently confirmed here). Key Ethereum addresses (non-on-chain-verified)
• Legacy MPL token (ERC‑20): 0x33349B282065b0284d756F0577FB39c158F935e6.
• DAO / treasury-related address: Etherscan labels 0xd6d4Bcde6c816F17889f1Dd3000aF0261B03a196 as “Maple Finance: DAO”, managing raised stablecoins and SYRUP tokens.
• Maple Labs / team address: Etherscan labels 0x94f98416ca0dc0310bcaeda0e16903e19307539f as “Maple.Finance: Maple Labs”. Explorer verification status for the core lending pool / protocol contracts is Not verifiable as of 2026‑08‑30 under the current constraints; only token and DAO-related labels are confirmed from explorer pages. Fork lineage / origin
• Publicly available descriptions consistently present Maple as a bespoke institutional lending / credit marketplace, not a fork of major money-market protocols like Compound or Aave.
• Its design (underwriter-led pools, undercollateralized term loans, ERC‑2222 profit-share) is architecturally distinct from standard pooled overcollateralized lending models, supporting non-fork status.
• Docs and about pages state that core contracts are custom-written in Solidity and have undergone multiple independent security reviews, but individual audit reports/links and audit coverage per module are Not verifiable as of 2026‑08‑30.
• No evidence in retrieved data of Maple being a malicious fork, nor of a history of malicious modifications in its own or closely related forks; however, systematic fork-family mapping of all Maple-inspired protocols is Not verifiable as of 2026‑08‑30. Because direct on-chain tooling is unavailable in this run, all contract-level details are not on-chain verified and should be treated as aggregator / explorer-sourced only, not primary truth.

Maple appears to have a real, functioning product portal rather than a static landing page: its documentation references an operational app portal at app.maple.finance/earn/portfolio for withdrawals, and the docs describe live deposit/withdraw flows, queue-based withdrawals, and pool interactions. The docs also include integration/API material for developers, including an SDK/API path for syrupUSDT deposits and withdrawals and cross-chain integration docs, which indicates an open developer interface. The user-facing materials look mature overall, but some claims remain unverified because on-chain checks are unavailable here. Product maturity signals are positive: the docs are detailed, updated recently, and describe concrete user actions such as requesting withdrawals, approving transactions, and waiting in a queue; they also mention a typical processing window under 24 hours but up to 30 days. The presence of technical resources, pool mechanics, and integration docs suggests a maintained documentation stack rather than a template landing site. No broken-link audit or live app test was possible in this run, so broken links, fake metrics, and template signs are Not verifiable as of 2026-08-30. Open API: yes, at least for integrations. The docs explicitly reference using an SDK/API for syrupUSDT deposits and withdrawals in an app, and deeper technical docs are available for protocol integration. That said, the exact public surface area and authentication requirements of the API are Not verifiable as of 2026-08-30.

Maple’s security framework summary lists a June 2023 audit cycle by Cantina (Spearbit) and Three Sigma for protocol updates, with all identified issues addressed before release. The snippet does not expose per-severity counts. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple Finance Core Smart Contract Audit Report covered the Maple core smart contracts (maple-core) on commit 05ef95f. The report states 1 critical, 1 high, and 0 medium findings, with issue resolution marked as resolved for the reviewed issue set. It explicitly notes that the audit was performed before the v1.0.0 release commit, so it does not by itself prove coverage of deployed Ethereum code unless the deployed bytecode matches the audited commit. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple’s security page lists a Spearbit audit for the December 2022 release. The snippet confirms the report link and that all relevant issues were addressed prior to V2 launch, but it does not provide critical/high/medium counts in the excerpt. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple’s November 2025 withdrawal manager upgrade was audited by Spearbit and Sherlock. The source says the upgrade underwent these audits, but the snippet does not provide critical/high/medium counts. Fix status is implied as completed prior to release. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple’s security page lists a Three Sigma audit for the December 2022 release. The snippet confirms the report link and that all relevant issues were addressed prior to V2 launch, but it does not provide critical/high/medium counts in the excerpt. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple’s security page and framework summary list audits for the August/December 2024 releases by Three Sigma and 0xMacro, with all relevant issues addressed before release. The provided excerpts do not include finding counts. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple’s security page lists a Trail of Bits audit for the December 2022 release. The provided source confirms the audit existed and links the report, but does not expose the finding counts in the snippet. Fix status is stated at the release level as: all relevant issues identified by auditors were addressed prior to launch of V2. Bytecode-match note: Not verifiable as of 2026-08-30.

Maple has an active bug bounty program on Immunefi. Immunefi lists it as live since 25 January 2022 and last updated 21 April 2026. The stated reward parameters are 10% of the funds directly affected, capped at $500,000. CertiK’s program page for Maple describes a similar structure for critical smart-contract issues, including a minimum payout of $50,000 and the same $500,000 maximum. Publicly available sources do not provide a verified aggregate results total for Maple’s bounty program in the search results provided, so the number of disclosed payouts or claims is Not verifiable as of 2026-08-30.

Maple’s main dependency and counterparty risk on Ethereum is institutional borrower credit risk, not a bridge-heavy architecture: Maple states that Syrup loans are governed by master lending agreements, secured by posted collateral, and remain exposed to borrower default and potential lender losses if collateral fails to cover the loan. Maple also appears to rely on qualified custody for some products, with BTC/ETH collateral held in qualified custody for Blue Chip Secured pools; this creates reliance on third-party custodians as a failure point. For oracle/manipulation risk, Maple says it uses Chainlink oracles plus oracle wrappers to reduce outage/manipulation risk, especially during liquidations, and adds minimum liquidation price and withdrawal cooldowns to reduce flash-loan/front-running risk. That lowers but does not eliminate dependency on external oracle infrastructure and wrapper logic. For external protocol exposure, Maple has publicly acknowledged indirect exposure through capital deployed to Aave V3 on mainnet and an isolated market on Mantle, and stated it had no direct exposure to rsETH because it was not approved as collateral. Maple also supports borrowing against stETH, so its risk surface includes Lido’s staking token economics and any depeg or staking-related stress in that collateral bucket. Maple’s docs describe the protocol as facilitating overcollateralized lending to institutional counterparties, which means underwriting and collateral liquidation quality are core dependencies. On custodians / SPV / RWA: the public materials reviewed show qualified custody and segregated custody arrangements, but I could not verify a specific RWA issuer/SPV dependency from the available sources. Not verifiable as of 2026-08-30. On bridges and CEX/MM exposure: I found no verifiable evidence in the reviewed sources of a material bridge dependency or a direct CEX market-maker dependency. Not verifiable as of 2026-08-30. Key failure scenarios: borrower insolvency/default, oracle outage or mispricing, collateral depeg (especially stETH or stablecoin-linked pools), and custodian failure/operational compromise.

Maple’s crypto custody is organized around institutional custodians and segregated custody contracts, not self-custody by end users. Its public materials describe collateral for Maple lending as being held in custody through partners such as Anchorage Digital, BitGo, Copper, and Zodia Custody, with assets placed in segregated wallets/custody arrangements rather than pooled on a single balance sheet. Maple’s protocol docs also show that loan administration is split across on-chain roles: Pool Delegates administer pools, while GovernorTimelock handles protocol-level configuration and emergency controls via multisig/governance, meaning custody and control are operationally separated from lending logic. In practice, lenders deposit into pools and receive ERC-4626 LP tokens, while borrower collateral is posted and monitored under the relevant custody arrangement; this is a permissioned institutional setup, not a retail wallet model. A Maple-linked partnership announcement specifically says pledged collateral will be securely held by Zodia Custody for certain lending arrangements. Because I cannot run on-chain verification here, the exact Ethereum contract-by-contract custody flow is Not verifiable as of 2026-08-30.

Maple’s documented incident history since launch is dominated by the December 2022 Orthogonal Trading default: Orthogonal defaulted on about $36 million of loans after its funds became tied up in the FTX collapse; Maple cut ties with Orthogonal, and the event was described as causing write-downs across multiple pools rather than a protocol exploit.

A second documented credit event was the Auros Global missed payment / distress in late 2022, described in contemporaneous coverage as a $3 million missed payment that contributed to a broader $54 million sour-debt episode across Maple pools; the pool cover had been largely depleted, and the event was handled through restructuring rather than a code fix.

Maple’s 2026 public incident narrative reports indirect exposure to the April 18, 2026 rsETH exploit via capital deployed to Aave V3 mainnet and an isolated Mantle market, but says it had no direct rsETH exposure, exited Aave promptly, unwound Mantle within 24 hours, and serviced over $800 million in redemptions without interruption; the post does not report a realized loss for Maple itself.

Maple’s key management is organized as a hierarchical permission system rather than as a single admin key. The protocol separates authority across roles such as Governor, Security Admin, Operational Admin, Pool Delegate, and Keeper, with each role limited to specific contracts and actions. At the protocol level, MapleGlobals acts as the central configuration point for system-wide parameters, while MapleTreasury handles treasury-related functions; this concentrates global control in governed contracts instead of ad hoc operator keys. For pool operations, Pool Delegates manage individual pools through contracts such as PoolManager and LoanManager, giving them operational control over funding and loan decisions within their assigned pools rather than across the whole protocol. For security and emergency response, the Security Admin has emergency pause powers across contracts, which is a distinct administrative key path from routine operations. The protocol documentation also describes specific custody contracts—such as LiquidityLocker, DebtLocker, CollateralLocker, and FundingLocker—that segregate asset control by function, reducing reliance on any single private key for all asset handling. In practical terms, Maple’s setup looks like multi-role, contract-governed key authority: governance keys set protocol-wide policy, security keys can intervene in emergencies, and pool-level keys handle day-to-day lending operations. I did not find a verifiable public disclosure of the exact multisig signer sets or key-rotation procedures in the provided sources, so those details are Not verifiable as of 2026-08-30.

Maple on Ethereum uses an upgradeable, role-heavy proxy architecture with protocol governance (Maple DAO) and pool delegates exercising significant control over pools; this implies non-trivial admin and freeze/rug risk if keys or governance are compromised. Addresses & verification Smart contract addresses for Ethereum are published via an on-chain address registry and mirrored in a GitHub list; Solidity sources for the registries are public, which aids verification of core contract addresses but is still an *unverified marketing claim* until checked on-chain. Core contracts (MapleLoan, PoolManager, WithdrawalManager, globals, etc.) live in the maple-core repo, following OpenZeppelin-style patterns. Upgradeability / proxy architecture Docs explicitly describe proxies and upgradeability with Maple DAO specifying approved implementations that relevant actors (e.g., pool delegates, borrowers) can upgrade to, but only among DAO‑approved versions. DAO can introduce timelocks on sensitive parameters (e.g., withdrawal cooldowns), but exact delays and whether they are consistently applied are Not verifiable as of 2026-08-30. Admin / owner / emergency roles Protocol actors include:

• Maple DAO / governors: control MapleGlobals, approve implementations, can activate pool managers and pool delegates.
• Pool Delegates / Pool Managers: configure pool parameters, set fees, manage strategies, administer loans, and interact with WithdrawalManager.
• Withdrawal Manager: controls redeemable tokens and withdrawal mechanics; compromising it gives effective control of pool funds. Audit findings highlight powerful functions:
• setWithdrawalManager() in PoolManager can swap the withdrawal manager without checks, giving full control of pool funds to a malicious delegate.
• Delegate fees (delegate origination and management) can be set up to 100%, diverting all loan proceeds away from lenders.
• MapleGlobals activatePoolManager() lacked validity checks on manager/delegate addresses, making misconfiguration or malicious addresses possible. Pause / withdrawal / exit risk Docs note DAO can enforce withdrawal cooldowns and timelocks, and Withdrawal Manager upgrades (e.g., support for multiple concurrent requests) alter liquidity behavior; whether users can *always* exit without admin cooperation under stress is Not verifiable as of 2026-08-30. Worst case if keys compromised / rug & freeze risk Given the ability to change WithdrawalManager, fee rates, and contract implementations, compromise of DAO or delegate keys could:
• Redirect fees and repayments away from lenders.
• Route pool funds via a malicious withdrawal manager or loan contract.
• Block or heavily delay withdrawals by changing cooldown and timelock parameters. Architecture risk map (conceptual)
• Top-level governance: Maple DAO / MapleGlobals approve implementations and activate pool managers.
• Per‑pool control: PoolManager + Pool Delegate configure terms, strategies, fees, and bind to WithdrawalManager.
• Liquidity layer: WithdrawalManager enforces queues, cooldowns, and redeemable balances; its integrity is critical for lender exit.
• Loan layer: MapleLoan / FixedTermLoanManager implement loan logic and repayment routing. Because on-chain role assignments, timelock delays, and any renounced roles cannot be inspected in this setting, all such details are Not verifiable as of 2026-08-30.

Maple’s publicly identifiable founders are Sid Powell (CEO/co-founder) and Joe Flanagan (Chairman/co-founder). Public profiles and interviews describe Maple as founded in 2019 and launched in 2021, with the founders coming from traditional finance and debt capital markets rather than anonymous crypto backgrounds. Maple itself and third-party writeups say the business shifted from an early tokenized-bonds idea to institutional lending, which is consistent with a real operating product rather than a pure web-front, but that business-model evolution is still mostly described by the project and media, not independently audited here. Credibility / prior experience: Sid Powell is described as a former institutional banker who had participated in $3BN+ of corporate bond issuance, ran a $200M+ bond funding program, and managed treasury at a commercial lending fintech. Joe Flanagan is publicly presented as co-founder/executive chairman with strategy and growth responsibilities. I did not find reliable evidence in the provided results of prior failed startups, hacks, or legal issues tied to either founder. Reality check: Maple presents as a public company with named leadership, a LinkedIn presence, interview trail, and a stated foundation structure rather than an anonymous team. Maple also says its top entity is the Maple DAO Foundation, a Cayman Islands foundation company with no members or shareholders, and claims no separate equity class with superior rights. That points to an offshore Cayman governance wrapper, while the search results do not verify a real office location, onshore operating company footprint, or the full corporate structure beyond Maple’s own disclosure. Bottom line: Maple looks like a real, named-team DeFi business with visible founders and institutional-finance backgrounds, not an anon-only web front. However, the office, legal-entity map, and any negative-history/hack screening are Not verifiable as of 2026-08-30 from the supplied sources alone.

Maple has a generally credible but higher-risk reputation in DeFi: it is widely described as a real, doxxed, institution-facing credit protocol with professional security reviews, but its model has also drawn repeated criticism because lenders bear counterparty credit risk directly rather than smart-contract risk alone. Independent commentary says the protocol is *not* a rug pull or exit scam, but emphasizes that it has suffered real historical losses and legal overhangs. On founders/team/investors, the search results support that Maple is run by a doxxed, professionally verifiable team with TradFi backgrounds, while the protocol’s own materials and third-party commentary frame it as institutional-grade asset management rather than an anonymous DeFi project. However, the results do not provide a clean, independently verified list of founders or investors for this question, so that detail is Not verifiable as of 2026-08-30. On security/audits, Cantina’s case study says Maple underwent repeated third-party security review and that Spearbit found no critical issues, though it did identify multiple high/medium/low-risk findings across reviews. That supports a view of a seriously engineered protocol, but not a zero-risk one. Main criticisms center on Maple’s undercollateralized lending model and legacy credit losses: one independent report says the model “catastrophically failed lenders in 2022,” including an 80% loss in one pool, and another notes the Orthogonal Trading default as a key example of borrower credit failure. Commentary also criticizes delegate incentives, suggesting pool delegates earn fees while lenders absorb default losses. For legal/regulatory issues, independent reports describe a core ongoing legal dispute and a Cayman Islands court injunction tied to the syrupBTC product, with allegations involving misuse of confidential information and breach of exclusivity. That is a material unresolved concern. I found no credible sanctions allegation in the supplied results. The unresolved concerns are therefore: credit-loss history, legal dispute over syrupBTC, and structural dependence on borrower quality and off-chain enforcement.

Maple is a permissioned credit marketplace where whitelisted pool delegates lend to institutional borrowers (mainly market makers, trading firms, and Web3 companies) using depositor capital. It is closer to undercollateralized/secured lending than passive yield farming. 1. Strategy & Assets

• Assets in: Primarily USDC and WETH on Ethereum, via segmented lending pools (e.g., Orthogonal Trading’s past pools, Maven, etc.).
• Assets out: Loans to KYC’d institutional borrowers under legal agreements, often term loans or revolving credit facilities.
• Yield source: Borrowers pay interest + origination fees; interest is shared between depositors, pool delegates, and protocol. 2. Organic vs. Subsidized Yield
• Yield is primarily organic credit yield from borrower interest, not farming incentives. MPL emissions/incentives have existed but are not the core driver in current institutional pools. 3. Risk Profile (Directional/Market Neutral/Leverage)
• Economic exposure is credit risk on specific borrowers, not price direction of crypto majors.
• No protocol-level leverage or looping; borrowers may use leverage/trading strategies off-platform (directional exposure for lenders is indirect).
• Not a restaking protocol; no external PoS staking or rehypothecation at protocol layer. 4. Lock-ups & Withdrawals
• Deposits usually have fixed term or notice periods, plus liquidity queues—withdrawals depend on pool liquidity and loan repayment schedules.
• Early exits can be gated if utilization is high or defaults occur. 5. Fees, Gates, Limits & Revenue
• Fee stack (percentages vary by pool):
• Protocol fee on interest to Maple Treasury (protocol revenue).
• Delegate fee to pool delegate for underwriting and monitoring.
• Origination fees paid by borrowers (shared per pool terms).
• Hard borrow and pool limits are set per pool; delegates manage concentration limits, covenants, and diversification. 6. Collateral Model
• Maple is designed for under‑ or partially collateralized loans, backed by:
• On-chain collateral in some pools.
• Off-chain guarantees, legal recourse, and borrower balance sheets.
• This is idiosyncratic credit risk, not overcollateralized DeFi lending. 7. TVL, Products, Trend & APY
• On-chain TVL and breakdown by pool/chain via Dune is Not verifiable as of 2026-08-30 (MCP unavailable).
• DeFiLlama shows Maple TVL peaked in 2022, dropped sharply after credit events (e.g., Orthogonal/Alameda exposure), and later stabilized at a lower base.
• APYs historically have been in the high single to mid‑teens range, but with significant drawdown risk from defaults; realized returns can deviate sharply from quoted APYs, and APY volatility is high around default events. 8. Sustainability
• Sustainability depends on credit underwriting quality, default rates, and ability to maintain high-quality, diversified borrower books.
• Yields are sustainable only to the extent borrowers can profitably deploy capital and honor obligations; past defaults highlight non‑trivial tail risk.

Maple’s publicly stated reserve/treasury picture is split across the Syrup Strategic Fund (SSF), the Maple Treasury, and reported liquid assets. Maple says the SSF is its protocol treasury and that it holds capital reserves, buyback capacity, token liquidity, and other liquid assets; it also says the Treasury is where SYRUP bought back from the market is held. Maple’s transparency page reports Assets Under Management of $4.81B, Deposits of $1.86B, SYRUP Holdings of 79.86M, and Liquid Assets of $4.08M; those are the only balance figures surfaced in the provided sources. Composition-wise, Maple describes the reserve balance sheet as a mix of SYRUP, stablecoins, and other liquid assets, and says the SSF receives 25% of monthly revenue under MIP-019, with buybacks and reserves managed through governance. Maple also states that the SSF bought back 8M SYRUP in 2025 and 2.5M SYRUP so far in 2026, while choosing to strengthen reserves this year. On custody/control, Maple says reserves retained by the SSF are held within the Foundation, while bought-back tokens remain in the Maple Treasury. Maple’s proof-of-reserves announcement says the system was built with The Network Firm and provides independent, third-party verification sourced directly from custodians, with collateral held by disclosed custodians. Maple also says reserve and allocation information is designed to be verifiable onchain through Proof of Reserves. Not verifiable as of 2026-08-30: exact reserve wallet addresses, a Dune-verified on-chain treasury balance, and a chain-by-chain custody breakdown for Ethereum were not provided in the accessible sources. The provided material does not include an on-chain balance query or explorer-confirmed reserve addresses, so the on-chain reserve size cannot be independently verified here.

Maple has a native token MPL on Ethereum. On‑chain verification via Dune is Not verifiable as of 2026‑08‑30. ### Basic token data

• Token name/ticker: Maple Token (MPL)
• Chain: Ethereum (ERC‑20)
• Indicative contract address: Multiple sources point to an ERC‑20 MPL; exact address is Not verifiable as of 2026‑08‑30 without on‑chain tools.
• Total vs circulating supply, market cap, FDV: Recent figures differ slightly by analytics site and are derived from CEX/DEX and price feeds, not raw chain. As exact on‑chain supply is Not verifiable as of 2026‑08‑30, treat all supply/MC/FDV numbers from market trackers as aggregator estimates. ### Utility and governance
• Protocol token: MPL is used for governance of Maple’s lending protocol and DAO decisions (e.g., pool parameters, fee structures).
• Staking / ecosystem role: MPL is staked or locked in various Maple governance/participation mechanisms; detailed mechanics and current yields differ by product version and are sourced from Maple docs and marketing — therefore unverified marketing claims. ### Revenue share, buybacks, burns
• Maple charges fees on lending/borrowing activity. Whether these fees are systematically used for MPL buybacks, burns, or direct revenue share to MPL holders is not fully documented across independent sources; specific mechanisms are unverified marketing claims unless confirmed via audited contracts. Not verifiable as of 2026‑08‑30. ### Emissions & unlocks
• MPL had an initial allocation among team, investors, treasury, and community typical of DeFi launches (found in Maple’s tokenomics blog/docs). These breakdowns are unverified marketing claims without raw on‑chain vesting verification.
• Emissions schedule and unlocks: Vesting schedules and unlock calendars are described in Maple materials, but whether each announced unlock has occurred on‑chain is Not verifiable as of 2026‑08‑30. ### Allocations & holder concentration
• Public tokenomics charts show allocations to team, investors, treasury, and community/liquidity. Precise percentages and identification of insider wallets/top holders are Not verifiable as of 2026‑08‑30 from raw chain and should be treated as aggregator estimates. ### Contract controls / special functions
• Whether MPL’s ERC‑20 contract includes mint, blacklist, or fee‑switch functions and who controls them is Not verifiable as of 2026‑08‑30 without direct contract inspection. ### Liquidity & listings
• MPL is listed on major CEXs and DEXs (e.g., Ethereum‑based DEX pools and at least one centralized exchange). Depth and exact pool composition are aggregator‑level and Not verifiable as of 2026‑08‑30 at raw‑chain level. > Due to the lack of Dune/on‑chain tooling in this run, all quantitative tokenomics (supplies, caps, unlocks, allocations, holder concentration, liquidity depth) remain Not verifiable as of 2026‑08‑30 and should be treated as approximate aggregator data, not on‑chain truth.

For Maple on Ethereum, a Bitcoin move below $10,000 would most likely be a severe credit-and-liquidity stress test, not a price-linked liquidation event by itself, because the latest available reporting says Maple has no active lending positions across DeFi and is instead positioned with overcollateralized loans, institutional custody, and a liquidity buffer. The main transmission channels would be:

• Borrower stress / defaults: a BTC crash of that magnitude would likely coincide with broad crypto and risk-asset deleveraging, which can pressure Maple’s institutional borrowers and raise default risk. Maple’s own discussion of its risk framework emphasizes that collateral and borrower selection are central to surviving drawdowns.
• Redemption pressure / liquidity stress: in a panic, lenders could try to redeem at the same time, creating funding stress even if underlying credit remains intact. Maple’s own incident write-up says it serviced over $800 million in redemptions over 72 hours without interruption, but that is a historical resilience datapoint, not a guarantee under a deeper BTC shock.
• Indirection through market contagion: Maple said it had indirect exposure through DeFi allocations in a prior incident and exited them after monitoring flagged anomalies; that suggests Maple’s exposure can come from market plumbing and counterparties, not only from direct BTC holdings. What I cannot verify from the available sources is Maple’s current Ethereum TVL, reserve composition, borrower list, or scenario-specific loss estimates under BTC < $10,000. Not verifiable as of 2026-08-30. So the stress view is: high systemic pressure, likely higher spreads and lower new originations, with outcomes depending on borrower quality and liquidity management rather than BTC price alone. No on-chain verification was available in this run, so any claims about Ethereum exposure percentages, live TVL, or liquidation thresholds are Not verifiable as of 2026-08-30.

Maple’s stress loss from a 20% depeg of the largest collateral is Not verifiable as of 2026-08-30 from the available web sources alone. The key reason is that the sources do not provide an Ethereum-only, loan-level breakdown of the largest collateral asset, the collateral mix, or current margin/liquidation buffers needed to model the shock precisely. What can be said is that Maple’s risk is primarily credit/default risk rather than AMM-style price-risk, and most current loans are described as being overcollateralized with BTC, ETH, or SOL, with margin-call and liquidation mechanics intended to protect principal. However, Maple also has a history of partially collateralized / undercollateralized lending in its earlier design, so a blanket 20% collateral shock could have very different effects depending on which loan cohort is being modeled. For a defensible estimate, I would need the live Ethereum portfolio composition and each loan’s collateral ratio and liquidation threshold; absent that, any numeric loss estimate would be speculation rather than a verified stress result.

For Maple on Ethereum, a top counterparty insolvency is primarily a pool-level credit loss, not a protocol-wide insolvency cascade. The loss path is: borrower misses payment or defaults → the pool delegate/manager declares or works the default → any collateral or recovery proceeds are applied → the pool’s accounting is marked down, and any shortfall is borne by the pool’s lenders after first-loss capital is exhausted. Who absorbs the loss: the affected pool’s lenders absorb the residual loss first, but only after any pool-cover / first-loss capital provided by the delegate or other designated buffer is used. In the 2022 Orthogonal default, reporting said the M11-managed pool covers were largely depleted, and lenders were left facing material losses while Maple pursued restructuring rather than immediate full recovery. Compensation / recovery: Maple’s recovery mechanics are off-chain and economic rather than insurance-like. The delegate may negotiate restructuring, pursue legal recovery, or liquidate any posted collateral; any proceeds are distributed back into the pool. If recovery is incomplete, lenders are compensated only pro rata from what is recovered, not made whole by the protocol. Impact path through smart contracts: the default reduces pool value, realizes unrealized losses, and feeds those losses into withdrawal and accounting calculations, so depositors see a lower claim value and potentially constrained withdrawals. The protocol-level contract effect is therefore a NAV reduction in the impacted pool, not automatic socialization across all Maple pools. What is not verifiable as of 2026-08-30: exact current Ethereum pool architecture, current loss-buffer sizing, and whether any specific active pool has a standing first-loss tranche can’t be confirmed from the provided sources without on-chain verification.

For a stress scenario involving committed fraud by the DAO or owners, Maple has credible allegations of misconduct and governance centralization risk, but I did not find a court judgment or on-chain proof establishing that the DAO or owners committed fraud. The strongest current evidence is a Cayman court injunction in a dispute with Core Foundation, where the court found there was a serious issue to be tried regarding Maple’s alleged breaches of a commercial agreement; Maple denies wrongdoing. There is also a third-party adversarial report alleging that Maple’s MPL→SYRUP migration stranded some retail holders and describing governance/tokenomics concerns, but this is an external critique rather than a legal finding of fraud. Maple’s own materials say the project has undergone large redemptions, had no direct exposure to the April 2026 rsETH exploit, and serviced redemptions without interruption, which argues against an immediate fraud-like insolvency narrative, though this is self-reported. Risk assessment: the appropriate stress-case assumption is legal/regulatory and governance disruption rather than confirmed fraud. The main downside channels are injunctions, litigation costs, impaired partnerships, reputational damage, and potential governance concentration effects. Based on the available sources, committed fraud is not verifiable as of 2026-08-30.

Maple’s primary yield source on Ethereum is its institutional lending book, where lender yield comes from borrower interest on fixed-rate, overcollateralized loans. Maple’s own documentation says this yield is generated primarily by interest paid by institutional borrowers, supported by DeFi liquidity provision and futures basis trading. However, the results provided do not verify a negative 30-day primary yield for Ethereum, so the requested stress scenario is Not verifiable as of 2026-08-30. The closest directly relevant evidence is Maple’s stated 30-day yield messaging: Maple’s transparency and marketing materials emphasize recent yield performance, but the provided results do not include a timestamped on-chain or independent 30-day yield series showing the primary source turning negative. One third-party research note also describes Maple’s lender yield as coming from borrower interest plus protocol token rewards, which matters because token incentives can mask or supplement underlying cash yield; but this still does not establish a negative 30-day primary yield on Ethereum. In short, based on the supplied sources, Maple’s Ethereum yield is structurally tied to borrower interest, but a negative 30-day primary yield cannot be confirmed from the available evidence.

Maple is primarily company-controlled, with limited on-chain governance and no evidence of a fully empowered DAO. Most control appears to sit with Maple’s corporate entity and designated pool delegates, not token holders. 1. Governance structure & control

• Maple Finance operates through a corporate entity (Maple Finance Pty Ltd in Australia has been referenced in past disclosures; exact current legal entity, registration number, and directors are Not verifiable as of 2026-08-30).
• Maple uses a pool-delegate model: each lending pool is managed by a “Pool Delegate” that controls underwriting and loan approvals, subject to Maple protocol rules.
• The protocol itself is described as governed by smart contracts with risk and underwriting handled off-chain by pool delegates and Maple’s team. 2. On-chain / token governance (MPL)
• MPL is the governance token, but there is no clear evidence of a robust, on-chain DAO with binding protocol-wide votes similar to major DeFi DAOs.
• Governance appears mostly off-chain / company-led, with Maple Labs or Maple Finance controlling core protocol changes, listings, and roadmap. Public records of formal governance proposals, voting mechanics, and timelocks for Ethereum contracts are Not verifiable as of 2026-08-30. 3. Contract, frontend, and funds control
• Smart contract upgrade rights, ownership of key protocol contracts, and any timelock / multisig structure for Ethereum mainnet are Not verifiable as of 2026-08-30 (no reliable explorer or audit source clearly mapping admin addresses and roles across all core contracts).
• Control of the frontend (main app site) and hosting infrastructure is held by Maple’s centralized team; this is an unverified marketing claim when sourced only from Maple’s own docs.
• Maple pools are non-custodial contracts, but pool delegates and Maple entities have material control over loan terms and borrower selection. 4. Voting concentration & top holders
• Dune MCP is unavailable; detailed MPL holder concentration, voting history, and top-token-holder analysis are Not verifiable as of 2026-08-30. 5. Timelocks, multisigs, powers
• Any Ethereum governance timelock contracts, multisig addresses, signer identities, thresholds, and independence (e.g., proportion controlled by Maple vs external entities) are Not verifiable as of 2026-08-30 based on accessible public data. Overall, Maple should be treated as a centrally steered protocol with limited transparent, on-chain governance; risk committees, pool delegates, and the company play the dominant role, rather than a dispersed token-holder DAO.

Maple’s public legal posture is *permissioned and compliance-heavy*, not open-access DeFi. Its interface terms say users are solely responsible for complying with applicable laws, and Maple’s KYC materials say individuals and entities must submit identity documentation; for entities, ultimate beneficial owners and directors are identified as well. Maple’s privacy policy identifies Maple Labs Pty Ltd in Melbourne, Australia as the contact entity for privacy requests, while the broader Maple Group’s privacy notices show different legal entities and jurisdictions depending on the service line, including Cayman Islands, Ireland, Luxembourg, Canada, and Hong Kong-related operations; this indicates a multi-entity structure rather than a single on-chain legal wrapper. On regulatory classification, the materials available here support the view that Maple operates as a *regulated-services-adjacent* protocol rather than a pure anonymous protocol, because access to lending and pools is gated by KYC/allowlists and the interface documentation emphasizes compliance obligations. However, a definitive legal classification as a security, collective investment scheme, money services business, or broker-dealer is *Not verifiable as of 2026-08-30* from the evidence gathered. I did not find verified court cases, sanctions designations, or enforcement actions specifically naming Maple in the gathered sources; those items are *Not verifiable as of 2026-08-30*. The strongest legal-risk takeaway is that Maple’s actual operational risk is shaped by off-chain entities, KYC/permissioning, and data-processing obligations, so the legal risk is not limited to smart-contract risk alone.

Maple’s stablecoin on Ethereum appears to be USDG from the provided sources, but a protocol-specific depeg history is not verifiable from the materials available here. The only direct Maple-linked source is a YieldScope page for “Maple · USDG,” which identifies the asset but does not provide a depeg-event count or a peg history. What can be said from the broader stablecoin references is that stablecoins *can* and do depeg, including major events such as USDT in May 2022 and USDC in March 2023, but those are not Maple USDG events and should not be attributed to Maple. The CoinGecko historical data shown for “Maple USD” also reflects a token trading around $2.88–$4.46 in late May to mid-June 2025, which indicates that this dataset is not a $1-pegged stablecoin series and therefore cannot be used to infer USDG depegs. So, for your exact question:

• Did the stablecoin used ever depeg? Not verifiable as of 2026-08-30.
• How many times? Not verifiable as of 2026-08-30.
• When was the last time? Not verifiable as of 2026-08-30.
• What was the % depeg? Not verifiable as of 2026-08-30. If you want, I can next try to identify the exact Ethereum stablecoin contract Maple uses and check independent market-history sources for its peg behavior.

For Maple on Ethereum, the top 5 protocol risks are borrower default / credit risk, collateral liquidation risk, liquidity mismatch / withdrawal stress, smart contract risk, and operational / delegate risk.

• Borrower default / credit risk: Maple’s lending model exposes lenders to counterparties failing to repay; Maple’s own docs explicitly name Default Risk, and third-party reviews describe borrower credit risk as the primary driver of risk.
• Collateral liquidation risk: Even with overcollateralized loans, rapid market deterioration can make collateral insufficient or hard to liquidate cleanly, creating loss risk for lenders.
• Liquidity mismatch / withdrawal stress: Maple highlights risk of loss, and independent reviews note that withdrawal queues or maturity mismatch can create stress if lenders want out while loans are still outstanding.
• Smart contract risk: Maple’s docs explicitly warn that smart contracts increase risk as more value is held, and audited code still can contain vulnerabilities or integration failures.
• Operational / delegate risk: Maple’s institutional model depends on underwriting and loan administration; third-party analysis points to pool delegate failure, poor underwriting, or fraud as a core risk, with the 2022 Orthogonal Trading default as the key precedent. A notable historical indicator is the Orthogonal Trading default, which exposed how hidden counterparty exposure can translate into lender losses across pools. Maple’s documentation and third-party reviews agree that the protocol is materially safer than earlier versions, but it remains a credit-risk-first DeFi protocol rather than a risk-free yield product.

Maple’s top strengths are: (1) institutional-grade credit underwriting with real borrower due diligence and credit standards, (2) access to undercollateralized lending that expands borrowing beyond overcollateralized DeFi models, (3) transparent onchain loan reporting so repayments and terms are visible in real time, (4) capital efficiency and global liquidity from blockchain-native, 24/7 settlement, and (5) professional pool management / modular architecture that supports compliant, scalable credit markets. These strengths are consistently described across independent research and industry coverage of Maple as a decentralized institutional lending marketplace.