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.
Every Raydium program has at least one privileged role — a key that can upgrade the program, create new configs, or withdraw protocol fees. Minimizing what these roles can do (and gating them behind multisigs with delays) is the primary defense against a compromised admin. This page catalogs the roles and how they’re secured in practice.
Roles by program
AMM v4
| Role | Authority address | What it can do |
|---|
| Program upgrade | Squads multisig (3/4) | Deploy new program bytecode |
| Pool admin | Treasury multisig (3/5) | Toggle pool status, update fees on existing pools |
CPMM
| Role | Authority address | What it can do |
|---|
| Program upgrade | Squads multisig (3/4) | Deploy new program bytecode |
| AmmConfig admin | Treasury multisig (3/5) | Create new AmmConfigs (fee tiers); toggle existing |
| Create pool fee recipient | Treasury multisig (3/5) | Receive the one-time create-pool fee |
CLMM
| Role | Authority address | What it can do |
|---|
| Program upgrade | Squads multisig (3/4) | Deploy new program bytecode |
| AmmConfig admin | Treasury multisig (3/5) | Create/modify AmmConfigs |
| DynamicFeeConfig admin | Treasury multisig (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — calibrate the dynamic-fee tiers a CreateCustomizablePool call may opt into |
limit_order_admin (program-wide) | Off-chain operational hot wallet, not a multisig | Settle and close limit orders on behalf of their owners. The keeper key is a single program-wide constant (different value on mainnet vs devnet), checked via signer == limit_order.owner || signer == limit_order_admin::ID on SettleLimitOrder / CloseLimitOrder. Output always lands in the original owner’s ATA; the keeper cannot redirect funds, modify orders, or open new ones. |
limit_order_admin is a deliberately narrow operational role. It exists so an off-chain keeper can sweep filled orders without the order’s owner having to be online. The keeper key is hot (lives on the keeper VM) and is rotated independently of the multisigs above. Concretely, the keeper authority is bounded to:
SettleLimitOrder — push the filled output of an order to the owner’s ATA at the order’s limit price.CloseLimitOrder — close a fully-settled order’s account to reclaim rent (rent goes to the order owner).
It cannot call OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, mutate any pool field, or sign for any other instruction — those checks are enforced on-chain by the seed and has_one constraints in the instruction’s Accounts struct. A compromised keeper can at worst be unavailable (orders stay parked until the owner settles them themselves) or settle/close legitimately-fillable orders out of order; it cannot move user funds anywhere other than where the owner already authorized them to go.
Farm v6
| Role | Authority address | What it can do |
|---|
| Program upgrade | Squads multisig (3/4) | Deploy new program bytecode |
| Farm creator (per farm) | The farm’s creator wallet | Fund reward vaults, extend schedules, reclaim unused rewards |
LaunchLab
| Role | Authority address | What it can do |
|---|
| Program upgrade | Squads multisig (3/4) | Deploy new program bytecode |
| Launch creator (per launch) | The launch’s creator wallet | Collect creator fees post-graduation; withdraw un-graduated curve remnant |
Program upgrade authority
Raydium’s programs use the standard Solana BPF Loader v3 upgrade mechanism. The upgrade authority for all programs is the 3/4 Squads multisig.
Why 3/4: enough signers that a single compromise is insufficient; few enough that coordinating a legitimate upgrade is tractable. The four authorities are independent, air-gapped cold-device signers held by core team members. Sequential signing prevents parallel approvals on the same transaction; transactions carry a fixed expiration window. Multisig operations are reviewed periodically in partnership with Solana’s STRIDE Program (Asymmetric Research).
Removing upgrade authority
Raydium has not set any program’s upgrade authority to null. The protocol operates under the principle that programs need to be upgradeable (to patch bugs, add extensions like Token-2022, fix integration drift). Trade-off: users trust that the 3/4 multisig will only deploy well-reviewed upgrades.
For users who want an immutable alternative, the older AMM v4 program has been stable since its last audit; zero upgrades in 18 months. That code path is effectively frozen even though the authority still exists.
AmmConfig authority
Each new AmmConfig creation is permissioned — the 3/5 treasury multisig authorizes new fee tiers and tick spacings. Existing pools reference their AmmConfig by PDA; the pool’s fee tier is whatever the AmmConfig says.
Can admins change an existing AmmConfig? Yes, technically. updateAmmConfig is callable by the admin. In practice, modifications to deployed AmmConfigs are avoided because it changes the economics of all pools using that config silently. Protocol policy is to create a new AmmConfig for any change and migrate.
Can admins steal protocol fees via config? No — the AmmConfig contains fee parameters but not the protocol fee recipient; that’s a separate immutable address per pool.
Protocol fee claim
A portion of swap fees (typically 3–12 bps of 25 bps swap fee, depending on config) accrues to a protocol fee vault. The multisig can withdraw these accrued fees. Users never see their LP balance change from this — it’s the protocol’s pre-allocated share, not LP money.
Farm creator authority
Farms v6 give the creator the power to:
- Fund the reward vault (add more tokens).
- Extend the schedule (push end time later).
- Call
withdrawReward after end time to reclaim unused vault balance.
Farm creators cannot:
- Withdraw staked user LP.
- Change the staking mint.
- Change emission rates retroactively (only forward-looking via
setRewards).
- Freeze user harvests.
A malicious farm creator can at worst under-fund the vault so the farm runs dry; users’ principal stake is always safe.
Squads multisig configuration
Raydium operates two separate Squads multisigs for distinct risk surfaces. Both can be inspected on-chain via the Squads Protocol UI.
| Multisig | Threshold | Timelock | Scope |
|---|
| Program upgrade | 3/4 | 24 hours | Sole authority for deploying new program bytecode for AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap, and the legacy Farm/Staking programs. View at app.squads.so/.../FytDr…ceZQK. |
| Treasury | 3/5 | none | Treasury assets, protocol revenue, operational expenses. Also holds Raydium’s limited program-admin authority (creating AmmConfigs, sweeping protocol fees, configuring pool parameters) for the time being. View at v3.squads.so/dashboard/RVha…dHdtYz09. |
- 24-hour timelock on any transaction. An upgrade approved today executes no earlier than 24 hours later, giving users time to respond.
- Air-gapped cold-device signing. Cold devices have network cards physically removed; they connect only to a hardware wallet and read transaction data via QR code from a separate hot device.
- Sequential signing. Only after one cold device generates and signs a transaction can the next cold device begin its signing process — preventing conflicting or parallel signatures on the same transaction.
- Transaction expiration. Every transaction carries a fixed expiration window, so stale transactions auto-invalidate.
- TOTP + physical-key enforcement on the hot devices used for transaction initiation and on-chain broadcast.
- Public transaction queue. Anyone can monitor pending upgrades on the Squads UI.
The treasury multisig has no timelock — its scope is narrower and routine ops (creating AmmConfigs, sweeping fees) need to land same-day. The treasury multisig also holds the limited program-admin authority listed in the per-program tables above; this is an interim arrangement and is reviewed periodically with the project’s security partners.
Verifying authority on-chain
The simplest way to verify a program’s current upgrade authority:
solana program show <PROGRAM_ID>
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Authority is not the expected Squads multisig address, something is wrong. Raydium publishes the expected authority addresses on reference/program-addresses.
For AmmConfig / pool admin roles, fetch the on-chain account and decode:
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Expected: 3/5 treasury multisig.
Historical authority changes
| Date | Program | Change |
|---|
| 2022-12 | AMM v4 | Upgrade authority migrated from single-sig to 3/4 multisig after incident |
| 2023-02 | All programs | All operational roles unified under 3/5 treasury multisig |
| 2023-11 | CLMM | Added second multisig for reward-only operations to reduce exposure |
| 2024-05 | CPMM | Initial deploy with multisig authority from day zero |
User-side considerations
What should you do as a user/LP/integrator?
- Check upgrade authority before large allocations. Confirm it matches the documented multisig.
- Monitor multisig activity. Squads UI shows pending transactions; a scheduled upgrade gives you 24 hours to unwind if you disagree with the change.
- Time-lock-aware redemption strategies. If you’re running an auto-compounder, make sure your unwind path doesn’t require an instruction that’s being changed.
- Don’t assume program immutability. Every Raydium program can be upgraded; plan for it.
Pitfalls for integrators
1. Caching authority addresses
If you hardcode the upgrade authority or admin multisig address in your code and it later rotates, your verification fails. Fetch from reference/program-addresses at runtime or refresh periodically.
2. Assuming AmmConfigs are stable
A new AmmConfig can be created at any time. Your aggregator/router should re-fetch the full config list periodically (hourly is fine).
3. Farm-creator grief vectors
If you’re depositing into a low-reputation farm, the creator could end the farm early and reclaim reward vault (assuming no user has staked yet). Once users have staked, pro-rata entitlements are enforced by the program; reclaim only gets the leftover after rational end.
Pointers
Sources:
