Meteora DLMM

Meteora DLMM (Dynamic Liquidity Market Maker) is a Solana-native concentrated-liquidity DEX engine that organizes liquidity into discrete price bins with dynamic, volatility-aware fees for spot and curve-style pools. ### Protocol Identification

• Name: Meteora DLMM (Dynamic Liquidity Market Maker).
• Main website / app: app.meteora.ag and meteoraswap.com host the swap/pool interface for DLMM and related products.
• Any claims from these sites are *unverified marketing claims* by definition.
• Docs: Official documentation at docs.meteora.ag, with a dedicated DLMM developer guide.
• Category: Solana DEX / liquidity infrastructure, concentrated-liquidity AMM engine used by Meteora’s own DEX and external integrators.
• Chains: Solana only (DLMM program explicitly documented as a Solana program, and all SDK/API references filter by a single Solana program ID).
• Native token: Meteora has a MET points system mentioned in the app; the existence or on-chain details of any MET token contract are Not verifiable as of 2026-08-29 based on the provided data.
• Launch date: Public materials describe DLMM as Meteora’s flagship Solana DEX engine but do not clearly state a mainnet launch date; this is Not verifiable as of 2026-08-29. ### Main Contract / Program Identification
• DLMM program ID (Solana): LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.
• Explicitly listed in Meteora’s official DLMM developer guide as Mainnet Beta program ID.
• Bitquery’s Solana DLMM API filters trades and pools using the same program address, confirming independent alignment.
• Third-party Rust math repo for “solana-dlmm-meteora” references Meteora’s DLMM as the swap engine, further corroborating the program identity.
• Explorer verification status: Direct explorer verification (e.g., Solana explorer program metadata, source-verified status) is Not verifiable as of 2026-08-29 from the available off-chain sources. ### Fork Lineage / Upstream Relationships
• GitHub description calls the math library for Meteora DLMM a “sibling to solana-clmm-raydium”, indicating conceptual similarity to Raydium’s CLMM but not an outright fork of its on-chain program.
• Public writeups and docs describe DLMM as Meteora’s own design with:
• Discrete price bins, zero-slippage swaps within a bin, and dynamic fees adjusted by volatility.
• No source explicitly states that the DLMM Solana program is a direct fork of another deployed program, nor that it reuses external audited code; therefore fork status is Not verifiable as of 2026-08-29. ### Audits & Malicious-Modification History
• Meteora docs list Zenith audits for DLMM (e.g., “Zenith v0.11.0” and “v0.10.1” DLMM audit reports).
• Existence of audits is verified; full findings and coverage require reading the reports, which is beyond the provided snippets.
• No independent source in the gathered data reports malicious modifications or exploit history in DLMM forks or clones; absence of evidence is *not* evidence of safety, so this remains Not verifiable as of 2026-08-29.

Meteora DLMM appears to be a real, functional product portal rather than a pure landing page: the documentation describes live DLMM app features, including dynamic terminal functionality on the site, and the docs expose indexed read-only data for pools, portfolios, positions, wallets, limit orders, and protocol stats. The presence of a production Swagger UI and explicit production/development endpoints also indicates an operating developer-facing API, not just marketing pages. Live deposits/withdrawals are not directly verifiable from the gathered evidence, but the docs and API surface include position deposit and withdraw endpoints, which strongly suggests these workflows exist in the product stack. Broken links, fake metrics, and template signs were not verifiable as of 2026-08-29. Open API: yes — the documentation explicitly states DLMM APIs, provides production and development Swagger UIs, and lists REST endpoints for pools, portfolios, positions, wallets, and protocol stats. Overall maturity assessment: high. The site looks like an active application ecosystem with docs, SDK, and indexed API access, not a hollow landing page; however, direct front-end UX quality and live transaction behavior are not fully verifiable from the available evidence.

DLMM audit reports are published for Meteora DLMM, including v0.10.1 and v0.11.0.

Meteora DLMM does have an active bug bounty program. Meteora’s documentation says the program is managed through OOO Security and covers vulnerabilities across its on-chain programs and protocol infrastructure, including DLMM, DAMM v1/v2, DBC, Alpha Vault, and other Meteora programs. OOOSec’s program page says it was launched 1 month ago, lists a maximum bounty of $10,000 for critical vulnerabilities, and shows 4 reports resolved with $8,600 total paid and the last bounty paid 1 month ago. The main parameters visible in the program page are: responsible disclosure through the bounty portal, coverage limited to Meteora’s listed products, and a reward cap of $10,000 for critical issues. Meteora’s own docs also direct reporters not to disclose issues publicly before resolution. The results currently visible are modest: 4 resolved reports and $8,600 paid out so far. I could not verify a more precise start date from the available sources beyond the program page’s relative launch statement (“1 month ago”), so the exact calendar start date is Not verifiable as of 2026-08-29.

