MiCA Whitepaper Inline XBRL

N	Field	Content
00	Table of contents	General Information Part A: Information about the offeror or the person seeking admission to trading Part B: Information about the issuer, if different from the offeror or person seeking admission to trading Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Part D: Information about the crypto-asset project Part E: Information about the offer to the public of crypto-assets or their admission to trading Part F: Information about the crypto-assets Part G: Information on the rights and obligations attached to the crypto-assets Part H: Information on the underlying technology Part I: Information on the risks Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
01	Date of notification	2026-05-29
02	Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114	This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
03	Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114	This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
04	Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114	The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.
05	Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114	False
06	Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114	The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
07	Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114	Warning This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
08	Characteristics of the crypto-asset	RAY is the native crypto-asset of the Raydium protocol, a decentralised finance (DeFi) protocol built on the Solana blockchain. The RAY token has a total supply of 555,000,000. The Raydium protocol provides automated market maker (AMM) services, liquidity pools, token swaps, concentrated liquidity market maker (CLMM) functionality, yield farming and related decentralised trading infrastructure. The protocol is designed to enable users to provide liquidity, trade digital assets and participate in DeFi applications operating on Solana. RAY does not provide holders with ownership rights, equity rights, repayment rights, guaranteed redemption rights, profit participation rights or claims against any legal entity. Holding RAY does not grant any rights comparable to shares, securities or other financial instruments.
09		Not applicable
10	Key information about the offer to the public or admission to trading	The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

N	Field	Content
A.1	Name	N/A
A.2	Legal form	N/A
A.3	Registered address	N/A
A.4	Head office	N/A
A.5	Registration date	N/A
A.6	Legal entity identifier	N/A
A.7	Another identifier required pursuant to applicable national law	N/A
A.8	Contact telephone number	N/A
A.9	E-mail address	N/A
A.10	Response time (Days)	N/A
A.11	Parent company	N/A
A.12	Members of the management body	N/A
A.13	Business activity	N/A
A.14	Parent company business activity	N/A
A.15	Newly established	N/A
A.16	Financial condition for the past three years	N/A
A.17	Financial condition since registration	N/A

N	Field	Content
E.1	Public offering or admission to trading	ATTR
E.2	Reasons for public offer or admission to trading	By admitting the RAY asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.
E.3	Fundraising target	N/A
E.4	Minimum subscription goals	N/A
E.5	Maximum subscription goals	N/A
E.6	Oversubscription acceptance	N/A
E.7	Oversubscription allocation	N/A
E.8	Issue price	N/A
E.9	Official currency or any other crypto-assets determining the issue price	N/A
E.10	Subscription fee	N/A
E.11	Offer price determination method	N/A
E.12	Total number of offered/traded crypto-assets	268967970 The circulating supply of RAY changes over time as tokens are released into circulation in accordance with the allocation and emission mechanisms. For the purpose of complying with the technical requirements of the MiCA Regulation XBRL taxonomy, a circulating supply of 268967970.467351 has been reflected as the number of tokens in the machine-readable version of the white paper. This figure emerges from https://api.raydium.io/ray/circulating, as consulted on 12 May 2026 is indicative and may vary over time depending on the token emissions, vesting releases, market activity of RAY tokens.
E.13	Targeted holders	ALL
E.14	Holder restrictions	N/A
E.15	Reimbursement notice	N/A
E.16	Refund mechanism	N/A
E.17	Refund timeline	N/A
E.18	Offer phases	N/A
E.19	Early purchase discount	N/A
E.20	Time-limited offer	N/A
E.21	Subscription period beginning	N/A
E.22	Subscription period end	N/A
E.23	Safeguarding arrangements for offered funds/crypto-Assets	N/A
E.24	Payment methods for crypto-asset purchase	N/A
E.25	Value transfer methods for reimbursement	N/A
E.26	Right of withdrawal	N/A
E.27	Transfer of purchased crypto-assets	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.
E.28	Transfer time schedule	N/A
E.29	Purchaser's technical requirements	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.
E.30	Crypto-asset service provider (CASP) name	N/A
E.31	CASP identifier	N/A
E.32	Placement form	NTAV
E.33	Trading platforms name	Bitstamp Europe S.A.
E.34	Trading platforms Market identifier code (MIC)	BESA
E.35	Trading platforms access	Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.
E.36	Involved costs	There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.
E.37	Offer expenses	Not applicable
E.38	Conflicts of interest	There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest. In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.
E.39	Applicable law	Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.
E.40	Competent court	Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

N	Field	Content
F.1	Crypto-asset type	Crypto-assets other than asset-referenced tokens or e-money tokens
F.2	Crypto-asset functionality	The token is used within the Raydium ecosystem for governance participation, staking and liquidity-related functions associated with the operation of the protocol and its DeFi infrastructure. RAY may be used in connection with staking mechanisms available through the Raydium application. The token is also used in liquidity pools and may function as a base or quote asset within Raydium trading infrastructure. A portion of trading fees generated through the Raydium protocol is used to buy back RAY tokens. The Raydium protocol provides decentralised trading and liquidity infrastructure through products including automated market maker pools, CLMM pools, liquidity farming infrastructure, token swap routing mechanisms and token launch infrastructure. RAY is associated with participation in and interaction with these ecosystem functionalities. Ownership or use of RAY is not required in order to swap tokens, provide liquidity, create pools or use perpetual trading functionality within the Raydium ecosystem.
F.3	Planned application of functionalities	Not applicable
F.4	Type of crypto-asset white paper	OTHR
F.5	The type of submission	NEWT
F.6	Crypto-asset characteristics	RAY is the native crypto-asset of the Raydium protocol, a DeFi protocol built on the Solana blockchain. The RAY token has a total supply of 555,000,000. The Raydium protocol provides AMM services, liquidity pools, token swaps, CLMM functionality, yield farming and related decentralised trading infrastructure. The protocol is designed to enable users to provide liquidity, trade digital assets and participate in decentralised finance applications operating on Solana. RAY does not provide holders with ownership rights, equity rights, repayment rights, guaranteed redemption rights, profit participation rights or claims against any legal entity. Holding RAY does not grant any rights comparable to shares, securities or other financial instruments.
F.7	Commercial name or trading name	Raydium Protocol
F.8	Website of the issuer	https://raydium.io/
F.9	Starting date of offer to the public or admission to trading	2026-07-01
F.10	Publication date	2026-06-30
F.11	Any other services provided by the issuer	Not applicable
F.12	Language or languages of the crypto-asset white paper	English
F.13	Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available	BL6GMJNDW
F.14	Functionally fungible group digital token identifier, where available	7HFXRDFHH
F.15	Voluntary data flag	FALSE
F.16	Personal data flag	TRUE
F.17	LEI eligibility	TRUE
F.18	Home Member State	Luxembourg
F.19	Host Member States	Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

