Meteora · DeFi Risk

DeploymentsSolana · —

Risk profile at a glance

1 red · 6 yellow · 4 green

Categories & evidence

184 factors · 13 categories

Code & audits Yellow 27 25 of 25

RD-F-002 green Audit recency Most recent audits: DAMM v2 v0.2.0 and DBC v0.1.10 audited by Offside Labs and Zenith in June 2025. DLMM v0.11.0 by Zenith and Offside Labs (2024-2025). Dynamic Vault by Offside Labs Sept 2024. All flagship programs have audits within 12 months.

RD-F-004 green Audit count At least 8 distinct firms confirmed from MeteoraAg/audits repo: Quantstamp, Halborn, Oak Security, Sec3, OtterSec, Offside Labs, Zenith, Sherlock. SolanaCompass additionally claims Zellic, Bramah Systems, and Neodyme for earlier DLMM and DAMM/Vault coverage. Conservative count of 8 confirmed firms far exceeds the green threshold of 2.

RD-F-008 green Ignored bounty disclosure No Meteora or Mercurial contract exploits are known. Profile and data-cache confirm zero incidents (hacks:[], rekt.incidents:[]). No post-mortem cites an ignored disclosure. Factor is assessing whether a disclosed vulnerability was ignored before exploit - with no exploits, this is affirmatively clean.

RD-F-018 green Signed/unsigned arithmetic confusion Rust type system strongly differentiates i64/u64; signed/unsigned mismatch is a compile-time error in Rust. Release builds use overflow-checks=true (confirmed in dlmm-sdk Cargo.toml). No published audit finding of signed/unsigned confusion found across 8 firms' coverage.

RD-F-022 green Public initialize() without initializer modifier Anchor (v0.31.0) enforces account initialization via #[account(init)] and #[account(init_if_needed)] constraints with PDA bump seeds and discriminators. The discriminator system prevents re-initialization (calling an init instruction on an already-initialized account fails the discriminator check at runtime). DBC program exposes initialize_virtual_pool_with_spl_token and initialize_virtual_pool_with_token2022 instructions using standard Anchor constraints. Eight audit firms across multiple versions with no published reinit vulnerability finding. The OZ initializer modifier equivalent is structurally enforced by the Anchor framework.

RD-F-024 green Code complexity vs audit coverage Seven-plus distinct programs each audited by at least 2 firms per version increment. MeteoraAg/audits contains 10 subdirectories with 40+ individual audit PDFs covering DLMM, DAMM v1, DAMM v2, DBC, Alpha Vault, Dynamic Vault, Stake2Earn, Zap, Dynamic Fee Sharing, Presale Vault. README policy: at least 2 different auditors each time a new version is released. This per-version multi-firm model provides adequate coverage relative to code complexity.

Governance & admin Yellow 38 24 of 24

RD-F-032 red Timelock duration on upgrades Squads v3 multisig has no on-chain time_lock field by design. Timelock duration = 0 hours for program upgrades. Any claimed Meteora timelock is off-chain policy only and not enforceable. This is a structural characteristic of Squads v3 (no time_lock field in borsh layout), confirmed by SOLANA_GOVERNANCE.md. Peers using Squads v4 (e.g., Kamino 12h) have on-chain timelocks; Squads v3 peers (Jupiter, Raydium, Sanctum Unstake) also have 0h on-chain delay. RD-F-033 red Timelock on sensitive actions No on-chain timelock on any sensitive action (upgrade, pool disable, config change). All gated by Squads v3 multisig threshold only, with immediate execution after threshold approval. DBC set_pool_status (enable/disable pools) callable by admin without on-chain delay. DLMM config changes and DAMM v2 admin actions similarly untimelocked. Squads v3 structural constraint — no time_lock field. RD-F-038 red Proposal execution delay < 24h Squads v3 executes program upgrades immediately after threshold approval — on-chain execution delay is 0 hours. No proposal queue or delay mechanism. This is a structural Squads v3 property (no time_lock field). All admin actions (upgrade, config, pool disable) execute with 0-hour delay once multisig threshold is met. RD-F-025 yellow Admin key custody type DLMM upgrade authority is off-curve PDA controlled by Squads v3 multisig CoEsykatDegLB7pcMJia79JSriDdi71nPnjgeSfw623k. Effective admin custody type is multisig with no on-chain timelock. MET governance: forum-based, not yet on-chain (July 2025 forum: no viable DAO voting plan). Other programs (DAMM v1/v2, DBC, Alpha Vault, M3M3, Dynamic Vault, Mercurial legacy) upgrade authorities not individually decoded this pass. SolanaCompass references Realms SafeSnap but not confirmed operational. RD-F-028 yellow Low-threshold multisig vs TVL Squads v3 multisig controls DLMM upgrades. Threshold (M) and member count (N) not decoded this pass — borsh RPC decode required but unavailable in agent environment. TVL $319.9M requires 3-of-5 or higher peer norm. No public threshold attestation found. July 2025 governance forum confirms team controls decisions without DAO voting. Cannot confirm threshold adequacy; risk of low threshold given no external signers confirmed. Yellow pending threshold decode. SOLANA_GOVERNANCE.md reference table shows Raydium at 2/3 (acknowledged low), Jupiter at 4/7, Kamino 5/10. RD-F-034 yellow Guardian/pause-keeper distinct from upgrader No dedicated pause-keeper or guardian role distinct from the upgrade authority found. DBC set_pool_status (admin disables pools) flows through the same multisig-controlled admin path as upgrades. No evidence of a separate, lower-privilege guardian multisig that can act independently of the upgrade path. Partial mitigation: pool-level disable capability does provide some emergency control without requiring a full program upgrade. RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle DBC and DAMM v2 show some role separation: feeClaimer field (fee collection) is separate from upgrade authority. pool_creator_authority controls pool creation separately from fee admin. DLMM has no oracle role (no external oracle used). However, the top-level Squads v3 multisig likely controls all admin roles including fee and config — full role separation not confirmed. Role graph incomplete without signer-level enumeration. RD-F-040 yellow Emergency-veto multisig present No emergency-veto multisig or security council identified. The Squads v3 multisig is the single control layer with no veto counterpart. Governance forum and SolanaCompass profile do not describe a guardian council or emergency-veto structure. Pool-level disable (DBC set_pool_status) provides partial emergency capability but is controlled by the same admin path. RD-F-041 yellow Rescue/emergencyWithdraw without timelock Squads v3 has no on-chain timelock — all admin operations (including any pool-drain or config-reset equivalent) execute with 0 on-chain delay after threshold approval. DBC set_pool_status (disable pools) is callable by admin without timelock. No confirmed dedicated emergencyWithdraw function found in DLMM public source, but all admin functions share the same untimed execution path. Multiple signer approvals required (multisig enforced), preventing single-key instant drain. Yellow vs red: multisig threshold protection mitigates single-actor immediate drain, but zero on-chain delay remains. RD-F-026 gray Upgrade multisig signer configuration (M/N) Squads v3 multisig CoEsykatDegLB7pcMJia79JSriDdi71nPnjgeSfw623k threshold and member count not decoded. Borsh decode requires direct RPC getAccountInfo not feasible in agent environment. No public disclosure of threshold found in documentation, governance forum, or search results. Per-program upgrade authority enumeration for other programs also incomplete. RD-F-029 gray Multisig signers co-hosted Signer addresses for Squads v3 multisig not publicly disclosed. Cannot assess co-hosting or ASN overlap. RD-F-030 gray Hot-wallet signer flag Signer addresses not known. Cannot assess hot-wallet behavior patterns. RD-F-031 gray Signer rotation recency No signer rotation events found in public governance forum or docs. Cannot decode on-chain rotation history without signer addresses. No threshold reduction events identified in available sources. RD-F-037 n/a Quorum achievable via single-entity flash loan No on-chain governor exists; quorum-via-flash-loan attack surface is not present. Factor requires an on-chain governor with quorum threshold. RD-F-039 n/a delegatecall/call in proposal execution without allowlist Solana BPF has no delegatecall opcode. No EVM-style governor with delegatecall execution path exists. Solana uses CPI (Cross-Program Invocation) which is architecturally distinct and not subject to the same attack vector. Factor is structurally inapplicable to Solana non-EVM substrate. RD-F-042 gray Admin has mint() with unlimited max DBC token_update_authority can allow creator/partner to mint tokens depending on pool configuration. This is a pool-creator-level option, not a protocol-admin unlimited mint on a governance/collateral token. MET token minting authority not confirmed as held by admin multisig with unlimited capability. No evidence of unlimited admin mint power on a protocol-level token. Insufficient primary evidence to score green or red; gray due to Solana-program-level admin token authority opacity. RD-F-044 gray Admin wallet interacts with flagged addresses Admin addresses (Squads vault PDA JADaUV8k, multisig CoEsykat) not cross-checked against flagged-address watchlists. Signer addresses unknown, cannot assess. No flagged-address report found for known admin addresses in public sources. RD-F-045 n/a Constructor args match governance proposal Solana programs use initialize instructions, not EVM constructor args. No EVM-style governance proposal with constructor arg specification applies. Structurally inapplicable to Solana non-EVM substrate. RD-F-047 gray Governance token concentration (Gini) MET token TGE October 2025, with 48% to community. Governance voting not yet live. Gini coefficient of MET distribution not assessed — no on-chain governor records exist to compute voting-power distribution. DeepDAO or equivalent analysis not performed. RD-F-167 gray Deprecated contract paused but pause reversible by live admin Mercurial legacy Multi-token Stable Pool (MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky) is a deprecated program. Whether it holds material value (>$100k) and whether admin retains a reversible pause: not decoded this pass. Dynamic Vault (24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi) is legacy but may hold user funds. Upgrade authority and pause-state for both legacy programs not verified.