Meteora DLMM is *mostly non-custodial* and the user-facing pool positions are described by Meteora as fully self-custodied, so there is no obvious embedded custody or bridge counterparty in the core DLMM design. The main external-dependency risk is therefore not a bridge/custodian chain, but *smart-contract and market-structure risk* inside Solana and within whatever asset pair is selected. Key dependency and counterparty-risk points:

• Oracle/manipulation risk: Meteora’s DLMM documentation emphasizes bin-based concentrated liquidity and limit-order style behavior, not a dependence on an external price oracle for standard DLMM operation; by contrast, Meteora’s LST documentation explicitly says its LST pools avoid price oracles to remove a dependency and exploit vector. For DLMM, the practical risk is *price-discovery/manipulation around thin liquidity or active bins*, rather than a named oracle dependency.
• External protocol exposure: DLMM itself is not described as lending into outside protocols, and Meteora notes DLMM liquidity is *not connected to Dynamic Vaults for lending yield*. That reduces direct counterparty exposure versus vault products, but does not eliminate risk from any paired asset, reward asset, or integrated strategy used by the LP.
• Stablecoin / LST exposure: Meteora’s stable-pool marketing says these pools are built for *USD stablecoins, liquid staking tokens (LSTs), and bridged assets*, which creates asset-specific depeg and wrapper risk even if the AMM itself is non-custodial. Meteora’s legacy LST pool docs explicitly warn that LPs face *LST protocol risk, smart contract risk, liquidity risk, depeg risk,* and changing incentives. That is the clearest counterparty bucket for DLMM-adjacent usage on Solana.
• CEX/MM exposure: Not verifiable as of 2026-08-29. I did not find independent evidence that DLMM requires a central market maker or exchange counterparty for core operation.
• Custodians / RWA issuer-SPV exposure: Not verifiable as of 2026-08-29. I did not find evidence that DLMM depends on custodians or RWA issuers/SPVs at the protocol level.
• Bridges: The core DLMM docs do not show bridge reliance, but Meteora’s stable-pool positioning includes *bridged assets*, which implies bridge risk for any such pair even if the AMM itself is non-custodial. Overall risk view: DLMM’s main counterparty risk is asset-side, not protocol-side—especially stablecoins, LSTs, and bridged assets—while the protocol-level risks are smart-contract failure, pool design error, and market-manipulation in thin liquidity conditions.

Meteora DLMM is organized as a non-custodial protocol: the app, smart contracts, and liquidity pools are described as not holding, storing, sending, or receiving user assets, and users retain control through their own wallet. In practice, custody stays with the user’s selected Solana wallet; LP funds are deposited into on-chain pool accounts and positions are represented by pool/position records rather than by Meteora controlling the assets off-chain. For DLMM specifically, liquidity is deposited into discrete-bin pools (LbPair accounts) with reserve vaults and position accounts defined on-chain, and the pool stores metadata such as token mints, vaults, active bin ID, fee parameters, and reward information. Meteora’s docs also state that DLMM liquidity is not connected to Dynamic Vaults for lending yield, so DLMM custody is not routed through a separate yield vault mechanism. The main custody risk is therefore smart-contract and wallet risk, not protocol custody: users still depend on their wallet security, correct pool selection, and the Solana program logic.

Meteora DLMM’s key management is user-controlled rather than custodial: the documentation and related tooling expect users to provide and sign with their own wallet private key / keypair when creating pools or operating on the protocol. The protocol docs also describe it as a self-custody DeFi system, meaning users remain responsible for securing their private keys and assets. For DLMM pool deployment, Meteora’s launch-pool guide explicitly asks for a PRIVATE_KEY for the wallet used to deploy the pool and generates a local keypair.json that is then used to sign subsequent actions in the guide. The DLMM docs likewise rely on wallet-owned accounts, PDAs, and program instructions, which indicates that protocol operations are signed by the user’s wallet rather than by Meteora holding keys on the user’s behalf. What is not verifiable as of 2026-08-29 from the available sources is any formal description of Meteora’s internal organizational key controls, such as multisig signers, hardware security modules, emergency admin key rotation, or a published key-management policy for protocol governance. Based on the sources available, the clearest answer is that end-user wallet keys are outside Meteora’s custody, while deeper admin/key-governance arrangements are not disclosed in the retrieved materials.

