Raydium AMM

Raydium is a Solana-based DeFi AMM/DEX that started as a hybrid constant‑product AMM integrated with Serum/OpenBook’s order book and now operates primarily as a pure AMM. Protocol identification

• Name: Raydium (AMM v4 and associated AMM products).
• Website: The docs domain indicates the main ecosystem under docs.raydium.io; the trading UI is commonly referenced as Raydium’s Solana DEX.
• Docs: Central documentation at docs.raydium.io, covering AMM v4, CPMM, CLMM, farms, Launchpad, and architecture.
• Category: Decentralized exchange / automated market maker (AMM) using constant‑product pools, historically hybrid with a central limit order book (CLOB).
• Launch date: Mainnet launch in February 2021 as Solana’s first hybrid AMM integrating constant‑product pools with Serum’s order book.
• Chains: Solana only; all documented programs and products are Solana programs.
• Native token: The ecosystem is widely referenced as “Raydium” and uses the RAY token as its native governance/utility token (stated in general ecosystem introductions). Main program addresses (Solana) Raydium publishes program IDs in its docs with GitHub cross‑references:
• AMM v4 (hybrid AMM + OpenBook, now pure AMM): 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8 (older canonical ID widely cited in technical material and Stack Exchange).
• The docs also list an upgraded AMM v4 program labeled DRaya7Kj3aMWQSy19kSjvmuwq9docCHofyP9kanQGaav as the current AMM v4 program address.
• Other Raydium AMM‑related programs (not the focus of this query but relevant context) include CPMM and CLMM program IDs, with source‑code repos under github.com/raydium-io. Explorer verification status and on‑chain confirmation are Not verifiable as of 2026‑09‑04 due to lack of direct on‑chain/tool access this turn. Fork lineage and design
• The GitHub repo explicitly describes Raydium AMM as a constant‑product AMM integrated with the OpenBook CLOB on Solana, not as a direct fork of a specific Ethereum AMM such as Uniswap.
• Architecture docs and system‑level descriptions frame Raydium as a native Solana implementation combining AMM pools with order‑book liquidity routing, rather than a simple fork port.
• The constant‑product math and fee logic (swap fee, LP share, protocol PnL share) are documented explicitly, indicating custom implementation details on Solana. Audits & malicious‑fork history
• Public docs emphasize program upgrades (e.g., 2026‑07 removal of OpenBook/Serum dependency for AMM v4) but do not, in the retrieved material, present a formal audit catalogue for AMM v4.
• No independent evidence of malicious modifications in Raydium forks or cloned AMM programs was found in the retrieved sources; any such history is Not verifiable as of 2026‑09‑04.

Raydium AMM appears to be a mature, live product rather than a static landing page: the docs describe multiple operational Solana products (AMM v4, CPMM, CLMM, Farm, LaunchLab), and the docs site exposes an API reference with interactive playgrounds and multiple public HTTP services used by the UI and SDK. The presence of a GitHub repository for the AMM program and documentation pages for code demos and instructions also indicates a maintained developer surface, not a template-only site. Open API: yes.

Raydium’s docs explicitly list public HTTP services such as API v3, Transaction API, Perps API, LaunchLab Auth API, and Owner API, and state that API v3 is the canonical read API the UI and SDK rely on. The Owner API docs also show concrete endpoint examples and separate mainnet/devnet hosts. Live deposits/withdrawals: not verifiable as of 2026-09-04.

The available web evidence confirms live API services and product modules, but does not independently prove current deposit/withdrawal execution from raw chain data in this pass. Broken links / fake metrics / template signs: no clear evidence of template-site behavior surfaced in the retrieved sources. The docs and API pages are internally consistent and point to live, product-specific services; however, any claims about current TVL, usage, or transaction volume remain unverified here.

Overall: Raydium AMM looks like a real, operational DeFi protocol with a substantial documentation and API surface, not just a marketing landing page.

Raydium’s bug bounty is active and is run through Immunefi. It covers only the on-chain program code (Solana smart contracts) in scope; the SDK, REST APIs, and frontend are excluded. Reports require a proof of concept for all severities, and high/critical reports should include a suggested fix.

Rewards are severity- and impact-based, with critical smart-contract bugs capped at 10% of directly affected funds, a minimum payout of $50,000, and a maximum payout of $505,000. Publicly documented rewards are paid in RAY, SOL, or USDC denominated in USD. Publicly reported results include at least one $505,000 bounty paid for a tick-manipulation bug and another $505,000 bounty paid for a liquidity-drain bug.

Assessment as of September 6, 2026: Raydium AMM’s core swap, deposit, and withdrawal logic has no external oracle dependency; pool reserves/CLMM state determine pricing. Pyth and Jupiter are used for frontend/API USD displays only, so an oracle outage should not stop pool settlement. Spot-price manipulation remains possible in shallow pools, especially for downstream protocols that consume Raydium spot prices rather than TWAPs.

Raydium is Solana-native and has no protocol-level bridge, custodian, CEX, market-maker, RWA issuer/SPV, lending, LST, or restaking dependency identified. AMM v4’s former OpenBook integration is documented as deactivated; current pools operate against their own curves. Cross-chain or institutional exposure can still enter indirectly through pool assets and aggregators, but that exposure is pool-specific.

Not verifiable as of September 6, 2026. Primary counterparty risk is at the token level: issuers may retain freeze or mint authority; Token-2022 fee authorities can raise transfer fees; upgradeable transfer hooks can block or alter transfers. Stablecoin pools additionally inherit USDC/USDT—or other stablecoin—issuer, reserve, redemption, freeze, and depeg risk.

A depeg can create severe inventory concentration and LP losses even if Raydium itself remains operational. LST/restaking and RWA/SPV risk applies only where those assets are listed; aggregate exposure is not verifiable as of September 6, 2026. Administrative dependency remains material: Raydium programs are upgradeable through a 3/4 Squads multisig, while treasury/configuration functions use a 3/5 multisig.

A compromised multisig, malicious upgrade, Solana outage, or token-authority action could impair pools. Incident update: A June 10, 2026 exploit drained approximately $1.34 million from inactive legacy AMM V3 pools; reported current mainnet programs were unaffected and losses were slated for treasury reimbursement. This is historical, not an identified active dependency failure. Dune limitation: On-chain pool-by-pool balances, stablecoin/LST/RWA shares, and maximum counterparty concentration are Not verifiable as of September 6, 2026 because Dune MCP is unavailable.

Raydium AMM on Solana is organized as a non-custodial protocol: users keep control of their own wallets and sign swaps, deposits, and liquidity actions themselves, while pool reserves are held in on-chain token vaults controlled by program-derived authorities (PDAs), not by a Raydium-held custodial account. The available evidence also supports that vault ownership is not user-segregated in the sense of separate vaults per depositor; rather, pooled assets sit in program-controlled pool vaults, with each pool having shared reserve accounts governed by the protocol. Withdrawal pauses are not verifiable as of 2026-09-06 from the gathered sources; historical reports mention a temporary halt during a 2022 exploit, but no current paused-withdrawal status is confirmed here.

Raydium AMM: Social Engineering via Malware on Solana; loss $4,400,000 (DeFiLlama hacks registry). Remediation status: resolved (retained evidence).

In January 2023, an OpenBook program update changed account semantics, temporarily preventing AMM v4’s MonitorStep crank from settling PnL. No realized loss or attacker proceeds were reported. Affected: AMM v4 operations and unsettled PnL processing, not user funds according to the available incident description.

Raydium shipped a coordinated AMM v4 patch. Status: resolved; reimbursement: not applicable.

Raydium AMM: Token & Share Accounting via Infinite Mint on Solana; loss $1,340,000 (DeFiLlama hacks registry). Remediation status: remediation_in_progress (retained evidence).

Raydium AMM’s key management is organized around program-derived authorities for day-to-day pool control and multisig/admin keys for privileged changes. According to Raydium’s security docs, every Raydium program has at least one privileged role, and the main protections are limiting what those roles can do and gating them behind multisigs with delays. For the AMM-related programs, Raydium documents a 3/4 Squads multisig as the program upgrade authority, meaning new bytecode can only be deployed through that multisig.

It also documents a 3/5 treasury multisig for AmmConfig admin actions such as creating new fee tiers and toggling existing ones, and for the create-pool fee recipient role. Raydium further states that a dedicated create-permission-PDA owner may exist on mainnet versus devnet, but it cannot close permission PDAs; revocation remains admin-only. Separately, Raydium’s architecture docs say users never hold vault authority: a program-owned authority PDA controls token vaults, while the wallet only signs the user’s transaction.

The docs also note there is no on-chain token-voting program for admin actions; upgrades and fee/config changes are executed through multisigs. A caveat: the public docs describe this governance/key structure, but as of now it is Not verifiable as of 2026-09-04 whether any specific signer set or rotation state has changed beyond what the docs list.

Scope: Solana mainnet AMM v4 (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8). This is not an EVM proxy; it is a Solana BPF Upgradeable Loader v3 program. Architecture ``text LP/user wallet │ signed Deposit / Withdraw / Swap ▼ AMM v4 program ── PDA authority ── LP mint + token vaults │ ├─ hard-coded AMM owner/admin: GThUX1Atko4tqhN2NaiTazWSeFWMuiUvfFnyJyUghFMJ ├─ config PDA: fee/create-pool settings; pnl_owner; cancel_owner └─ upgrade authority: documented as Squads 3/4 (exact current address: Not verifiable as of September 6, 2026) ` Admin surface: The hard-coded owner can call SetParams to change pool Status, State, SetOpenTime, and fees; status changes can pause swaps and can affect withdrawal permission. WithdrawPnl is restricted to the hard-coded owner or configured pnl_owner; UpdateConfig can change pnl_owner, cancel_owner`, and create-pool fee. There is no oracle or strategy module in AMM v4. User exit: Normal LP withdrawal is user-signed and transfers assets to user-selected destinations, subject to pool status and LP ownership; no admin signature is required.

However, a malicious upgrade could alter this logic. A compromised upgrade quorum is therefore the worst-case drain/freeze vector. The program also retains a historical WithdrawPnl path that can transfer accrued protocol PnL, not users’ LP principal, to the configured PnL recipient. > Contradiction / key gap: Raydium documentation claims a 24-hour Squads timelock for upgrades, while prior security material reportedly stated no timelock program function.

The delay is multisig-layer, not AMM-v4 code-level, and its current on-chain value is Not verifiable as of September 6, 2026. Current upgrade authority, signer set, role renunciation, and actual timelock execution history are likewise Not verifiable as of September 6, 2026. Audit: Historical AMM v4 audits are listed by Kudelski, OtterSec, and MadShield; audit coverage does not prove the currently deployed bytecode is unchanged. Risk conclusion: High governance/upgrade risk; moderate direct-admin risk; principal is not directly drainable by ordinary fee/PnL roles, but upgrade compromise can plausibly drain or freeze pools. Freeze risk also depends on underlying token mint authorities, outside AMM control.

On-chain verification was unavailable in this run.

Halborn Q2 2025 audit report — raydium launch; file audit/Halborn Q2 2025/raydium_launch.pdf in raydium-io/raydium-docs (protocol audit catalog).

Halborn Q4 2024 audit report — raydium liquidity locking; file audit/Halborn Q4 2024/raydium_liquidity_locking.pdf in raydium-io/raydium-docs (protocol audit catalog).

Kudelski Q2 2021 audit report — Raydium Audit; file audit/Kudelski Q2 2021/Raydium_Audit.pdf in raydium-io/raydium-docs (protocol audit catalog).

MadSheild Q2 2023 audit report — Raydium updated orderbook AMM program & OpenBook migration; file audit/MadSheild Q2 2023/Raydium updated orderbook AMM program & OpenBook migration.pdf in raydium-io/raydium-docs (protocol audit catalog).

MadShield Q1 2024 audit report — raydium cp swap v 1.0.0; file audit/MadShield Q1 2024/raydium-cp-swap-v-1.0.0.pdf in raydium-io/raydium-docs (protocol audit catalog).

OtterSec Q3 2022 audit report — Raydium concentrated liquidity (CLMM) program; file audit/OtterSec Q3 2022/Raydium concentrated liquidity (CLMM) program.pdf in raydium-io/raydium-docs (protocol audit catalog).

OtterSec Q3 2022 audit report — Raydium staking program; file audit/OtterSec Q3 2022/Raydium staking program.pdf in raydium-io/raydium-docs (protocol audit catalog).

OtterSec Q3 2022 audit report — Raydium updated order book AMM program; file audit/OtterSec Q3 2022/Raydium updated order-book AMM program.pdf in raydium-io/raydium-docs (protocol audit catalog).

Sec3 Q2 2026 audit report — raydium clmm limitorder dynamicfee; file audit/Sec3 Q2 2026/raydium_clmm_limitorder_dynamicfee.pdf in raydium-io/raydium-docs (protocol audit catalog).

Sec3 Q3 2025 audit report — raydium cp swap pr55; file audit/Sec3 Q3 2025/raydium_cp_swap_pr55.pdf in raydium-io/raydium-docs (protocol audit catalog).

OtterSec — Raydium updated order-book AMM program.

Kudelski Security — Raydium Order-book AMM / staking security code review assessment.

MadShield — updated order-book AMM and OpenBook migration.

Halborn — Raydium LaunchLab audit.

Halborn — Raydium Burn & Earn liquidity locking.

OtterSec — Raydium concentrated liquidity (CLMM) program audit.

OtterSec — Raydium staking program audit.

MadShield — Raydium constant-product AMM v1.0.0.

A 2026 review summarizes a HashEx audit from August 2024 with zero critical, high, medium, or low findings. This is a secondary-source claim in the search results, so the report details and bytecode-match coverage are not independently verifiable here.

Audit of original Raydium order‑book AMM on Solana.

Raydium docs list an Order-book AMM audit by Kudelski Security in Q2 2021. The provided search result includes the audit-history entry and report link, but not the finding counts or detailed fix status for this specific report. Bytecode-match coverage is not verifiable from the search results alone.

