Responsible disclosure

​

Scope

​

In bounty scope (paid)

The bounty applies only to deployed on-chain program code:

• Deployed programs at the program IDs in reference/program-addresses:
  • AMM v4 (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8)
  • CPMM (CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C)
  • CLMM (CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK)
  • Stable AMM (5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h)
  • LaunchLab (LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj)
  • Farm v3 / v5 / v6
  • LP-Lock / Burn & Earn (LockrWmn6K5twhz3y9w1dQERbmgSaRkfnTeTKbpofwE)
  • AMM Routing
• Smart-contract CPI composability bugs where a composing program’s correct use of a Raydium program causes the Raydium program itself to misbehave.

​

Not in bounty scope (welcome to report — see below)

• Raydium SDK v2 (@raydium-io/raydium-sdk-v2) on npm.
• REST APIs (every host listed in the API Reference tab — api-v3.raydium.io, transaction-v1.raydium.io, launch-*-v1.raydium.io, etc.).
• Frontend (raydium.io) — including XSS, CSRF, auth-flow bugs, wallet-spoofing, broken UI states.
• Off-chain indexers, image / IPFS gateways, and any other infrastructure that serves data into the UI.

These do not pay out. Reports are still welcome and helpful — submit them through the Non-bounty channel below.

​

Out of scope (not eligible at all)

• Third-party programs that compose with Raydium (report to their teams).
• Third-party aggregators that route through Raydium (e.g. Jupiter).
• Off-chain tooling not maintained by Raydium (community SDKs in Python, third-party bots, etc.).
• Social-engineering attacks against Raydium team members.
• Any finding requiring validator-side collusion or majority-stake attacks (this is Solana-layer, not a DeFi bounty target).
• DoS via spamming public RPC endpoints.
• Automated scanning-tool outputs without a working proof-of-concept.

Program-specific exclusions (per the Immunefi listing):

• AMM v4 / OpenBook dependencies — bugs pertaining to OpenBook dependencies are not in scope. AMM v4 is set to Status 6, so liquidity is no longer shared to OpenBook markets.
• Findings already flagged in prior security reviews are not eligible: the Ottersec review of CLMM, and the Kudelski, Ottersec, and MadShield reviews of the Hybrid AMM program. Re-reporting an already-disclosed issue does not pay out.
• CLMM yield-claim failure by design — the CLMM emits trading-fee and farming-yield tokens to LPs. If an attacker drained the vault or fee tokens, users would be unable to claim yield and transactions would fail. This is by design and is not considered a vulnerability.

​

Gray zone — discuss first

• Bugs in MEV-resistance primitives that interact with external infrastructure.
• Token-2022 integration edge cases where the “correct” behavior is ambiguous.
• Economic / game-theoretic attacks that don’t map cleanly to a code bug.

When uncertain, err on the side of reporting.

​

Severity and rewards

Reports are classified using the Immunefi Vulnerability Severity Classification System V2.3, under a Primacy of Rules model: the terms on this page and the Immunefi listing govern, and take precedence over the default classification where they differ. Rewards are denominated in USD and paid by the Raydium team in RAY, SOL, or USDC. The smart-contract reward tiers are: There is no separate paid tier below Medium. The $50,000 critical minimum exists specifically to discourage researchers from withholding a report when the directly-affected funds are small.

​

Critical reward calculation

For mainnet assets, the critical reward is 10% of the funds directly affected, up to a maximum of $505,000. If 10% of funds at risk falls below $50,000, the report still pays the $50,000 minimum. The cap and the 10%-of-funds-at-risk basis apply to critical smart-contract reports.

​

Impacts in scope

The bounty uses Immunefi’s standardized impact taxonomy. Raydium-specific examples are given to illustrate how each impact maps onto the programs. Critical

• Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield — e.g. draining a user’s LP funds via a valid Raydium instruction, or an unbounded mint of LP tokens.
• Permanent freezing of funds — e.g. corrupting pool accounting so funds become permanently unrecoverable.
• Vulnerabilities that could freeze user funds permanently, or that drain or steal funds without user transaction approval — e.g. bypassing the program upgrade authority, or a steal-all-protocol-fees bug.

High

• Theft of unclaimed yield — e.g. stealing pending rewards from farms or CLMM positions.
• Permanent freezing of unclaimed yield.
• Temporary freezing of funds for any amount of time — e.g. freezing a user’s position so they cannot close it via a malicious tx.
• Vulnerabilities that could freeze user funds temporarily or intentionally alter the value of user funds — e.g. manipulating pool math or bypassing slippage protection.

Medium

• Smart contract unable to operate due to lack of token funds.
• Block stuffing for profit.
• Griefing (no profit motive for the attacker, but damage to users or the protocol) — e.g. a griefable DoS where all swaps on a pool revert.
• Theft of gas.
• Unbounded gas consumption.

​

Contact paths

​

Primary: Immunefi

Raydium’s bug bounty is listed on Immunefi. Report through the Immunefi platform:

1. Create an Immunefi account.
2. Navigate to the Raydium bounty page.
3. Submit the finding with a full PoC. A proof-of-concept is required for all severities — explanations and statements are not accepted, working code is required. Critical and High reports should also include a suggested fix.
4. Reports are handled quickly — the program’s median resolution time is ~1 day.

Payouts are handled by the Raydium team directly, not by Immunefi escrow — denominated in USD and paid in RAY, SOL, or USDC. No KYC is required for payout processing.

​

Alternative: email submission

Bounty-scope findings may also be submitted by email instead of (or in addition to) Immunefi:

• security@raydium.io
• security@reactorlabs.io