Meteora DLMM on Solana uses an upgradeable program architecture with privileged admin roles, creating both operational flexibility and non‑trivial key/rug/freeze risk. On‑chain verification via Dune is Not verifiable as of 2026‑08‑29. ### 1. Core program & addresses

• DLMM is implemented as a Solana program (no EVM proxy pattern; upgradeability via Solana’s program‑upgrade authority). This relies on a single upgrade authority key that can redeploy new code to the same program ID.
• Exact DLMM program ID, upgrade authority, and any separate config/admin PDAs are Not verifiable as of 2026‑08‑29. ### 2. Upgradeability & admin powers On Solana, if the program is not set to immutable, the upgrade authority can:
• Deploy new logic that changes swap, fee, withdrawal, or accounting behaviour without prior user consent.
• Potentially introduce logic to freeze pools, block withdrawals, or redirect fees, depending on code. Meteora docs and audits indicate admin/config authorities exist for:
• Fee parameters (LP fees, protocol fees).
• Pool configuration, tick spacing, and strategy settings for DLMM. All of the above are currently unverified marketing claims unless backed by audits. ### 3. Audits & role design
• Meteora has published audits for its DLMM and other programs (e.g., by OtterSec / other Solana‑focused auditors). These typically show:
• Config/admin PDA(s) controlling fee and strategy parameters.
• No direct “admin can withdraw user liquidity” function; withdrawals follow pool token accounting. Audit conclusions, including statements about limited admin powers, are audit-sourced, not on-chain verified. ### 4. Exit guarantees & worst‑case scenarios
• User exit path: As long as the deployed program logic remains honest and non‑frozen, LPs can withdraw via standard DLMM instructions using their LP tokens; this is enforced by program code, not admin discretion.
• If the upgrade authority is compromised or malicious:
• New code could block swaps/withdrawals (freeze risk).
• Fees could be set to confiscatory levels or redirected.
• In extreme designs, logic could misaccount balances and effectively rug LPs. Renounced roles, timelock, and any on-chain governance:
• Whether Meteora has:
• Set its DLMM program to immutable.
• Transferred upgrade authority to a multisig or DAO.
• Implemented any timelock on upgrades. is Not verifiable as of 2026‑08‑29. ### 5. Architecture map (conceptual)
• DLMM Program (Solana): core swap/liquidity logic.
• Config/Admin PDA(s): store fee, strategy, pool parameters.
• Upgrade Authority Key: can change program code (unless made immutable).
• LPs/Traders: interact via client/frontend; constrained by current program logic. Risk bottom line: DLMM is structurally upgradeable with meaningful admin/config powers; absence of hard, on-chain proof of immutability or timelock is a material smart‑contract & admin‑key risk for institutional users.

Meteora DLMM is a Solana liquidity protocol that emerged from the Mercurial Finance project and is now led by a small, partly public, partly pseudonymous team with a mixed credibility profile. Founders & key leads

• Multiple sources identify Ben Chow as a founder/co‑founder of Mercurial/Meteora and of Jupiter, Solana’s major DEX aggregator.
• Zen (often “Zhen Hoe Yong” / “Zen”) and Soju are described as co‑leads of Meteora, effectively running the protocol post‑rebrand and after Ben’s resignation.
• The pseudonymous Meow, known as Jupiter’s founder, helped establish Mercurial/Meteora but does not run day‑to‑day operations at Meteora.
• CryptoRank profiles list Zen, Meow, Ben Chow, Siong, Soju as founders/co‑founders or co‑leads of Meteora DLMM. Prior track record & controversies
• Meteora evolved from Mercurial Finance, a 2021 Solana stablecoin AMM that raised seed funding (~$3.5m) from DeFiance Capital, HTX Ventures, Signum Capital, and was based in Singapore.
• Ben Chow is credited with leading product architecture for DLMM/DAMM and co‑founding Jupiter.
• In February 2025, Ben Chow resigned following the LIBRA memecoin scandal and a federal class‑action lawsuit alleging pump‑and‑dump schemes involving LIBRA, M3M3, TRUST and celebrity promotions; Meteora and Ben publicly denied misconduct but acknowledged poor judgment.
• After his resignation, sources state Zen/Soju (or Zen with co‑lead Soju) took over project leadership. Public vs. anon, offices, jurisdiction, business reality
• Some team members are public and identifiable (e.g., Zen/Zhen Hoe Yong, Soju via interviews; contributors like Shane H with prior Kyber Network strategy role).
• Others (e.g., Meow) remain pseudonymous.
• Mercurial was described as based in Singapore; this is the clearest jurisdictional signal available. Meteora’s current legal entity domicile, office address, and corporate structure are Not verifiable as of 2026‑08‑29.
• Governance content references a 20‑person+ senior team building on Solana since 2021, but this is effectively a self‑description and therefore an unverified marketing claim. Reality check (institutional lens)
• Positive: multi‑year Solana DeFi building history; backed by recognizable crypto VCs; leadership with Jupiter/Kyber background suggests real ecosystem integration.
• Negative/risks: founder involved in an active lawsuit and reputational scandal; partially pseudonymous leadership; unclear legal entity and physical office; team and treasury statements largely self‑reported. Overall, Meteora DLMM appears to be a real, actively developed DeFi business in the Solana ecosystem, but with meaningful founder‑related legal and reputational risk and limited verifiable corporate footprint beyond prior Singapore links.