N	Field	Content
G.1	Purchaser rights and obligations	Not applicable as the RAY crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the Raydium project. Holding RAY does not give rise to contractual claims or entitlements against any natural or legal person.
G.2	Exercise of rights and obligations	Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.
G.3	Conditions for modifications of rights and obligations	Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.
G.4	Future public offers	Not applicable
G.5	Issuer retained crypto-assets	111000000
G.6	Utility Token Classification	FALSE
G.7	Key features of goods/services of utility tokens	Not applicable
G.8	Utility tokens redemption	Not applicable
G.9	Non-trading request	TRUE
G.10	Crypto-assets purchase or sale modalities	Not applicable
G.11	Crypto-assets transfer restrictions	Not applicable
G.12	Supply adjustment protocols	FALSE
G.13	Supply adjustment mechanisms	Not applicable
G.14	Token value protection schemes	FALSE
G.15	Token value protection schemes description	Not applicable
G.16	Compensation schemes	FALSE
G.17	Compensation schemes description	Not applicable
G.18	Applicable law	There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.
G.19	Competent court	There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Part H – Information on underlying technology

N	Field	Content
H.1	Distributed ledger technology	Not applicable as DTI is provided in F.13
H.2	Protocols and technical standards	RAY is a fungible token issued on the Solana mainnet-beta network under the Solana Program Library (SPL) token standard. All protocols, standards, and interfaces described in this section are those of the Solana network and the SPL Token program on which RAY operates; Raydium does not operate a separate distributed ledger. Networking, Transport and Session RAY transactions and Raydium protocol interactions reach the network through Solana's remote procedure call (RPC) interface, which provides HTTP and WebSocket endpoints for reading network state, submitting transactions, simulating execution, and subscribing to live updates. RPC requests target a specific cluster: the mainnet endpoint serves production traffic using real SOL, whilst devnet and testnet serve development and validator testing, respectively. Public RPC endpoints are shared infrastructure subject to rate limits and traffic restrictions; production applications are expected to use dedicated or private RPC infrastructure. Commitment levels govern how finalised a state view must be before a node returns data. The processed level reflects the node's most recently processed block, which may still be rolled back. Confirmed reflects a block that a supermajority of the network's active stake has voted on directly. Finalised reflects a block the cluster has recognised with maximum lockout, the strongest confirmation state available on the network. At the application layer, Raydium publishes a REST API (v3) for querying pool, mint, farm, and chain-time data on Solana, and a route API for computing swap quotes and building swap transactions. These interfaces support front ends, wallets, and integrators in constructing Raydium-related transactions and reading protocol state; settlement remains an on-chain Solana transaction and does not bypass the network's consensus process. Solana RPC supplies the base read-and-write interface for the network, providing state queries, transaction submission, simulation, and live WebSocket subscriptions. Serialisation Solana transactions comprise signatures and a message, with the message carrying account addresses, a recent blockhash, and compiled instructions. Multiple instructions may be composed into a single transaction, allowing a single user interaction to span several Solana programs or account updates within one atomic execution unit. The current maximum transaction size is 1,232 bytes; an increase to this limit is under development and expected by Agave 4.1 but does not form part of the current baseline. RAY transfers are executed as an SPL Token program Transfer instruction, which moves token units between token accounts. The owner of the sender's token account must sign the transaction; a transfer cannot proceed without an authorised signature and cannot alter balances outside the Token program's instruction logic. Cryptography and Key Material Solana accounts are keyed by 32-byte addresses. Transaction signing uses the Edwards-curve Digital Signature Algorithm (Ed25519); the base network fee covers Ed25519 signature verification, with additional precompile verifications supported for Secp256k1 and Secp256r1. Proof of History uses a sequentially run cryptographic hash function, chosen so that output cannot be predicted without fully executing the function, to create an ordered, verifiable record of events that can be checked in parallel by multi-core verifiers. The RAY mint account records supply, decimal precision, mint authority, and freeze authority in its on-chain state. No mint authority is present on the RAY mint, meaning the supply is permanently fixed and no further tokens may be minted by any party. No freeze authority is set, meaning no party can freeze holder token accounts. Solana Explorer confirms this configuration. Ledger Solana's ledger stores state in accounts. Each account holds lamports, arbitrary data, an owner program, an executable flag, and a rent epoch. programs are stateless: mutable program state lives in separate data accounts passed to program instructions as arguments. The RAY mint, holder token accounts, and Raydium program accounts are each distinct Solana accounts, updated exclusively by valid signed transactions. Each RAY token account records the mint, the account owner, and the token amount held. Associated token accounts derive a deterministic default address from the owner's public key and the RAY mint address, providing a standard derivation path for wallets and integrators without requiring an additional on-chain lookup. Execution Solana programs are compiled to the Solana Bytecode Format (sBPF) and are stateless. Instructions carry a program identifier, a list of accounts, and opaque instruction data. RAY token transfers execute under the SPL Token program. Raydium protocol interactions, swaps, liquidity provision, farming, and staking, execute under the respective Raydium program identifiers on the Solana mainnet-beta runtime. Token Standards RAY is an SPL token under the original Token program. The original Token program provides core token functionality, minting, transfer, delegation, freezing, and burning, and is immutable and widely deployed across the Solana ecosystem. Token-2022, the extension-capable successor program, is used in Raydium's CPMM for pool pairs denominated in Token-2022 tokens. The RAY mint itself is not a Token-2022 mint and carries none of the extension configurations available under that program. Permits, Approvals and Compliance The SPL Token program supports delegated spending authority: a token-account owner may approve a delegate to transfer or burn a defined amount on their behalf, and may revoke that delegation at any time. Authority roles which are mint authority, freeze authority, account owner, and close authority, may be changed or renounced at the mint or token-account level. No transfer restriction, allow-list, or compliance hook specific to RAY is identifiable in the token's current on-chain configuration. Solana Explorer records no programmable configuration on the RAY mint.
H.3	Technology used	Implementation and Architecture RAY is implemented as a Solana SPL token. Raydium's protocol is delivered through a set of Solana on-chain programs, each deployed at a canonical mainnet-beta program address. The active program set comprises AMM v4, CPMM, CLMM, Stable AMM, Farm v6, LaunchLab, AMM Routing, and Burn & Earn or LP Lock. Farm v3 and Farm v5 remain deployed and operational for existing positions but are in wind-down: no new farms are accepted on these versions, and all new ecosystem farms are created exclusively on Farm v6. Farm v3 additionally serves as the legacy RAY single-asset staking program. AMM v4 is a constant-product market maker that was originally integrated with the OpenBook CLOB. That OpenBook integration has since been deactivated; AMM v4 pools no longer share liquidity to OpenBook, and all swaps execute purely against the constant-product curve. AMM v4 is in stewardship mode having security fixes only, with no new feature development, and new pool creation is discouraged in favour of CPMM. CPMM is the current default constant-product pool, rewritten in the Anchor framework. It supports Token-2022 pairs, requires no OpenBook market account, and has a simpler account structure than AMM v4. CLMM is the concentrated liquidity program and operates on a single program version; improvements are delivered as in-place upgrades behind the 24-hour timelocked upgrade multisig rather than as new program generations. A SwapV2 instruction was added to CLMM to handle Token-2022 transfer-fee mathematics correctly; integrators should target SwapV2 for Token-2022 pairs. Program-derived addresses (PDAs) are used throughout the architecture for account organisation. PDAs are deterministic addresses derived from a program identifier and seed bytes; only the owning program may sign on behalf of a PDA through Solana's cross-program invocation mechanism. Canonical PDA seed conventions are published for CPMM and CLMM account types. Token-pair ordering in CPMM pool PDAs follows public-key byte order (token0 < token1) before hashing. AMM v4, CPMM, and CLMM ship with public source repositories under the Raydium GitHub organisation. Stable AMM, LaunchLab, AMM Routing, Burn & Earn or LP Lock, and the Farm programs are closed-source and verifiable against live on-chain bytecode and published IDL schemas in the raydium-idl repository. Runtime and Build Parameters Solana programs are compiled to sBPF and deployed via the standard BPF Loader v3 upgrade mechanism. Raydium operates two distinct Squads multisigs for program governance. The program upgrade multisig operates at a 3-of-4 threshold with a mandatory 24-hour timelock; it is the sole authority for deploying new bytecode for all Raydium programs. The four signers are independent, air-gapped cold-device holders; signing is sequential and every transaction carries a fixed expiration window. The treasury multisig operates at a 3-of-5 threshold with no timelock and governs operational roles including creating new AmmConfigs, sweeping protocol fees, and configuring pool parameters. Raydium has not set any program's upgrade authority to null. All programs remain upgradeable; users can monitor pending upgrade transactions through the public Squads Protocol interface, which provides a 24-hour window to respond before any upgrade executes. Account-level operational authorities, including protocol-owner and fund-owner fields in CPMM and CLMM AmmConfig accounts, are stored on-chain and may differ from the program-level admin key. For CLMM specifically, a separate limit-order admin role exists: a single operational hot wallet (not a multisig) that can settle and close filled limit orders on behalf of their owners, routing output exclusively to the order owner's associated token account. This role cannot open, modify, or redirect orders, and cannot interact with any other program instruction. AmmConfig accounts, which define fee tiers and tick spacings, are created by the treasury multisig. Existing pools reference their AmmConfig by PDA; the pool's fee parameters are whatever the AmmConfig specifies at the time of interaction. Protocol policy is to create a new AmmConfig for any fee-tier change rather than modifying an existing config, because modifying a deployed AmmConfig would silently affect all pools referencing it. Dependencies Token interactions depend on the Solana Token program for RAY and non-Token-2022 pool tokens, and on the Token Extension program for Token-2022 pool pairs. Published IDL schemas serve as the verifiable interface for each program. A 2021 security review performed RustSec advisory checks on the AMM and staking codebase, identifying dependency advisories present in that historical version at the audited commit hashes; those findings are specific to that codebase snapshot. Deployment and Addresses The RAY mint address is 4k3Dyjzvzp8eMZWUXbBCjEvwSkkk59S5iCNLY3QrkX6R. The token has a fixed maximum supply of 555,000,000 units with six decimal places of precision. Solana Explorer records the circulating fixed supply at 554,997,740.34359 RAY, consistent with the absence of a mint authority. Protocol program identifiers for all mainnet-beta deployments are published in the Raydium documentation and are independently verifiable on-chain; the expected upgrade authority for each program is the 3-of-4 program upgrade multisig. Client Interfaces and SDKs Application access is provided through Raydium's REST API v3 and route APIs, together with published program IDLs that underpin SDK and front-end integrations. The live API at api-v3.raydium.io provides configuration lookups including AmmConfig lists for CPMM and CLMM, which should be fetched at runtime rather than hardcoded, as new configs may be added at any time. Solana RPC and WebSocket subscriptions provide the base connectivity layer for balance queries, transaction submission, and event streaming. On-chain token and program state is independently verifiable through block explorers such as Solana Explorer.
H.4	Consensus Mechanism	RAY does not run a standalone consensus mechanism. As a Solana SPL token, its issuance record, transfers, and token-account balances are ordered, validated, and finalised by Solana's consensus process. Raydium's on-chain programs add application logic but do not alter or substitute for Solana's underlying consensus. Solana's consensus architecture combines Proof of History with a Proof-of-Stake validator voting process. Proof of History is a sequential cryptographic hash computation that produces a verifiable record of the ordering and passage of time between events. A designated leader sequences user messages, executes transactions against current state, and publishes the resulting state signature to verifier nodes. Verifier nodes execute the same transactions on their own state copies and publish signed confirmations, which serve as votes in the consensus process. Solana's consensus protocol is Tower BFT, a variant of Practical Byzantine Fault Tolerance that uses Proof of History as a cryptographic clock. Validators vote on the PoH sequence using an exponential lockout mechanism: each vote commits the validator to the voted fork for a doubling lockout period, making it progressively harder to roll back earlier votes and producing increasing practical finality as confirmations accumulate. Consensus validity requires a supermajority involving 2-of-3 of validators weighted by their staked bonds. A branch is accepted once a supermajority of bonded validators votes within the prescribed timeout. The leader for each slot is determined by a stake-weighted leader schedule computed at the start of each epoch. If the scheduled leader for a slot fails to produce a block, that slot is skipped and the network moves to the next scheduled leader; no election occurs at the time of failure. Slashing, the penalty destruction of a portion of a validator's stake for double-voting or voting on an invalid hash, is a stated roadmap objective, but the Solana network currently has no in-protocol slashing implementation. The first planned step is the introduction of slashing proofs without any automatic penalty enforcement. . No slashing penalties are presently enforced on the Solana mainnet. An updated consensus protocol, Alpenglow, is under development and targeted for Agave 4.1. Alpenglow would replace Proof of History and on-chain vote transactions with a new mechanism designed to deliver approximately 150-millisecond confirmation times, and would introduce a Validator Admission Ticket fee of 1.6 SOL per epoch for validators included in the consensus set. Until Alpenglow is active on mainnet, Solana's current Proof of History and Proof-of-Stake mechanism governs RAY transactions.
H.5	Incentive Mechanisms and Applicable Fees	Network-Level Fees Every RAY transfer and every Raydium protocol interaction settles as a Solana transaction and incurs a network fee. The total fee is the sum of a base fee and an optional prioritisation fee. The base fee is 5,000 lamports per signature and is charged whether the transaction succeeds or fails, deducted from the fee payer before execution begins. 50% of the base fee is burned, permanently removed from the circulating SOL supply, and the remaining 50% is distributed to the block-producing validator. The prioritisation fee, calculated as the compute-unit price multiplied by the compute-unit limit divided by 1,000,000 lamports, is paid entirely to the validator and is not burned. Account rent is also payable when creating pools, positions, farms, or token accounts; rent is a redeemable deposit recoverable on account closure and is separate from Raydium protocol fees. Protocol-Level Fees Every swap on Raydium incurs a trading fee calculated as a percentage of the trade amount. The liquidity-provider, RAY buyback and treasury allocations are then calculated as percentages of that trading fee. For CLMM and CPMM pools, 84% of the trading fee is distributed to liquidity providers, 12% funds RAY buybacks, and 4% goes to the treasury. For Standard AMM v4 pools, 88% is distributed to liquidity providers and 12% funds RAY buybacks, with no treasury allocation. Common swap-fee tiers differ by product: CLMM pools are available at 0.01%, 0.05%, 0.25%, and 1%; CPMM pools at 0.01%, 0.25%, and 1%; AMM v4 pools use a fixed legacy rate of approximately 0.25%. CPMM and CLMM use a fee denominator of 1,000,000 (so a stored value of 2,500 represents 0.25%); AMM v4 uses a denominator of 10,000. The default CPMM AmmConfig (index 0, standard 0.25% pool) additionally carries a creator fee of 500 basis points in the 1,000,000 denominator, equivalent to 0.05% of trade volume, routed to the original pool creator. Pool creation fees apply when creating a CPMM or Standard AMM v4 pool: 0.15 SOL per pool, payable to the protocol for spam prevention and infrastructure support. CLMM pools carry no separate Raydium pool creation fee; only Solana account rent applies. Fee Collection and Buyback Routing Protocol-side fees accumulate at program-specific collection addresses before being converted and routed: the CLMM collection address is projjosVCPQH49d5em7VYS7fJZzaqKixqKtus7yk416, the CPMM collection address is ProCXqRcXJjoUd1RNoo28bSizAA6EEqt9wURZYPDc5u, and the AMM v4 collection address is PNLCQcVCD26aC7ZWgRyr5ptfaR7bBrWdTFgRWwu2tvF. Each collection address may hold various SPL tokens, as fees are paid in the tokens traded by each pool. Bought-back RAY is held by the protocol at the public on-chain address DdHDoz94o2WJmD9myRobHCwtx1bESpHTd4SSPe6VEZaz, which can be inspected directly on any Solana block explorer. Bought-back RAY is retained by the protocol and is neither redistributed nor burned. Validator Incentives Solana validator rewards are funded by base-fee proceeds and staking inflation. SOL staked and delegated to a validator increases the probability of that validator being selected to produce blocks; validators and their delegators earn proportionally more rewards as transaction throughput increases. Validators may charge commission as a percentage of rewards earned by their delegators. A further under-development protocol change, SIMD-123, would additionally enable validators to share block revenue, comprising priority fees and maximal extractable value, with delegators on-chain at each epoch. SIMD-0123 is currently in the review stage and has not been approved or activated on mainnet; it is not an active reward mechanism at the time of this white paper. RAY Staking RAY holders may stake RAY through an application-level mechanism to earn additional RAY rewards. This is executed by the Farm v3 program, which operates as the legacy RAY single-asset staking program and remains functional for this purpose. It is distinct from Solana validator staking: it is a protocol-level farming arrangement distributing RAY token rewards proportional to staked balances, with no connection to Solana consensus security or SOL validator reward flows. Governance of Protocol Parameters Raydium protocol parameters are managed through the program-level upgrade multisig (3-of-4, 24-hour timelock) and the treasury multisig (3-of-5, no timelock). New AmmConfig accounts, which set fee tiers and fee splits, are created by the treasury multisig; existing pool fee parameters derive from their referenced AmmConfig and cannot be changed by modifying an existing config in practice. No RAY tokenholder governance mechanism for protocol parameters currently exists on-chain, though the prior RAY white paper identifies governance participation as a planned feature. Solana base-layer parameters are governed through the Solana Improvement Document (SIMD) process.
H.6	Use of distributed ledger technology	FALSE
H.7	DLT functionality description	N/A
H.8	Audit	TRUE
H.9	Audit outcome	Security audits of Raydium's technology have been conducted by Kudelski Security/Nagravision, OtterSec, MadShield, Halborn, and Sec3. Members of the Neodyme team have additionally performed reviews under bug-bounty agreements. The audits span ten engagements across successive program generations, covering the order-book AMM, concentrated liquidity, staking, CPMM, LaunchLab, and the LP lock program; assessing logic correctness, account validation, arithmetic handling, Token-2022 composability, administrative access controls, and dependency hygiene. A continuous bug-bounty program is also active on Immunefi, covering on-chain programs, SDKs, and off-chain components. Kudelski Security/Nagravision, Q2 2021, Raydium Order-Book AMM Security Code Review Assessment Object: External security code review of the Raydium AMM and staking smart-contract applications on the Solana blockchain. The engagement ran from 15 March to 9 April 2021 against identified commit hashes in the raydium-staking and raydium-amm repositories. Third-party libraries were out of scope. Results: 0 high, 4 medium, 5 low, and 3 informational findings. Findings concerned memory and secure-information handling, arithmetic overflow, low test coverage, coding practices, RustSec advisory exposure, and sensitive-data zeroing. Actions: Several findings, including RustSec dependency advisories and sensitive-data zeroing, remained open at the time of publication. The report does not confirm final closure of these findings. OtterSec, Q3 2022, Raydium Staking program Audit Object: Assessment of the raydium-staking program, which allows users to stake tokens to earn reward tokens, and the farm program, which allows users to stake liquidity-pool tokens to earn up to two reward tokens. The audit was performed against commit 76a2744. Results: 5 findings in total: 1 critical, 0 high, 0 medium, 0 low, and 4 informational. The critical finding concerned missing validation on a reward vault account that could allow an attacker to steal liquidity-provider tokens. Actions: The critical vulnerability was resolved, with corrective account validation confirmed in the report. Informational recommendations addressed code redundancy, ambiguous program states, purposeless instructions, and optional reward vault inconsistency. OtterSec, Q3 2022, Raydium Updated Order-Book AMM Audit Object: Assessment of the raydium-amm constant-product market maker with OpenBook integration. The assessment was conducted between 24 October and 11 November 2022, with incremental patch confirmations through to February 2023. The audit was performed against commits d70a8fb through 8da289a. Results: 6 findings in total: 0 critical, 1 high, 1 medium, 0 low, and 4 informational. The high-severity finding concerned liquidity-pool monopolisation through manipulation of the share-to-token ratio. The medium-severity finding concerned stale open-orders account data during swap operations, potentially leading to improper settlement of funds. Actions: Both the high and medium vulnerabilities were resolved prior to report finalisation, with patches confirmed by OtterSec during the incremental review period. OtterSec, Q3 2022, Raydium Concentrated Liquidity (CLMM) Audit Object: Assessment of the raydium-amm-v3 concentrated-liquidity market maker program. The assessment was conducted between 25 September and 9 December 2022, with final patch confirmation delivered on 30 December 2022. The audit was performed against commit 4fe73c7. Results: 12 findings in total: 0 critical, 1 high, 2 medium, 3 low, and 6 informational. The high-severity finding involved an unchecked type cast in liquidity mathematics. Medium-severity findings included ungated closing of personal positions and arbitrary AMM configuration use in a swap-router instruction. Low-severity findings addressed unsafe account closing, active-account closure, and a reward-state denial-of-service risk. Actions: All listed vulnerabilities were marked resolved, with specific fixes confirmed during the final patch-confirmation review. MadShield, Q2 2023, Raydium Order-Book AMM and OpenBook Migration Audit Object: Assessment of the updated order-book AMM program and its migration from the original Serum/OpenBook integration. Full scope and commit range are detailed in the published report, available in the Raydium audit repository on GitHub. Results: Full findings are detailed in the published report. Per Raydium's audit documentation, per-finding breakdowns should be read directly from the report. Actions: Resolution status per finding is detailed in the published report. MadShield, Q1 2024, Raydium Constant Product AMM program (CPMM) Audit Object: Assessment of the CPMM program in the raydium-cp-swap repository, which removes OpenBook integration, adds support for SPL Token-2022 pairs, and is written in the Anchor framework. The audit ran from commit 0d56d2c to 8f10f25. The scope included review of the Token-2022 program's composability with the CPMM, specifically the TransferFeeConfig extension. Results: 4 findings in total: 3 critical and 1 high. Within the CPMM program: two critical findings ;pool-account initialisation failure due to Solana runtime stack limits, and incorrect evaluation of pool vault relationships in swap instructions; and one high-severity finding concerning misplaced rounding in swap division calculations. One further critical finding was identified in the SPL Token-2022 program itself, concerning incorrect inverse-fee calculation for mints using the TransferFeeConfig extension; this vulnerability affects any program interacting with Token-2022 transfer-fee configurations, not only the CPMM. One informational improvement recommendation was raised concerning incorrect swap-event token-amount logging. Actions: All four vulnerabilities were communicated privately to the Raydium developer team and are confirmed resolved. The informational recommendation was acknowledged without a remediation commitment. Halborn, Q4 2024, Raydium Burn & Earn (Liquidity Locker) Audit Object: Assessment of the Burn & Earn or LP Lock program, which provides liquidity-position locking functionality. Full scope and commit range are detailed in the published report, available in the Raydium audit repository on GitHub. Results: Full findings are detailed in the published report. Actions: Resolution status per finding is detailed in the published report. Halborn, Q2 2025, Raydium LaunchLab Audit Object: Assessment of the LaunchLab program, which supports permissionless token issuance and liquidity bootstrapping with bonding-curve mechanics. Full scope and commit range are detailed in the published report, available in the Raydium audit repository on GitHub. Results: Full findings are detailed in the published report. Actions: Resolution status per finding is detailed in the published report. Sec3, Q3 2025, Raydium CPMM Update Audit Object: Re-audit of a significant update to the CPMM program (raydium-cp-swap). The scope was limited to the program diff rather than a full re-audit of the entire program. Full scope and commit range are detailed in the published report. Results: Full findings are detailed in the published report. Actions: Resolution status per finding is detailed in the published report. Sec3, Q2 2026, Raydium CLMM Update Audit — Limit Order, Dynamic Fee, and Single Asset Fee Object: Re-audit of CLMM program updates covering the Limit Order instruction set, the Dynamic Fee configuration mechanism, and the Single Asset Fee feature. The scope was limited to the program diff for these three additions. Full scope and commit range are detailed in the published report. Results: Full findings are detailed in the published report. Actions: Resolution status per finding is detailed in the published report. Historical Security Incidents Two notable security incidents in Raydium's operational history are on record in the published security documentation. In December 2022, the AMM v4 pool authority private key was compromised, allowing an attacker to drain several pools. The incident arose from a key management failure, not a program code vulnerability. The code had been reviewed by OtterSec and no bug was present in the program logic; the failure was in the operational handling of the authority key. The remediation was a full migration of all authority roles to the Squads multisig structure currently in use. In January 2023, an OpenBook program update changed account semantics, preventing AMM v4's settlement mechanism from correctly processing pending profit-and-loss calculations until an AMM v4 patch was deployed. The incident was an integration bug ;neither program was incorrect in isolation; and was resolved through a coordinated AMM v4 patch and upgrade.