RD-F-027 green Single admin EOA DLMM upgrade authority JADaUV8kvDpDbJr55wxXJHVaBS3VCj8thZZHjfeuCVLd is off-curve (is_on_curve = FALSE per SOLANA_GOVERNANCE.md methodology). This is a Squads v3 vault PDA, not a single private-key EOA. Controlled by Squads v3 multisig CoEsykatDegLB7pcMJia79JSriDdi71nPnjgeSfw623k. Not a single admin EOA scenario. Anti-drift item-12 applied: do not score red based on upgrade authority address alone without curve classification.

RD-F-036 green Flash-loanable voting weight No on-chain governor with flash-loanable voting weight exists. MET token governance remains forum-based (Discourse) as of July 2025 — no on-chain voting program deployed. Data-cache snapshot_space = null. No Snapshot, Tally, or Realms governor with live voting confirmed. Flash-loan attack on governance not applicable without a live on-chain governor.

RD-F-043 green Admin = deployer EOA after 7 days DLMM upgrade authority is off-curve PDA (Squads v3 vault PDA), not a deployer EOA. Governance has been multisig-controlled since at least the Mercurial/Meteora rebrand era (2022-2023). The protocol was not launched with a deployer EOA retaining admin power. No evidence of a single EOA deployer holding admin rights beyond 7 days.

RD-F-046 green Contract unverified on Etherscan/Sourcify All major Meteora programs are open-source on MeteoraAg GitHub with public IDLs. Programs are verifiable on Solscan/Solana Explorer. MeteoraAg/audits repo contains 40+ audit PDFs covering all major programs. Multiple audit firms (8 total: Offside Labs, OtterSec, Sec3, Zenith, Halborn, Quantstamp, Oak Security, Sherlock) have engaged. Not an unverified launch scenario.

Oracle & external dependencies Green 17 17 of 17

RD-F-050 yellow Dependency graph (protocols depended upon) Main swap products (DLMM, DAMM v2, DBC) are self-contained with Solana SPL Token Program as the only system-level dependency. DAMM v1 calls into Dynamic Vault (24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi). Dynamic Vault CPI-calls Solend and Tulip Protocol (named in docs); documentation says 'various lending protocols' without full enumeration. Precise CPI target list requires reading vault program account data [?]. Scored yellow due to incomplete lending-platform enumeration for Dynamic Vault. RD-F-051 yellow Fallback behavior on oracle failure No primary oracle exists in DLMM/DAMM/DBC swap paths, making oracle-failure fallback N/A for core AMM products. For Dynamic Vault: Hermes keeper rebalances across lending platforms when one becomes unavailable, which functions as an operational fallback. However, this is keeper-dependent with no confirmed on-chain automated failover circuit. If Hermes fails, vault allocations freeze in last-known state (liveness risk, not immediate fund loss). Scored yellow for keeper-only fallback without on-chain circuit. RD-F-052 yellow Breakage analysis per dependency Breakage analysis partial. Core swap products (DLMM, DAMM v2, DBC) are self-contained; no external dep failure impairs their swap execution. Dynamic Vault: Solend/Tulip failure could impair yield delivery and, if those protocols are exploited, funds deposited there are at risk. Hermes keeper failure halts rebalancing (liveness, not direct loss). No published Meteora-authored breakage analysis for vault lending dependencies. Scored yellow: major deps identified but no formal breakage document exists. RD-F-062 yellow External keeper/relayer not redundant Dynamic Vault relies on the Hermes keeper (operated by Meteora) to rebalance allocations across lending protocols (Solend, Tulip, others). Documentation describes Hermes as rebalancing every few minutes, triggering the rebalance crank when allocation drifts >0.1%. No documentation confirms multiple independent Hermes instances, a permissionless fallback keeper, or an on-chain automated failover. If Hermes fails, Dynamic Vault stops rebalancing and vault funds remain static in last-allocated lending protocols (liveness risk for yield optimization). DLMM/DAMM v2/DBC do not use keepers in their swap path and are unaffected. Scored yellow: single keeper with no confirmed redundancy for Dynamic Vault. RD-F-054 n/a TWAP window duration No TWAP oracle is used by any Meteora swap product. DLMM, DAMM v1/v2, and DBC use internal on-chain state for pricing; no DEX pool TWAP window exists in the protocol. RD-F-055 n/a Oracle pool depth (USD) No DEX-TWAP oracle is used. Oracle pool depth measurement is inapplicable when no oracle pool is consumed. RD-F-056 n/a Single-pool oracle (no medianization) No single-pool or multi-pool oracle is used by Meteora swap products. Medianization across venues is not applicable when no external price feed is consumed. RD-F-057 n/a Circuit breaker on price deviation No oracle price is consumed in the swap path; circuit breaker on oracle price deviation is not applicable for DLMM/DAMM/DBC. Dynamic Vault has risk-allocation caps per lending platform (not a price-deviation circuit breaker). RD-F-058 n/a Max-deviation threshold (bps) No oracle circuit breaker threshold configured; no oracle is consumed. Max-deviation bps is inapplicable. RD-F-059 n/a Oracle staleness check present No push-oracle is consumed; no staleness check is required or present in swap path. DLMM/DAMM/DBC read on-chain pool/bin state which is always current. Not applicable. RD-F-060 n/a Chainlink aggregator min/max bound misconfig Meteora does not use Chainlink on Solana. The EVM Chainlink min/maxAnswer misconfiguration pattern does not apply to the Solana substrate. Data-cache oracle_feeds=[]; no Chainlink feed addresses. Not applicable on both oracle-dependency and substrate grounds. RD-F-180 n/a Immutable oracle address CRITICAL-CANDIDATE F180 (PD-017): NOT_APPLICABLE for Meteora. Core swap programs (DLMM, DAMM v1/v2, DBC, Stake2Earn) consume no external oracle address — there is no hardcoded or immutable oracle address to assess. Dynamic Vault calls into lending protocol CPI endpoints (Solend, Tulip) but does not embed a hardcoded Pyth/Switchboard feed address as its own oracle price source. No EVM-immutable equivalent oracle pattern exists in Meteora's Solana programs. The immutable-oracle-address failure mode (USR/USDX/xUSD/USD0++ pattern) requires a lending protocol with hardcoded collateral price feed — Meteora is a DEX/AMM, not a lending protocol. Orchestrator note: F180 critical-CANDIDATE per PD-017 tracked separately. RD-F-181 n/a Permissionless-pool lending oracle Meteora is not a lending protocol and does not accept spot prices from permissionless pools as collateral oracle. DLMM, DAMM v1/v2, and DBC are pure AMMs with no borrow/lending surface. Dynamic Vault allocates yield capital but does not function as a lending market accepting token collateral priced from permissionless pools. RD-F-181 by definition applies to lending protocols accepting spot prices from permissionlessly-created DEX pools. Data-cache confirms borrow.present=false; protocol_type=DEX.

RD-F-048 green Oracle providers used No external oracle provider is used in any Meteora swap path (DLMM, DAMM v1/v2, DBC). Pricing is fully internal: DLMM uses bin-step math, DAMM v1/v2 uses constant-product formula, DBC uses supply-based bonding curve. Dynamic Vault calls Solend/Tulip CPI for yield allocation but does not import or validate external price feeds directly. Data-cache oracle_feeds=[]; Solana program oracle field=null.

RD-F-049 green Oracle role per asset No oracle-per-asset mapping exists. Meteora AMM products use internal on-chain state for pricing, not external price feeds. The absence of oracle dependency is the correct design for a pure AMM on Solana. Dynamic Vault reads APY from lending protocols, not asset prices.

RD-F-053 green Oracle source = spot DEX pool (no TWAP) CRITICAL FACTOR - GREEN. Meteora DLMM, DAMM v1/v2, and DBC do NOT use any spot DEX pool price feed. Prices emerge from on-chain bin state (DLMM bin-step math: P*x+y=L constant-sum per bin; DAMM constant-product; DBC bonding curve f(supply)). No slot0() call, no getReserves() call, no external price oracle in any swap path. Data-cache oracle_feeds=[]. DLMM docs confirm bin-step deterministic pricing without oracle. DAMM v2 source: constant-product formula with no oracle module. DBC lib.rs: no Pyth/Switchboard/Chainlink imports.