Include a full working PoC, and for Critical / High reports a suggested fix, just as on Immunefi. Encrypt sensitive details with the team’s PGP key if needed — ask in the email and the team will exchange keys. Do not submit the same finding through multiple channels at once (pick Immunefi or email).

​

Direct (for critical, time-sensitive findings)

If the finding is being actively exploited or imminent and you cannot wait for Immunefi triage, the fastest secondary path is:

• Direct email to security@raydium.io or security@reactorlabs.io — the fastest path to reach the team directly; flag the subject line as an active exploit.
• Immunefi’s emergency button on the bounty page — escalates within minutes during business hours.
• Encrypted contact through Immunefi — Immunefi can relay an end-to-end encrypted message to the Raydium team.

Avoid public channels (X / Twitter, Telegram, Discord) for security reports — the disclosure itself can trigger exploitation. Use Immunefi or the security emails above for both the report and any follow-up contact.

​

Non-bounty reports (SDK / API / UI)

For issues in components outside the bounty — the SDK, the REST APIs, the raydium.io frontend, or any off-chain infrastructure — there is no payout, but the team still wants to hear about them. Use:

• Email: security@raydium.io or security@reactorlabs.io for anything with security implications (XSS, CSRF, auth-flow leaks, signed-message replay, wallet spoofing, sensitive data exposed by an API, etc.). Encrypt with the team’s PGP key if the bug is sensitive; ask in the email and the team will exchange keys.
• GitHub issues: for non-security functional bugs in the SDK, the docs, or any Raydium-maintained open-source repo. Open an issue on the relevant repository (e.g. raydium-io/raydium-sdk-V2).
• Discord (discord.gg/raydium): fine for low-impact UI / UX feedback that does not touch security. Do not post anything that could enable an exploit if read by a stranger.

What you get from non-bounty reports:

• Acknowledgment in the response within a few business days.
• Cross-repo coordination if the fix spans the program and the SDK.
• Public credit (with your consent) in the relevant changelog or release notes.
• Repeat reporters of substantive findings are sometimes invited to a contributor program; that path is separate from the on-chain bounty and is offered on a discretionary basis.

What you do not get:

• A scaled payout, regardless of severity. The bounty is for program-code findings.
• Coverage under the safe-harbor policy below — that policy specifically refers to bounty-scope research. For SDK / API / UI testing, follow normal responsible-disclosure conventions and standard terms of service.

​

Rules of engagement

​

Do

• Test only against a local fork of mainnet or public testnet. All proof-of-concept work must be done on a local fork.
• Include a working PoC in the report (required for all severities).
• Estimate the economic impact to the best of your knowledge.
• Propose a fix — required for Critical and High reports.

​

Don’t

• Test on mainnet or public testnet deployed code. Any such testing is prohibited; use local forks only.
• Test with pricing oracles or third-party smart contracts, or with third-party systems, applications, browser extensions, or websites.
• Publicly disclose the vulnerability before a fix is deployed (public disclosure of an unpatched bug in an embargoed bounty is prohibited).
• Run automated testing that generates significant traffic, or any denial-of-service attack against project assets.
• Attempt phishing or other social engineering against Raydium team members or users.
• Submit the same finding through more than one channel at once — pick Immunefi or email, not both, and never via public DMs.

These follow the Immunefi Rules; violations invalidate the bounty.

​

Response timeline

The program’s median resolution time is about 1 day (per the public Immunefi listing). The phases below are indicative of how a report progresses; exact SLAs are governed by the Immunefi listing and triage process, not by this page: For critical findings, the fix track accelerates: the team convenes the multisig, drafts a fix, submits for review, and queues the timelocked deploy.

​

What not to disclose publicly

Until a fix is deployed and the Raydium team has coordinated disclosure with you:

• Don’t tweet about the finding (even vague “I found something big”).
• Don’t describe the bug class to third parties.
• Don’t share PoC code with anyone outside Raydium’s triage team.

After fix deployment + coordinated disclosure window:

• Public writeups are welcome and encouraged.
• Raydium will cross-promote substantive writeups.
• Researchers who consent to be named are credited on the Immunefi Whitehat Hall of Fame.

​

Safe-harbor policy

Research conducted within the scope and rules above is explicitly authorized. Raydium:

• Will not pursue legal action for good-faith research that follows this policy.
• Will not interfere with research activities (e.g., blacklist researcher wallets).
• Will collaborate on understanding the finding.

Research outside scope or rules is not protected by safe harbor. If your research plan is borderline, ask via Immunefi’s “Ask Project” channel before testing.

​

Notable past disclosures

Aggregated statistics for the program-code bounty, which has been live on Immunefi since 25 April 2023 (figures per the public Immunefi listing):

• Total rewards paid to date: ~$3.4M.
• Median resolution time: ~1 day.

The Immunefi Whitehat Hall of Fame lists researchers who consented to be named. Non-bounty reports (SDK / API / UI) are tracked separately and acknowledged in the relevant repository’s release notes rather than on Immunefi.

​

Related programs

• Solana Foundation Bug Bounty — covers Solana validator client bugs (sealevel, consensus). Report there for Solana-layer issues. solana.com/security.
• Squads Protocol Bug Bounty — covers multisig itself. squads.so/security.
• Immunefi — covers many DeFi protocols including Raydium. immunefi.com.

A bug that spans layers (e.g. a Solana validator bug that manifests on Raydium) should be reported to all applicable programs.

​

Pointers

• security/audits — prior audit history.
• security/admin-and-multisig — authority structure.
• security/attack-vectors — known attack classes.

Sources:

• Immunefi Raydium bounty page — canonical scope, payout terms, and contact path.