Meteora DLMM currently has a mixed but generally solid technical reputation, backed by audits, VC funding, and broad ecosystem integration, but with a serious founder-level legal controversy that is an unresolved concern for institutional risk. Founders & history Meteora is a Solana-native DeFi liquidity protocol that evolved from Mercurial Finance in 2023, with DLMM as its flagship product. IQ.wiki reports that a co‑founder, Ben Chow, is named in a February 2025 US federal class‑action lawsuit alleging pump‑and‑dump schemes involving LIBRA, M3M3, and TRUST tokens, using celebrity endorsements to defraud retail investors. This is a material founder‑reputation and legal‑risk issue; case outcome is not yet reported and remains unresolved as of 2026‑08‑29. Investors & ecosystem reputation Multiple sources describe Meteora as backed by notable crypto VCs and Solana‑aligned entities, including DeFiance Capital, HTX Ventures, Signum Capital, Alliance, Arche Fund, ArkStream Capital, Gate Labs, and the Solana Foundation. A strategic round led by YZi Labs with participation from IDG Capital is reported, with total funding figures ranging from about $3.5M (earlier seed) to >$55M across seed, Series A, and strategic rounds. These are secondary‑source analytics and media, not on‑chain verified. Audits, security posture & bug bounty Meteora maintains a public audit section for DLMM and related programs on its documentation site, including multiple versions (e.g., audits listed from OtterSec, Offside Labs and Zenith for DLMM). External coverage notes that Meteora runs a bug bounty program up to $500,000 via a security partner, covering on‑chain programs and infrastructure. A third‑party overview highlights that core pool/vault programs are open‑source, with public audits and auditable on‑chain state; this is a positive signal on transparency, though still aggregator interpretation. Incidents, fraud/rug/insolvency allegations Search results show no documented protocol‑level rug pull, insolvency or major exploit specific to DLMM as of 2026‑08‑29. Not verifiable on-chain as of 2026‑08‑29. The main negative datapoint is the co‑founder lawsuit referenced above, which alleges broader token‑scheme fraud but not a DLMM exploit. Regulatory / sanctions No independent evidence of sanctions designations or formal regulatory actions against the Meteora protocol itself was found. Not verifiable as of 2026‑08‑29. Sentiment & criticisms Recent reviews and ecosystem writeups present Meteora DLMM as innovative Solana liquidity infra with strong capital efficiency and extensive audits. The key institutional concern is founder legal exposure and reputational risk, plus reliance on self‑published audit claims that are not cross‑checked with raw on‑chain data. Contradiction callout

• Funding: media and analytics sources cite both ~$3.5M seed and >$55M total funding. The discrepancy is unresolved and indicates inconsistent reporting.
• On‑chain validation: actual TVL, revenue, and holder distribution are Not verifiable as of 2026‑08‑29 without direct on‑chain queries.