RD-F-061 green LP token balanceOf used for pricing No LP token balanceOf pricing pattern used in Meteora swap products. DLMM uses bin reserve state and bin_step math; DAMM uses constant-product reserves math; DBC uses supply-based bonding curve. None of these derive pricing from balanceOf of LP tokens in a contract, eliminating the donation-manipulation attack surface.

Economic risk Yellow 33 13 of 13

RD-F-063 yellow TVL (current + 30d trend) TVL $319.87M (2026-05-16). 30-day change -21.63%. 12-month peak $1.687B on ~2025-01-09, driven by TRUMP/MELANIA memecoin launch liquidity on Meteora. Peak-to-current decline ~81%. 90-day CoV 0.084 (mean $392.6M, std $33.1M). Sustained downward drift from Jan 2025 peak following LIBRA scandal and co-founder resignation. TVL is above the $100M coverage threshold but in a structural decline trend. Yellow: elevated volatility, memecoin-correlated peak, ongoing -21.63% 30d decay. RD-F-065 yellow Liquidity depth per major asset Meteora DLMM is top-3 Solana DEX by volume (~26% of Solana DEX activity per Artemis/Blockworks analytics as of late 2025). SOL/USDC and major stable-pair pools have substantial liquidity depth. DBC/memecoin pools are structurally thin at launch — inherent to bonding curve bootstrapping mechanics. Aggregate 2%/5% slippage depth figures are not available from DefiLlama for multi-pool Solana AMMs; programmatic pool-by-pool enumeration not implemented in data pipeline. Yellow: depth is adequate for major pairs but thin for the long-tail/memecoin pool segment that contributed a disproportionate share of peak TVL. RD-F-072 yellow Market-listing governance threshold Adapted for DEX context: Meteora DBC is a fully permissionless token-launch platform — any user can create a new bonding curve with zero governance threshold. This is intentional and a core product feature, but it is the direct mechanism by which TRUMP (Jan 2025), MELANIA (Jan 2025), and LIBRA (Feb 2025) tokens were launched on Meteora infrastructure, driving the memecoin-correlated TVL spike and subsequent 81% collapse. Per-pool DLMM/DAMM creation is also permissionless. Yellow: permissionless listing creates structural exposure to memecoin-launch cycles — a material economic risk for Meteora's TVL profile as demonstrated by the Jan 2025 event. RD-F-064 gray TVL concentration (top-10 wallet share) Meteora is a multi-pool Solana AMM suite (DLMM, DAMM, DBC) with hundreds of individual pools. LP positions are per-account NFTs (DLMM) or fungible LP token holders (DAMM) spread across thousands of pools. DefiLlama data-cache provides no depositor-concentration field for Solana AMM protocols. Programmatic enumeration of top-10 LP wallet share across all Meteora pools requires Solana RPC enumeration not implemented in the data pipeline. Qualitative note: memecoin launch pools (DBC/ILM) are structurally concentrated (insider-seeded at launch per TRM Labs LIBRA analysis); major stable/SOL pairs are more distributed. RD-F-066 n/a Utilization rate (lending protocols) Meteora is a DEX/AMM protocol with no lending book. Utilization rate (borrowed/supplied ratio) is a lending-specific metric. DefiLlama data-cache confirms borrow.present=false, utilization_rate_pct=null. Taxonomy Cat 4 PD-024 explicitly marks this lending-only; N/A for DEX/AMM protocols. RD-F-067 n/a Historical bad-debt events Bad debt events are a lending-protocol phenomenon (losses socialized when collateral < debt). Meteora is a DEX/AMM with no collateral/borrow ledger. No bad debt event is possible at the Meteora protocol level. Taxonomy Cat 4 PD-024 marks this lending-only. RD-F-068 n/a Collateralization under stress Collateralization ratio under stress is a lending-protocol metric. Meteora has no collateral positions. Taxonomy Cat 4 PD-024 marks this lending-only. N/A for DEX/AMM. RD-F-069 n/a Algorithmic / under-collateralized stablecoin Meteora is a DEX/AMM, not a stablecoin issuer. No algorithmic or under-collateralized stablecoin design exists in the Meteora product suite. The legacy Mercurial multi-token stable pool is an AMM for stable assets, not an algo-stablecoin. Taxonomy Cat 4 PD-024 marks this lending/stablecoin-issuer-only. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) RD-F-070 is the critical-factor (★) for Compound V2 fork empty-cToken-market donation attacks. Meteora is an original Solana AMM (DLMM bin-based, DAMM constant-product, DBC bonding curve) with no Compound V2 fork lineage. Profile §5 explicitly confirms: 'Not forked / original. Meteora (previously Mercurial Finance) is an independently designed protocol suite.' No cToken mechanics, no share-based lending markets, and no zero-supply cToken exploit path exist. Taxonomy Cat 4 PD-024 states: 'Compound-fork-only (subset of lending-only): RD-F-070 — N/A for non-Compound-fork protocols.' ★ critical-flag penalty does NOT apply. RD-F-071 n/a Seed-deposit requirement for new market listing Seed-deposit requirement for new-market listing is a lending-protocol concept (prevents empty-market donation attacks). Meteora has no lending markets. DBC token launches do not require a seed deposit in the lending sense. Taxonomy Cat 4 PD-024 marks this lending-only. RD-F-073 n/a Oracle-manipulation-proof borrow cap Oracle-manipulation-proof borrow cap is a lending-protocol concept (per-asset borrow cap tied to oracle pool depth to prevent manipulation attacks). Meteora has no borrow book. Taxonomy Cat 4 PD-024 marks this lending-only. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) ERC-4626 vault virtual-share offset (OpenZeppelin >= 4.9 pattern) is an EVM/Solidity-specific primitive for preventing first-depositor share inflation. Meteora is a Solana-native protocol written in Rust, deployed as BPF programs — ERC-4626 does not exist in this architecture. Taxonomy PD-024 (lending-only) and substrate mismatch (Solana vs EVM) both render this not_applicable. RD-F-075 n/a First-depositor / share-inflation guard Adapted for Solana AMM context. DLMM uses position NFTs (not fungible LP tokens) — the classic ERC-4626 first-depositor share-inflation attack does not directly apply. DAMM v1/v2 mint fungible LP tokens proportional to pool share; the first-depositor inflation attack (donate tiny first deposit, then inflate per-share value against later depositors) may theoretically apply if the DAMM program does not implement a guard. DAMM v1 was audited by Oak Security (Oct 2022) and Halborn (Jul 2022); DAMM v2 by OtterSec (Apr 2025), Offside Labs, and Zenith. These audits would be expected to surface first-depositor inflation risks, but reading each audit PDF to confirm is outside programmatic scope. Not_assessed: requires curator to confirm whether DAMM programs include a minimum-liquidity burn / first-deposit guard in audit findings or program source.

Operational history Green 12 15 of 15

RD-F-089 red Insurance coverage active No active insurance coverage found on Nexus Mutual, Sherlock, Unslashed, or any equivalent platform for Meteora. Nexus Mutual is EVM-focused and does not list Solana protocols. Sherlock conducted a Dynamic Vault audit (v0.9.4) but audit engagements do not automatically confer ongoing coverage; no Sherlock coverage program for Meteora found. TVL at assessment: $319.87M. Even 5% coverage floor would require ~$16M active cover — not found. Structural gap: Solana DeFi insurance infrastructure is materially less developed than EVM-chain equivalents. RD-F-166 yellow Deprecated contracts still holding value The Mercurial Multi-token Stable Pool program (MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky) was sunsetted with the Feb 2023 rebrand but remains deployed on Solana mainnet as a BPFLoaderUpgradeable program. Meteora docs mention v1 stable pools were migrated to the Meteora.ag UI, but the underlying Solana program accounts are not self-destructible and remain on-chain. DefiLlama tracks meteora-damm-v1 as a continuing sub-slug, suggesting residual TVL attribution from legacy programs. Exact USD balance not determinable without direct Solana RPC access (Solscan returned 403). Scored yellow: residual TVL plausible but not confirmed above the $100K red threshold; evidence insufficient for green (program is deployed and not formally force-migrated with confirmed zero balance). RD-F-081 n/a Post-exploit response score No prior Meteora or Mercurial contract exploit. Post-exploit response score requires at least one incident to assess. Not applicable per factor definition: gray = no prior exploits (N/A). Using not_applicable per schema. RD-F-082 n/a Post-mortem published within 30 days No prior contract incident; no post-mortem to assess. Factor not applicable. RD-F-083 n/a Auditor re-engaged after last exploit No prior contract exploit; no re-audit-post-incident to assess. Factor not applicable. RD-F-085 n/a Incident response time (minutes) No prior contract incident; incident response time not applicable.

RD-F-076 green Protocol age (days) Mercurial Finance mainnet launch June 2021; as of 2026-05-16 approximately 1,810 days (59 months) live as a continuous entity (Mercurial then Meteora post-rebrand). Comfortably above the 365-day green threshold.