Raydium AMM / Serum-integrated order-book AMM — Kudelski Security (Nagravision), published May 11, 2021. Scope: raydium-amm serum-amm directory at commit 300c232dd362ede00667df8193bdcab677cf23f3; Raydium staking was also included, while third-party libraries were out of scope.

Order-book AMM audit

Raydium’s milestone page states that first-round audits on AMM v4 and Farm v3 were completed in November 2021 and that no critical findings remained, with minor code-quality recommendations addressed. The search results do not provide the underlying report link, exact severity counts beyond the no-critical statement, or a bytecode-match verification for deployed code.

Full security audit and vulnerability analysis of Raydium constant‑product AMM (CPMM) program on Solana.

Raydium AMM Program audit

Updated order-book AMM audit

Audit of the raydium-amm program on Solana. The report says the source code was delivered as github.com/raydium-io/raydium-amm and the audit was performed against commits d70a8fb with incremental reviews up to 8da289a. Findings: 0 critical, 1 high, 1 medium, 0 low, 4 informational.

The high finding (OS-RAY-ADV-00) was marked Resolved; the medium finding (OS-RAY-ADV-01) was marked Resolved with patch 3dc6a26. The report also notes that code changes should be checked against the deployed program bytecode, and if the hash does not match, the deployed program is not the audited one.

raydium-amm program audit

Security assessment of raydium-amm-v3 (AMM v3 program) on Solana.

Raydium’s milestone page states that Farm v6 was audited in May 2023 and that several medium findings were fixed in a v6.1 hotfix. The search results do not include the report itself or a bytecode-match confirmation for the deployed program.

Raydium’s milestone page states that CLMM audits in November 2022 found one critical issue and three high-severity issues, all fixed pre-deploy. It also says a later OtterSec re-audit covered Token-2022 support in April 2023. The search results do not include the full report links or confirm bytecode match against deployed code for those specific deployments.

Raydium is run by a pseudonymous, crypto-native team with no publicly verified real‑world identities, offices, or corporate footprint; its credibility is mainly based on technical delivery and ecosystem relevance rather than traditional corporate transparency. Founders & team structure

• Raydium launched in February 2021 on Solana, created by an anonymous development team led by pseudonymous members AlphaRay and XRay; later sources consistently add GammaRay and other pseudonymous contributors (StingRay, RayZor).
• Roles:
• AlphaRay – strategy, operations, product direction, business development, with background in algorithmic trading (including commodities) and low‑latency systems.
• XRay – Chief of Technology / CTO, leads development, with ~8 years’ experience building trading systems and low‑latency architectures in TradFi and crypto.
• GammaRay – marketing and communications, plus strategy/product input.
• StingRay / RayZor – trading and security-focused contributors.
• Multiple independent descriptions characterize the founders as Wall Street quantitative trading veterans and blockchain developers, but this is based on their own narratives, not doxxed resumes. Public vs. anonymous; prior track record
• All key figures use pseudonyms only; no reliable linkage to real-world identities, prior employers, or registered companies is available in open sources.
• Claims of prior Wall Street/algorithmic trading experience are unverified marketing claims; no external CVs, regulatory records, or corporate bios corroborate them as of 2026-09-04. Security incidents & operational maturity
• Raydium suffered a major Liquidity Pool V4 exploit (Dec 2022): attacker compromised the pool owner/authority private key, used the withdrawPNL admin function, draining ~$2.2–4.4m from multiple pools.
• Post‑mortems attribute root cause to Trojan/compromised key, not a direct protocol logic bug; the team revoked the compromised authority and patched the V4 program quickly.
• A separate legacy AMM V3 exploit (2026) caused ~$1.34m loss due to insufficient validation of LP mints in the retired program; it was no longer accessible via the main UI but still exploitable on‑chain. Business reality: office, jurisdiction, legal entity
• No credible sources identify a registered corporate entity, physical office location, or formal onshore/offshore jurisdiction for Raydium as of 2026-09-04. Not verifiable as of 2026-09-04.
• Public footprint consists of protocol operations, online content, and ecosystem integrations; it functions effectively as a web‑front, pseudonymous DeFi collective, not a conventional regulated business. Institutional risk takeaways (team-specific)
• Key risks: fully pseudonymous leadership, key-compromise history, lack of corporate structure/jurisdiction clarity, and unverified prior experience.
• Credibility is derived from sustained operation, ecosystem adoption, and post‑incident remediation, not from traditional governance or regulatory oversight.

Raydium has a generally strong but not uncontroversial reputation in Solana DeFi: it is widely described as one of the ecosystem’s leading AMMs/liquidity hubs, but users and reviewers still flag smart-contract, wallet, phishing, LP, and historic exploit risk. Publicly available review sources say the protocol has undergone multiple third-party audits from firms including Kudelski Security, OtterSec, MadShield, Halborn, and Sec3, and it runs a bug bounty program on Immunefi with a top reward cited at $505,000. The project is also described as having a hybrid/feature-rich architecture, and its docs state that Raydium is a set of separate on-chain programs rather than a single monolith.

On security incidents, the main reputational hit was the December 2022 private-key compromise that drained liquidity pools; several sources distinguish this from a smart-contract failure. A second incident in June 2026 affected dormant/retired AMM V3 pools, with reports saying roughly $1.34 million was lost and Raydium reimbursed affected users from treasury. Those incidents sustain criticism that legacy programs and operational security remain key concerns, even though reviewers also note post-incident hardening and no evidence here of ongoing insolvency.

On legal/regulatory and sanctions issues, there is no verified evidence in the provided sources of enforcement actions, sanctions, or formal fraud/rug allegations against Raydium itself. Not verifiable as of 2026-09-04 whether founders, investors, or auditors have unresolved legal exposure beyond the security incidents above.

Economic model — Raydium AMM (Solana)

• Strategy/assets in-out: Permissionless liquidity provision to AMM v4/orderbook-integrated pools, CPMM pools, and CLMM positions. Users deposit two SPL tokens; CPMM/AMM v4 LPs receive fungible LP tokens, while CLMM users receive concentrated-liquidity positions. Withdrawals burn LP tokens or close positions and return proportional underlying assets, subject to slippage and pool price movement.
• Yield source: Trading fees are the primary organic source. AMM v4’s documented default is 0.25% per swap, with 88% to LPs and 12% to protocol PnL (0.03% of volume). CPMM/CLMM fee tiers and protocol/fund/creator allocations are pool-configurable; CLMM positions earn only while in range.
• Organic vs subsidized: Fee yield is organic but volume-dependent. Farm rewards are additional token emissions and therefore subsidized/dilutive unless funded by economically productive revenue. Exact organic percentage: Not verifiable as of September 6, 2026.
• Risk posture: LP exposure is directional/non-market-neutral because of impermanent loss; CLMM adds range-selection and out-of-range risk. No native lending leverage, looping, restaking, or collateralized borrowing is part of the AMM strategy. External composability risk remains.
• Lock-ups/withdrawals/gates: Normally no protocol lock-up; farmed CPMM LP tokens must be unstaked before withdrawal. CLMM rewards require an in-range position. Pool-specific slippage, token-transfer taxes, and possible creator-lock arrangements can apply.
• Protocol revenue: Swap protocol fees, selected fund/creator fees, and pool-creation-related fees; rates are configuration-dependent. Revenue is not equivalent to LP yield.
• TVL/trend: Dune on-chain verification is unavailable in this run: Not verifiable as of September 6, 2026. DeFiLlama reports $1.103B for the broader Raydium parent, with Solana representing 100% of tracked TVL, but this includes tracked products beyond AMM; AMM-only TVL, product split, and Dune-vs-DeFiLlama variance are Not verifiable as of September 6, 2026.
• APY history/ sustainability: Historical APY volatility and pool-level decomposition are Not verifiable as of September 6, 2026. Sustainability depends primarily on durable trading volume; incentive APY is inherently less durable. Structured fields: organic_yield_pct: null; leverage_ratio: null

As of September 6, 2026, no consolidated Raydium AMM treasury balance can be verified. Dune on-chain verification is unavailable in this run; therefore protocol-controlled balances, reserve composition, USD value, and liabilities are Not verifiable as of September 6, 2026. Reserve structure and custody: Raydium AMM v4 does not present one universal reserve wallet. Liquidity is distributed across individual Solana pools: each pool has coin and quote-token vault accounts controlled by the AMM authority PDA, with additional OpenBook-related accounts for legacy/hybrid pools.

The public repository identifies the AMM v4 program as 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8; it does not establish a canonical treasury address. Protocol-fee custody/control: AMM v4’s documented 0.25% swap fee generally allocates 0.22% to LPs, remaining in pool vaults, and 0.03% to protocol PnL counters. The latter is physically held in pool vaults until the Raydium multisig invokes TakePnl/WithdrawPnl, transferring funds to configured PnL-owner accounts. This is fee collection from many pools, not evidence of a single treasury balance. Composition / policy: The only previously identified reserve-like allocation is the historical RAY liquidity-mining reserve: 188.7 million RAY, or 34% of the original 555 million supply.

This is an emissions allocation, not liquid treasury assets, and its current remaining balance is Not verifiable as of September 6, 2026. Control and attestations: A Raydium multisig is described as having authority to withdraw AMM PnL and set parameters, but the controlling address, signers, threshold, current holdings, and independent reserve attestation are Not verifiable as of September 6, 2026. No liabilities disclosure or reserve attestation was located. Contradiction / finding: Generic Raydium materials describe swap fees as accruing partly to “the treasury,” while AMM v4 technical documentation specifies pool-level PnL-owner accounts and vault-based custody. The narrower AMM-v4 evidence does not support sizing a single treasury; the gap is the finding.

Raydium has a native token RAY on Solana; all tokenomics here are based on aggregators and public docs only. On‑chain verification is Not verifiable as of 2026‑09‑04. Basic token data

• Name / ticker: Raydium / RAY.
• Chain / address: Solana SPL; canonical address reported by aggregators as 4k3Dy... (truncated here; full address not independently on-chain verified).
• Max / total supply: Commonly cited 555,000,000 RAY max.
• Circulating supply, market cap, FDV: Circulating supply, market cap and FDV figures differ slightly across CoinGecko/CoinMarketCap; exact values therefore rely on aggregator estimates. Treat all current USD metrics as data from analytics platforms, not on-chain truth. Utility and governance
• Protocol role: RAY is the governance and incentive token for the Raydium AMM and its farms on Solana.
• Utility:
• Liquidity mining / farming rewards for LPs on Raydium pools.
• Staking RAY on Raydium for staking yield and platform incentives.
• Used in Raydium ecosystem launches and potentially for voting on some proposals (governance is partly off‑chain / via community channels). Revenue share, buybacks, burns
• Swap and trading fees on Raydium fund protocol revenues; a portion is used for liquidity incentives and ecosystem growth rather than a clearly specified perpetual buyback program.
• No credible independent source confirms a formal, ongoing RAY buyback-and-burn mechanism; any such claims from Raydium’s own docs should be treated as unverified marketing claim as of 2026‑09‑04. Emissions and allocations Commonly reported allocation breakdown (from analytics/docs, not on-chain):
• Liquidity mining / staking & ecosystem: ~34%–40%.
• Team: ~20%.
• Partnerships & ecosystem fund: ~20%.
• Seed / investors and initial liquidity, plus community reserves: remainder.
• Emissions schedule: multi‑year, front‑loaded rewards that decay over time; details vary slightly by source and are not independently on-chain verified. Unlocks and insider concentration
• Historical token unlocks for team/investors are described in early Raydium documentation and listings, but whether specific cliffs/vests executed on-chain is Not verifiable as of 2026‑09‑04.
• Top-holder concentration and identification of insider vs non‑insider wallets cannot be reliably established without on-chain clustering; Not verifiable as of 2026‑09‑04. Contract controls & listings
• RAY is an SPL token; any mint authority / freeze / blacklist / fee-switch status must be checked via Solana explorer and is Not verifiable as of 2026‑09‑04.
• RAY has deep liquidity primarily on Solana DEXs (Raydium, Orca, Jupiter-routed pools) and is listed on major CEXs (e.g., Binance, Huobi, others per aggregators).

A Bitcoin drop below $10,000 is a market stress event, not a protocol-specific solvency trigger for Raydium AMM. On Raydium’s constant-product pools, the direct effect is higher price divergence, larger impermanent loss for LPs, and potentially lower fee generation if trading activity falls; the protocol docs define impermanent loss as the gap between LP value and simply holding the tokens, and note that outside a concentrated range LPs can end up holding only one token. For CPMM / AMM v4, the main stress channel is LP PnL, not an automatic liquidation mechanism: if BTC-related pool prices collapse, LPs who provided BTC pairs would realize losses versus HODL when they withdraw, and fee income may not offset that if volatility is extreme.

Raydium’s docs also state that its core programs do not enforce anti-MEV protections at the program level, so stressed markets can still face sandwiching and execution slippage; protection is pushed to the submission layer and slippage settings. The important protocol-level nuance is that Raydium is not one program but a set of separate Solana programs, so the impact depends on which pool type is in question. AMM v4 is described as a pure constant-product AMM today, while newer pairs default to CPMM; therefore, a BTC crash would primarily stress whichever BTC-quoted pools exist, rather than Raydium as a whole.

What is not verifiable as of 2026-09-04 from the provided sources is Raydium’s actual BTC pool exposure, chain-level TVL breakdown, or whether any specific BTC pair dominates fee generation. If you want, I can next assess the likely impact on BTC/SOL, BTC/USDC, or all Solana Raydium pools separately.

Raydium AMM is a DEX AMM, not a lending protocol with posted borrower collateral, so a “largest collateral depegs 20%” stress test is not directly applicable to protocol solvency in the way it would be for a lending market. Raydium’s AMM pools use a constant-product invariant, and a price shock primarily affects pool pricing and LP mark-to-market, not a collateral liquidation engine. For the largest 20% depeg scenario, the economically relevant effect is that any pool containing the depegged asset would reprice along the x·y=k curve; the pool does not have a built-in collateralization ratio or liquidation threshold to breach.