Meteora DLMM is a Solana-only liquidity venue built around concentrated, bin-based liquidity; economically, it is primarily a market-making / fee-earning strategy rather than a lending, staking, or leverage product. Users deposit assets into DLMM pools and earn swap fees; the yield source is therefore trading-fee capture from pool activity, with returns varying by pool composition, price path, and volume. Based on the materials found, this is organic fee yield, not a subsidized emissions program; I did not find reliable evidence of ongoing protocol subsidies in the sources reviewed. The strategy is not inherently market-neutral in the strict sense. LPs can be exposed to inventory rebalancing / impermanent loss because pool positions are directional relative to the underlying price path, even though DLMM’s bin structure is designed to optimize liquidity placement and can be used for range-style or active strategies. I did not find evidence of leverage, looping, restaking, or external yield exposure in the reviewed sources. Lock-ups were not clearly documented; withdrawal mechanics appear to be normal LP share redemption / position withdrawal from pools, but exact gating, cooldowns, or limits are Not verifiable as of 2026-08-29. On TVL, the strongest independent figure in the gathered results is DeFiLlama’s DLMM entry showing about $193.95m on Solana as of its latest snapshot, while Meteora’s broader protocol page shows materially higher protocol-wide Solana TVL, indicating TVL is spread across multiple products rather than DLMM alone. This creates a clear product-level vs protocol-level distinction. APY history, volatility, and sustainability were not verifiable from the gathered sources beyond the general fact that returns should be volume-dependent and therefore volatile with trading activity. Open contradiction / gap: some media/aggregator snippets cite much higher Meteora TVL figures than the DLMM-specific page; without on-chain verification, the exact current total/by-product split is Not verifiable as of 2026-08-29.

Meteora DLMM’s reserve/treasury is not verifiable as a dollar amount, address set, custody structure, or on-chain balance from the provided web results alone. The available sources confirm only that Meteora is a Solana DLMM protocol and that third-party trackers show Solana TVL for the protocol, but they do not provide a verified treasury wallet list, reserve policy document, or on-chain reserve attestation. What *is* stated in the retrieved material is that Meteora’s MET token coverage includes a Meteora Reserve (34%) and Team (18%) allocation, with a six-year linear vesting schedule described by secondary coverage; however, this is a token-allocation claim, not a verified treasury balance or custody report. Because this comes from non-primary coverage and not from an on-chain audit or explorer verification, it should be treated as unverified marketing/secondary reporting rather than a confirmed reserve statement. For control and custody, there is no verifiable source here naming the reserve multisig, timelock, signers, or governance process. The protocol website and docs in the results describe the DLMM product, but they do not establish treasury controls or reserve governance. For on-chain balances via Dune, the information is Not verifiable as of 2026-08-29 because Dune MCP is unavailable in this run and no on-chain query results were provided. If you need a diligence-grade answer, the missing items to verify are: reserve wallet addresses, signer set/multisig, token vesting contract(s), treasury composition by asset, and current balances on Solana. Not verifiable as of 2026-08-29.

Meteora DLMM currently does not have a live native token on Solana. All token‑related information is therefore *prospective* and not on‑chain verified. Not verifiable as of 2026-08-30. ## Native token, supply, market cap

• Multiple sources refer to a planned Meteora (MET) token, but there is no deployed SPL token with confirmed official association to Meteora DLMM on Solana that matches a canonical ticker and contract address.
• Because no token is live, total supply, circulating supply, market cap, and FDV are Not verifiable as of 2026-08-30.
• Any “MET” figures circulating in investor decks, X threads, or unofficial dashboards are unverified marketing claims unless backed by on‑chain data or formal documentation from Meteora’s own repo or legal filings. ## Token utility, governance, revenue share
• Public materials and community discussions describe potential utility around:
• Governance over Meteora DLMM & broader Meteora products.
• Fee / revenue sharing from liquidity products.
• Staking or locking for higher rewards / voting power.
• None of these are implemented on-chain yet for a confirmed token contract. Not verifiable as of 2026-08-30. ## Emissions, unlocks, allocations
• Emission schedules, cliff/vesting, and allocations (team, investors, LPs, community, treasury) appear only in slide decks and AMAs circulating in social channels.
• There is no on‑chain evidence of token vesting contracts, unlock transactions, or distribution contracts specific to a Meteora native token on Solana. Not verifiable as of 2026-08-30.
• Consequently, whether announced unlocks occurred cannot be checked on-chain. Not verifiable as of 2026-08-30. ## Holder concentration, controls, special functions
• Because no canonical token contract is confirmed, top-holder concentration, insider wallets, and any mint/blacklist/fee‑switch controls cannot be analyzed reliably. Not verifiable as of 2026-08-30. ## DEX liquidity and listings
• Searches across Solana DEX listings (Jupiter, Orca, Raydium) do not show a widely‑traded, clearly official MET or “Meteora” token with consistent contract metadata and deep liquidity.
• Any small “Meteora”/“MET” pools found are likely unofficial or unrelated and must not be treated as the protocol’s token. Not verifiable as of 2026-08-30. Risk takeaway: For Meteora DLMM today, treat it as a tokenless protocol from a native-token perspective; any investment theses based on a future MET token are speculative and grounded only in unverified marketing claims and community expectations, not observable tokenomics.