RD-F-077 green Prior exploit count Zero Meteora or Mercurial smart-contract exploits found across all sources: in-house hacks database (grep meteora/mercurial/DLMM = zero matches), DefiLlama API hacks field empty, Rekt data-cache empty, OSINT corroboration. No contract-level incident has been recorded in any public source as of 2026-05-16.

RD-F-078 green Chronic-exploit flag (≥3 incidents) Zero incidents per F077. Chronic-exploit threshold (>=3 incidents) not reached. Binary flag = false.

RD-F-079 green Same-root-cause repeat exploit Zero incidents; no root-cause cluster analysis possible. No repeat exploit of any kind found. Green by definition.

RD-F-080 green Days since last exploit No prior contract incident; factor definition: green if >365 days or no incidents. No incidents applies.

RD-F-084 green TVL stability (CoV over 90d) Data-cache tvl_cov_90d.cov = 0.08428 (mean $392.6M, std $33.1M, trailing 90-day window ending 2026-05-16T09:33:13Z). CoV 0.084 is below the green threshold of 0.15. The 90-day window captures a period of relative stability at post-scandal TVL levels (~$320-450M range), distinct from the high-volatility spike period around January 2025.

RD-F-086 green Pause activations (trailing 12 months) No deliberate pause activations with documented reason found in the trailing 12 months across any Meteora program. Solana programs use BPFLoaderUpgradeable and program-specific freeze authorities rather than EVM-style pause events; no pause-event record found in data-cache or OSINT. Green = 0 pauses.

RD-F-087 green Pause > 7 consecutive days No pause events found for any Meteora program in trailing 12 months. No pause exceeding 7 consecutive days identified. See F086.

RD-F-088 green Re-deployed to new addresses in last year No full protocol redeployment to new addresses in the trailing 12 months (May 2025 to May 2026). The Mercurial to Meteora rebrand (Dec 2022 / Feb 2023, >38 months ago) introduced new programs but is outside the 12-month window. Within trailing 12 months, incremental program updates (DAMM v2 v0.2.0 Jun 2025, DBC v0.1.10 Jun 2025) occurred but are versioned upgrades, not full re-deployments to new address sets. Active development confirmed (last GitHub commit 2026-05-14).

Real-time signals Green 7 22 of 22

RD-F-105 yellow DNS/CDN/frontend hash drift Cat 6B exploit-in-progress signal (T-09 v1 phase-2 signal). Legitimate meteora.ag frontend appears stable as of 2026-05-16. Multiple confirmed Meteora-brand phishing/typosquat domains actively targeting users: (1) meteora-ag.org — registered 2026-02-21 via Dynadot LLC, first detected 2026-02-26, flagged by 5 security vendors including PhishDestroy/MetaMask/SEAL blocklists; (2) ag.meteora.gifts — registered 2026-02-21 (same day coordinated registration); (3) meteora.to — registered 2025-08-24 via Spaceship Inc, HTTP 530 but domain still live 173+ days post-abuse report; (4) meteora.tools — flagged by 1 security vendor as of 2026-04-27. PCRisk published 'Fake Meteora Website Scam' removal guide. The coordinated same-day registration of meteora-ag.org and ag.meteora.gifts suggests an organized phishing campaign. Signal applies to legitimate domain integrity monitoring; typosquat ecosystem elevates urgency of active monitoring. RD-F-109 yellow Social-media impersonation scam spike Elevated brand-impersonation risk following LIBRA/M3M3 scandal. Multiple phishing domains active (meteora-ag.org, ag.meteora.gifts both registered 2026-02-21; meteora.to registered 2025-08-24; meteora.tools flagged April 2026). MET token TGE (Oct 2025) and ongoing SDNY litigation (amended complaint July 2025) create ongoing scam-incentive windows. PCRisk published 'Fake Meteora Website Scam' removal guide indicating active user-facing campaigns. No real-time social media monitoring feed available for this assessment; qualitative posture elevated relative to baseline. Requires curator social-listening tool per T-09 spec for production monitoring. RD-F-092 gray Unusual mempool pattern from deployer wallet Cat 6A precursor signal (T-09 phase-2 signal). Solana architecture: the deployer wallet analog is the Squads v3 multisig (CoEsykatDegLB7pcMJia79JSriDdi71nPnjgeSfw623k) rather than an individual EOA. Standard EVM mempool monitoring for deployer wallet unusual patterns does not apply. Solana transaction monitoring via RPC and Squads account-state polling is the structural equivalent but requires Squads-specific monitoring infrastructure not defined in the T-09 v1 signal spec. Last confirmed program activity: GitHub commit 2026-05-14 per data-cache. No unusual sequences observable from available public signals. RD-F-093 n/a Abnormal gas-price willingness from attacker wallet Solana uses compute unit pricing (priority fees), not EVM gas-price model. The signal threshold (5x EMA baseline gas-price willingness) is architecturally specific to EVM mempool gas auction mechanics. Solana compute unit prices behave differently and cannot be mapped to this threshold without protocol-specific re-specification. U10 Solana-substrate not_applicable. RD-F-094 n/a New contract with similar bytecode to exploit template Solana programs use BPF/SBF bytecode, not EVM bytecode. The EVM bytecode similarity tooling and the Etherscan 4-byte signature database that underpin this signal do not exist for Solana. Concept of attacker deploying exploit-contract mimicking protocol is applicable in principle but mechanically requires different substrate-native tooling not defined in the T-09 signal spec. U10 Solana-substrate not_applicable. RD-F-095 n/a Known-exploit function-selector replay Solana Anchor programs use 8-byte discriminators, not EVM 4-byte function selectors. The signal spec (call-pattern matching against known-exploit EVM function-selector replay templates) is EVM-architecture-specific. No equivalent Anchor-discriminator replay template database exists in the T-09 signal spec. U10 Solana-substrate not_applicable. RD-F-096 n/a New ERC-20 approval to unverified contract from whale Solana uses SPL token delegate authority model, not ERC-20 approve() approval model. The signal (ERC-20 approval to unverified contract from high-TVL user) is structurally incompatible with Solana's token account model. U10 Solana-substrate not_applicable. RD-F-099 n/a Oracle price deviation >X% from secondary DLMM pricing is entirely from on-chain bin state (active bin price + bin step). No external oracle price feed is consumed in the DLMM swap path. DAMM v1 Dynamic Vaults interface with external Solana lending protocols (Solend, Francium) that use Pyth/Switchboard internally, but Meteora's own swap execution does not call external oracle contracts. DBC bonding curve price is a mathematical function of token supply with no external oracle. DefiLlama data-cache oracle_feeds: []. Signal has no trigger surface on this protocol. RD-F-102 gray Admin/upgrade transaction in mempool Cat 6B exploit-in-progress signal (T-09 v1 phase-2 signal). Solana/Squads v3 equivalent: monitoring Squads v3 transaction queue for pending upgrade proposals on program upgrade multisig CoEsykatDegLB7pcMJia79JSriDdi71nPnjgeSfw623k. Squads v3 has NO on-chain time_lock; an approved upgrade transaction executes immediately when threshold signers have approved. No publicly observable pending upgrade transactions in Squads queue as of 2026-05-16 (based on Solscan DLMM program history and GitHub commit logs; last authorized commit 2026-05-14). Signal requires Solana/Squads account-state polling pipeline not yet implemented in T-09 v1 spec. RD-F-103 n/a Bridge signer-set change proposed/executed Meteora has no bridge surface (has_bridge_surface: false; cross_chain: false; layerzero.present: false per data-cache). Meteora is Solana-only. The bridge signer-set-change signal is doubly not applicable: no bridge exists (protocol-type not_applicable) and the EVM bridge-contract event monitoring spec does not translate to Solana. RD-F-106 n/a Cross-chain bridge unverified mint pattern Meteora is Solana-only (cross_chain: false; has_bridge_surface: false). No cross-chain bridge surface exists. The signal (cross-chain deposit-src mint-dst without proof pattern) has no trigger surface. U10 Solana-substrate and protocol-architecture not_applicable. RD-F-107 n/a Admin EOA signing from new geography/device Admin EOA signing geography/device fingerprint signal requires off-chain signing telemetry that is not distinguishable at the Solana chain level. Squads v3 multisig signing produces standard Solana signatures that cannot be attributed to geography or device fingerprint without off-chain metadata. EVM-specific device fingerprint signal architecture does not translate to Solana. U10 Solana-substrate not_applicable. RD-F-108 gray GitHub force-push to sensitive branch MeteoraAg GitHub organization is active with last commit 2026-05-14 per data-cache. Core repos: MeteoraAg/dlmm-sdk, MeteoraAg/dynamic-bonding-curve, MeteoraAg/damm-v2, MeteoraAg/audits. No GitHub force-push incidents identified in public reporting. Direct GitHub API query for force-push events to sensitive branches requires authenticated access not available in this assessment. No security advisories flagged. Signal would require GitHub API monitoring pipeline per T-09 phase-2 spec. RD-F-110 gray Unusual pending/executed proposal ratio No on-chain Governor contract exists for Meteora (no Realms on-chain program, no OZ Governor). MET token governance (Oct 2025 TGE) status as on-chain vs off-chain Snapshot unconfirmed. Discourse forum at proposals.meteora.ag shows normal active governance discussions (LP share proposals, MET governance evolution threads, loyalty point proposals). A computable pending/executed ratio baseline cannot be established without an on-chain Governor event stream. Signal requires Solana-specific governance contract monitoring not in T-09 v1 spec. RD-F-182 gray Security-Council threshold reduction (RT) Cat 6B batch-24 RT signal. Security-Council threshold reduction event. Applicable: Meteora uses Squads v3 multisig (CoEsykatDegLB7pcMJia79JSriDdi71nPnjgeSfw623k) to control DLMM upgrade authority. Squads v3 has NO on-chain time_lock — any approved threshold change executes immediately. An unannounced threshold reduction (e.g., from current threshold to a lower value) or new-signer addition within 14 days of another such change is the Solana analog of the Drift-class F182 event. Current posture: Squads v3 multisig threshold and current signer set NOT decoded (governance-admin-analyst task; requires SOLANA_GOVERNANCE.md Step 4 decode of CoEsykat... account data). The co-founder resignation (2025-02-18) may have involved signer-set changes on the multisig — unconfirmed. No publicly reported threshold change or signer anomaly identified in public sources. Signal is applicable and load-bearing for Meteora given no on-chain time_lock protection, but monitoring gap prevents assessment.