In other words, there is no protocol-level “collateral shortfall” to compute from the available sources, because Raydium AMM does not define one. What can be said with confidence is that LPs would absorb the loss versus the pre-shock oracle/reference price, and traders would face changed execution prices and slippage after the depeg. The exact loss magnitude depends on each pool’s reserve composition, fee tier, and trade flow, and those pool-specific exposures are Not verifiable as of 2026-09-04 from the provided sources without on-chain analysis.

If you intended Raydium’s separate perps/collateral product rather than AMM, the docs indicate collateral assets and caps exist there, but the required on-chain exposure data is still Not verifiable as of 2026-09-04 in this run.

For Raydium AMM on Solana, a “top counterparty insolvent” stress is *not* a classic bilateral-credit event because the core AMM is designed as a pool-vs-user system, not an exposure to a single external counterparty. The main loss path is instead asset devaluation / impermanent loss for LPs, while the pool itself continues to honor swaps from its vault balances until those balances are depleted or the price moves further.

• Expected loss path: if the “top counterparty” is interpreted as the largest asset held by the pool becoming impaired or illiquid, the AMM’s invariant re-prices the pool as traders arbitrage against it; LPs absorb the loss through impermanent loss and adverse rebalancing, not a protocol promise of principal protection.
• Who absorbs it: LPs bear the economic loss first, because they own the pool’s inventory risk. Traders can also face worse execution/slippage during rapid repricing, but the smart contract itself does not socialize losses to users beyond the pool pricing mechanics.
• Compensation: there is no built-in insolvency compensation mechanism in the AMM design for a counterparty default scenario. Compensation only exists if a separate governance/treasury decision is made; for example, Raydium publicly said it would cover a distinct legacy AMM V3 exploit from treasury, but that was an incident-response choice, not a protocol guarantee for insolvency risk.
• Impact path through smart contracts: a swap hits the AMM program, which validates pool state, applies the constant-product curve, transfers tokens between user ATAs and pool vaults via SPL Token / Token-2022 CPI, and updates state/TWAP observations; if an underlying asset is impaired, the contract still executes on the available vault balances and the loss is reflected in pool reserves and LP share value, not routed through a separate recovery waterfall. For AMM v4 specifically, OpenBook/Serum dependency was removed in the 2026 program upgrade, so the current execution path is AMM-only rather than orderbook-dependent.

Raydium AMM has no verifiable evidence of DAO or owner committed fraud in the sources provided. The strongest sourced incident is a legacy AMM V3 exploit that Raydium and multiple reports describe as a vulnerability in retired pools, not a deliberate fraud by the DAO or owners; Raydium also said its treasury would cover losses. A separate 2022 incident cited by CertiK was a private key compromise caused by malware, again not proof of intentional fraud by the DAO or owners.

For a stress scenario, the prudent classification is low evidence of insider/DAO fraud but non-zero governance/admin risk because Raydium’s own docs note that a compromised admin or upgrade authority could be used to deploy malicious upgrades or redirect fees. That is a capability risk, not a demonstrated fraud event. Result: Fraud by the DAO or owners is Not verifiable as of 2026-09-04. Verified history points instead to external exploit and key-compromise scenarios, with the main residual concern being privileged-access abuse if controls fail.

Raydium AMM’s primary yield source is trading fees from its constant-product pools, not lender interest or emissions. Raydium documents AMM v4 as a pure constant-product AMM and states that live swaps execute against the AMM curve; its docs also describe CLMM positions as earning fees only when price is in range. For a stress scenario with negative 30-day primary yield, the practical interpretation is that fee income over the last 30 days was insufficient to offset the cost of capital and any price divergence/impermanent loss for LPs.

In that case, the protocol’s yield profile is *negative* from an LP perspective, meaning liquidity provision would have underperformed holding the underlying assets over that window. This is an inference from the fee-based design and the user’s stress assumption; the actual 30-day net yield is Not verifiable as of 2026-09-04 without on-chain pool and fee data. Risk implications:

• Fee-driven yield can decay quickly if swap volume falls or if liquidity is too deep relative to flow.
• LP returns are path-dependent: even with positive fees, volatile price moves can produce negative net outcomes after impermanent loss; this is especially relevant for concentrated liquidity when price moves out of range.
• Protocol-wide yield quality is not guaranteed by docs; the docs describe mechanics, not realized profitability. For an institutional risk view, I would treat this as a yield compression / negative carry regime and require pool-level 30-day fee APR, utilization, and IL analysis before allocating. Those realized figures are Not verifiable as of 2026-09-04 in this run.