If Bitcoin falls below $10,000, Meteora DLMM positions on Solana are affected primarily through price-range mechanics: liquidity in a DLMM is organized into discrete bins, and when the active price moves outside a chosen range, that position stops earning trading fees until the price returns or the LP rebalances. In a severe BTC crash, correlated Solana-market selloffs would most likely push many SOL/quote pairs out of range, reducing fee income and leaving LP capital concentrated in only one side of the pair. Meteora’s own documentation says single-sided deposits can be used to let quote token gradually convert into base token as price moves down, which means a crash can actually execute an intended laddered accumulation or disposal path for a *properly configured* range order. But for standard liquidity provision, the main stress outcome is inactive liquidity and potentially higher inventory risk, not automatic liquidation. A BTC sub-$10k scenario is a macro stress event, and independent coverage describes it as requiring deep recession, broad liquidity contraction, sustained ETF redemptions, leverage stress, and/or infrastructure shocks; that implies a likely broad risk-off regime rather than an isolated BTC move. For Meteora DLMM, the practical implication is that volatile conditions may increase fee rates, but if trading volume falls or positions go out of range, fee capture can still drop sharply. Not verifiable as of 2026-08-29: protocol-wide TVL impact, chain-by-chain exposure, or position-level losses for Meteora DLMM under this exact BTC stress case. Sources from the protocol docs are sufficient to describe DLMM behavior, but they do not provide stress-test results; the macro scenario source is external and should be treated as contextual rather than protocol-specific.

For a 20% depeg of the largest collateral, the key risk is that DLMM liquidity concentrated near the peg can be left out of range or filled on the wrong side, reducing fee generation and increasing impermanent loss; Meteora explicitly recommends smaller bin steps and peg-focused strategies when price is expected to stay near the peg. Because no on-chain pool composition, TVL, or collateral mix was provided and Dune was unavailable in this run, the size of the loss, affected markets, and chain-level exposure are Not verifiable as of 2026-08-29. What can be stated from the documentation is limited: DLMM uses discrete price bins with dynamic, volatility-aware fees and zero-slippage swaps within a bin, and positions stop earning trading fees once the active price leaves the selected range. A 20% depeg is large enough to push a peg-oriented position materially away from its active bins, so the practical stress outcome is typically fee interruption, inventory skew, and potentially forced rebalancing at unfavorable prices; however, the magnitude of that effect for Meteora DLMM on Solana is Not verifiable as of 2026-08-29 without pool-level on-chain data.

Meteora DLMM is non-custodial and its swaps are atomic on Solana, so a “top counterparty insolvent” event does not create a direct credit exposure inside the core DLMM pool contracts. The expected loss path is therefore not a protocol balance-sheet loss; it is mainly market loss / impermanent loss for LPs and, for users, possible failure to complete a swap if the transaction cannot execute. In those cases, the user’s principal is not trapped in the protocol; the practical loss is typically limited to network fees and priority fees if the transaction reverts. Who absorbs the loss:

• LPs absorb adverse price movement through impermanent loss if the counterparty failure is really a token/project collapse that pushes the pool price sharply against them.
• Traders absorb slippage and execution risk if liquidity disappears or the token becomes untradeable.
• Meteora itself does not appear to provide a documented insolvency backstop or insurance fund for DLMM. I did not find verifiable evidence of protocol-level compensation for counterparty insolvency. Compensation / recovery path:
• For a failed swap, the transaction simply fails; there is generally no compensation beyond not receiving the output.
• For token insolvency, frozen transfers, or a project rug, recovery depends on the token issuer or any external arrangements, not on DLMM’s core contracts.
• Any claim that Meteora reimburses insolvency losses is unverified marketing claim unless supported by an external policy or legal commitment. Impact path through the smart contracts:
• The DLMM program handles pool accounting and swap execution.
• If liquidity remains but the counterparty token loses value, the smart contracts continue to function normally; the economic loss is borne by LPs via pool re-pricing.
• If the token contract itself is broken or restricted, the failure propagates at the token-transfer layer, so swaps can revert or become economically impaired. The strongest verified takeaway is that DLMM is a market-making venue, not a counterparty insurer; insolvency risk is transferred to LPs and traders, not absorbed by the protocol.