RD-F-090 green Mixer withdrawal → protocol interaction Cat 6A precursor signal. No confirmed mixer-funded wallet interacting with Meteora core contracts within the 30-day threshold window as of 2026-05-16. The LIBRA/M3M3 conduct matter (Hurlock v. Kelsier SDNY 2025-04-19) involved Kelsier-linked wallets operating allegedly manipulative liquidity positions on DBC/Alpha Vault; public reporting does not characterize these wallets as Tornado Cash proximate. LIBRA token launch involved direct USDC/SOL extraction via liquidity removal from Meteora DLMM one-sided pools, not a mixer-funded reconnaissance setup. T-09 v1 phase-2 signal; not yet wired for production monitoring.

RD-F-091 green Partial-drain test transactions Cat 6A precursor signal (T-09 phase-2 signal). No partial-drain test transactions observed against Meteora programs. No smart-contract exploit in Meteora history establishes a drain-pattern precedent. The LIBRA liquidity extraction (Feb 2025) was alleged insiders removing LP positions via permissionless DBC/Alpha Vault mechanics, not an admin-level partial drain against Meteora's own program TVL. TVL decline since Jan 2025 peak ($1.69B) to current ($319.87M) is gradual market-driven outflow, not a test-drain spike pattern. Admin-level drain on DLMM would require Squads v3 multisig threshold approval with no on-chain time_lock enforcement.

RD-F-097 green Sybil surge of identical-pattern transactions Cat 6A precursor signal (T-09 phase-2 signal). No active sybil surge against Meteora core programs observed as of 2026-05-16. The historical M3M3 insider wallet pattern described in the Hurlock v. Kelsier amended complaint (~150 insider wallets funded by Kelsier acquiring M3M3 supply before public trading, Oct 2024) is outside the current monitoring window and represents a pre-market insider scheme rather than an on-chain sybil surge detectable by the signal threshold. Meteora DBC and Alpha Vault remain permissionless infrastructure, creating ongoing exposure to future sybil setups, but no current anomaly is observable.

RD-F-098 green TVL anomaly — % drop in <1h Cat 6B exploit-in-progress signal (T-09 v1 launch signal). TVL at $319.87M as of 2026-05-16. 30d baseline from data-cache: mean $392.6M, std $33.1M, CoV 0.084. Current TVL / 30d mean ratio approximately 0.816 — below 1.0 but this reflects a gradual 30-day downtrend (-21.63%), not an acute 1-hour drop event. 1d change -0.99% — not anomalous. T-09 tier-A threshold requires TVL_now / TVL_baseline_30d < 0.70 over 60-minute trailing window; current posture does not breach this threshold. TVL has declined 81% from the $1.69B Jan 2025 peak (following LIBRA scandal), but this was a prolonged market-driven exit over months, not a single exploit-class drain event. Signal not yet wired for Meteora in production.

RD-F-100 green Flash loan >$10M targeting protocol tokens Cat 6B exploit-in-progress signal (T-09 v1 phase-2 signal). No flash-loan-class attack against Meteora programs identified. Solana does not have EVM-equivalent atomic flash loan primitives (Aave/Balancer flashLoan), though composable transactions within a single Solana transaction can achieve similar effects. Meteora DLMM pools are not flash loan sources in the EVM sense. No documented composability-exploit targeting Meteora programs in the hacks database or public sources. The LIBRA token collapse involved liquidity manipulation by alleged insiders, not an external flash-loan attack.

RD-F-101 green Large governance proposal queued Cat 6B exploit-in-progress signal (T-09 v1 launch signal). Meteora has no on-chain Governor contract (no Realms on-chain governance program, no OZ Governor). Governance forum at proposals.meteora.ag is advisory Discourse. MET token governance (launched Oct 2025) on-chain vs off-chain status unconfirmed. Squads v3 multisig is the upgrade-authority mechanism, not a Governor with ProposalCreated events. Active forum discussions (LP share proposals, Jul 2025 MET governance thread, loyalty point discussions) show normal discourse cadence — no malicious-pattern proposals observed. No flagged-pattern proposal in queue.

RD-F-104 green Stablecoin depeg >2% on shared-LP venue Cat 6B exploit-in-progress signal (T-09 v1 launch signal). USDC and USDT stable at peg as of 2026-05-16. Meteora DLMM pools pair USDC/USDT/USDS as paired assets; a major stablecoin depeg would cause LP pool imbalance (indirect exposure), not a collateral-failure cascade. DAMM v1 Dynamic Vaults interface with Solend, Francium (which use Pyth/Switchboard oracles internally). Meteora is not a lending protocol; stablecoin depeg exposure is via LP value erosion, not collateral-model insolvency. No active depeg event. Signal would require Solana-specific depeg detection (Pyth/Switchboard feed monitoring) for meaningful implementation.

Dev identity & insider risk Yellow 26 16 of 16

RD-F-111 yellow Team doxx status Mixed doxx status. Ben Chow (resigned co-founder) is doxxed: real name, LinkedIn profile (linkedin.com/in/hellochow), X handle @hellochow, prior roles at Jupiter Aggregator and WishWell documented in media. Meow (continuing co-founder, X: @weremeow) is pseudonymous with consistent multi-year Solana track record (Instadapp, Fluid, Kyber, Blockfolio adviser; Jupiter co-founder). General dev team: MeteoraAg GitHub org has 0 public members — contributors not publicly enumerable. Mixed profile: one doxxed (but departed) founder, one pseudonymous-with-track-record continuing founder, anonymous dev team. RD-F-112 yellow Team public accountability surface Ben Chow: LinkedIn, X, multiple media interview appearances, Jupiter co-founder role, New York-based public professional. Meow: X (@weremeow) with 5+ year Solana ecosystem presence, named adviser at Instadapp/Fluid/Kyber/Blockfolio, IQ.wiki profile. General dev team: not publicly enumerable (MeteoraAg GitHub 0 public members, LinkedIn company page exists but team not listed). Accountability surface is thin beyond the two co-founders. RD-F-113 yellow Team other-protocol involvement history Ben Chow: prior roles at Jupiter Aggregator (co-founder), WishWell. No confirmed prior rug or exit-scam in pre-Meteora history. Meow: Jupiter co-founder, Instadapp/Fluid/Kyber/Blockfolio adviser, Handshake contributor — clean prior track record. HOWEVER: the Hurlock v. Kelsier amended complaint (SDNY 1:25-cv-03891, filed 2025-04-19, amended 2025-07-29) alleges Chow was an active participant in M3M3, LIBRA, MELANIA, ENRON, and TRUST token manipulation schemes while at Meteora. These are alleged [?] but the litigation is active and the complaint is a filed court document. Yellow for material current-project involvement concern. RD-F-115 yellow Prior rug/exit-scam affiliation No confirmed prior rug/exit-scam affiliation for Ben Chow or Meow in their pre-Meteora project history. However, the active Hurlock v. Kelsier class-action (SDNY 2025) alleges Chow participated in pump-and-dump schemes during his tenure at Meteora — specifically M3M3, LIBRA, MELANIA, ENRON, and TRUST tokens. If proven, this would constitute insider-exit-scam conduct at the current protocol. The factor primarily addresses prior-project affiliations, but the ongoing litigation materially elevates concern. Yellow for litigation risk rather than confirmed prior-rug history. RD-F-121 yellow Contributor OSINT depth score Ben Chow: OSINT depth approximately 3/5 — LinkedIn with career history, multiple media appearances (The Block, DL News, BeInCrypto, CoinTelegraph), X account, Jupiter co-founder role, New York-based. Meow: approximately 3/5 — X with substantial history, named adviser at multiple named protocols (Instadapp, Fluid, Kyber, Blockfolio), IQ.wiki profile, pseudonymous but consistent. General dev team: approximately 1/5 — no public GitHub membership, minimal publicly attributable contributors. Aggregate depth is below the threshold for a green in a protocol with $319M TVL. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion [STAR CRITICAL] The Hurlock v. Kelsier amended complaint (SDNY 1:25-cv-03891, filed 2025-04-19, amended 2025-07-29) alleges defendants 'retained hidden upgrade authority over Meteora smart contracts through a multisig wallet under their exclusive control, allowing them to manipulate pools and freeze trading while portraying the system as decentralized.' [?] This is the insider-admin-use-without-disclosure pattern F123 captures. Facts confirmed: (1) DLMM upgrade authority is Squads v3 PDA (JADaUV8k...) with no on-chain timelock; (2) Ben Chow's resignation was announced unilaterally by co-founder Meow via X on 2025-02-18, not via a governance proposal on proposals.meteora.ag; (3) no corresponding governance forum discussion at proposals.meteora.ag was identified for the alleged M3M3 pool-freeze events. Underlying admin-use-acts are alleged [?] in the complaint and not confirmed by independent on-chain analysis in this assessment pass. Graded yellow: litigation allegation is documented an RD-F-125 yellow Deployer linked within 3 hops to DPRK/Lazarus [STAR CRITICAL] No OFAC SDN listing for any Meteora team member, program address, or Kelsier Ventures entity (OFAC.treasury.gov; confirmed via Chainalysis public DPRK blog and TRM Labs OFAC coverage). No Chainalysis or public Lazarus-cluster attribution for Meteora deployer, multisig signers, or named team. Hayden Davis / Kelsier Ventures are subject to Argentine civil asset freeze — not a US OFAC or Lazarus action. The Hurlock v. Kelsier amended complaint (SDNY 2025, amended 2025-07-29) contains no DPRK allegations. HOWEVER: F125 captures illicit-association and criminal-nexus proximity. A Meteora co-founder (Ben Chow) is alleged in an active class-action to have been an active participant in a coordinated token-manipulation scheme. The amended complaint also references approximately 150 insider wallets funded by Kelsier; the full hop-analysis of those wallets against known threat-actor clusters has not been publicly completed. Graded yellow for material insider-association risk: conf RD-F-114 gray Deployer address prior on-chain history Solana non-EVM substrate: pipeline deployer.address is null. Mercurial Finance 2021 program deploy transaction and deploying keypair are not derivable without direct Solana RPC access. Institutional funding context: Mercurial received VC seed from DeFiance Capital, Huobi Ventures, Signum Capital (2021) and IEO on FTX/Gate.io/Raydium — consistent with institutionally-funded deploy rather than anonymous shell. Deployer wallet prior on-chain history cannot be assessed without RPC access to the 2021 deploy transaction. RD-F-116 gray Contributor tenure at admin-permissioned PR MeteoraAg GitHub org has 0 public members. Contributor identities for admin-permissioned code changes are not publicly enumerable. MeteoraAg repos (dlmm-sdk, damm-v2, dynamic-bonding-curve) are public for code inspection but author handles for specific commits are not mapped to confirmed team identities. Contributor tenure for the most recent admin-permissioned PR cannot be assessed without knowing who authored it. Protocol opacity on team membership. RD-F-117 n/a ENS/NameStone identity bound to deployer Solana non-EVM substrate. ENS (Ethereum Name Service) is an Ethereum-native registry and does not exist on Solana. U7 substrate non-applicability rule applies. No equivalent Solana Name Service (.sol) binding to program deployer or governance signers is documented in Meteora's governance or protocol documentation. RD-F-119 gray Commit timezone consistent with stated geography MeteoraAg GitHub org shows active commit history (last commit 2026-05-14 per data-cache). Commit-time distribution analysis (hour-of-day breakdown for timezone anomaly flag) was not conducted — requires GitHub API contributor commit timestamp access not available in this assessment pass. Ben Chow's LinkedIn places him in New York (UTC-5/UTC-4); Meow's stated timezone not confirmed. No DPRK-anomaly commit-time concentration identified in public reporting. RD-F-122 gray Contributor paid to DPRK-cluster wallet No public reporting or on-chain analysis has surfaced a Meteora contributor payment-wallet path to a DPRK-labeled cluster. The Hurlock v. Kelsier amended complaint contains no DPRK allegations. OFAC SDN list contains no Meteora-associated name. Chainalysis public DPRK blog makes no mention of Meteora contributor payments. Full contributor payment-wallet hop analysis requires Chainalysis/Arkham enterprise access not available in this pass. Gap: pipeline_unimplemented for non-EVM contributor payment tracing. RD-F-124 gray Deployer wallet mixer-funded within 30 days [STAR CRITICAL] Solana non-EVM substrate: pipeline deployer.address is null (data-cache). The Mercurial Finance / Meteora program deployer wallet (the keypair that signed the 2021 BPFLoaderUpgradeable deploy transactions) is not resolvable without direct Solana on-chain RPC access. No public reporting or blockchain analytics label links any Meteora/Mercurial program deployer wallet to a mixer withdrawal within 30 days of program deployment. The Kelsier Ventures 'central coordinating wallet' (alleged prefix 0xcEA per blockchain forensics cited in class-action coverage) funded token-launch sniper wallets, not the Meteora protocol deployer. Mercurial Finance's 2021 funding was institutional (DeFiance Capital, Huobi Ventures, Signum Capital; IEO on FTX/Gate.io/Raydium). Gap: non-EVM deployer-address pipeline gap; not a clean finding. RD-F-184 gray Real-capital social-engineering persona No public reporting or on-chain analysis has identified a Meteora team contributor or external integrator persona who built credibility via 1M+ USD deposits to the protocol for the purpose of later social-engineering or insider access. The LIBRA/M3M3 scheme involved Kelsier Ventures seeding liquidity pools as an external token-launch client, not as an infiltrating contributor building insider protocol access. F184 is M-only OSINT requiring curator-level confidence. Gray per F184 taxonomy note (Drift comparator: no analogous multi-month in-person social-engineering build-up pattern identified for Meteora). Curator input required to confirm or deny.

RD-F-118 green Handle reuse across failed/rugged projects Ben Chow's handles (@hellochow, @benchow_sol) and Meow's handle (@weremeow) have been consistently associated with Meteora and Jupiter throughout their multi-year tenure. The Meteora/Mercurial rebrand (December 2022) was a publicly documented product evolution, not an identity-laundering rebranding. No evidence of either founder handle being previously associated with a rugged or failed project under a different alias.

RD-F-120 green Video-off/voice-consistency flag Meteora held regular public community calls throughout 2023-2024, with summaries published on Medium (Jan, Feb, Mar, Apr 2024 documented). Ben Chow made public statements via X (@hellochow) and participated in media coverage. Meow (@weremeow) communicated substantively via X including the February 2025 resignation announcement. No video-off flag or voice/timezone inconsistency anomaly identified in public record. No curator-flagged interview refusals noted.

Fork / dependency lineage Green 0 10 of 10

RD-F-126 n/a Is-a-fork-of Meteora (formerly Mercurial Finance) is an original implementation, not a fork. Independently designed in 2021 as a Solana-native stablecoin AMM. DLMM bin-based concentrated liquidity is Meteora-original. Solana execution model precludes bytecode forking from EVM protocols. Profile is_forked: false. RD-F-127 n/a Upstream patch not merged No upstream fork source exists. Factor assesses whether upstream has an unmerged patch. Not applicable for original implementations. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) No upstream fork source exists. Factor assesses upstream vulnerability disclosures affecting this fork. Not applicable for original implementations. RD-F-129 n/a Code divergence from upstream (%) No upstream fork source exists. Factor measures % lines changed from upstream. Not applicable for original implementations. RD-F-130 n/a Fork depth (generations from original audit) Meteora is the origin. Fork depth = 0 (not a fork). Factor measures fork hops from originally audited protocol. Not applicable. RD-F-131 n/a Fork retains upstream audit coverage No fork relationship. Each program is audited on its own merits with independent coverage. Factor assesses whether fork retains upstream audit coverage. Not applicable. RD-F-132 n/a Fork has different economic parameters than upstream No upstream to compare economic parameters against. Factor assesses whether fork deviates from upstream audited defaults. Not applicable for original implementations.

RD-F-133 green Dependency manifest uses unpinned versions All programs use exact version pins in Cargo.toml: anchor-lang = '0.31.0', anchor-spl = '0.31.0', solana-sdk = '2.1.0', bytemuck = '1.20.0' (damm-v2), bytemuck = '1.13.1' (dlmm-sdk). No semver range operators (^, ~) found for security-critical libraries. Cargo.lock pins all transitive dependencies by hash.

RD-F-134 green Dependency had malicious-release incident (last 90d) No known malicious-release advisory for anchor-lang 0.31.0, solana-sdk 2.1.0, bytemuck, or other Anchor ecosystem dependencies in the trailing 90 days as of 2026-05-16. No GitHub Security Advisory flagged for these packages.

RD-F-135 green Shared-library version with known-vuln status Anchor 0.31.0 is a recent stable release and the recommended production version for Solana programs as of 2025-2026. Solana SDK 2.1.0 is current. No known CVE or GHSA advisory against anchor-lang 0.31.0. Bytemuck 1.13.1 and 1.20.0 have no known critical vulnerabilities.

Post-deploy hygiene & change mgmt Yellow 27 13 of 13

RD-F-136 yellow Deployed bytecode matches signed release tag MeteoraAg GitHub has active repos with tags and releases matching version strings used in audit file naming. Audit files are keyed to version strings (e.g., damm-v2-audit-0.2.0.pdf). Exact bytecode hash match between deployed program and release-tag commit not independently verified — requires local build + RPC bytecode comparison. Policy appears followed based on audit file versioning, but cannot confirm bytecode-level match. RD-F-137 yellow Upgrade frequency (per 90 days) Active upgrade cadence across all programs. DBC: ~7 version increments in last 12 months with audit coverage per version. DAMM v2: multiple version bumps from v0.1.2 through v0.2.0 with June 2025 as latest audited. DLMM: v0.8.2 through v0.11.0 with 10 audit files. Frequent upgrades are mitigated by the stated two-auditor-per-update policy, but represent ongoing change surface. RD-F-138 yellow Hot-patch deploys without timelock (last 30 days) Squads v3 structural constraint: all upgrades execute without on-chain timelock. Whether any recent upgrade was an out-of-band hot-patch (bypassing normal proposal flow) is not distinguishable from normal upgrades without on-chain upgrade event history. DBC Protocol v0.1.8 released January 21, 2026. Not confirmed as hot-patch; audit coverage exists for v0.1.8 (Offside Labs, Zenith). Yellow because the 0-hour timelock means every upgrade is technically immediately executable. RD-F-139 yellow Post-audit code changes without re-audit Meteora policy: at least 2 auditors per program update. Audit file evidence shows consistent coverage: DBC v0.1.1 through v0.1.10 (Offside Labs + Zenith + OtterSec for v0.1.3); DLMM v0.8.2 through v0.11.0 (Offside Labs + Zenith + OtterSec + Sec3); DAMM v2 v0.1.2 through v0.2.0 (Offside Labs + Zenith + OtterSec). Policy broadly followed. DBC Protocol v0.1.8 has Offside Labs and Zenith audit PDFs in repo. However, exact deployed bytecode hash to audit-version matching not independently confirmed; yellow reflects unconfirmed alignment rather than confirmed gap. RD-F-142 yellow Storage-layout collision risk across upgrades Solana BPF programs use account data with Anchor discriminator-based layout rather than EVM storage slots. Account data layout breaks between program versions are possible but structurally different from EVM storage-layout collisions. No known instance of account-data layout collision in Meteora program upgrades. Anchor discriminator pattern reduces risk. Yellow for Solana-analog concern rather than confirmed EVM-style collision risk. RD-F-145 yellow Deployed bytecode reproducibility All programs are open-source Rust/Anchor on MeteoraAg GitHub. Reproducibility not independently verified this pass. Anchor programs typically produce deterministic bytecode from the same Rust toolchain version + Anchor version. Whether deployed bytecode on mainnet is reproducible from current repo state not confirmed via hash comparison. RD-F-146 yellow New contract deploys in last 30 days DBC Protocol v0.1.8 deployed January 21, 2026 (within 90 days of assessment). DAMM v2 and DBC show version increments every few weeks per audit file listing. Active deployment cadence means fresh attack surface is regularly introduced, mitigated by the two-auditor-per-update policy. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant Meteora is not a bridge; no bridge rate-limiter applies. Positive mitigant: DBC and DAMM v2 have admin-controlled pool disable (set_pool_status) allowing emergency pool freeze without full program upgrade. DLMM likely has similar admin-level pool control. Solana network has emergency-halt precedent (2022 network outages). However, the pool-disable capability is controlled by the same Squads v3 multisig with no on-chain timelock — it's an emergency lever, but requires multisig coordination. Partial positive mitigant; not a full rate-limiter. RD-F-143 n/a Reinitializable implementation (no _disableInitializers) Solana BPF programs are not EVM proxy contracts. The OpenZeppelin _disableInitializers() pattern is EVM-proxy-specific. Solana programs use Anchor account discriminators and PDA-based one-time initialization constraints that serve a different but analogous purpose. This EVM-specific critical factor is not applicable to Solana substrate. RD-F-144 n/a CREATE2 factory permits same-address redeploy CREATE2 is an EVM opcode with no Solana equivalent. Solana program deployment via BPFLoaderUpgradeable assigns a permanent program ID. Program IDs cannot be redeployed with different bytecode to the same address. Structurally inapplicable. RD-F-168 gray Stale-approval exposure on deprecated router Solana uses SPL token approval (token-authority-delegate) pattern rather than EVM unlimited approvals. Legacy Mercurial Multi-token Stable Pool (MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky) is deprecated; stale SPL token delegations not assessed. The Solana approval model is per-transaction in most patterns, reducing persistent stale-approval surface vs EVM. No allowance scan performed.

RD-F-140 green Fix-merged-but-not-deployed gap No known instance of a merged fix not deployed. No public disclosure of such a gap in governance forum, audit reports, or news sources. Active audit cadence per version update reduces likelihood of fix-but-not-deployed gap.

RD-F-141 green Test-mode parameters in deploy No test-mode parameter findings identified in public audit reports or community discussions. All programs deployed on mainnet with production configurations (permissionless pool creation, real fee structures, live user funds). Eight audit firms have reviewed programs without flagging test-mode residuals.

Cross-chain & bridge Gray 0 12 of 12

RD-F-147 n/a Protocol has bridge surface Meteora is Solana-only; no bridge surface. Profile has_bridge_surface=false, is_a_bridge=false, cross_chain=false. All Cat 10 factors are not_applicable. RD-F-148 n/a Bridge validator count (M) No bridge validator set exists; Meteora has no bridge surface. Solana-only protocol. RD-F-149 n/a Bridge validator threshold (k-of-M) No bridge validator threshold; Meteora has no bridge surface. Solana-only protocol. RD-F-150 n/a Bridge validator co-hosting No bridge validators to co-host. Meteora has no bridge surface. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) CRITICAL FACTOR - NOT_APPLICABLE. Meteora is a Solana-native program suite with no bridge. There is no EVM ecrecover call, no bridge verifier contract, and no cross-chain message validation code. The Wormhole-class ecrecover zero-address check is structurally inapplicable: (1) no bridge exists, (2) Solana uses ed25519 signature scheme not ECDSA/ecrecover, (3) Meteora has no EVM contracts. RD-F-152 n/a Bridge binds message to srcChainId No cross-chain messages; no srcChainId binding needed. Meteora is Solana-only. RD-F-153 n/a Bridge tracks nonce-consumed mapping No bridge replay; no nonce-consumed mapping needed. Meteora is Solana-only with no cross-chain messaging. RD-F-154 n/a Default bytes32(0) acceptable as valid root CRITICAL FACTOR - NOT_APPLICABLE. Meteora has no Merkle root acceptance logic, no bridge inbox, and no cross-chain proof validation. The Nomad-class default-value bytes32(0) root acceptance bug is structurally inapplicable: (1) Meteora has no bridge, (2) Meteora is Solana-only with no EVM contracts that would use bytes32 types for Merkle roots, (3) no cross-chain messaging architecture exists. RD-F-155 n/a Bridge validator-set rotation recency No bridge validator set; no rotation events. Meteora has no bridge surface. RD-F-156 n/a Bridge uses same key custody for >30% validators No bridge validators; key custody analysis inapplicable. Meteora is Solana-only, non-bridge. RD-F-157 n/a Bridge TVL per validator ratio No bridge TVL per validator ratio. Meteora has no bridge. TVL ($319.87M) is held in AMM pools, not a bridge. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) No LayerZero OFT adapter. Meteora is Solana-only with no LayerZero OApp. Data-cache layerzero.present=false, layerzero_bridge=false. The DVN configuration factor (F179) applies only to LayerZero OFT integrations.

Threat intelligence & recon Yellow 28 8 of 8

RD-F-161 red Protocol-impersonator domain registered (typosquat) Cat 11 threat intelligence signal. Multiple confirmed Meteora-brand typosquat/phishing domains registered within the 90-day assessment window: (1) meteora-ag.org — registered 2026-02-21 via Dynadot LLC (84 days before 2026-05-16 assessment; within 90-day window); flagged by 5 security vendors; listed on PhishDestroy, MetaMask, and SEAL blocklists; confirmed malicious by PhishDestroy investigation. (2) ag.meteora.gifts — registered 2026-02-21 (same day as meteora-ag.org; 84 days; within 90-day window); confirmed phishing by PhishDestroy. The coordinated same-day registration (2026-02-21) of meteora-ag.org and ag.meteora.gifts suggests an organized phishing campaign, not opportunistic individual registration. Additional domains: meteora.to (registered 2025-08-24, 265 days ago; outside 90-day window but still partially active); meteora.tools (flagged 2026-04-27 by 1 vendor; registration date unknown but flagging is within window). Registration-date-to-assessment-date delta for primary dom RD-F-158 yellow Known-threat-actor cluster has touched protocol Cat 11 threat intelligence signal (T-09 v1 phase-2 advisory). Kelsier-linked wallets (civil litigation defendants in Hurlock v. Kelsier SDNY Case No. 1:25-cv-03891-JLR) actively used Meteora DBC and Alpha Vault infrastructure for the alleged M3M3 (Oct 2024) and LIBRA (Feb 2025) token manipulation schemes. These wallets are confirmed as having interacted with Meteora core programs as part of an alleged coordinated fraud scheme. Classification note: these are civil-litigation-attributed wallets, not OFAC-sanctioned addresses or Chainalysis-verified DPRK/Lazarus cluster addresses. The amended complaint (July 2025) expands allegations to potentially 15 cryptocurrencies. No confirmed OFAC-sanctioned or DPRK-cluster wallet interaction with Meteora core contracts within 30 days as of 2026-05-16 (M3M3/LIBRA events are outside the 30-day window). Protocol infrastructure (DBC/Alpha Vault) remains permissionless, creating ongoing exposure to future bad-actor use. RD-F-165 yellow Protocol social channel has scam-coordinator flag Cat 11 threat intelligence signal. Elevated qualitative risk: the LIBRA/M3M3 scandal (Feb 2025 collapse, Apr 2025 class action, amended Jul 2025) created an environment with active scam-adjacent social activity around the Meteora brand. Multiple active phishing domains (meteora-ag.org, ag.meteora.gifts, meteora.tools) suggest scam-coordinator activity is ongoing. PCRisk published Fake Meteora Website Scam removal guide. MET token TGE (Oct 2025) and ongoing SDNY litigation create ongoing scam-incentive windows incentivizing Discord/Telegram impersonation. No specific Discord/Telegram channel admin confirmed on a curator scam-coordinator watchlist. Curator social-monitoring tool required for production assessment per T-09 spec. RD-F-163 gray Avg attacker reconnaissance time for peer-class protocols Cat 11 analytical factor. No Meteora-specific external-attacker reconnaissance time datum exists (no contract exploit precedent). For Solana DEX class analogues: Raydium Dec 2022 hack was opportunistic/rapid once private key was compromised (single-session, no extended reconnaissance). Drift Protocol Apr 2026 DPRK attack involved 6 months of social engineering buildup (insider implant class, not DEX reconnaissance). The LIBRA/M3M3 matter was alleged insider manipulation over months of coordination (Oct 2024 M3M3, Feb 2025 LIBRA), not external reconnaissance. DEX protocols with permissionless access (like Meteora DBC) have low reconnaissance barriers — anyone can interact without prior relationship. No Meteora-specific attacker reconnaissance time datum is available for scoring. Curator must establish protocol-class baseline from hack DB. RD-F-164 gray Leaked credential on paste/sentry site Cat 11 threat intelligence signal. No confirmed leaked credential incident for Meteora infrastructure (meteora.ag frontend, proposals.meteora.ag governance forum, docs.meteora.ag) identified in public sources as of 2026-05-16. Meteora has no published SECURITY.md (security_md_present: false per data-cache) and no confirmed SIRT email or security disclosure channel, which increases the risk profile for credential-leak response failures. The absence of a security contact increases the likelihood that a credential disclosure would not be promptly handled. Signal requires paste-site credential-dump monitoring feed (DomainTools, SpyCloud class) not available in this assessment.

RD-F-159 green Attacker wallet pre-strike probe (low-gas failing txs) Cat 11 threat intelligence signal (T-09 phase-2 signal). No mempool probe pattern (failing low-priority-fee transactions sent by known threat-actor wallets to Meteora programs) identified in public sources as of 2026-05-16. The LIBRA launch involved direct high-value liquidity interactions, not a reconnaissance-probe pattern of failing transactions. No Solana-native equivalent of the EVM mempool-probe pattern observed against Meteora programs.

RD-F-160 green GitHub malicious-dependency incident touching protocol deps Cat 11 threat intelligence signal. No security advisory flagged for Rust/Anchor crates or npm dependencies used by MeteoraAg repos in public sources as of 2026-05-16. MeteoraAg GitHub org shows no public critical security advisories in data-cache. Meteora uses Rust/Anchor toolchain (Solana BPF programs); supply chain risk via crates.io is a monitoring surface but no current malicious-release incident identified. Data-cache shows no GitHub security advisory events flagged.

RD-F-162 green Known-exploit-template selector deployed by any address Cat 11 threat intelligence signal. No known-exploit-template programs targeting Meteora-class AMM patterns (DLMM bin-based, DAMM constant-product, DBC bonding curve) deployed and identified in public sources as of 2026-05-16. No Meteora contract exploit exists in history to establish an exploit template. The DBC/Alpha Vault permissionless infrastructure has been used for alleged token manipulation (M3M3/LIBRA — social/economic fraud, not technical exploit-template replay). No Solana BPF program with discriminator patterns matching a known Meteora exploit template identified.

Tooling / compiler / AI Gray 0 5 of 5

RD-F-170 n/a Solc version used (known-bug versions flagged) Meteora programs are compiled with rustc targeting the Solana BPF/SBF backend, not solc. No Solidity compiler is involved. Factor measures solc version and known-bug list. Structurally not applicable to Rust/Anchor Solana programs. RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation EVM bytecode similarity analysis (Slither CFG comparison) is not applicable to Solana BPF/SBF bytecode. Meteora is an original protocol with no EVM upstream. Factor measures EVM bytecode similarity to audited upstream. Structurally not applicable. RD-F-172 gray Repo shows AI-tool co-authorship in critical files GitHub Copilot co-authorship metadata (Co-authored-by trailers) could theoretically appear in Rust commits. A full commit history review of MeteoraAg repos for AI co-authorship trailers was not performed. The taxonomy factor's measurement specifically references Solidity critical files but the underlying concern (AI-generated code in security-critical paths) is language-agnostic. Scored gray pending curator review of commit history. RD-F-173 n/a Team self-disclosure of AI-generated Solidity Factor specifically assesses team disclosure of AI-generated Solidity. Meteora uses Rust/Anchor, not Solidity. No public statement about AI-generated Rust in security-critical programs found. The factor as literally defined (Solidity) is not applicable to a Rust/Anchor protocol. RD-F-174 n/a Dependency tree uses EOL Solidity version No Solidity version is involved. Rust toolchain rustc 1.79.0-1.85.0 is a supported, non-EOL version. Solana SDK 2.1.0 is current. Factor measures EOL Solidity version. Structurally not applicable to Rust/Anchor programs.

Response & disclosure hygiene Red 50 4 of 4

RD-F-175 red Disclosure channel exists No confirmed active public security disclosure channel found as of 2026-05-16. Direct checks: (1) Immunefi program URL immunefi.com/bug-bounty/meteora/ returns 404; immunefi.com/bug-bounty/meteora/information/ returns 404; (2) Immunefi 223-program live listing does not include Meteora; (3) data-cache bug_bounty.platform = null, bug_bounty.url = null; (4) SECURITY.md: security_md_present = false; (5) docs.meteora.ag/security-and-risks/smart-contract-risk returns 404; (6) no security@ email found in GitHub or docs. Secondary sources claiming a $500K Immunefi bounty exist but are unverified by Immunefi's own platform — treated as stale/inaccurate reporting. RD-F-176 red Disclosure SLA public No disclosure SLA found. No disclosure channel exists (see F175), so no SLA can be attached. No acknowledgment-time SLA text found in any Meteora documentation, Medium posts, GitHub, or Discord announcements searched.

RD-F-177 green Prior known-ignored disclosure No prior Meteora or Mercurial contract exploit means there is no post-mortem in which an ignored disclosure could be documented. OSINT search found no security researcher public disclosure of a Meteora/Mercurial vulnerability that was subsequently exploited. No evidence of prior known-ignored disclosure in any source.

RD-F-178 green CVE/GHSA advisory issued against protocol No CVE, GHSA, or equivalent public advisory found against Meteora or Mercurial repositories. GitHub Security Advisories search for MeteoraAg organization returned no advisories. No NVD CVE indexed against Meteora or Mercurial in OSINT. data-cache security_md_present = false (no advisory history published). The Immunefi non-listing means no disclosed payout record exists that would indicate past advisories.

rubric_version v1.7.0 graded_at 2026-05-16 11:30:34 factors 184 protocol meteora