General information	Page 3
Part A - Information about the offeror or the person seeking admission to trading	Page 4
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading	Page 5
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	Page 6
Part D - Information about the crypto-asset project	Page 7
Part E - Information about the offer to the public of crypto-assets or their admission to trading	Page 8
Part F - Information about the crypto-assets	Page 9
Part G - Information on the rights and obligations attached to the crypto-assets	Page 10
Part H – Information on underlying technology	Page 11
Part I - Information on risks	Page 12
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts	Page 13

N	Field	Content
I.1	Offer-related risks	Market volatility and liquidity RAY's market price can fluctuate materially, and trading depth varies across centralised and decentralised venues. Reduced trading volume, uneven token distribution or broader market stress can widen spreads, increase slippage and impair execution quality. Exchange access and compliance constraints Access to RAY trading can be affected by listing decisions, delisting, geo-restrictions, AML/KYC checks and local legal requirements. Verification delays, account restrictions or platform policy changes can restrict deposits, withdrawals or trading activity without prior notice. Market manipulation and price discovery RAY is exposed to manipulative trading practices that can distort market prices and impair fair price discovery. Wash trading, spoofing or coordinated trading activity can increase volatility and mislead holders regarding available liquidity. No statutory compensation RAY is not covered by investor compensation schemes under Directive 97/9/EC or deposit guarantee schemes under Directive 2014/49/EU. Holders cannot rely on statutory recovery arrangements if the token loses value, becomes illiquid or is lost through custody failure. Delisting Risks Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.
I.2	Issuer-related risks	Financial resilience and continuity Raydium Foundation supports the Raydium Protocol, which provides decentralised exchange, AMM, liquidity pool and LaunchLab functionality. Public information on the Foundation's financial condition for the past 3 years is not available, limiting external assessment of long-term operational resilience. Governance and administrative authority concentration The Raydium Foundation, as issuer, is responsible for the governance of the Raydium protocol through two administrative structures. Raydium's program upgrade authority is held under a 3-of-4 Squads multisig with a mandatory 24-hour execution timelock. Operational admin authority ;including the creation of AmmConfig fee tiers and the routing of protocol fee collection; is held under a separate 3-of-5 treasury multisig with no execution timelock, meaning fee parameter and configuration changes can be applied immediately without a user response window. Both multisig structures represent concentrated control: a threshold compromise or coordinated misuse of either could alter program behaviour or fee routing. The treasury multisig's admin authority over protocol parameters is disclosed as an interim arrangement subject to periodic review. Treasury and buyback control risk Fee collection, treasury and RAY buyback holding addresses are controlled by the Raydium Foundation through the protocol multisig. Misconfiguration, compromise or operational error affecting those controls could disrupt treasury operations, fee handling or RAY buyback execution. Bought-back RAY is held at a single on-chain address, creating concentration in post-buyback custody. Brand and ecosystem dependency The Raydium Foundation's reputation is closely linked to the performance and security of the Raydium protocol. Foundation-level failures, including security incidents, loss of key personnel, governance failures, or adverse regulatory outcomes affecting the Foundation directly, can impair community confidence in the protocol and reduce the utility and market value of RAY. Regulatory and jurisdictional exposure Raydium Foundation, incorporated in the Cayman Islands and operating a globally accessible protocol, is exposed to regulatory developments across multiple jurisdictions. Changes to legal frameworks governing decentralised finance protocols, token issuance, or the classification of RAY may require the Foundation to modify or cease operations in certain markets, alter the protocol's functionality, or comply with requirements that affect its capacity to support the Raydium ecosystem.
I.3	Crypto-assets-related risks	Supply allocation and holder concentration RAY has a fixed maximum supply of 555,000,000 tokens, distributed across mining reserve, partnership and ecosystem, team, liquidity, community pool and adviser allocations, with team, community and adviser tranches subject to lock-up periods. Concentrated holdings among early allocatees, the foundation or the mining reserve can affect perceived scarcity, secondary-market sell pressure and governance influence. Emissions and liquidity mining Ongoing RAY emissions from the 34% mining reserve (188,700,000 RAY) distribute liquidity mining rewards to incentivise pool participation. Emission flows increase circulating supply over time and may create sell pressure if reward recipients liquidate positions. The 12% of protocol trading fees directed to programmatic RAY buybacks provides a partial offset, but the net supply impact varies with protocol trading volume and participation levels. Key custody, bearer risk and transfer error RAY is a non-custodial bearer asset: control of a wallet's private key constitutes control of the associated RAY balance. Loss or compromise of private keys or recovery credentials provides no protocol-level mechanism for fund recovery. Transfer errors ;including incorrect recipient addresses, wrong network selection or misdirected on-chain operations; result in permanent, irrecoverable loss. RAY token accounts on Solana require correct SPL token program compatibility, and using a wrong-chain or incompatible address will render tokens unrecoverable. Future use-case uncertainty RAY's present utility includes governance participation and ecosystem alignment. Future uses depend on community decisions, developer commitment and continued ecosystem success. Expected utility may not materialise if product adoption or development activity weakens.
I.4	Project implementation-related risks	Technical delivery and implementation risk New Raydium product features, liquidity strategies and integrations may be delayed by technical hurdles, resource constraints or unanticipated security flaws. Delays or defects can affect protocol functionality and the utility of RAY. Quality assurance and residual audit risk Raydium smart contracts have undergone multiple audits across AMM, CLMM, staking, CPMM, Burn & Earn, LaunchLab, and program update engagements. These audits identified critical, high, medium, low and informational findings. Resolved findings reduce known-defect risk but do not eliminate residual implementation risk in deployed or future program versions. Third-party reliance Raydium's ecosystem relies on liquidity providers, custodians, aggregators and infrastructure partners including RPC operators and off-chain indexers. Operational disruption or policy changes among those parties can reduce token effectiveness or degrade platform performance without Raydium's direct control. Product interdependency Raydium includes multiple product surfaces ;AMM v4, CPMM, CLMM, Farm and Staking, LaunchLab and Perps. Farm v3 and v5 remain deployed in wind-down for existing positions but no longer accept new farms; Farm v6 is the current program. Failures, deprecated states or changes in one product can affect user activity, liquidity routing or the perceived utility of RAY across the ecosystem. Speculative value and ecosystem dependency RAY has no intrinsic value independent of its use within the Raydium ecosystem. Its market value is speculative and may be influenced by user participation, broader market sentiment, macroeconomic conditions and network activity. Holders may experience significant mark-to-market losses unrelated to protocol performance. Demand for RAY is further linked to the continued use of Raydium products, governance participation, and the buyback and staking reward flows generated by protocol activity; a sustained reduction in protocol usage reduces those flows directly. Integration and API dependency Raydium integrators rely on public APIs, SDKs, program addresses, IDLs and route-building tools. API synchronisation lag ;including newly created pools taking several minutes to appear in the API; incorrect program IDs, outdated integrations or transaction-building errors can impair swaps, pool discovery and application reliability. Raydium explicitly notes that a mismatched program ID is the single easiest way to lose funds on Solana.
I.5	Technology-related risks	Solana Layer 1 dependency RAY is an SPL token on Solana and inherits the network's consensus, transaction, fee and account-model characteristics and risks. Network congestion, transaction expiry from exceeded blockhash lifetime, fee changes, validator disruption or protocol-level upgrades ;including the planned Alpenglow consensus replacement and Validator Admission Ticket fee; can delay execution, increase costs or affect settlement visibility. Any Solana-level incident affects all RAY transactions regardless of Raydium's own program state. Smart-contract and program logic defects Raydium smart contracts implement AMM, liquidity pool, LP-token, staking and LaunchLab functionality. Implementation defects; including those identified in past audits — can cause incorrect execution, disrupted liquidity operations, mispriced swaps or fund loss. CPMM, CLMM and associated programs are also subject to composability risks when interacting with other Solana programs. Upgradeable programs and admin-key exposure All Raydium programs remain fully upgradeable under the Solana BPF Loader v3 upgrade mechanism; no program's upgrade authority has been set to null. program upgrades are gated by the 3-of-4 upgrade multisig and subject to a 24-hour execution timelock, providing a response window before any upgrade takes effect. However, 24 hours may be insufficient for holders or integrators to assess, react to or unwind positions in response to complex program changes. Operational admin paths ;including AmmConfig creation and protocol fee routing; are governed by the 3-of-5 treasury multisig, which carries no timelock and can take effect immediately. A compromised or misused admin key could introduce regressions, alter program behaviour or redirect fee flows before users can react. Token-2022 extension and mint-support risk CPMM and CLMM use a strict allow-list for Token-2022 mint extensions and reject unsupported configurations at pool creation. Supported transfer-fee mints transfer less than the nominal amount per instruction due to the fee deduction; naive UI implementations may understate effective costs or received amounts. Epoch-based fee updates on Token-2022 mints can alter swap economics between a quote and its settlement. Pools created with Token-2022 mints are supported only on Farm v6; older farm programs reject Token-2022 staking mints. AMM and CLMM liquidity mechanics Constant-product pools, concentrated-liquidity ranges and LaunchLab bonding curves carry distinct execution and liquidity risks. CLMM positions stop accruing fees when the market price moves outside the deposited range; impermanent loss is amplified relative to wide-range positions as a result. CLMM positions are represented as non-fungible tokens: loss of the position NFT prevents retrieval of associated liquidity. LaunchLab tokens trade along a bonding curve prior to graduation, which means pre-graduation liquidity is limited and graduation mechanics create discrete price-transition risk. Execution and slippage RAY swaps and routed trades depend on prevailing pool depth, route selection, transaction settings and slippage tolerance. Market movement beyond the selected tolerance can cause failed transactions, while thin liquidity can produce material price impact. Solana transactions that fail due to slippage, expired blockhash or insufficient compute still incur the base network fee. RPC, API and explorer visibility risk Raydium users and integrators rely on RPC endpoints, block explorers, REST APIs and indexers to view on-chain state and build transactions. Public RPC endpoints are shared infrastructure subject to rate limits; exceeding limits returns HTTP 429 errors and can block transaction submission. API synchronisation delays can cause stale pool visibility or outdated configuration reads. Explorer parsing issues can display incorrect balances or transaction statuses. Perps infrastructure dependency Raydium Perps uses Orderly Network infrastructure for perpetual futures functionality, including account management, order routing, market data, and deposit, withdrawal and settlement rails. Disruptions, parameter changes or dependency failures in the Orderly infrastructure can affect Raydium Perps trading, collateral handling and withdrawals, even where the underlying RAY SPL token remains transferable on Solana. Raydium Perps collateral parameters are subject to change by Orderly independently of Raydium's own program controls. Quantum computing and cryptographic forward risk Solana's transaction authentication relies on Ed25519 elliptic-curve signatures, and Proof of History is built on sequential SHA-256 hashing. The security of Ed25519 rests on the hardness of the elliptic-curve discrete logarithm problem, which is solvable in polynomial time by Shor's algorithm running on a sufficiently large, fault-tolerant quantum computer. Every RAY holder account or program account that has ever signed a transaction has its public key publicly visible on-chain and would be at risk if such a quantum capability were achieved, as private keys could in principle be derived from exposed public keys. SHA-256 is subject to Grover's algorithm, which reduces the effective brute-force security margin from 256 bits to approximately 128 bits; this remains computationally infeasible with current or near-term quantum hardware but degrades the classical security assumption. Solana has not published a post-quantum cryptographic migration roadmap; any transition to post-quantum signature standards would require a coordinated upgrade across the Solana validator set, carrying its own implementation and compatibility risks.
I.6	Mitigation measures	Offer-related risks Market volatility and liquidity: Trading-fee shares distributed to liquidity providers across CLMM, CPMM and AMM v4 pools create an economic incentive for liquidity provision. RAY token rewards distributed through Farm v6 incentivise pool participation in selected pairs. These mechanisms support continuous liquidity but do not guarantee price stability, minimum depth or protection against adverse market conditions. Issuer-Related Risks Governance and administrative authority concentration: program upgrade authority is held under a 3-of-4 Squads multisig with a 24-hour mandatory execution timelock. This provides users and integrators a minimum window to observe, assess and; where possible; unwind positions before any program upgrade takes effect. The Squads transaction queue is publicly monitorable in real time, and air-gapped cold-device signing with sequential approval reduces the risk of single-point compromise. Treasury multisig operations carry no timelock and require independent monitoring to detect misuse; Raydium's treasury multisig address and pending operations are publicly visible on the Squads Protocol interface. Treasury and buyback control risk: Protocol fee collection, treasury and buyback holding addresses are published and publicly verifiable on-chain. The buyback holding address (DdHDoz94o2WJmD9myRobHCwtx1bESpHTd4SSPe6VEZaz), pool-specific fee collection addresses and the treasury multisig address are disclosed, allowing independent monitoring of flows and balances without relying on Raydium's own reporting. Regulatory and jurisdictional exposure: RAY holder restrictions require compliance with applicable securities laws, sanctions and jurisdictional restrictions. Exchange-level KYC and AML checks create access controls at trading venues. These requirements operate at the disclosure and platform level and do not remove the risk of future changes to the regulatory treatment of RAY. Crypto-Assets-Related Risks Supply allocation and holder concentration: RAY's maximum supply is fixed at 555,000,000 tokens and cannot be increased, as no mint authority is present on the RAY mint account. The full allocation breakdown — mining reserve, partnership and ecosystem, team, liquidity, community pool and advisers — together with applicable lock-up categories, is publicly disclosed. Emissions and liquidity mining: 12% of all Raydium protocol trading fees are directed to programmatic RAY buybacks, creating a demand-side flow that partially offsets mining-reserve emissions. Bought-back RAY is retained by the protocol at a published on-chain address and is not burned or redistributed, providing an auditable record of the buyback program's scale relative to emissions. Key custody, bearer risk and transfer error: Raydium publishes canonical program addresses and instructs users not to sign transactions where a program ID does not match the published table, reducing spoofing and wrong-program transaction risk. Correct recipient address and network verification before signing are user-level controls; no protocol mechanism exists to recover transferred tokens sent to an incorrect address or an incompatible network. Project Implementation-Related Risks Quality assurance and residual audit risk: Raydium maintains a published audit record across ten engagements covering AMM, CLMM, staking, CPMM, Burn & Earn, LaunchLab and program update scopes, with identified critical, high, medium and low findings resolved across those reviews. An active bug-bounty program on Immunefi provides a continuous post-deployment vulnerability disclosure channel, with critical smart-contract reports eligible for rewards up to USD 505,000. Integration and API dependency: Raydium publishes official SDK repositories, program IDLs, canonical program addresses and on-chain verification guidance. Integrators can validate program IDs against on-chain upgrade authority, fetch live IDLs to compare against published interfaces, and use the live API configuration endpoint for current AmmConfig data rather than cached or hardcoded values. Technology-Related Risks Smart-contract and program logic defects: The Immunefi bug-bounty program provides an active external vulnerability disclosure channel with proof-of-concept requirements and defined response timelines. Critical smart-contract vulnerabilities are eligible for rewards up to USD 505,000, aligning external researcher incentives with protocol security. Upgradeable programs and admin-key exposure: The program upgrade multisig operates with a 24-hour timelock, giving users and integrators a minimum response window before any deployed upgrade takes effect. All pending upgrade transactions are visible on the public Squads Protocol interface. Users who disagree with a proposed upgrade have the timelock window to assess positions and unwind if necessary. Operational admin paths not gated by the upgrade multisig, including AmmConfig creation and fee-parameter updates under the treasury multisig, do not carry a timelock and are not subject to this mitigation. Token-2022 extension and mint-support risk: CPMM and CLMM apply strict allow-list gating at pool creation, reverting unsupported Token-2022 extensions before any pool state is written. Transfer-checked instruction flows are used for supported transfer-fee mints, allowing the program to account for fee deductions in swap calculations. These controls limit unexpected extension-related failures to pool creation time rather than allowing them to affect active pools. Execution and slippage: Raydium's Trade API includes slippage tolerance expressed in basis points, route-plan selection, price-impact fields and minimum output thresholds when building swap transactions. These parameters allow integrators and users to set execution guardrails, though they do not prevent market impact from large orders or failed transactions in fast-moving markets. RPC, API and explorer visibility risk: Raydium's official SDK, published program addresses, on-chain IDLs and the live configuration API provide primary sources for program state that do not depend on a single third-party RPC provider. Integrators are directed to refresh AmmConfig data at runtime and to verify program IDs on-chain rather than relying on explorer displays. These approaches reduce but do not eliminate exposure to RPC rate limits, availability issues or synchronisation delays.

Index

General information

Part A - Information about the offeror or the person seeking admission to trading

Part B - Information about the issuer, if different from the offeror or person seeking admission to trading

Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114

Part D - Information about the crypto-asset project

Part E - Information about the offer to the public of crypto-assets or their admission to trading

Part F - Information about the crypto-assets

Part G - Information on the rights and obligations attached to the crypto-assets

Part H – Information on underlying technology

Part I - Information on risks

Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts