Orca
Open-source concentrated-liquidity AMM (Whirlpools) on Solana; permissionless CLMM pool creation; original protocol, not a fork.
DeploymentsSolana · $253.7M
01
Risk profile at a glance
0 red · 1 yellow · 11 green 02
Categories & evidence
184 factors · 13 categoriesCode & audits Green 8 25 of 25
RD-F-003 yellow Resolved-without-proof findings Audit PDFs are not machine-parseable from this assessment pass (binary PDF format). No evidence from secondary sources (dexrank.com review, Neodyme public report) of unresolved findings left open. Zero exploit history in 4+ years provides indirect corroboration. Cannot independently verify per-finding resolution without reading each PDF. Confidence is medium; per-finding mapping requires curator PDF review. RD-F-005 yellow Audit firm tier All four firms are Tier-2 per the taxonomy's EVM-centric Tier-1 list (Trail of Bits, OZ, ConsenSys Diligence, Certora, Sigma Prime, Spearbit, Zellic). Kudelski Security (established multi-domain firm), Neodyme (top-tier Solana specialist), OtterSec (leading SVM auditor), Sec3 (Solana-native with formal analysis tool X-ray) represent the best available audit coverage for Solana programs. Note: The Tier-1 taxonomy list is EVM-centric; OtterSec and Neodyme are effectively Tier-1 equivalents for SVM protocols. RD-F-024 yellow Code complexity vs audit coverage Six audit engagements over 4 years on a codebase of moderate complexity (programs/whirlpool/src/ with ~15 modules including math, state, instructions). Three Sec3 quarterly audits in 2025 demonstrate incremental coverage of changes. Active development continues with recent commits (2026-05-14). PDF metadata for exact audit duration not publicly accessible; cannot compute LOC/audit-day ratio. Code size and audit cadence appear adequate based on available evidence but cannot be quantitatively confirmed. RD-F-009 gray Formal verification coverage No formal verification engagement found (Certora Prover, Kani, Halmos, or equivalent). Sec3 uses X-ray static analysis but this is not a full FV proof system. No published invariant specification found in the repository. The Certora SecurityReports index does not list Orca. Formal verification is genuinely absent for this protocol — consistent with the current norm for Solana AMMs. Gray: protocol has not declared critical invariants in a machine-checkable form. RD-F-010 gray Static-analyzer high-severity count Slither/Mythril/Semgrep are EVM-specific static analysis tools and cannot be run on Rust/BPF bytecode. Orca Whirlpools is an Anchor/Rust Solana program; no Etherscan-verified source exists (non-EVM substrate). Sec3's X-ray tool was used in the 2025 audits but findings are not publicly summarized. Structurally not assessable via the taxonomy-specified toolchain on this substrate. RD-F-011 n/a SELFDESTRUCT reachable from non-admin path SELFDESTRUCT is an EVM opcode not present in Solana BPF/SBF programs. Solana account lifecycle uses program-owned account closing via authorized paths (e.g., BPFLoaderUpgradeable). No SELFDESTRUCT equivalent exists in Anchor/Rust. Factor structurally does not apply to this substrate. RD-F-012 n/a delegatecall with user-controlled target delegatecall is an EVM Solidity primitive. Solana uses CPI (cross-program invocation) which is architecturally distinct — CPI targets are constrained by typed Anchor account constraints, not arbitrary user-supplied addresses. No user-controlled CPI target surface analogous to EVM delegatecall exists in the Whirlpools program. RD-F-013 n/a Arbitrary call with user-controlled target Arbitrary .call(target, data) with user-controlled target is an EVM pattern. Solana CPI uses typed program accounts validated by Anchor's account constraints; arbitrary call targets are not permissible in the Anchor programming model used by Whirlpools. RD-F-014 gray Reentrancy guard on external-calling functions Slither reentrancy detectors are EVM-only and cannot run on Rust/BPF. Solana CPI reentrancy is a real threat vector but is distinct from EVM reentrancy. Anchor's account borrowing model and the 2022 Kudelski/Neodyme audits address CPI reentrancy patterns. No findings on reentrancy reported in available audit summaries. Cannot assess via the specified toolchain on this substrate. RD-F-015 n/a ERC-777/1155/721 hook without reentrancy guard ERC-777/1155/721 are EVM token standards. Orca Whirlpools uses SPL Token and Token-2022 (Solana native standards). SPL Token does not have callback hooks analogous to ERC-777 tokensReceived. No ERC-777/1155/721 integration exists. RD-F-016 gray Divide-before-multiply pattern Slither divide-before-multiply detector is EVM-only and cannot run on Rust/BPF. The Whirlpool math module uses Q64.64 fixed-point arithmetic audited by Neodyme (2022) and OtterSec (2024). No findings on integer ordering reported in available summaries. Structurally not assessable via the specified toolchain. RD-F-019 n/a ecrecover zero-address return unchecked ecrecover is an EVM Solidity/Ethereum cryptography primitive. Solana uses Ed25519 signature verification via the ed25519_program system instruction. No ecrecover calls exist in the Anchor/Rust Whirlpools codebase. RD-F-020 n/a EIP-712 domain separator missing chainId EIP-712 is an Ethereum typed structured data signing standard. Solana uses Ed25519 signatures over Borsh-serialized message bytes. No EIP-712 domain separator exists in the Whirlpools codebase. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned UUPS (EIP-1822) is an EVM proxy upgrade pattern. Whirlpools uses BPFLoaderUpgradeable — Solana's native program upgrade mechanism where the upgrade authority is a separate account (Squads v4 vault, 3-of-10 multisig, 24h timelock). No _authorizeUpgrade() function exists in Anchor/Rust programs. RD-F-023 n/a Constructor calls _disableInitializers() _disableInitializers() is an OpenZeppelin EVM pattern for proxy implementations to prevent re-initialization of the implementation contract directly. Anchor/Rust Solana programs have no constructor in the EVM sense and use discriminator-based account initialization that cannot be re-triggered. Factor structurally does not apply.
RD-F-001 green Audit scope mismatch Six audit engagements documented in .audits/ directory. OtterSec verifiable build (verify.osec.io) confirms on-chain program whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc matches commit e5f089bc5c49b01f5c8abb43c78457ab6c440568, verified 2026-02-04. Most recent Sec3 audit dated 2025-08-22 is the latest coverage point. Solana verifiable builds substitute for the Etherscan bytecode-match methodology on non-EVM substrates; hash match confirmed by OtterSec's independent verification service. No material mismatch between audited and deployed code identified.
RD-F-002 green Audit recency Most recent audit: Sec3, dated 2025-08-22. Days since sign-off at assessment date 2026-05-16: approximately 267 days. Within the green threshold (<=365 days). Three Sec3 audits conducted in 2025 (Feb, Jun, Aug) demonstrate a continuous quarterly re-audit cadence.
RD-F-004 green Audit count Four distinct audit firms engaged across six engagements: Kudelski Security (2022-01-28), Neodyme (2022-05-05), OtterSec (2024-08-21), Sec3 (2025-02-28, 2025-06-23, 2025-08-22). Well above the green threshold of >=2 distinct firms.
RD-F-006 green Audit-to-deploy gap Kudelski audit signed 2022-01-28; Whirlpools CLMM launched 2022-03-23 (approximately 54 days gap, within the green <=60 day threshold). Neodyme audit (2022-05-05) was a post-launch review; the 2024-2025 Sec3/OtterSec audits are incremental re-audits of live code — standard cadence for live protocols. The initial Kudelski pre-launch audit-to-deploy gap is within green range.
RD-F-007 green Bug bounty presence & max payout Active Immunefi program at immunefi.com/bug-bounty/orca, $500k maximum critical payout (minimum $100k for critical). Program live since 2022-05-19, last updated 2026-01-08. Whirlpools program is explicitly in scope. Funded by community governance vote (1M ORCA passed 2022-05-28). Meets green threshold (active program with max payout >=500k USD).
RD-F-008 green Ignored bounty disclosure No prior exploits of the Orca Whirlpools protocol documented (Rekt DB empty, DefiLlama hacks empty per cache). No evidence of any disclosed vulnerability being ignored pre-exploit. Four years of operation with zero protocol hacks provides strong corroborating evidence. Factor is effectively N/A (no prior incidents to assess ignored disclosure against) but scored green per the methodology (no evidence of ignored disclosure).
RD-F-017 green Mixed-decimals math without explicit scaling Whirlpools handles SPL tokens with varying decimal counts. The sqrt_price math framework uses Q64.64 fixed-point representation as the canonical unit, providing explicit scaling across all token decimal configurations. Neodyme audit (2022-05-05) and OtterSec audit (2024-08-21) both covered mathematical correctness. No findings on decimal scaling errors reported in available summaries. Rust's type system and the audited fixed-point math library provide strong structural protection.
RD-F-018 green Signed/unsigned arithmetic confusion Rust's strong static type system distinguishes signed (i64/i128) from unsigned (u64/u128) integers and requires explicit casts. Whirlpools uses u128 for liquidity amounts and i128/i64 for tick indices (signed by design — ticks range from negative to positive). The Neodyme and OtterSec audits covered arithmetic correctness. No signed/unsigned confusion findings reported. Rust's type safety provides structural protection beyond what Slither detection offers for Solidity.
RD-F-022 green Public initialize() without initializer modifier The OpenZeppelin initializer modifier / unprotected initialize() pattern is an EVM Solidity vulnerability class (proxy re-initialization). Anchor Rust programs use discriminator-based account initialization (#[account(init, ...)]) which is enforced at the Solana runtime level — once an account is initialized with a discriminator, it cannot be re-initialized by any caller. No unprotected EVM-style initialize() surface exists. The program is fully open-source; all 6 audit engagements across 4 firms would have flagged this class of vulnerability if present. Zero exploit history in 4+ years corroborates the green finding.
RD-F-183 green Bug bounty scope gap on highest-TVL contracts Active Immunefi program with $500k max payout. The program explicitly covers Whirlpools — described on the Immunefi page as 'Orca has created custom smart contracts for its concentrated liquidity product, Whirlpools.' The Whirlpools program (whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc) is the primary TVL-bearing component at $254M TVL; it is in scope per program description. Three total assets in scope. No indication the core program is excluded. SECURITY.md in the repo directs all researchers to the Immunefi program.
Governance & admin Green 16 24 of 24
RD-F-028 yellow Low-threshold multisig vs TVL 3-of-10 threshold at $254M TVL. Peer cohort per SOLANA_GOVERNANCE.md: Kamino KLend v2 is 5/10 at comparable TVL; Sanctum Router is 4/7. A 3-of-10 is one below peer norm for this TVL band. Not catastrophic (10 members total is high; 3 signers required), but below the expected threshold for a $250M+ TVL protocol. RD-F-032 yellow Timelock duration on upgrades Squads v4 on-chain time_lock field = 86400 seconds = exactly 24 hours. Per methodology: green >=48h, yellow 24-47h, red <24h. At the yellow/green boundary — 24h is yellow. Timelock is genuine and on-chain verified (not a docs-only claim). RD-F-033 yellow Timelock on sensitive actions Upgrade: timelocked (24h Squads v4). Fee authority changes: routed through same Squads multisig (timelocked). Config authority changes: same multisig (timelocked). Collect_protocol_fees_authority: held by team; no independent verification that this specific role requires Squads multisig execution (fee collection is not a drain path since LP funds are not extractable this way). Pause: no global pause function exists — N/A. 3-4 of relevant action types timelocked = yellow. RD-F-036 yellow Flash-loanable voting weight SPL Governance (Realms) requires ORCA token deposit into the governance program before a vote can be cast; tokens are locked in the Voter Token Record for the duration of active proposals. This prevents same-block flash-loan attacks (Beanstalk-style) on voting weight. However, the governance token (ORCA/xORCA) can be accumulated via open-market purchases over multi-day windows without any time-weighted lock requirement. Governance v0 docs confirm 1-ORCA=1-vote model with 7-day voting period. No checkpoint-based snapshotting. Yellow: not flash-loanable within a single tx; open-market accumulation risk over longer windows remains. RD-F-037 yellow Quorum achievable via single-entity flash loan SPL Governance deposit model prevents same-block flash-loan quorum attack. For open-market accumulation: quorum = 500,000 ORCA (0.67% of ~75M circulating supply). A large holder accumulating ORCA over days/weeks could exceed quorum without flash loans. No single-block flash-loan path exists. Yellow reflects non-flash-loan accumulation risk. RD-F-040 yellow Emergency-veto multisig present Orca governance has a 4-day tokenholder veto window on governance council proposals (confirmed in council re-election 2026 forum post). There is no separate EVM-style cancel-role multisig. The veto mechanism is token-holder-driven via SPL Governance voting. Cancel role is effectively held by collective ORCA holders (>500K quorum to veto). Yellow: veto exists but is token-holder-driven rather than a dedicated guardian multisig. RD-F-167 yellow Deprecated contract paused but pause reversible by live admin Orca deprecated its legacy AMM v1 (non-concentrated pools) in Q1 2023 and placed them in withdrawal-only mode. As of mid-2023 approximately $9M remained in legacy contracts. The legacy program is a separate BPF program; whether its upgrade authority was set to the same Squads multisig or was immutably frozen is not confirmed in this session. If the upgrade authority was not renounced/frozen, the live admin could theoretically re-enable deposit functionality. Yellow with low confidence pending on-chain verification of legacy program upgrade authority status. RD-F-029 gray Multisig signers co-hosted Squads v4 multisig member pubkeys are not publicly enumerated for Orca. ASN/custodian co-hosting inference cannot be performed without the 10 signer addresses. Structural data gap. RD-F-030 gray Hot-wallet signer flag Signer wallet addresses not publicly enumerated. Hot-wallet behavioral heuristics (nonce velocity, gas-price jitter) cannot be applied without the 10 Squads multisig signer pubkeys. RD-F-031 gray Signer rotation recency Squads v4 emits ConfigTransactionExecuted events for member changes, but signer pubkeys are not publicly listed. No public announcement of signer rotation found on forums.orca.so or Medium. Cannot determine rotation recency without member pubkeys to trace events. RD-F-039 n/a delegatecall/call in proposal execution without allowlist Orca uses SPL Governance on Solana (non-EVM). The delegatecall/call proposal-execution attack surface does not exist on Solana — proposal execution invokes authorized Solana program instructions with typed accounts, not arbitrary EVM calldata with arbitrary targets. Structural N/A by architecture. RD-F-042 n/a Admin has mint() with unlimited max The Whirlpool DEX program does not contain a mint() instruction. The ORCA governance token has a hard-capped supply of 100M (25M burned per April 2025 governance proposal; ~75M circulating). The protocol's program itself does not mint tokens. N/A: no admin-callable unlimited mint exists on this DEX protocol. RD-F-044 gray Admin wallet interacts with flagged addresses Squads multisig member pubkeys are not publicly enumerated. The vault PDA itself is a non-signing PDA. Without the 10 signer addresses, Chainalysis/TRM cluster screening cannot be run. Structural data gap due to protocol opacity on signer identities. RD-F-045 gray Constructor args match governance proposal EVM constructor-arg verification via Etherscan does not apply to Solana BPF programs. Solana program upgrades in Squads v4 specify a buffer account containing the new bytecode; matching the buffer hash to the deployed program hash requires Squads v4 proposal decoding. Not performed in this session. Not applicable in the EVM sense; pipeline-unimplemented for Solana. RD-F-046 n/a Contract unverified on Etherscan/Sourcify Etherscan/Sourcify contract verification does not exist for Solana programs. The Whirlpool program source is publicly available on GitHub (orca-so/whirlpools, open-source Anchor/Rust), independently audited by 4 firms, and buildable via Anchor framework. The equivalent for Solana would be anchor verify reproducibility. Structural N/A for EVM-specific verification mechanism. RD-F-047 gray Governance token concentration (Gini) ORCA token Gini coefficient not computed. Token has 100M hard cap; 25M burned; ~75M circulating. Top-holder concentration not queried via Dune/subgraph in this session. Pipeline-unimplemented for Solana SPL token holder distribution.
RD-F-025 green Admin key custody type Upgrade authority is Squads v4 vault PDA (multisig + on-chain 24h timelock). Pipeline-verified: verified_type=squads_v4_vault, verified_time_lock_seconds=86400. Fee authority and config authority roles exist in WhirlpoolConfig and are controlled through the same Squads multisig. Classification: multisig+timelock.
RD-F-026 green Upgrade multisig signer configuration (M/N) Pipeline-verified on-chain: 3-of-10 Squads v4 multisig. Vault PDA GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV; parent multisig BQsDWkL417U4tVE2sDnPks469pKdm6YzFgKH77doiEjF. verified_threshold=3, verified_members=10. Display: 3/10.
RD-F-027 green Single admin EOA Upgrade authority is Squads v4 PDA GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV with is_on_curve=false (off-curve = PDA, not an EOA). System Program ownership is correct for Squads v4 vault PDAs by design (anti-drift #12). 3-of-10 multisig signature required for any upgrade; 24h timelock enforced on-chain.
RD-F-034 green Guardian/pause-keeper distinct from upgrader No global pause function exists in the Whirlpool program — there is no PAUSER_ROLE or pause/unpause instruction. Individual pool closure is user-driven. No distinct guardian role needed because no pause mechanism exists. Factor vacuously green (pause absent = no separation violation).
RD-F-035 green Role separation: upgrade ≠ fee ≠ oracle Three distinct roles identified: upgrade authority (Squads vault PDA), fee_authority (WhirlpoolConfig parameter — set_fee_authority instruction), collect_protocol_fees_authority (set_collect_protocol_fees_authority instruction). No oracle role (no oracle in swap path — F180 N/A). Upgrade and fee roles are distinct Solana account roles, both gated through the Squads multisig but assigned separately.
RD-F-038 green Proposal execution delay < 24h Total execution delay = 7-day voting period (SPL Governance) + 24h Squads v4 timelock = >192 hours before an upgrade can be executed after proposal submission. Per methodology: green >=48h total. Well above threshold.
RD-F-041 green Rescue/emergencyWithdraw without timelock Full instruction enumeration of programs/whirlpool/src/lib.rs found no rescue, emergencyWithdraw, sweep, skim, or drain function. collect_protocol_fees is the only fee-extraction function and it only extracts protocol fee accumulations (not LP capital). LP positions can only be closed by position owners. No admin drain-in-1-tx path found.
RD-F-043 green Admin = deployer EOA after 7 days Current upgrade authority is Squads v4 multisig PDA, not the deployer EOA. Whirlpools launched March 2022; governance and multisig structure was established from early operations. Squads v4 verified as current controller. No deployer-as-sole-admin pattern at any point in accessible history.
Oracle & external dependencies Green 0 17 of 17
RD-F-049 n/a Oracle role per asset No external oracle provider exists; there is no oracle-to-asset mapping to enumerate. All pricing is reserve-based CLMM math (sqrt_price, tick state). Factor presupposes an oracle role assignment per asset, which does not apply to a pure AMM with no oracle consumption. RD-F-051 n/a Fallback behavior on oracle failure No oracle is consumed, so fallback behavior on oracle failure is not applicable. The factor presupposes a primary oracle that can fail or go stale. Orca Whirlpools pricing derives entirely from pool reserves (always available while the Solana network is live). The protocol cannot experience an oracle failure. RD-F-054 n/a TWAP window duration No TWAP oracle is consumed by Whirlpools internally. Factor measures TWAP window duration for an oracle read by the protocol — inapplicable when there is no TWAP oracle dependency. Note: Whirlpool pool prices can be used as TWAP sources by other protocols, but Orca itself does not read a TWAP for its own swap operations. RD-F-055 n/a Oracle pool depth (USD) No DEX-TWAP oracle is consumed by Whirlpools. Factor measures depth of the DEX pool feeding an oracle — inapplicable when there is no such pool in Orca's oracle consumption path. RD-F-056 n/a Single-pool oracle (no medianization) No oracle is consumed; no pool-reading oracle path exists in Whirlpools swap logic. Factor tests single-pool versus medianized oracle — inapplicable when there is no oracle source to evaluate. RD-F-057 n/a Circuit breaker on price deviation No oracle-based circuit breaker applicable. There is no external price feed to deviate. Orca implements a sqrtPriceLimit (slippage tolerance) parameter in swap instructions, which the caller provides — this is a caller-side slippage guard, not a protocol-level circuit breaker on an external oracle feed. The factor tests a circuit breaker on oracle price deviation, which presupposes an oracle. RD-F-058 n/a Max-deviation threshold (bps) No circuit breaker on an oracle feed (see F057). Factor measures the configured deviation threshold in bps — not applicable when no circuit breaker on an oracle feed exists. RD-F-059 n/a Oracle staleness check present No external oracle is read; there is no updatedAt field to check for staleness. Factor presupposes an oracle read with a timestamp that can become stale. Inapplicable for a pure on-chain AMM. RD-F-060 n/a Chainlink aggregator min/max bound misconfig Orca does not use any Chainlink feed. Non-EVM substrate (Solana/Rust); Chainlink does not operate on Solana in the same feed-registry model as EVM. No Chainlink integration present or architecturally applicable. Factor is EVM-specific (Chainlink aggregator minAnswer/maxAnswer bounds). gap_reason: not_applicable (non-EVM substrate + no Chainlink usage). RD-F-061 n/a LP token balanceOf used for pricing Orca does not use balanceOf of LP tokens for pricing. CLMM pricing is based on sqrt_price and tick state in the Whirlpool state account. LP positions are represented as NFT position accounts, not fungible LP tokens with balanceOf semantics. Additionally, Solana does not have Solidity-style EVM function calls — the EVM-specific balanceOf donation-manipulation pattern is architecturally inapplicable. gap_reason: not_applicable (non-EVM substrate + NFT-based position accounting). RD-F-180 n/a Immutable oracle address NOT_APPLICABLE — architectural basis: Orca Whirlpools uses no external oracle in the swap pricing path. RD-F-180 tests whether an oracle source address is hardcoded (EVM immutable, non-EVM hardcoded, or closed-source binary embedding) such that the protocol cannot replace the oracle if the underlying asset depegs. Because Whirlpools has no oracle address at all — pricing is derived from pool reserves (sqrt_price, tick state) — the failure mode this factor tests is structurally absent. Evaluated on merits per briefing instruction. Orchestrator flag: F180 critical-candidate status per PD-017 is noted; inapplicability here does not affect its star status for other protocols. gap_reason: not_applicable (no oracle address exists to be mutable or immutable). RD-F-181 n/a Permissionless-pool lending oracle NOT_APPLICABLE — architectural basis: RD-F-181 measures whether a lending protocol accepts spot prices from a permissionless-pool venue without TWAP or liquidity-floor guards. Orca is a pure DEX/AMM — coverage_flags.lending_protocol is false; there is no borrow market. The factor is inapplicable to non-lending protocols by design (taxonomy applicability: lending-protocol-only, analogous to PD-024 lending-only Cat 4 factors). Separately noted: Orca's permissionless pool creation makes Orca a potential oracle venue for other lending protocols — this is an outbound ecosystem risk, not an inbound oracle-acceptance risk to Orca itself. gap_reason: not_applicable (non-lending protocol).
RD-F-048 green Oracle providers used No external oracle provider is used. Whirlpools swap pricing is derived entirely from on-chain pool reserves (sqrt_price, tick-array state). The oracle.rs state file in programs/whirlpool/src/state/ is an internal adaptive-fee volatility tracker — it does not read any external price feed. Cargo.toml has no Pyth, Chainlink, or Switchboard crate. Data cache sources.oracle_feeds is an empty array, consistent with architectural analysis.
RD-F-050 green Dependency graph (protocols depended upon) Minimal dependency graph: SPL Token Program (Solana core runtime) and Token-2022 Program (Solana core extended token standard). No third-party DeFi protocol dependencies (no Aave pool, no Uniswap router, no oracle adapter). No bridge protocol dependency. No off-chain keeper or relayer required for core operations. Eclipse deployment is an independent SVM L2 instance — Orca's Solana mainnet program has no CPI dependency on Eclipse. Cargo.toml confirms only: anchor-lang, anchor-spl, solana-program, pinocchio suite — all Solana core framework.
RD-F-052 green Breakage analysis per dependency Per-dependency breakage analysis: (1) SPL Token Program failure — all token transfers halt; swaps and liquidity operations revert. This is a Solana chain-level event, not an Orca-specific risk. (2) Token-2022 Program failure — Token-2022 pool pairs affected; classical SPL-Token pairs unaffected. (3) No oracle dependency to fail. (4) No third-party DeFi protocol dependency to fail. The dependency surface is minimal and confined to Solana core runtime programs.
RD-F-053 green Oracle source = spot DEX pool (no TWAP) GREEN — confirmed via source inspection. Orca Whirlpools IS the DEX; it does not consume an external spot DEX price as an oracle. Pricing is derived from on-chain reserve math (sqrt_price, tick-array state) during swap execution. The oracle account in swap.rs is an internal adaptive-fee state tracker ('currently unused' per inline comment for trade pricing). No Chainlink, Pyth, Switchboard, or other external feed crate is present in Cargo.toml. Data cache oracle_feeds array is empty. F053 is green by architectural design — the swap pricing path has no external price feed dependency.
RD-F-062 green External keeper/relayer not redundant Orca Whirlpools does not depend on an external keeper or relayer for core swap or liquidity operations. All operations are user-initiated on-chain transactions on Solana. No Gelato, Chainlink Automation, or equivalent keeper dependency found in the instructions directory or Cargo.toml. The update_fees_and_rewards instruction is permissionless (callable by anyone) — no single keeper dependency. Reward emissions are user-claimable; no relayer required.
Economic risk Yellow 22 13 of 13
RD-F-065 yellow Liquidity depth per major asset Orca IS the primary liquidity venue for many Solana pairs. 30-day volume $6.21B on Solana (DefiLlama, 2026-05-16) against $254M TVL implies ~1.2x daily volume/TVL — high capital efficiency consistent with concentrated CLMM ranges. SOL/USDC pool is one of the deepest on Solana with 48.1% APY (high volume). Major pairs (SOL, USDC, JitoSOL, mSOL, BONK) carry strong depth. Graded yellow (not green) because: (a) 2%-slippage depth USD not enumerated from on-chain Solana pool state — volume/TVL ratio is a proxy only; (b) long-tail permissionless pools are thin by design; (c) CLMM liquidity can concentrate outside the active range during high-volatility events, transiently reducing effective depth. RD-F-072 yellow Market-listing governance threshold Applied in DEX-pool-creation context per phase-2 briefing pre-mark. Orca Whirlpools pool creation is fully permissionless: anyone can create a pool within an initialized WhirlpoolsConfig fee-tier space with no governance approval, DAO vote, or multisig action — confirmed by dev.orca.so documentation ('Whirlpools is set up such that anyone is able to set up a liquidity pool within a WhirlpoolsConfig space'). This enables: (a) creation of low-liquidity honey-pot or malicious-token pools visible on-chain; (b) thin-liquidity Whirlpool pools being consumed as TWAP oracle inputs by downstream protocols, creating price manipulation risk for those consumers (not for Orca itself). Mitigations: Orca UI displays a curated/verified pool list (users must deliberately access permissionless pools); fee tiers (9-14 on Solana, 0.01%-2.00%) are governance-controlled at the WhirlpoolsConfig level, not per-pool. Scored yellow (permissionless) per methodology categorical. RD-F-064 gray TVL concentration (top-10 wallet share) Orca Whirlpools LP positions are NFT-represented (Whirlpool position NFTs) distributed across thousands of position holders. No pipeline enumeration of top-10 LP concentration exists for Solana-native CLMM pools — standard subgraph/Dune EVM tooling does not cover Solana position NFT ownership. Structural argument: CLMM NFT-based positions are non-fungible and publicly visible; extreme concentration would be observable but has not been flagged by any public analysis. Not assessed due to pipeline data gap, not due to evidence of concentration. RD-F-066 n/a Utilization rate (lending protocols) Orca is a DEX/AMM with no lending markets. Cache confirms borrow.present=false. Utilization rate is a lending-protocol metric with no structural analog in a reserve-based CLMM. Not applicable per PD-024. RD-F-067 n/a Historical bad-debt events Orca is a DEX/AMM; bad-debt events are structurally impossible in a reserve-based AMM where no borrowing occurs. Not applicable per PD-024. Cache: borrow.present=false, hacks=[]. RD-F-068 n/a Collateralization under stress No collateral/borrow structure exists. Orca is a reserve-based CLMM DEX. Stress-collateralization simulation is inapplicable. Not applicable per PD-024. RD-F-069 n/a Algorithmic / under-collateralized stablecoin Orca does not issue a stablecoin. It is a token-swap DEX. Algorithmic/under-collateralized stablecoin classification is inapplicable. Not applicable per PD-024. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) RD-F-070 ★ CRITICAL — not_applicable. Orca Whirlpools is an original open-source Anchor/Rust CLMM on Solana; it is NOT a Compound V2 fork and has NO cToken-style market accounting, no totalSupply/totalBorrow market state, and no borrow-enable lifecycle. The donation-exploit vector (zero-supply cToken market + direct token donation inflating exchange rate) has no structural analog in Whirlpools' reserve-based pool accounting. Pre-marked not_applicable in the phase-2 briefing and consistent with PD-024 Compound-fork-only designation in the taxonomy. RD-F-071 n/a Seed-deposit requirement for new market listing Seed-deposit requirement for new-market listing is a lending-protocol concept (preventing borrow-before-supply attacks). Orca Whirlpools pool creation requires a funded wallet for Solana account rent (SOL), but this is a Solana runtime cost, not a borrow-enable seed deposit. No borrow-enable lifecycle exists. Not applicable per PD-024. RD-F-073 n/a Oracle-manipulation-proof borrow cap Orca has no borrow function and no per-asset borrow caps. No DEX-TWAP oracle is consumed in the swap execution path (reserve-based CLMM pricing). Not applicable per PD-024. Cache: oracle_feeds=[], borrow.present=false. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) Orca runs on Solana's SPL Token standard (non-EVM). There are no ERC-4626 vaults in the Whirlpools architecture. The ERC-4626 virtual-share offset pattern (OpenZeppelin >=4.9) is an Ethereum-specific mitigation with no Solana equivalent concept needed. Pre-marked not_applicable in the phase-2 briefing (no ERC-4626 vault — Solana SPL). Cache: non_evm_substrate=true. RD-F-075 n/a First-depositor / share-inflation guard Whirlpools uses reserve-based CLMM pool accounting with NFT position receipts, not an ERC-4626 share-based vault. LP value is computed from sqrt_price and tick ranges at redemption time, not from a share/totalAssets ratio. The first-depositor share-inflation attack vector (donating tokens to inflate share price before initial deposit) does not apply to this accounting model. Pre-marked not_applicable in briefing (Solana SPL, no ERC-4626). Cache: non_evm_substrate=true.
RD-F-063 green TVL (current + 30d trend) TVL $254.16M as of 2026-05-16 (DefiLlama cache, cross-checked live at $255.11M within 0.4%). Well above the $100M green floor. 30-day decline -6.93% is below the 20% yellow trigger. 90-day CoV = 0.033 (low volatility). 12-month peak ~$466M (Oct 2025); current is ~55% of peak — gradual compression, not a sudden drawdown. Chain split: Solana 99.81%, Eclipse 0.19%.
Operational history Green 9 15 of 15
RD-F-089 red Insurance coverage active No active insurance coverage found for Orca Whirlpools on Nexus Mutual, Sherlock, or Unslashed. Nexus Mutual protocol cover list and Sherlock protocol list do not include Orca. The bug bounty program is a disclosure/remediation mechanism, not insurance coverage. At $254M TVL, absence of insurance is a material structural gap. A secondary source (cryptonews.net) referenced 'multi-layered insurance' in the context of the Drift hack, but this appears editorial and is not confirmed by Orca's own documentation or primary insurance platform listings. Red threshold: no active coverage. RD-F-081 n/a Post-exploit response score No prior protocol exploits. Methodology specifies this factor is N/A (gray) when there are no prior incidents. The April 2026 Vercel frontend credential event did not involve an on-chain exploit and does not trigger F081. RD-F-082 n/a Post-mortem published within 30 days No prior protocol exploits. Methodology specifies gray (N/A) when there are no prior incidents — no post-mortem publication can be assessed. RD-F-083 n/a Auditor re-engaged after last exploit No prior protocol exploits. Methodology specifies gray (N/A) when there are no prior exploits — no post-exploit re-audit can be assessed. Note: Orca has conducted six proactive audits (Kudelski 2022, Neodyme 2022, OtterSec 2024, Sec3 x3 in 2025) but these are routine audits, not post-exploit re-audits. RD-F-085 n/a Incident response time (minutes) No prior protocol exploits; F085 measures on-chain exploit response time. The April 2026 Vercel frontend credential event is not an on-chain protocol incident and does not trigger F085. No exploit first-tx timestamp exists to measure response against.
RD-F-076 green Protocol age (days) Whirlpools CLMM deployed 2022-03-23 (~1,515 days at 2026-05-16, ~50 months). Original AMM v1 deployed 2021-02 (~63 months). Green threshold is >=365 days. Orca clears this by a large margin on both the Whirlpools basis and the protocol-origin basis.
RD-F-077 green Prior exploit count Zero protocol exploits found. In-house hacksdatabase grep for 'orca' and 'whirlpool' (case-insensitive) across ~190 incident files returned no matches. Data cache confirms defillama.hacks=[] and rekt.incidents=[]. Additional searches on rekt.news returned no Orca Whirlpools incidents. Green threshold: 0 prior exploits.
RD-F-078 green Chronic-exploit flag (≥3 incidents) Derived from F077: 0 incidents, far below the >=3 chronic-exploit red threshold. Green threshold: <3 incidents.
RD-F-079 green Same-root-cause repeat exploit Zero incidents on record; no same-root-cause repeat possible. Green threshold: no repeat root cause. Derived from F077 search results.
RD-F-080 green Days since last exploit No incidents on record. Methodology green threshold: >365 days OR no incidents. With zero incidents the green condition is satisfied by definition.
RD-F-084 green TVL stability (CoV over 90d) 90-day TVL CoV = 0.0329, mean $255.5M. Green threshold is CoV <0.15. TVL history spans from 2021-04 onward; 90-day window is fully populated. This is an exceptionally stable TVL profile consistent with a mature, high-liquidity DEX.
RD-F-086 green Pause activations (trailing 12 months) Whirlpools is a Solana BPF program (non-EVM) with no standardized Pausable mechanism. No pause events are on record. The protocol has been continuously live since launch. Green threshold: 0 pauses. Solana programs can be frozen by upgrade authority but this is a program-level action distinct from an EVM pause mechanism; no freeze has been executed on the Whirlpools program.
RD-F-087 green Pause > 7 consecutive days No pause events on record in the trailing 12 months or ever. Protocol has been continuously live since March 2022. Green threshold: no pause >7 consecutive days. Derived from F086 analysis.
RD-F-088 green Re-deployed to new addresses in last year The Whirlpools program (whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc) is upgraded in-place via BPFLoaderUpgradeable — no migration to a new program address has occurred. The original program ID has been in continuous use since March 2022. The v1 standard pool to Whirlpools migration predates the 12-month window and was market-driven, not a forced protocol redeployment. Green threshold: no full redeployment in last 12 months.
RD-F-166 green Deprecated contracts still holding value No deprecated Orca contracts with >$100K residual TVL identified. Pipeline coverage flag has_legacy_v1=false explicitly indicates no legacy v1 contract is tracked as holding material value. The Whirlpools program is a single live upgradeable program with no deprecated contract-level addresses announced by governance or docs. Individual pools with zero liquidity within Whirlpools are pool-state deprecated, not contract deprecated — the briefing explicitly notes parameter-level pool deprecation is NOT contract deprecation. Solana SPL Token delegation does not create EVM-style stale approvals. Green threshold: deprecated contracts hold $0 or have been self-destructed.
Real-time signals Green 4 22 of 22
RD-F-109 yellow Social-media impersonation scam spike Social-media impersonation scam spike. Orca has active social channels (X: @orca_so, Discord). Orca's own documentation explicitly warns: 'If someone messaged you first on Discord, they are likely an imposter' with a dedicated #scam-reports channel — indicating ongoing low-level impersonation noise consistent with yellow (1-2 accounts, normal DeFi background noise). No coordinated campaign (>=5 accounts or confirmed drain reports) identified. Below tier-red threshold. This is a C-tier signal (advisory only, never flips grade). RD-F-090 gray Mixer withdrawal → protocol interaction Mixer-withdrawal to protocol interaction signal. Applicable in principle on Solana (Solana-native mixer equivalents exist — Elusiv deprecated, Railgun minimal). No confirmed mixer-funded wallet interaction with Orca contracts in public data. Signal cannot be assessed in T-10 static mode without a configured Solana-native CTI feed and Helius/QuickNode protocol interaction indexer. No red-flag evidence in public data. RD-F-091 gray Partial-drain test transactions Partial-drain test transaction signal. Conceptually applicable to Solana Whirlpools pools. No exploit history for Orca means no retrospective pre-strike pattern has been documented; no reference pattern in the DB. On-chain pattern matcher not deployed for Orca pools in T-10 static context. RD-F-092 n/a Unusual mempool pattern from deployer wallet Unusual mempool pattern from deployer wallet. Structurally inapplicable per U10: Solana uses Gulf Stream transaction forwarding directly to validator leaders — there is no EVM-style pending mempool observable via standard RPCs. The Squads v4 upgrade authority (vault PDA GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV) has no observable mempool activity. Signal infrastructure is EVM-native and does not translate to Solana. RD-F-093 n/a Abnormal gas-price willingness from attacker wallet Abnormal gas-price willingness. Structurally inapplicable per U10: Solana uses compute unit price (priority fee) rather than EVM EIP-1559 gas mechanics. The ≥5× EMA gas baseline threshold concept does not translate to Solana's fee model. Signal is calibrated to EVM gas bidding infrastructure. RD-F-094 gray New contract with similar bytecode to exploit template New contract with similar bytecode to exploit template. Partially applicable on Solana (BPF program deployments can be scanned), but no Solana exploit-template index for Orca's instruction set exists in the standard tooling. No Orca exploit means no reference exploit-template in the canonical DB. Signal cannot be assessed without a Solana-native bytecode similarity index. RD-F-095 n/a Known-exploit function-selector replay Known-exploit function-selector replay. Structurally inapplicable per U10: Solana programs use Anchor instruction discriminators (8-byte hash-derived), not EVM 4-byte function selectors. No public equivalent of the Etherscan 4-byte signature database exists for Solana. The replay-template index is EVM-native and not applicable to Anchor/Rust programs. RD-F-096 n/a New ERC-20 approval to unverified contract from whale New ERC-20 approval to unverified contract from whale. Structurally inapplicable per U10: Orca operates on Solana with SPL Token (not ERC-20). The SPL Token delegate/approve model differs fundamentally from ERC-20 allowance: program-derived authority, no EOA-style approval event, no Etherscan contract verification status concept. RD-F-099 n/a Oracle price deviation >X% from secondary Oracle price deviation vs secondary source. Doubly inapplicable: (1) per U10, Solana oracle comparison infrastructure (Chainlink vs Pyth vs DEX TWAP cross-chain) is EVM-native; (2) structurally, Orca's swap path contains no external oracle at all — Whirlpools is a reserve-based CLMM where pricing derives from pool reserves (sqrt_price, tick state). F053 is green; F180 is N/A for Orca. No oracle hook exists. RD-F-100 n/a Flash loan >$10M targeting protocol tokens Flash loan >$10M targeting protocol tokens. Structurally inapplicable in EVM form per U10: Solana lacks EVM flash-loan infrastructure (Aave, Balancer, Uniswap V3 flash callbacks). Solana programs support atomic single-transaction composition but no standard flash-loan provider exists with the Aave/Balancer event model. The signal as specified is calibrated to EVM flash-loan mechanics and cannot fire on Solana. RD-F-102 n/a Admin/upgrade transaction in mempool Admin/upgrade transaction in mempool. Structurally inapplicable per U10: Solana has no EVM-style pending mempool. Squads v4 upgrade transactions (via the vault PDA GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV) are not observable via an EVM mempool listener. The Squads v4 on-chain event model uses transaction batching via multisig vault PDA — fundamentally different architecture from EVM admin/upgrade transaction flows. RD-F-103 n/a Bridge signer-set change proposed/executed Bridge signer-set change. Not applicable: Orca has no bridge surface. `has_bridge_surface: false`, `is_a_bridge: false` verified from briefing §7 and profile §3. Eclipse deployment is an independent native SVM program instance on the Eclipse chain — not an Orca-operated bridge endpoint. Cat 10 entirely N/A for Orca. RD-F-106 n/a Cross-chain bridge unverified mint pattern Cross-chain bridge unverified mint pattern. Not applicable: Orca has no cross-chain bridge (`has_bridge_surface: false`). Eclipse is a native SVM deployment, not an Orca-operated bridge endpoint. No cross-chain message bridge exists in Orca's protocol architecture. RD-F-107 gray Admin EOA signing from new geography/device Admin EOA signing from new geography/device. Requires off-chain signing telemetry and team opt-in. Additionally, Orca's admin is a Squads v4 multisig PDA (GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV), not an EOA — reducing the signal's applicability further. This factor is practically gray for all protocols that have not opted into signing telemetry. RD-F-182 n/a Security-Council threshold reduction (RT) Security-Council threshold reduction (RT). Structurally inapplicable per U10: F182 monitors EVM Safe/Gnosis ChangedThreshold/RemovedOwner/AddedOwner events. Orca uses Squads v4 on Solana — not EVM Safe. The conceptual analog (Squads v4 multisig member change or threshold reduction) is a valid concern for the 3-of-10 configuration (GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV), but the batch-24 signal specification requires EVM Safe/Gnosis event monitoring which does not apply to Solana. The Squads v4 current config is 3-of-10 with 24h timelock (on-chain verified) — no threshold reduction events identified.
RD-F-097 green Sybil surge of identical-pattern transactions Sybil surge of identical-pattern transactions. Applicable on Solana via Solana tx indexers. No documented sybil campaign targeting Orca pools as of 2026-05-16. Permissionless pool creation creates a surface where sybil-like pool manipulation could occur, but no current signal firing. Signal not firing.
RD-F-098 green TVL anomaly — % drop in <1h TVL anomaly — % drop in <1h. TVL $254.16M as of 2026-05-16T02:14:01Z. 90-day mean $255.5M (CoV 0.033 — very stable). 1d change -3.22% (market range). 30d change -6.93% (mild downtrend). Current TVL / 30d baseline ≈ 0.995 — far above the 0.70 tier-A fire threshold. No sector-wide Solana TVL collapse event observed. Signal not firing.
RD-F-101 green Large governance proposal queued Large governance proposal queued. Orca uses Realms (SPL Governance) for token-holder governance; Squads v4 3-of-10 with 24h timelock for upgrade authority. Most recent completed proposals: ORCA treasury buyback program (executed Aug 2025), governance program v3.1.1 upgrade (completed). No malicious-pattern proposal (admin-change, delegatecall, threshold-reduction payload) currently queued in Realms as of 2026-05-16. Signal not firing.
RD-F-104 green Stablecoin depeg >2% on shared-LP venue Stablecoin depeg >2% on shared-LP venue. Orca is a DEX with stable pool pairs (USDC, USDT, others). Orca does not hold stablecoin collateral internally — pool LPs bear individual depeg risk. No major stablecoin depeg active as of 2026-05-16. USDC and USDT maintain pegs. Signal not firing. Note: Orca's DEX-only architecture means the signal has lower severity than for lending protocols with direct collateral dependency.
RD-F-105 green DNS/CDN/frontend hash drift DNS/CDN/frontend hash drift. orca.so is the live frontend; dev.orca.so is developer docs. No known DNS attack, CDN compromise, or frontend hash drift for orca.so in public sources as of 2026-05-16. No incident reported in research. No CertStream or PhishFort alerts for orca.so surface identified in public search. Signal not firing.
RD-F-108 green GitHub force-push to sensitive branch GitHub force-push to sensitive branch. Repository orca-so/whirlpools is public. GitHub last commit 2026-05-14 (cache). No force-push incidents documented in public sources. Normal active development commit cadence. No unauthorized pusher events identified. Signal not firing.
RD-F-110 green Unusual pending/executed proposal ratio Unusual pending/executed governance proposal ratio. Orca uses Realms on-chain governance. Recent proposals reviewed: treasury buyback program (Aug 2025, executed), governance program v3.1.1 (executed). No anomalous proposal queue ratio vs. trailing 30-day baseline identified. Standard DEX governance cadence — routine treasury and upgrade management. Signal not firing.
Dev identity & insider risk Green 0 16 of 16
RD-F-117 n/a ENS/NameStone identity bound to deployer Orca is a Solana-native protocol (non-EVM substrate). ENS (Ethereum Name Service) and NameStone operate exclusively on Ethereum L1 and have no registry, resolver, or deployment on Solana mainnet. There is no architectural path by which a Solana program or keypair can have a bound ENS name. This factor is structurally inapplicable due to substrate incompatibility — not due to data absence. RD-F-184 gray Real-capital social-engineering persona No curator-flagged social-engineering persona matching the RD-F-184 pattern (≥$1M real-capital deposits to build credibility ahead of attack) has been identified for Orca. The reference pattern is Drift Protocol Apr 2026 (UNC4736, 6-month in-person build-up + real capital). Orca's open-source, non-custodial CLMM architecture presents a different attack surface. Absence of a detected pattern cannot confirm absence: this threat class is by design traceless at the reconnaissance stage and requires ongoing OSINT monitoring across contributor and integrator personas. Scored gray pending ongoing curator monitoring; gap_reason is requires_curator_input.
RD-F-111 green Team doxx status Co-founders Grace Kwan (Ori) and Yutaro Mori (rawfalafel) are real-name doxxed with verifiable prior professional histories. Kwan: Stanford BS/MS CS, Coursera SWE, IDEO Tokyo interaction designer; publicly named in media since at least 2021. Mori: Eth 2.0 Golang client contributor, UMA Protocol engineer; public LinkedIn + podcast appearances. Initially launched pseudonymously as 'YM' and 'Ori' in Feb 2021; progressive disclosure to full real-name since. Core governance council members include named professionals (Lakshman Sankar, Chris Montagano, Hart Lambur, Min Teo, Larry Sukernik) plus one community pseudonym (Cortina).
RD-F-112 green Team public accountability surface Both co-founders have ≥4 distinct verifiable public trails. Grace Kwan: LinkedIn with employment history, Stanford academic record, Coin Rivet named video interview, Solana Foundation podcast (Validated Ep #46), logo design attribution. Yutaro Mori: LinkedIn, GitHub (Eth 2.0 Golang, UMA contributions), YouTube podcast appearances, named in CoinDesk funding coverage. Michael Hwang (tmoc): LinkedIn + GitHub. Each core team member exceeds the green threshold of ≥3 trails.
RD-F-113 green Team other-protocol involvement history Yutaro Mori: prior contributor to Ethereum 2.0 Golang client (legitimate, successful); engineer at UMA Protocol (legitimate DeFi protocol). Grace Kwan: Coursera SWE, IDEO Tokyo interaction designer — non-crypto legitimate employers. No team member linked to prior rug or exit scam in Rekt DB, DefiLlama hacks DB, or comprehensive OSINT search. Three Arrows Capital (2021 investor, not a team member) collapsed in 2022 — investor failure with no bearing on team identity or misconduct scoring.
RD-F-114 green Deployer address prior on-chain history Whirlpools program (whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc) deployed 2022-03-23 on Solana mainnet; AMM v1 launched Feb 2021. The original deploy authority was subsequently transferred to the Squads v4 vault PDA (GwH3Hiv5mACLX3ufTw1pFsrhSPon5tdw252DBs4Rx4PV), verified on-chain. Orca was bootstrapped via Solana Foundation grant; no deployer address linked to prior rug in any CTI source. Normal dev history: open-source repo, 4+ years of continuous commits, 6 audit engagements. Solana does not expose a traditional EVM-style deployer EOA with a separate funding trail; the program deploy keypair was used once and authority transferred — consistent with best practice.
RD-F-115 green Prior rug/exit-scam affiliation No rug or exit-scam affiliation found for any Orca team member. Rekt DB (cache): no Orca incidents. DefiLlama hacks (cache): empty. OSINT search across multiple queries for 'Yutaro Mori rug', 'Grace Kwan rug', 'rawfalafel prior project', 'Ori Kwan exit scam': no positive results. OFAC SDN search: no Orca team member entries. Three Arrows Capital (investor): collapsed 2022, but TAC was a passive investor — no team affiliation.
RD-F-116 green Contributor tenure at admin-permissioned PR The orca-so GitHub org has been active since Feb 2021 with continuous core-contributor activity. The orca-so/whirlpools repo shows last commit 2026-05-14 (cache). Multiple Sec3 audit engagements in 2025 (Feb, Jun, Aug) imply that program-level code changes are gated by an audit review process, functionally providing a strong structural control equivalent to tenure requirements. A formal per-PR contributor-tenure calculation was not possible in this run (GitHub API not called); assessed green based on the org's 4+ year continuous history and audit-gated change discipline.
RD-F-118 green Handle reuse across failed/rugged projects No handle reuse across prior rugged or failed projects detected. '@orca_so' on X/Twitter has been in continuous use under the same identity since 2021 launch. 'rawfalafel' (Yutaro Mori) used continuously for this same identity; 'Ori' (Grace Kwan) likewise. OSINT search found no archived association of these handles with prior failed/rugged protocols. The 'tmoc' handle (Michael Hwang) similarly shows no reuse pattern.
RD-F-119 green Commit timezone consistent with stated geography Orca team is US-based (San Francisco area context: Coursera is Mountain View CA; IDEO has SF/Tokyo offices; Solana Foundation ecosystem is US-centric). Public interviews conducted in English at US-compatible hours. No commit-timezone anomaly (DPRK UTC+9 precursor pattern) has been reported by any security researcher across the 4+ year public development history. Formal commit-hour histogram analysis was not performed in this run; assessed green based on absence of any anomaly flag in any CTI or security research publication.
RD-F-120 green Video-off/voice-consistency flag Grace Kwan (Ori) has on-camera video appearances: exclusive Coin Rivet interview (video format) and Solana Validated Ep #46 (YouTube/podcast with visual). Yutaro Mori has on-camera appearances: YouTube EP #74 co-founder interview (youtube.com/watch?v=1Uq9IsH0TBE). Both co-founders show consistent visual and voice identity across ≥2 public appearances spanning multiple years. No video-declination or identity inconsistency flagged by any observer.
RD-F-121 green Contributor OSINT depth score OSINT depth scoring per team member: Grace Kwan — LinkedIn with employment history (Coursera, IDEO), Stanford academic record, named media interviews, logo design attribution, podcast/video appearances = 5/5. Yutaro Mori — LinkedIn, GitHub with aged contribution history (Eth 2.0 client, UMA), podcast/video appearances, CoinDesk named coverage = 5/5. Michael Hwang (tmoc) — LinkedIn + GitHub = 3/5. Average score ≥4 across core team. Governance Council includes Lakshman Sankar (0xParc founder), Chris Montagano (named general counsel), Hart Lambur (UMA founder) — each independently verifiable.
RD-F-122 green Contributor paid to DPRK-cluster wallet No public CTI report (Chainalysis, TRM Labs, OFAC) links any Orca contributor payment path to a DPRK/Lazarus cluster wallet within 3 hops. Individual contributor wallet addresses are not publicly disclosed by Orca, preventing direct on-chain hop-count traversal. Assessed green based on: (1) absence of any positive signal across comprehensive CTI/OSINT search; (2) co-founders' fully public professional histories with no DPRK linkage; (3) no OFAC entry for any team member. The gap in contributor wallet disclosure is noted as a protocol opacity item.
RD-F-123 green Sudden admin-rescue/ACL change without discussion All Whirlpools program upgrades must pass through the Squads v4 multisig (3-of-10, 86400s = 24h on-chain timelock) — pipeline-verified. The 24h timelock is genuine (not a documentation claim). Governance Council changes are deliberated via forums.orca.so proposals with public comment periods and on-chain Realms tokenholder votes with veto windows. No evidence of sudden ACL changes executed without preceding public discussion. The governance forum (forums.orca.so) maintains a public, indexed record of proposals dating from 2022, and on-chain Realms proposals (governance.orca.so) provide additional auditability. Contrast with Drift Protocol comparator (RD-F-182 class): Orca's timelock is genuine and the access-control change process is public.
RD-F-124 green Deployer wallet mixer-funded within 30 days No mixer funding of the Whirlpools deployer or upgrade authority observed. Tornado Cash is Ethereum-native with no Solana deployment; no analogous Solana mixer is linked to any Orca wallet. Protocol-level funding provenance: Solana Foundation grant (bootstrapping, publicly documented), followed by Sep 2021 $18M Series A from Coinbase Ventures, Polychain Capital, Jump Trading, and others — all institutional/CEX-traceable sources. No CTI report or on-chain trace (Chainalysis, TRM Labs, OFAC, or Solscan) links any Orca privileged address to a mixer withdrawal within 30 days of any deploy event. Applies across the Feb 2021 AMM v1 deploy and the Mar 2022 Whirlpools CLMM deploy.
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No path ≤3 hops from any identified Orca privileged address to a DPRK/Lazarus-labeled cluster found. Co-founders (Grace Kwan, Yutaro Mori) have fully public professional identities with no OFAC or CTI DPRK linkage. OFAC SDN search: no Orca team member or protocol authority listed. TRM Labs and DPRK-focused OFAC actions (Jul 2025, Feb 2026) do not mention Orca team members. U4 rule applied: if DPRK entities use Orca pools as a wash-trading venue (permissionless DEX risk), that adversarial-venue-use routes to Cat 11 (F158 yellow) — it does NOT contaminate team-level DPRK proximity. This factor assesses deployer/team proximity, not protocol venue use, and remains green.
Fork / dependency lineage Green 0 10 of 10
RD-F-126 n/a Is-a-fork-of Orca Whirlpools is an original Anchor/Rust Solana program, not a fork of any upstream protocol. GitHub repo (github.com/orca-so/whirlpools) shows no fork relationship. Founded by Grace Kwan and Yutaro Mori as an original protocol starting Feb 2021. The mathematical approach (tick-spacing, sqrt-price CLMM) is conceptually informed by Uniswap v3 design principles but is an independent Rust implementation for SVM. No bytecode similarity measurement applicable (non-EVM, different runtime). No upstream fork to identify. RD-F-127 n/a Upstream patch not merged Not applicable — no upstream fork identified (see F126). No upstream protocol whose patches could be unmerged. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) Not applicable — no upstream fork identified (see F126). No upstream protocol to track security disclosures for. RD-F-129 n/a Code divergence from upstream (%) Not applicable — no upstream fork identified (see F126). Code divergence measurement requires an upstream codebase to diff against. RD-F-130 n/a Fork depth (generations from original audit) Not applicable — original protocol, not a fork. Fork depth is definitionally 0 (origin point); this factor measures risk from multi-generation forking which does not apply. RD-F-131 n/a Fork retains upstream audit coverage Not applicable — no upstream fork. Orca has its own independent audit coverage (6 engagements from 4 firms). The question of retaining upstream audit coverage does not apply when the protocol is the original. RD-F-132 n/a Fork has different economic parameters than upstream Not applicable — no upstream fork. Economic parameter comparison requires an upstream codebase with audited default parameters.
RD-F-133 green Dependency manifest uses unpinned versions All dependencies in programs/whirlpool/Cargo.toml use strict = version pinning with no ^ or ~ prefixes on any dependency, including security-critical ones: anchor-lang = "=0.32.1", anchor-spl = "=0.32.1", solana-program = "=2.2.1", pinocchio = "=0.9.2", borsh = "=0.10.4", bytemuck = "=1.22.0". This is the strongest possible dependency pinning. Cargo workspace uses resolver = "2" with exact version enforcement.
RD-F-134 green Dependency had malicious-release incident (last 90d) No GHSA/crates.io advisories found for the Rust crates used (anchor-lang 0.32.1, solana-program 2.2.1, pinocchio, borsh, bytemuck, arrayvec, etc.) involving malicious releases in the trailing 90 days (2026-02-16 to 2026-05-16). The two active Anchor GHSA advisories (GHSA-429q, GHSA-c6rc, published 2026-05-07/08) are design vulnerability disclosures affecting anchor-lang 1.0.0+ only, not malicious supply-chain releases, and Orca uses 0.32.1. The solana-web3.js malicious release (Dec 2024, GHSA-jcxm-7wvp-g6p5) affected JavaScript tooling only, not the on-chain Rust program.
RD-F-135 green Shared-library version with known-vuln status Key shared library versions: anchor-lang 0.32.1, anchor-spl 0.32.1, solana-program 2.2.1. Two active GHSA advisories for anchor-lang: GHSA-429q-fhh4-r6hj (Critical — InterfaceAccount type substitution, affects 1.0.0-rc.1 only, fixed in 1.0.0-rc.2) and GHSA-c6rc-8jpp-2fgc (High — Program<System> validation, affects 1.0.0+, fixed in 1.0.2). Both explicitly affect the 1.0.x release series only. Orca uses anchor-lang 0.32.1 (the 0.x series) which is NOT in the affected version range for either advisory. No active advisories found for solana-program 2.2.1, pinocchio, borsh, or other pinned crates.
Post-deploy hygiene & change mgmt Green 13 13 of 13
RD-F-137 yellow Upgrade frequency (per 90 days) Active development cadence: TokenExtensions (May 2024), OtterSec-audited build (Aug 2024), Dynamic Tick Arrays and Liquidity Locking (2025 Q1), three Sec3 audits in 2025 (Feb, Jun, Aug). Each upgrade goes through the Squads v4 24h timelock. Estimated 2-4 upgrades per 90 days over the past year. Per methodology: yellow = 3-5 upgrades per 90d. High upgrade cadence is well-matched by audit frequency (three audits in 2025). RD-F-139 yellow Post-audit code changes without re-audit Six audit engagements: Kudelski (2022-01), Neodyme (2022-05), OtterSec (2024-08), Sec3 (2025-02, 2025-06, 2025-08). GitHub commits in Jan-Feb 2026 show post-audit code changes (adaptive fee constants, slippage precision, reposition liquidity instruction, idempotent token account creation) after the last audit (Aug 2025). Estimated <200 LOC in new instructions/changes. Yellow not red: open-source codebase, three Sec3 audits in 2025 demonstrate strong re-audit cadence, changes are functional extensions not security-core rewrites, 9-month gap is meaningful but not unusually long for an active protocol. RD-F-136 gray Deployed bytecode matches signed release tag Orca uses GitHub release tags with semver. Bytecode-to-release-tag matching requires anchor verify comparison between the on-chain deployed program hash and the compiled artifact from the tagged commit. Not performed in this session. Pipeline-unimplemented for Solana BPF programs. RD-F-142 n/a Storage-layout collision risk across upgrades Solana BPF programs use account-based state with Anchor discriminators — there is no Solidity storage-slot model. Storage layout collision between upgrade versions is not a risk class on Solana. N/A by architecture. RD-F-143 n/a Reinitializable implementation (no _disableInitializers) BPFLoaderUpgradeable programs on Solana do not use an initialize()+proxy pattern. The _disableInitializers() guard is specific to EVM OpenZeppelin UUPS/Transparent proxies. Structural N/A for non-EVM architecture. RD-F-144 n/a CREATE2 factory permits same-address redeploy Solana does not use CREATE2. Program addresses are derived from the BPFLoaderUpgradeable PDA scheme. No selfdestruct+redeploy-to-same-address pattern possible on Solana. N/A by architecture. RD-F-145 gray Deployed bytecode reproducibility Orca publishes build instructions and uses Anchor framework with pinned versions. Anchor programs are deterministically compilable via anchor build from source + Anchor.toml. Specific bytecode reproducibility verification (anchor verify against deployed program) not performed in this session. Pipeline-unimplemented for Solana. RD-F-146 n/a New contract deploys in last 30 days The factor measures new deployer-address contract deploys. Orca is a single-program architecture on Solana; pool accounts are PDAs created by user interactions (not new deployer-address contract deploys). Program upgrades to the single Whirlpool program are tracked under F137. Etherscan txlist for deployer address does not apply to Solana. N/A by architecture. RD-F-168 gray Stale-approval exposure on deprecated router Legacy Orca AMM v1 was deprecated Q1 2023. SPL Token approve() on Solana grants per-account delegate authority (not ERC-20 allowances). Residual SPL token delegate approvals to the legacy program cannot be enumerated without on-chain indexer scan of approve() events for legacy program addresses. Addresses of legacy program not retrieved in this session. Pipeline-unimplemented for Solana SPL approval scanning. RD-F-185 n/a Bridge rate-limiter / chain-pause as positive mitigant Orca is not a bridge. has_bridge_surface=false, is_a_bridge=false. Eclipse deployment is a native SVM program instance, not a bridge endpoint. Rate-limiter and chain-pause mitigant factors are not applicable. N/A by protocol type.
RD-F-138 green Hot-patch deploys without timelock (last 30 days) Squads v4 enforces the 24h on-chain timelock on all upgrade transactions — there is no bypass mechanism in the multisig config. No hot-patch executed without timelock found in the last 30 days. The time_lock field is enforced at the protocol level, not policy-only.
RD-F-140 green Fix-merged-but-not-deployed gap No known undeployed security fix found. Immunefi program is active with no open critical advisories publicly visible. No open GitHub security-fix PRs identified. No post-mortem references to merged-but-undeployed fixes.
RD-F-141 green Test-mode parameters in deploy Whirlpool program uses Anchor declare_id! with production program ID (whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc). No test-oracle addresses, infinite allowance patterns, or admin=deployer-EOA configuration applicable. Production WhirlpoolConfig is initialized through governance-controlled initialization instructions. No test-mode parameters identified.
Cross-chain & bridge Gray 0 12 of 12
RD-F-147 n/a Protocol has bridge surface Orca operates no bridge surface. Eclipse deployment (0.19% TVL) is an independent SVM L2 native deployment of the same Whirlpools program — it is not a protocol-operated bridge endpoint. Assets on Eclipse are bridged by users via Eclipse's own infrastructure. has_bridge_surface: false, is_a_bridge: false (profile §7). Cache coverage_flags.layerzero_bridge: false, sources.layerzero.present: false. RD-F-148 n/a Bridge validator count (M) No bridge surface operated by Orca. Bridge validator count is not applicable. See F147 for architectural basis. RD-F-149 n/a Bridge validator threshold (k-of-M) No bridge surface. Bridge validator threshold (k-of-M) not applicable. See F147. RD-F-150 n/a Bridge validator co-hosting No bridge surface. Bridge validator co-hosting not applicable. See F147. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) No bridge surface. Solana programs do not use ecrecover (Solana uses ed25519 / secp256k1 via syscall, not the EVM ecrecover opcode pattern). The Wormhole-class ecrecover zero-address check is not applicable to Orca's architecture. See F147. RD-F-152 n/a Bridge binds message to srcChainId No bridge surface. Bridge srcChainId binding not applicable. See F147. RD-F-153 n/a Bridge tracks nonce-consumed mapping No bridge surface. Bridge nonce-consumed mapping not applicable. See F147. RD-F-154 n/a Default bytes32(0) acceptable as valid root No bridge surface. Solana does not use bytes32 Merkle roots in the EVM sense. The Nomad-class default-value acceptable root pattern is an EVM-specific failure mode and architecturally inapplicable to Orca's Solana CLMM AMM with no bridge surface. See F147. RD-F-155 n/a Bridge validator-set rotation recency No bridge surface. Bridge validator set rotation recency not applicable. See F147. RD-F-156 n/a Bridge uses same key custody for >30% validators No bridge surface. Bridge key custody concentration not applicable. See F147. RD-F-157 n/a Bridge TVL per validator ratio No bridge surface. Bridge TVL per validator ratio not applicable. See F147. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) No LayerZero OFT integration. Data cache sources.layerzero.present: false, coverage_flags.layerzero_bridge: false. Orca Whirlpools is a Solana SVM AMM with no cross-chain messaging layer. Eclipse deployment is a native SVM program instance, not a LayerZero OFT adapter. DVN configuration assessment is not applicable. See F147.
Threat intelligence & recon Green 11 8 of 8
RD-F-158 yellow Known-threat-actor cluster has touched protocol Known-threat-actor cluster has touched protocol. Per U4 instruction: Lazarus Group (DPRK) is confirmed to have used Solana DEX infrastructure for laundering funds post-Bybit hack (February 2025, $1.5B). TRM Labs and ZachXBT documented 920+ laundering addresses and Solana DEX/Pump.fun routing. Orca is the second-largest Solana DEX by TVL ($254M) with permissionless pool creation — class-level evidence of adversarial-venue-use for Solana DEX ecosystem. No specific confirmed, publicly-attributed interaction of a named Lazarus cluster address with Orca contracts found in available public reports (Chainalysis, TRM, ZachXBT). Scored yellow per U4 (adversarial-venue-use basis; specific pool interaction not confirmed). This signal is a venue-use flag, NOT team contamination (dev-identity-analyst scope, F125). RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) Attacker wallet pre-strike probe (low-gas failing txs). Applicable in principle on Solana (failed transactions from CTI-flagged wallets to Orca program). No pre-strike probe pattern identified in public sources. CTI feed + Solana-native failed-tx monitoring not configured for T-10 static run. No Orca exploit history means no retrospective pre-strike pattern documented. RD-F-161 gray Protocol-impersonator domain registered (typosquat) Protocol-impersonator domain registered (typosquat). Official domain: orca.so. 90-day window: 2026-02-15 to 2026-05-16. Orca's documentation confirms ongoing Discord impersonation noise. No specific typosquat of orca.so (e.g., orca-so.com, orcaso.io, whirlpools-app.io) identified in public search. CertStream/PhishFort live domain monitoring feed not configured for T-10 static run. Cannot compute registration-date-to-2026-05-16 delta for any lookalike domain without live monitoring data. Gap_reason: pipeline_unimplemented for domain monitoring feed. RD-F-162 gray Known-exploit-template selector deployed by any address Known-exploit-template selector deployed by any address. Solana exploit-template index not maintained for Orca Whirlpools' instruction discriminator set. No known Orca exploit means no reference exploit-template in canonical DB. BPF program deployment scanning would require a Solana-native discriminator pattern index. Etherscan-equivalent scan infrastructure not available. RD-F-164 gray Leaked credential on paste/sentry site Leaked credential on paste/sentry site. No leaked credential incident for Orca infrastructure identified in public sources. SECURITY.md directs to Immunefi. No HaveIBeenPwned-style public report of credential dump for orca.so or dev.orca.so. Paste monitoring feed (PasteHunter/GitHub secret scanner continuous) not executed in T-10 static run. RD-F-165 gray Protocol social channel has scam-coordinator flag Protocol social channel has scam-coordinator flag. Orca has Discord and X. Orca's docs confirm ongoing Discord impersonation noise (scam-reports channel active), but this is generic bot/scam activity consistent with any major DeFi protocol. No protocol-adjacent channel admin confirmed on a curator scam-coordinator watchlist. Curator social watchlist not configured for T-10 static run.
RD-F-160 green GitHub malicious-dependency incident touching protocol deps GitHub malicious-dependency incident touching protocol deps. Orca's orca-so/whirlpools is public. Dependencies: Anchor framework (Rust), SPL Token program, SPL Token-2022, standard Rust crates. No active GHSA advisory targeting Anchor framework or Orca's Rust dependencies identified in public data as of 2026-05-16. No malicious npm or crate release advisory for Orca's specific dependency set found.
RD-F-163 green Avg attacker reconnaissance time for peer-class protocols Avg attacker reconnaissance time for peer-class DEX protocols. Class-level statistic from hack DB. For DPRK-class attacks on large Solana DEXes, reconnaissance windows of weeks-to-months are consistent with the evidence: USPD pattern (78 days), Drift Protocol (weeks of insider preparation before $285M exploit), Bybit (months of social engineering). For DEX-class protocols generally, reconnaissance >= 30 days is consistent with the evidence. Green threshold (>=30 days) is met for this class.
Tooling / compiler / AI Green 0 5 of 5
RD-F-170 n/a Solc version used (known-bug versions flagged) Solc (Solidity compiler) is not used. Orca Whirlpools is written in Rust 2021 edition targeting BPF/SBF (Solana Bytecode Format). Anchor 0.32.1 is the framework version; it is on the actively maintained 0.x series. Two active GHSA advisories for Anchor affect only the 1.0.0+ release series, not 0.32.1. No Solidity compiler; no solc known-bug list applicable. Rust 2021 edition is current and supported. RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation Bytecode similarity to audited EVM upstream is not applicable. Orca is an original Solana/Rust protocol with no EVM upstream to compare BPF bytecode against. The conceptual similarity to Uniswap v3 design is at the algorithm level only, not at the bytecode level. EVM bytecode diff tools cannot operate on Solana BPF/SBF programs. RD-F-173 n/a Team self-disclosure of AI-generated Solidity This factor measures team self-disclosure of AI-generated Solidity in production. Orca does not use Solidity — the codebase is Rust/Anchor. The Rust analog (AI-generated Rust in security-critical on-chain program paths) also shows no evidence from team blog posts, Medium articles, or developer documentation. Factor is not applicable for the Solidity-specific framing; the Rust analog is scored green under F172. RD-F-174 n/a Dependency tree uses EOL Solidity version Solidity is not used; EOL Solidity version risk does not apply. Rust 2021 edition is current and actively maintained. Anchor 0.32.1 is on the actively maintained 0.x series. No EOL language runtime concern applicable to this substrate.
RD-F-172 green Repo shows AI-tool co-authorship in critical files Reviewed recent GitHub commit history for orca-so/whirlpools. Last 5 commits (2026-05-14 to 2026-05-01) show normal developer commit messages with no AI-tool co-authorship trailers (no 'Co-authored-by: GitHub Copilot' or equivalent). The repository is public and commit metadata is auditable. Web search for AI co-authorship in orca-so/whirlpools returned no hits. No public disclosure by team of AI-generated code in security-critical Rust paths. Recent commits ('TypeScript SDK updates for immutable whirlpools', 'Add support for dynamic program_id to rust SDK') appear to be normal developer output.
Response & disclosure hygiene Green 8 4 of 4
RD-F-176 yellow Disclosure SLA public No acknowledgment-time SLA is stated on the Immunefi program page or in SECURITY.md. Immunefi's platform imposes SLA enforcement (projects can be removed for SLA breakage), providing an implicit framework, but Orca has not published its own explicit acknowledgment window (e.g., '48h ack'). Yellow threshold: SLA stated but not tested or >72h. Absence of an explicit published SLA places this in yellow rather than green.
RD-F-175 green Disclosure channel exists Immunefi program is active (immunefi.com/bug-bounty/orca, live since 2022-05-19, last updated 2026-01-08). SECURITY.md in repo routes researchers directly to Immunefi. Program funded by passed governance vote (1M ORCA allocation). The 2026-01-08 last-update timestamp confirms active maintenance. Green threshold: public disclosure channel exists and is actively monitored.
RD-F-177 green Prior known-ignored disclosure No prior protocol incidents exist, so no post-mortem can document a received-but-not-actioned disclosure. No public security researcher disclosures citing ignored reports against Orca found in OSINT searches. Green threshold: no evidence of ignored disclosure.
RD-F-178 green CVE/GHSA advisory issued against protocol No CVE or GHSA advisory found against Whirlpools protocol or orca-so/whirlpools GitHub repository. GitHub Security Advisories for orca-so/whirlpools shows no public advisories. NVD CVE search for 'orca whirlpools' returns no results. Green threshold: no advisory or all advisories patched.
rubric_version v1.7.0 graded_at 2026-05-16 12:11:59 factors 184 protocol orca