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	ORCA is the native governance asset of the Orca protocol, which is a decentralised exchange on Solana. Orca enables users to swap supported Solana tokens, provide liquidity through liquidity pools, create permissionless pools, interact with open-source smart contracts and software development kits and to stake ORCA in order to receive xORCA tokens. ORCA was launched on 9 August 2021 and uses the Solana network. The ORCA SPL token address isorcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE. ORCA has a fixed total supply of 75 million crypto-asset.ORCA holders may participate in Orca governance. The official governance documentation states that token holders can propose changes, vote on decisions and shape the future of the protocol. Governance may cover matters such as fee structures, treasury allocation, upgrades, protocol features, partnerships, parameter changes and governance changes. ORCA and xORCA holders may also delegate voting power, participate in discussions and, subject to applicable thresholds, submit proposals. Approved proposals are implemented by the team or the DAO Council.
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 ORCA 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	60798788 The circulating supply of ORCA may vary over time as tokens enter or leave circulation, including as a result of treasury allocations, grant allocations, staking-related mechanisms, market activity and any governance-approved changes affecting the treatment of ORCA tokens. The circulating supply excludes treasury and grant allocations, while total supply represents all minted ORCA tokens. This figure 60798788 is taken from Orca’s official circulating-supply endpoint, https://api.orca.so/v2/solana/protocol/token/circulating_supply, as consulted on May 19, 2026, and is indicative only.
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	ORCA is the native governance asset of the Orca protocol on Solana. The token is used to support decentralised decision-making, protocol alignment, xORCA staking and DAO participation. ORCA holders may vote on proposals concerning the Orca protocol, including proposals relating to fee structures, treasury allocation, upgrades and other protocol matters. ORCA and xORCA holders may also delegate voting power, submit proposals where applicable and participate in the election of the DAO Council. ORCA may be staked to receive xORCA. The xORCA system is designed to allow participants to receive exposure to protocol fee-funded ORCA buybacks while participating in Orca governance. Protocol fees are partly used to buy ORCA and add it to the xORCA vault, and that the exchange rate between xORCA and ORCA increases when buybacks add ORCA to the vault without minting new xORCA. Unstaking xORCA requires a seven-day cooldown period before ORCA can be withdrawn. Returns from xORCA are variable and depend on trading volume and the ORCA price; xORCA also involves price exposure and smart contract risk. ORCA is also used in Orca governance. Token holders can propose changes, vote on decisions and shape the future of the protocol. The governance process includes community proposals, discussion, voting by ORCA or xORCA holders and implementation of approved proposals by the team or DAO Council. Governance proposals may include protocol upgrades, parameter changes, treasury allocation and governance changes.
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	ORCA is the native governance asset of the Orca protocol, which is a decentralised exchange on Solana. Orca enables users to swap supported Solana tokens, provide liquidity through liquidity pools, create permissionless pools and interact with open-source smart contracts and software development kits. ORCA was launched on 9 August 2021 with an initial supply of 100 million crypto-assets and uses the Solana network. The ORCA SPL token address is orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZ. Following a protocol upgrade in April 2025, ORCA token supply was reduced to a fixed amount of 75 million tokens.
F.7	Commercial name or trading name	Orca
F.8	Website of the issuer	https://www.orca.so/
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	Z63372HJ5
F.14	Functionally fungible group digital token identifier, where available	QS946B4NN
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, Holders of the ORCA crypto-asset do not, solely by acquiring or holding ORCA, acquire any ownership, equity, profit participation, repayment, redemption or compensation rights against any identified issuer, the Orca DAO Council, the Orca Community or any other natural or legal person. Holding ORCA does not give rise to contractual claims or entitlements against any natural or legal person. As reflected in the official Orca governance documentation https://docs.orca.so/governance/overview? , at the time of this white paper ORCA holders are granted functional governance and protocol-related rights within the Orca ecosystem where applicable and participate in DAO Council elections. These rights are governance-based and protocol-based functionalities, and are further described as crypto-asset functionalities in F.2.
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	14200768
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	Networking, transport and session ORCA is an SPL token deployed on the Solana blockchain at mint address orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE, with an initial total supply of 75 million ORCA minted on launch date of 9 August 2021, and reduced to a fixed total supply of 75 million through a burn in April 2025. Token transfers and protocol interactions propagate over Solana's permissionless peer-to-peer network, which uses a gossip protocol for node communication and a leader-based block production model in which each slot has a designated leader responsible for producing a block. Validators propagate transactions to the current leader's mempool, where they await inclusion. The Orca protocol's principal on-chain application is Whirlpools, an open-source concentrated-liquidity automated market maker deployed on Solana at program address whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc. Whirlpools does not operate a separate networking layer; all interactions are submitted as standard Solana transactions via conventional RPC endpoints. A REST API for pool data and analytics is available for read-only queries. A separate program, Wavebreak, has also been deployed under the Orca protocol and audited independently. Serialisation Solana transactions use a compact binary encoding. Each transaction contains a header, an account addresses array, a recent blockhash, and one or more instructions. Instructions directed at the Whirlpools program are encoded using the Anchor framework's discriminator-based format, where each instruction is identified by an 8-byte discriminator derived from a hash of the instruction name, followed by its arguments in little-endian binary layout. Cryptography and key formats Solana uses the Ed25519 elliptic-curve signature scheme for transaction authentication. User wallets hold Ed25519 key pairs; the public key serves as the account address. ORCA token transfers require the owner of the sender's token account to sign the transaction using their Ed25519 private key. Associated Token Account addresses and all Whirlpools program-derived account addresses are computed using SHA-256-based program-derived address derivation, which applies a bump seed to produce a deterministic off-curve address from a set of seeds. This ensures that all account locations within the Whirlpools account hierarchy are derivable from their inputs and cannot be pre-signed by external parties. Ledger ORCA balances are recorded through Solana's token-account structure. The mint account stores global metadata for the ORCA token, including the fixed total supply and mint authority. Each token account records the mint it belongs to, the owner authorised to transfer tokens, and the amount held. Associated Token Accounts provide a deterministic default holding address for a given owner and mint combination. The Whirlpools ledger is structured as a hierarchy of program-derived accounts. A WhirlpoolsConfig account defines the authorities governing the pools it owns, including default fee settings and the authority to collect protocol fees. Whirlpools visible on the Orca interface are derived from and controlled by a WhirlpoolsConfig account owned by the Orca Foundation; other users and protocols may deploy their own WhirlpoolsConfig accounts on the same program. A WhirlpoolsConfigExtension account holds additional authorities for managing Token-2022 assets and TokenBadge accounts. Each FeeTier account records a specific fee rate, defined per WhirlpoolsConfig and tick spacing. A Whirlpool account represents a concentrated-liquidity pool between a token pair and holds all pool accounting data alongside two vault token accounts, one per pooled token; only the Whirlpools program has authority to withdraw from those vaults, with neither the program owner nor the WhirlpoolsConfig owner holding withdrawal authority. TickArray accounts record the liquidity and fee state across price ranges. Position accounts represent a unit of liquidity distributed across a price range within a single Whirlpool, and position ownership is tokenised as a non-fungible token held in the owner's wallet. A PositionBundle account allows up to 256 positions to be managed under a single non-fungible token, reducing rent overhead when rebalancing frequently. Execution ORCA transfers execute through Solana's Token program. The Transfer instruction moves tokens between token accounts and requires the owner of the sender's token account to sign the transaction. The token's total supply is fixed at 75 million ORCA; no active minting capability is in operation against the ORCA mint. Whirlpools swap execution occurs through the deployed Whirlpools program, with all state transitions recorded in the Whirlpools account hierarchy described above. Token standards ORCA is an SPL token on Solana. The Token program contains the instruction logic for interacting with fungible and non-fungible tokens on the network. The Whirlpools program additionally supports the Token-2022 standard, also referred to as Token Extensions. V2 instructions handle tokens owned by the Token-2022 program, enabling pools that combine standard SPL tokens with Token-2022 assets. TokenBadge accounts serve as a whitelist mechanism for tokens carrying extensions that pose elevated risk to pool users; a token with such extensions may only be used for pool initialisation if the TokenBadge authority has issued a TokenBadge for that specific mint. External APIs Developer access to Whirlpools is provided through TypeScript and Rust high-level software development kits, lower-level generated clients for account, instruction, and error parsing, and core utility, mathematics, and quoting packages. A REST API exposes pool data and analytics for read-only integrations. These interfaces support transaction construction and data retrieval against the deployed Whirlpools program and do not constitute a separate settlement or consensus layer for ORCA
H.3	Technology used	Implementation and architecture ORCA is implemented as an SPL token on Solana. Its on-chain representation follows Solana's mint-account and token-account architecture, separating the token's global identity and supply data from individual ownership records. The Orca protocol's primary on-chain application component is Whirlpools, written in Rust and built using the Anchor framework. The Whirlpools monorepo contains the Rust smart contract, TypeScript software development kits, Rust software development kits, generated clients, core utility packages, documentation, and legacy SDK materials. Dependencies between packages are managed automatically by NX, which resolves the Rust and TypeScript codebases within the monorepo. xORCA is the staking derivative of ORCA. Users stake ORCA to receive xORCA, which appreciates in value over time as protocol fee buybacks add ORCA to the xORCA vault. The exchange rate between xORCA and ORCA increases monotonically as buybacks accrue. Unstaking requires a seven-day cooldown period; upon initiating redemption, the user receives a Claim Ticket non-fungible token representing the pending claim, and the applicable exchange rate is locked at that moment. After seven days, the user may withdraw the corresponding ORCA amount. Runtime and build parameters The Whirlpools program is deployed using a verifiable build, meaning the hash of the on-chain program can be independently compared against the hash of the published source code to confirm build integrity. Local development targets Anchor v0.32.1 and Solana v2.1.0. Dependencies The ORCA token's direct on-chain dependency is Solana's Token program, which contains the instruction logic for token transfers and balance management. The Whirlpools program depends on the Anchor framework and Solana, and supports interactions with both the standard SPL Token program and the Token-2022 program. The monorepo uses NX for cross-package dependency resolution. Deployment and addresses The ORCA mint address is orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE. The Whirlpools program address on Mainnet-Beta is whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc. All Whirlpools program accounts are program-derived addresses deterministically derivable from their parent account in the account hierarchy. Treasury-related addresses disclosed in the token treasury documentation include the Orca Fee Treasury, the Climate Fund wallet, the Community ORCA Treasury, and a wallet holding undistributed Solana fees. Client interfaces and SDKs Developers interact with Whirlpools through the orca-so/whirlpools TypeScript package and the orca_whirlpools Rust package for high-level operations. Lower-level integrations use generated clients for account and instruction parsing. These are non-consensus interfaces for constructing and submitting Solana transactions to the deployed program.
H.4	Consensus Mechanism	ORCA, as an SPL token on Solana, inherits Solana's network-level consensus for all token transfers and Whirlpools program executions. Ordering and finality are determined entirely by Solana's validator network. Solana generates a source of time through a Verifiable Delay Function known as Proof of History. Time is divided into slots, each with a designated leader elected from the active validator set. The leader produces a block for each slot, and validators communicate their fork preference through signed votes identifying the validator and the block being voted for. The leader schedule is recalculated at epoch boundaries, with each validator updating its own root fork and leader schedule each time the slot height crosses an epoch boundary. Tower BFT augments the voting system with lockouts. When a validator votes on a fork, a lockout is imposed for a number of slots during which the validator cannot switch to a non-descendant fork without forfeiting that commitment. Lockouts increase in duration exponentially with each successive vote on the same fork, making rollback of deeply confirmed forks progressively more costly. Validators that violate lockouts by voting for a diverging fork within the lockout window are subject to slashing, where the concurrent vote can be proven to the cluster.
H.5	Incentive Mechanisms and Applicable Fees	Network-level execution fees Every Solana transaction requires a fee paid in SOL. The base fee is calculated per signature at 5,000 lamports, split evenly between burning and validator compensation. An optional priority fee may be set by the submitter to increase scheduling likelihood and is paid in full to the validator. The default compute-unit limit is 200,000 per instruction, with a maximum of 1,4 million compute units per transaction. Orca does not charge fees to create a Whirlpool or to open a position in an existing pool. Solana network fees and rent apply to all transactions; rent associated with position creation is refundable on position closure, whereas network fees are not. Protocol-level fees and economic flows Whirlpool swaps may use either a fixed fee structure or an adaptive fee structure, depending on pool configuration. Under the fixed model, the total swap fee is a proportion of the input amount determined by the pool's stored fee rate, expressed in hundredths of a basis point. Of that total fee, the protocol fee is the portion diverted to the wallet controlled by the WhirlpoolsConfig collectProtocolFeesAuthority. Liquidity providers receive the remainder after the protocol fee is subtracted. Under the adaptive fee model, the total swap fee is the sum of a static base fee and a dynamic variable fee component that responds to market volatility. The variable fee is computed using a volatility accumulator measuring recent price movement across tick groups and decays over time, allowing fees to rise during volatile conditions and fall during calm periods. A hard cap of 10% applies to the total adaptive swap fee. The fee allocation for Orca-controlled pools is 87%of trading fees to liquidity providers, 12% to the DAO Treasury, and 1% to the Climate Fund. Of the 12% protocol share, 40% is used to buy back ORCA and add it to the xORCA vault as staker rewards, and 60% flows to the Orca Fee Treasury for development, grants, and operations. Validator incentives Validator incentives for ORCA transactions are Solana network-level incentives denominated in SOL. Base fees are split 50 % burnt and 50 % paid to the validator; priority fees are paid 100 % to the validator. There are no ORCA-denominated validator rewards and no distinct ORCA validator set. Parameter governance and fee disclosure Governance of protocol parameters is exercised by ORCA and xORCA holders. Any ORCA holder may submit a proposal; proposals are discussed on the Orca governance forum at gov.orca.so before on-chain voting on the Realms platform at realms.today/dao/ORCA. Voting weight is determined by ORCA and xORCA holdings, with xORCA carrying boosted voting weight relative to unstaked ORCA. Approved proposals are implemented by the protocol team or the DAO Council. The DAO Council is an elected body that executes governance decisions and manages day-to-day protocol operations within bounds defined by token holders. Its remit covers parameter adjustments, emergency responses, routine maintenance, proposal execution, treasury management, and ecosystem relations. The Council operates transparently and may be replaced by community vote. Governance proposal types include protocol upgrades, parameter changes, treasury allocation, and governance changes.
H.6	Use of distributed ledger technology	FALSE
H.7	DLT functionality description	N/A
H.8	Audit	TRUE
H.9	Audit outcome	Kudelski Security \| Whirlpools \| 28 January 2022 Object: Security assessment of the Orca Whirlpool smart contract, conducted remotely from 3 to 18 January 2022. The scope covered the Whirlpool program source code supplied via a private repository at commit 1bff5eccf12a70002e32627177dde0c502ea2a97, encompassing instruction handlers, account management, mathematical libraries, and reward logic. Results: Three findings, all of low severity. KS-ORCA-WHIRLPOOL-01: lamports cannot be transferred from funder accounts. KS-ORCA-WHIRLPOOL-02: the code did not compile to BPF. KS-ORCA-WHIRLPOOL-03: no error occurs when updating rewards twice at the same time. No critical, high, or medium severity issues were identified. The overall assessment concluded that the small number of findings indicates a high maturity of the code. Actions: All three findings were documented for remediation. The report notes that formal verification of the account relationship graphs confirmed that the reviewed code correctly implements the documented functionality. Report available at https://github.com/orca-so/whirlpools/blob/main/.audits/2022-01-28.pdf Neodyme \| Whirlpools \| 5 May 2022 Object: Security audit of the Orca Whirlpools smart contract on Solana, conducted from 7 March to 1 April 2022. The scope covered the on-chain Whirlpools contract and its custom U256 mathematics implementation used for swap calculations, at commit c55588a6eae1144be58bd348992f693e8b5ddc01. Results: Three findings in total. One high severity finding: lower tick could be larger than upper tick, arising from a missing validation check on position creation. One medium severity finding: integer overflow when swapping, identified in the swap calculation path. One informational finding: overflow in the checked multiplication function, carrying no impact under current usage. The codebase was assessed as being of very good quality and documentation. No critical severity issues were identified. Actions: All three findings were resolved by the Orca team. The high severity fix was applied in commit 78ecd7e2f81c2036710ba9859192757a353b7e21 and verified by Neodyme. The informational overflow was fixed in commit 5e035a1db513b848dd8729e1c992ff4d6199ae78 and verified by Neodyme. Report available at https://github.com/orca-so/whirlpools/blob/main/.audits/2022-05-05.pdf OtterSec \| Whirlpools \| 21 August 2024 Object: Security review of the Whirlpools program covering updates introduced ahead of the August 2024 release. Results: Detailed findings, severity counts, and methodology are contained in the published report. The PDF was not included in the uploaded compressed file and could not be accessed from the available sources. Actions: Report available at https://github.com/orca-so/whirlpools/blob/main/.audits/2024-08-21.pdf Sec3 \| Whirlpools \| 28 February 2025 Object: Security review of pull request 768, introducing the Liquidity Locking feature to the Whirlpools program. The audit covered the source code at commit 26057c46bc614f26aa01792315f3d9a50e565a3d, excluding tests. Results: Four findings in total. Two informational findings: I-01 recommended removing the freeze authority when locking positions permanently; I-02 recommended setting the mint freeze authority if token-based locking were to be supported. Two questions, both resolved: Q-01 concerned use cases against freezing position token accounts; Q-02 questioned whether checking the existence of lock configuration accounts could be made more versatile. No high or medium severity issues were identified. Actions: Informational findings I-01 and I-02 were acknowledged by the team. Questions Q-01 and Q-02 were resolved. Report available at https://github.com/orca-so/whirlpools/blob/main/.audits/2025-02-28.pdf Sec3 \| Whirlpools \| 23 June 2025 Object: Security review of five pull requests to the Whirlpools program: PR918 (Adaptive Fee Release), PR902 (Reset position range), PR903 (Allow locking concentrated positions), PR904 (Transfer locked position), and PR970 (Dynamic TickArray). The audit covered the respective commits for each pull request, excluding tests. Results: Thirteen findings in total. One medium severity finding: P1-M-01, a malicious user could maintain a high adaptive fee at low cost. Two low severity findings: P1-L-01, liquidity gaps were not skipped when fetching the last tick group index; P1-L-02, inconsistent volatility accumulator updates. Three informational findings across PR918 and PR970 concerning tick group index update conditions, an unresolved comment, and a redundant condition. Seven questions covering the adaptive fee rate cap, tick group index reference edge cases, comment inconsistencies, a potential redundant checkpoint reset, a potential incorrect error code, and future support for variable-sized tick arrays. Actions: All thirteen findings were resolved. Report available at https://github.com/orca-so/whirlpools/blob/main/.audits/2025-06-23.pdf Sec3 \| Whirlpools \| 22 August 2025 Object: Security review of three pull requests to the Whirlpools program: PR974 (Token-2022 support update), PR1010 (Safer account initialisation), and PR1038 (Superstate: Non-transferable position). The audit covered the respective commits for each pull request, excluding tests. Results: Two findings in total. One question: P1-Q-01 raised questions on DefaultAccountState-related checks in PR974, specifically regarding the removal of the initialised status check for the DefaultAccountState token extension, meaning token badges could now be granted regardless of DefaultAccountState status. One informational finding: P3-I-01 identified migration edge cases in PR1038. No issues were found in PR1010. Actions: P1-Q-01 was resolved; the team acknowledged the finding and retained the DefaultAccountState status check. P3-I-01 was acknowledged by the team after confirming behaviour across the four networks where the Whirlpool program is deployed. Report available at https://github.com/orca-so/whirlpools/blob/main/.audits/2025-08-22.pdf Sec3 \| Whirlpools \| 14 January 2026 (two reports) Object: Two security reviews of the Whirlpools program covering pull requests 99 and 1189, and pull requests 94, 95, and 96 respectively. Results: Both reports are listed on the official security audits page. The corresponding PDF files were not accessible from any available source at the time of drafting. Actions: Reports linked at https://docs.orca.so/reference/security-audits. The PDF files should be uploaded to complete this entry. Sec3 \| Wavebreak \| 28 July 2025 Object: Security review of the Wavebreak program. Results: Detailed findings are contained in the published report. The PDF was not accessible from the hosted link at the time of drafting. Actions: Report linked at https://docs.orca.so/reference/security-audits. The PDF file should be uploaded to complete this entry. Immunefi \| Bug Bounty program \| Ongoing Object: Continuous vulnerability disclosure program covering all deployed Orca contracts, including Whirlpools and Wavebreak. Results: Submissions and payouts are processed under coordinated disclosure. program scope and reward tiers are published at https://immunefi.com/bug-bounty/orca Actions: program active as of the date of this document.

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 price volatility and liquidity ORCA may experience material price fluctuations driven by broader crypto-asset market conditions, trading volume, venue depth, and investor sentiment unrelated to protocol fundamentals. Secondary-market liquidity can vary substantially across centralised and decentralised venues, and periods of low depth may widen spreads or make large positions difficult to exit at predictable prices. Irreversibility of transactions On-chain transactions involving ORCA are final once confirmed on Solana and cannot be reversed at protocol level. Mistaken, fraudulent, or accidental transfers cannot be recovered through any protocol mechanism; recovery depends entirely on control of the relevant private keys and the voluntary cooperation of any receiving party. Network fee and failed-transaction cost risk All Solana transactions require fees paid in SOL, including base fees and optional priority fees. Network fees are deducted before execution and are charged regardless of whether a transaction succeeds or fails. Increased network congestion can raise priority fees necessary for timely transaction inclusion, adding to the effective cost of ORCA-related activity. Access and interface dependency Access to the Orca protocol depends on the availability of the official interface, third-party wallets, RPC endpoints, and other access channels. The official interface may be restricted in certain jurisdictions. Third-party interfaces through which users may access the protocol are not owned, administered, or controlled by Orca, and may apply their own terms, restrictions, or access policies. Key custody and wallet-provider risk Control over ORCA balances depends on secure management of the private keys corresponding to the owner of each token account. Loss, theft, or compromise of private keys results in permanent loss of access to ORCA; no protocol mechanism can restore access or reverse a transfer made under a valid signature. Wallet software and hardware used to manage keys are third-party products not operated by Orca. Regulatory, tax and jurisdictional risk Digital-asset regulatory and tax frameworks remain evolving across jurisdictions. Changes in national or international rules may affect the permissibility, exchange, transfer, reporting, taxation, or value of ORCA. Regulatory developments may also restrict access to trading venues or interfaces through which ORCA is held or transferred. Delisting Risks Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.
I.2	Issuer-related risks	Whirlpools configuration authority risk The WhirlpoolsConfig account owner, currently the Orca for pools displayed on the Orca interface, holds authority over default fees, protocol-fee collection, and pool configuration. Compromise or misconfiguration of these authorities could affect fee collection, pool settings, or supported pool parameters. Vault assets can only be withdrawn by the Whirlpool program itself, not by the configuration owner, which limits but does not eliminate the scope of this authority risk.
I.3	Crypto-assets-related risks	Governance and utility dependency ORCA's primary on-chain utility is governance participation and staking for fee-linked rewards through the xORCA system. Its relevance and demand depend on continued use of the Orca protocol, sustained trading volume, active governance participation, and the maintenance of the xORCA staking and buyback mechanism. A material decline in protocol activity, trading volume, or governance engagement would reduce the practical utility of ORCA. Fixed supply and treasury-distribution risk ORCA has a stated fixed total supply of 75million tokens. Community governance proposals may direct treasury ORCA allocations toward grants, development, or other purposes. Such treasury movements can affect circulating supply, market expectations, and perceived token scarcity. The community treasury wallet addresses are publicly disclosed and can be monitored on-chain. xORCA staking liquidity and redemption risk Staking ORCA creates a seven-day cooldown before redemption is complete. During this period, a Claim Ticket non-fungible token is issued to represent the pending claim, and the redemption rate is locked at the moment of initiation. ORCA staked in the xORCA vault is subject to smart-contract risk for the duration of the staking period. Stakers cannot access their underlying ORCA immediately in the event of adverse market conditions during the cooldown. Public-ledger transparency risk ORCA transfers, swap activity, liquidity positions, staking transactions, and associated wallet addresses are permanently and publicly recorded on Solana. These records can be analysed, combined with other data sources, and used to infer user activity patterns or identify participants. This is an inherent characteristic of public blockchain infrastructure and cannot be mitigated at the protocol level. Token price and market manipulation risk ORCA market prices can move rapidly due to market conditions, regulatory developments, security events, sentiment changes, or deliberate manipulation by market participants. Crypto-asset markets may be susceptible to wash trading, spoofing, pump-and-dump activity, and other abusive practices across decentralised and centralised trading venues, which can cause material and rapid price movements.
I.4	Project implementation-related risks	Proposal implementation and delivery risk Governance proposals must pass through community discussion, feasibility review, voting, and implementation stages. Delivery depends on proposal quality, implementer capacity, participation levels, technical feasibility, and adherence to milestones. Proposals that are approved may nonetheless be delayed, modified, or not fully implemented if implementation conditions change after voting. Governance participation risk On-chain voting requires a minimum participation threshold and is weighted by token holdings. Low voter turnout, apathy, or disengagement by token holders may result in proposals passing without representative community support, or may prevent quorum from being reached. Participation is not mandatory and cannot be compelled. Third-party interface and wallet dependency Users access the Orca protocol through third-party wallets, interfaces, and RPC providers not controlled by Orca. Outages, policy changes, geographic restrictions, or discontinuation of these services can impair access to protocol functions, affect the ability to submit transactions, and disrupt asset management. Treasury and funding dependency Protocol development, grants, and operational activities depend on funds held in the Orca Fee Treasury and Community ORCA Treasury. Ineffective treasury management, governance disputes over allocation, or depletion of treasury resources could constrain development capacity, ecosystem grants, and implementation timelines. Data handling and privacy risk Orca collects wallet addresses, device data, usage behaviour, transaction history, and communications data through the site and via third-party service providers. This data may be shared with vendors, analytics providers, affiliates, and public authorities, and may be transferred to jurisdictions outside of users' home countries. Users have limited ability to prevent collection of on-chain transaction data, which is inherently public. Jurisdiction and dispute-resolution complexity Orca Management Company S.A. is a Panama corporation. Arbitration under the Orca Terms of Use is subject to applicable law selected under those terms. Multi-jurisdictional legal arrangements may complicate user recourse, regulatory engagement, and the enforceability of dispute outcomes across different legal systems. RPC and API dependency Orca software development kits require an active RPC endpoint to communicate with the Solana network. The Orca REST API provides pool data, protocol metrics, and token information that integrators and users rely on. Degradation or unavailability of RPC providers, indexers, or Orca API services can affect state visibility, integration reliability, and user decision-making. Service continuity and force-majeure risk Access to the Orca interface or related services may be suspended, restricted, or terminated due to system failures, adverse events, regulatory action, natural disasters, or other emergencies. Such disruptions can interrupt access to protocol functions without advance notice. Community governance and vote concentration The Orca protocol is governed by ORCA and xORCA token holders, with voting weight proportional to token holdings. Concentrated holdings or coordinated voting blocs may exert disproportionate influence over proposals affecting fee structures, treasury allocation, protocol upgrades, and governance changes. Delegated voting power may further concentrate effective voting authority. DAO Council execution and operational discretion The DAO Council executes approved governance decisions and manages day-to-day protocol operations, including emergency responses and parameter adjustments. Operational failures, coordination gaps, or incorrect Council execution could affect protocol maintenance, incident response, or the implementation of approved community decisions. The Council operates within community-defined limits and is subject to replacement by community vote, but this oversight is itself subject to governance participation levels. xORCA administrative control risk The xORCA staking system includes a 3-of-5 multisig requirement for program changes and an emergency pause capability. Compromise of a sufficient number of signing keys or misuse of the pause function could affect staking operations, fee-buyback execution, or user access to governance participation through xORCA. User ORCA redemptions are stated to remain available during a pause
I.5	Technology-related risks	Smart-contract and concentrated liquidity logic risk ORCA and the Whirlpool protocol depend on Rust smart contracts deployed on Solana. Whirlpools use concentrated liquidity, meaning execution quality depends on whether active liquidity exists within the relevant price range at the time of a swap. In the absence of in-range liquidity, swaps may fail or result in high slippage. Adaptive fees can increase automatically during periods of elevated price volatility, raising transaction costs for users. Defects in smart-contract logic, SDK implementations, or fee calculations could cause incorrect execution, fund inaccessibility, or unintended pool behaviour. Solana Layer-1 dependency ORCA and all Whirlpools operations depend entirely on Solana's network for transaction inclusion, ordering, and finality. Solana network congestion, validator outages, protocol-level bugs, or extended downtime would prevent ORCA transfers, Whirlpool interactions, staking, and governance participation. Priority fees, compute-unit constraints, and failed-transaction fee deductions are inherent to the Solana fee model and affect all ORCA-related activity. SPL token infrastructure dependency ORCA is issued as an SPL token and its transferability depends on the correct operation of Solana's Token program, associated token accounts, and account rent mechanics. Users must hold a compatible Solana wallet with sufficient SOL to cover account rent and transaction fees. Errors in token account setup, signing authority, or associated token account derivation can prevent receipt or transfer of ORCA. Whirlpools configuration and fee-authority risk WhirlpoolsConfig and FeeTier accounts define fee rates, tick spacing, and collection authorities for pools. Misconfiguration or compromise of these authorities could affect pool-level fee settings, protocol-fee collection, or supported pool parameters. The program-only vault withdrawal restriction limits the scope of this risk to configuration and fee parameters rather than pooled liquidity directly. TokenExtensions compatibility risk Certain Solana Token-2022 extensions can introduce elevated risk to pool operations and user outcomes. Tokens bearing such extensions require a TokenBadge issued by the TokenBadge authority before they can be used for Whirlpool pool initialisation. Errors in TokenBadge issuance, or the introduction of new extension types that are not yet covered by the badge mechanism, could affect pool safety or expose users to unexpected token behaviour. xORCA contract and emergency-control risk ORCA staked into the xORCA vault is held in smart contracts. Contract defects, compromise of the 3-of-5 multisig signer set, or misuse of the emergency pause capability could affect staking operations, fee-buyback execution, or user access to pending redemptions. While withdrawals are stated to remain available during a pause, the interaction between the pause mechanism and in-progress redemption Claim Tickets is a source of residual risk. Vault-withdrawal and custody-boundary risk Whirlpool vault assets can only be withdrawn through the execution of the Whirlpool program itself. No party, including the program owner and the WhirlpoolsConfig owner, can withdraw vault assets directly. Users remain exposed to correct program execution and to the distinction between assets held within program-controlled vaults and assets held in individual wallets. Any defect in program withdrawal logic could affect liquidity provider access to pooled assets. Quantum computing risk Solana uses the Ed25519 elliptic-curve signature scheme for all transaction authentication. A cryptographically relevant quantum computer capable of running Shor's algorithm could in principle derive private keys from their corresponding public keys, compromising the security of ORCA token accounts and all Solana-based key pairs. program-derived addresses, which rely on SHA-256-based hashing, carry greater resistance to quantum attack under Grover's algorithm but are not immune. No quantum computer currently capable of executing these attacks at a cryptographically relevant scale exists, and the timeline for such capability is uncertain. The National Institute of Standards and Technology finalised its first post-quantum cryptography standards in August 2024, recognising the long-term threat to elliptic-curve-based systems. Solana has not published a post-quantum migration roadmap, meaning any migration would depend on future community and validator coordination that has not yet been defined.
I.6	Mitigation measures	Offer-Related Risks Market price volatility and liquidity: Pool-level liquidity, TVL, token balances, fee rates, and adaptive-fee status are available in real time through the Orca Whirlpools REST API, allowing users and integrators to assess pool conditions and available depth before executing transactions. Access and interface dependency: The Whirlpools program is permissionless and accessible via any Solana-compatible RPC endpoint and wallet, independently of the official Orca interface. Interaction does not require use of the Orca front end; the open-source Whirlpools SDK can be configured against any valid RPC URL. Issuer-Related Risks Whirlpools configuration authority risk: The Whirlpool program enforces in its on-chain logic that vault assets can only be withdrawn through program-controlled execution. This constraint is not overridable by the WhirlpoolsConfig owner or the program deployer, and is independently verifiable in the open-source contract code at github.com/orca-so/whirlpools. Crypto-Asset-Related Risks Fixed supply and treasury-distribution risk: The ORCA total supply of 75 million tokens is recorded in the on-chain mint account at address orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE and is verifiable by any party on Solana Explorer without reliance on issuer representations. xORCA staking liquidity and redemption risk: Upon initiating unstaking, the applicable xORCA-to-ORCA exchange rate is locked at the moment of redemption initiation and recorded in the Claim Ticket non-fungible token issued to the user. This prevents exchange rate deterioration from affecting the redeemable ORCA amount during the seven-day cooldown period. Project Implementation-Related Risks Proposal implementation and delivery risk: Governance proposal templates require implementer identification, milestone definition, risk and consideration sections, and DAO Council feasibility review before a proposal proceeds to on-chain voting. This structure creates a documented accountability framework tied to each approved change. Treasury and funding dependency: The Orca Fee Treasury, Community ORCA Treasury, Climate Fund wallet, and undistributed-fee wallet addresses are publicly disclosed and monitorable on-chain, allowing token holders and the public to observe treasury balances and movements without reliance on issuer reporting. Governance participation risk: A minimum participation threshold is applied to on-chain votes, and proposals must pass through a mandatory community discussion period on the Orca governance forum before voting opens. These requirements prevent low-participation outcomes from being produced by a small number of votes. RPC and API dependency: The Orca software development kit accepts a configurable RPC URL, allowing integrators and users to substitute their own RPC provider or use any public Solana RPC endpoint, reducing dependence on any single infrastructure provider for transaction submission. Community governance and vote concentration: ORCA and xORCA holders may delegate voting power to any address of their choosing, distributing governance influence beyond direct token holdings. Voting and proposal activity occur on the publicly auditable Realms platform at realms.today/dao/ORCA, where all submissions, votes, and outcomes are verifiable on-chain. The DAO Council is subject to removal by community vote at any time. DAO Council execution and operational discretion: Council powers are bounded by community-approved limits; actions outside those bounds require full governance approval. Decision logs, meeting notes, and operational communications are published through the Orca governance forum at gov.orca.so, maintaining a public record of Council activity against which departures from mandate can be identified. xORCA administrative control risk: Program changes to the xORCA system require approval from at least three of five designated multisig signers, distributing change-management authority and making unilateral modification by a single party impossible. User redemptions are stated to remain accessible during an emergency pause. Technology-Related Risks Smart-contract and concentrated liquidity logic risk: The Whirlpools program has undergone eight independent security audits by Kudelski Security, Neodyme, OtterSec, and Sec3 between January 2022 and January 2026. The program is deployed using a verifiable build that allows any party to independently confirm that the on-chain executable matches the published source code. An active bug bounty program on Immunefi offers rewards of up to USD 500,000 for qualifying vulnerability disclosures against deployed Orca contracts. TokenExtensions compatibility risk: Tokens bearing Token-2022 extensions that pose elevated risk to pool operations require a TokenBadge issued by the designated authority before they can be used to initialise a Whirlpool. This on-chain gating mechanism is enforced by the Whirlpools program logic and prevents pools from being created with tokens carrying potentially harmful extensions without explicit authorisation. Vault-withdrawal and custody-boundary risk: The program-only vault withdrawal restriction is implemented in the open-source Whirlpools contract and is enforceable exclusively through Whirlpool program execution. This structural constraint is independently auditable in the published source code and has been confirmed across multiple independent security reviews.

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