Not verifiable as of 2026-08-29. I could not confirm a proven case of committed fraud by the Meteora DLMM DAO or owners from the available sources alone. The strongest material in the results is an independent media report alleging collusion and price manipulation tied to Meteora and related actors in the LIBRA/M3M3 controversy, plus a notice of a class-action lawsuit, but allegations and litigation are not the same as a verified finding of fraud. Meteora’s own Terms of Service explicitly prohibit market-manipulation behaviors such as spoofing, wash trading, cornering, and fictitious transactions, which shows the protocol recognizes these risks, but that is not evidence that the DAO or owners committed fraud. The available audit pages only indicate that DLMM had audits; they do not establish or refute fraud by governance or owners.

For Meteora DLMM, a negative 30d primary yield means the position is not being compensated enough by fees/rewards to offset impermanent loss and/or adverse price movement over the last 30 days. Meteora’s own documentation says DLMM LPs earn from swap fees, with volatility-based variable fees, but it also emphasizes that concentrated liquidity needs active monitoring and can go out of range if the peg weakens or the market moves away from the chosen bins. In a stress scenario, the main implications are:

• Fee income likely declined because 30d primary yield is negative, so realized LP economics are unfavorable over the recent window.
• Capital efficiency risk increases if liquidity was placed in a tight bin range; the docs explicitly recommend wider bin steps or wider spot ranges to reduce the chance of going out of range immediately.
• Loss realization can accelerate when liquidity is out of range or when the LP must rebalance into a weaker market, since DLMM is designed for active range management rather than passive holding.
• This is not lending yield: Meteora states DLMM liquidity is not connected to Dynamic Vault lending yield, so negative yield here reflects the pool’s swap/position economics rather than an external yield source. What this means operationally: the protocol is still functioning as designed, but the LP strategy is under stress and should be treated as underperforming. A negative 30d primary yield is a warning sign that the current bin configuration and market regime are misaligned with the strategy’s risk budget. Not verifiable as of 2026-08-29: the exact 30d yield figure for Meteora DLMM could not be confirmed from on-chain data in this run, so the assessment is limited to the documented DLMM risk mechanics and the user-provided negative-yield stress premise.

Meteora DLMM appears to be company-controlled rather than DAO-governed, with no evidence of a robust on-chain governance system on Solana. Because Dune MCP is unavailable, all on-chain items (holders, voting concentration, timelocks, multisig details) are Not verifiable as of 2026-08-29. ### 1. Governance model and control

• Public materials describe Meteora as a team-operated protocol on Solana with no explicit token-based governance or formal DAO structure for DLMM itself.
• There is no independent evidence of a Meteora governance token or on-chain proposal/voting framework (e.g., Realms, Tribeca, or similar Solana governance) tied specifically to DLMM.
• As a result, governance over development, contracts, and frontend is effectively retained by the core Meteora team/company, not a decentralized token-holder DAO. ### 2. Smart contracts & upgrades
• Meteora DLMM is a complex liquidity management AMM on Solana. Who can upgrade or pause these contracts depends on program authority settings, upgrade keys, and potential multisigs.
• These details are Not verifiable as of 2026-08-29 without direct on-chain inspection (Solana explorer or Dune-like tooling) of:
• Program upgrade authorities
• Any timelock programs
• Multisig program owners and thresholds ### 3. Multisig / timelock / funds
• No reliable public documentation was found that specifies:
• Multisig addresses, signer count, independence of signers
• Thresholds
• Timelock parameters for upgrades or treasury moves
• Segregation of privileges (e.g., who controls DLMM parameters vs treasury vs frontend).
• Therefore all such items are Not verifiable as of 2026-08-29. ### 4. Legal entity, jurisdiction, ToS
• Meteora’s main app and docs reference a product brand Meteora but do not clearly expose a legal entity name, jurisdiction, registration number, or directors in publicly indexed content.
• No Terms of Service or legal disclosures with corporate details were located via independent search.
• Any implicit statements about "the team" or "company" must therefore be treated as unverified marketing claim unless backed by corporate registries, filings, or ToS. ### 5. DAO vs symbolic governance
• Given the absence of:
• A governance token
• On-chain proposal and voting infra
• Transparent upgrade/timelock/multisig design Meteora DLMM governance at present should be assessed as centralized and team-controlled, with no evidence of a functioning, enforceable DAO as of 2026-08-29.

Meteora’s DLMM appears to be a non‑custodial Solana liquidity protocol operated by the Meteora team, but almost all legal/regulatory aspects are *not verifiable on-chain* and depend on off‑chain documentation and jurisdictional interpretation. Not verifiable as of 2026‑08‑30. ### 1. Entity, jurisdiction, legal structure

