Responsible disclosure

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

​

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.

​

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 rubric

Payouts are based on a blend of severity and economic impact. Examples per tier:

​

Critical — $100,000–$500,000

• Drain of any user’s LP funds via a valid Raydium instruction.
• Unbounded mint of LP tokens.
• Bypass of program upgrade authority.
• Steal-all-protocol-fees bug.
• Make the pool’s accounting permanently wrong in a way that corrupts future LPs.

​

High — $25,000–$100,000

• Steal pending rewards from farms or CLMM positions.
• Freeze a user’s position (they cannot close it) via a malicious tx.
• Manipulate pool math such that profitable extraction is possible with moderate capital.
• Bypass slippage protection.

​

Medium — $5,000–$25,000

• Griefable DoS of a specific pool (all swaps revert).
• Rounding errors that systematically favor attackers, aggregated over many swaps.
• Fee misaccounting that benefits some users at others’ expense.
• CLMM tick-array corruption requiring manual admin intervention to fix.

​

Low — $500–$5,000

• Information-disclosure bugs (expose non-public state).
• Error-handling flaws that make diagnosis harder.
• Edge cases that revert cleanly but should have been handled gracefully.
• Typos in error messages that cause confusion.

​

Informational — No payout (but acknowledgment)

• Code-quality suggestions.
• Documentation improvements.
• Gas optimizations without security implications.

​

Economic-impact multiplier

For tier-qualifying bugs, the payout is further weighted by:

• Direct loss potential — how much TVL is practically extractable?
• Exploitability — is it trivially callable, or requires specific preconditions?
• Reproducibility — does the exploit work every time, or only under rare conditions?

A critical-severity bug affecting a $10M pool pays more than a critical-severity bug affecting a $100k pool, even though both are critical.

​

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 full PoC.
4. Triage typically within 24 hours.

Immunefi handles escrow and payout once the finding is confirmed.

​

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:

• 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 for both the report and any direct contact channel established afterward.

​

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 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

• Use your own funds on mainnet for proof-of-concept (small amounts).
• Develop against devnet or a forked mainnet validator when possible.
• Include a working PoC in the report.
• Estimate the economic impact to the best of your knowledge.
• Propose a fix if you have one in mind.

​

Don’t

• Publicly disclose the vulnerability before a fix is deployed.
• Attempt to extract more funds than necessary to demonstrate the bug.
• Conduct attacks against other users’ funds.
• Submit the same finding on multiple platforms (Immunefi, Twitter DM, email).
• Attempt social engineering against Raydium team members.
• Test authentication or DoS against raydium.io infrastructure.

Violations of these rules invalidate the bounty.

​

Response timeline

For critical findings, the fix track accelerates: the team convenes the 3/4 multisig immediately, drafts a fix, submits for review, queues the timelocked deploy. You can expect updates every 24 hours during a critical response.

​

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 Raydium leaderboard.

​

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 since program inception (2021):

• 200+ in-scope reports submitted across all severity tiers.
• 18 critical-severity findings paid out, totaling ~$2M.
• 60+ high-severity findings paid out.
• Median response time (initial triage): 8 hours.
• 0 public disclosures that bypassed the coordinated process.

The 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 the Immunefi leaderboard.

​

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.