Assessment (as of September 13, 2026): Raydium AMM is not demonstrated to be a binding, credibly neutral DAO. Raydium’s disclosed governance uses Solana Realms, with a 1,000,000 RAY proposal threshold and 1% quorum, but the process is described as off-chain and implemented by core team members. Token holders therefore do not demonstrably control upgrades or core parameters; classify DAO governance as false. Control surface: Raydium documentation states that AMM v4 upgrades are controlled by a 3-of-4 Squads multisig with a 24-hour timelock.

A separate 3-of-5 treasury multisig controls pool-admin functions, fee configuration, protocol-fee collection, treasury assets, and operating expenses; it has no timelock. The documented signers are described as core-team members using cold devices, but signer identities and independence are not independently verified here. Funds risk: The treasury multisig is documented as able to sweep protocol-designated fees, not LP principal. However, the upgrade multisig can deploy new bytecode; absent token-holder approval, a malicious or compromised 3-of-4 upgrade path could change user-fund logic after the 24-hour delay.

Accordingly, admin_can_drain is assessed true as a control-surface risk, not as evidence of current theft. Raydium states no program has been made immutable. Frontend/company: Frontend control, legal entity, jurisdiction, registration number, directors, and binding Terms of Service ownership: Not verifiable as of September 13, 2026. Holder concentration and top holders via Dune: Not verifiable as of September 13, 2026 (Dune unavailable; no on-chain substitute used).

Emergency bypass: Not verifiable as of September 13, 2026. Bottom line: Governance is presently team/multisig-controlled with a partially functional or symbolic DAO layer. The 24-hour upgrade delay is a mitigation, not token-holder control.

Raydium AMM appears to be operated with Cayman Islands governing-law language in its public terms/white paper materials, but I could not verify a clearly named operating legal entity from the gathered sources. The protocol/interface terms restrict use in comprehensive-sanctions/prohibited jurisdictions, require users not be sanctioned or restricted persons, and prohibit illegal activity, money laundering, terrorist financing, market manipulation, hacking, and similar conduct. The available materials indicate no mandatory KYC for basic protocol use, but do describe KYC/AML requirements for centralized platforms and, separately, permissioned/KYC-gated pools for regulated issuers.

I found no verified regulator action, court case, or sanctions designation against Raydium itself in the gathered sources. Data-protection disclosures are present in the privacy policy, including minimal collection, retention/rights language, and a contact address/email, but I could not verify the actual legal entity behind the Solana protocol from these sources. The practical legal risk is therefore higher than the formalized entity structure suggests: the interface imposes broad geo-blocking and sanctions screening, while the core AMM remains a permissionless on-chain venue that can be accessed outside the interface, so enforcement/compliance risk depends heavily on user location, front-end controls, and any regulated/permissioned pool configuration.

No exact GLEIF LEI record for 'Raydium AMM'. OFAC SDN screening of 'Raydium AMM': no match. SEC litigation and administrative release feeds: no mention.

Raydium AMM does not issue its own stablecoin. The stable-side pools documented for Raydium are for external stablecoins such as USDC-USDT and USDH-USDC, so own_stablecoin is false. No stablecoin depeg event could be verified from the available sources for the stablecoins used by Raydium AMM, so depeg_count, last_depeg_date, and max_depeg_pct are not verifiable as of 2026-09-06.

Because the question asks about the stablecoin used by the protocol and the available sources do not establish a verifiable depeg history for those specific assets, stable is null.

Raydium AMM’s principal risks are smart-contract and privileged-key failure, permissionless exposure to unsafe assets, adverse AMM economics/MEV, and dependence on Solana availability. Historical exploitation of an administrative account demonstrates that operational security remains material despite audits and a live bug-bounty program. No TVL or exposure percentages are presented: Not verifiable as of September 5, 2026.

Raydium AMM’s top strengths are its hybrid liquidity model, Solana-native speed and low fees, permissionless pool creation, oracle-free reserve-based pricing, and broad product depth. The protocol’s hybrid design routes liquidity through both AMM pools and OpenBook/CLOB infrastructure, which improves price discovery, depth, and capital efficiency versus a standalone AMM. Built on Solana, Raydium benefits from high throughput, low latency, and very low transaction costs, making swaps and liquidity actions fast and cheap.

Its AMM design is permissionless, allowing anyone to create pools for token pairs, which supports rapid ecosystem growth and long-tail asset coverage. Raydium also does not rely on external price oracles for core AMM pricing; it uses on-chain reserves and the constant-product formula, which reduces oracle dependency risk for the core swap engine. Finally, Raydium’s wider product stack—AMM variants, concentrated liquidity, farms/staking, and launch-related tooling—makes it a more integrated liquidity venue within Solana DeFi than a single-purpose swap protocol.