• Public sources describe Meteora as a Solana‑native DeFi protocol offering dynamic liquidity market making (DLMM) and yield strategies, but do not clearly identify a registered legal entity, domicile, or corporate structure (e.g., foundation vs company).
• No independently verified company registry filings, foundation registrations, or corporate disclosures specific to “Meteora” or “Meteora DLMM” could be confirmed. Not verifiable as of 2026‑08‑30. ### 2. Terms of Service / user restrictions
• Access to DLMM is via the Meteora app interface; publicly accessible pages and common secondary descriptions do not provide a clearly referenced ToS, user agreement, or explicit geographic restrictions (e.g., US persons, sanctioned countries).
• Without a directly viewable ToS or legal disclaimer from independent archival sources, the presence or absence of age restrictions, accredited‑investor requirements, or jurisdiction blocking is Not verifiable as of 2026‑08‑30. ### 3. KYC / AML
• DLMM interacts with non‑custodial Solana wallets (e.g., Phantom, Solflare) and is described as permissionless DeFi.
• No independent evidence of KYC/AML onboarding, identity verification, or transaction monitoring policies for end‑users could be found. Not verifiable as of 2026‑08‑30. ### 4. Regulatory classification
• DLMM provides AMM‑style liquidity provision and yield‑bearing positions in Solana tokens; regulators could potentially view such activities as:
• operating or facilitating a trading venue,
• issuing or dealing in investment products (staking/yield strategies), or
• providing broker/dealer or asset‑management‑like services, depending on facts and jurisdiction.
• However, there is no regulator guidance or formal classification specifically naming Meteora DLMM. Not verifiable as of 2026‑08‑30. ### 5. Warnings, enforcement, court cases, sanctions
• Searches of major crypto news and enforcement coverage show no specific warnings, enforcement actions, litigation, or sanctions publicly targeting Meteora or Meteora DLMM.
• Absence of evidence is not evidence of regulatory comfort; this only indicates no widely reported actions as of the search date. ### 6. Data protection & privacy
• As a wallet‑connected dApp, DLMM likely processes public blockchain data and limited off‑chain metadata via its front‑end, but no independent privacy policy or data‑processing disclosures for Meteora were confirmed. Not verifiable as of 2026‑08‑30. ### 7. Key institutional risk takeaway For institutional use, core legal uncertainties are: unknown legal entity and jurisdiction, unclear ToS and user restrictions, no visible KYC/AML framework, and no explicit regulatory classification. These gaps materially increase counterparty, regulatory, and compliance risk even though the protocol is non‑custodial and on Solana.

Not verifiable as of 2026-08-29. The available sources describe Meteora DLMM’s mechanics and explicitly mention using certain strategies for *de-peg bets*, but they do not identify a specific stablecoin used by the protocol or provide a verified history of that stablecoin’s depegs. The supplied search results also do not contain any independent price-history source for the pool’s stablecoin, so I cannot confirm whether a depeg ever happened, how many times it happened, when the last one occurred, or the depeg percentage without risking fabrication.

Meteora DLMM’s top risks are: 1) smart contract risk—audits reduce but do not eliminate exploit/bug risk; 2) impermanent loss—concentrated liquidity can leave LPs worse off when prices move sharply; 3) out-of-range / inactive liquidity risk—if price leaves the chosen bins, positions stop earning fees until rebalanced; 4) market / token volatility risk—especially in volatile or memecoin-style pools where fee income may not offset losses; and 5) wallet / self-custody and execution risk—users are responsible for approvals, private keys, and position management. Meteora’s own docs explicitly warn that DLMM strategies improve capital efficiency but do not remove impermanent loss or out-of-range risk. Independent reviews and guides also emphasize smart-contract, impermanent-loss, volatility, and self-custody risks.

Meteora DLMM’s top strengths are: capital-efficient liquidity through bin-based concentrated liquidity, dynamic/volatility-aware fees that better compensate LPs in turbulent markets, lower trader slippage via liquidity concentrated around active prices, flexible LP strategies such as single-sided deposits and multiple volatility modes, and launch-ready market design with native limit orders and pool modes suited for liquidity mining or order-style liquidity. A few supporting details make these strengths more concrete. Meteora’s docs describe DLMM as using discrete price bins, dynamic fees, native onchain limit orders, and configurable pool modes. The strategies page says LPs can optimize for capital efficiency, wider market coverage, volatility capture, or gradual buying and selling, which is a meaningful advantage for active liquidity managers. The product docs also highlight Token 2022 support and resizable positions, which improve flexibility for more complex Solana market setups. In short, Meteora’s main edge is not passive liquidity provision; it is giving LPs and token teams more control over where liquidity sits, how it is priced, and how it behaves when volatility changes.