SuperEarn Web & Smart Contracts: Program info

Crosschain & bridge accounting

• Unauthorized cross-chain message authorship, replay, or reordering with financial impact
• Bridge accounting drift in BridgeAccountant — over-/under-counting of assetsInTransitOutbound() / assetsInTransitInbound() (and the per-vault helpers OriginVault.assetsInTransitToRemote() / RemoteVault.assetsInTransitToOrigin()), double-credit, or missed SYNC_BRIDGED reconciliation in the _awaitingAssetQueue. Important — the eligibility perspective for crosschain accounting findings is the Kaia (OriginVault) view, not the Ethereum (RemoteVault) view. RemoteVault is intentionally not required to track Kaia-side balances in real time: in-transit assets (e.g., a Kaia → Ethereum bridge that has already been credited on Kaia’s side but has not yet been deducted on Ethereum, or vice versa) can transiently make RemoteVault.totalAssets() look “inflated” relative to the eventual reconciled state. Findings are bug-eligible only when the inconsistency manifests as a sudden, material change on the OriginVault side (e.g. abrupt jumps in OriginVault.totalAssets(), OriginVault.remoteAssets(), or share-price during the same block / next round-trip). See SE-P23 below for the full eligibility rule.
• Reordering or nonce manipulation on CrosschainAdapter outbound / inbound queues with demonstrable financial impact. There is intentionally no per-message signature scheme — authentication is provided exclusively by Chainlink CCIP’s source-chain selector + the RunespearProtocol envelope verification + the adapter-only entry gate (OnlyAdapter). Reports framed as “the protocol does not sign individual messages” / “a signature scheme is missing” are OOS as design preference. Eligible findings must show a concrete path that bypasses the layered authentication and produces a double-credit / drain / freeze.
• Spoofed inbound bridge accounting via _processBridgeReceived / forceProcessBridgeReceipt that bypasses BridgeAccountant invariants (the _awaitingAssetQueue reconciliation, BridgeQueue library nonce tracking). Note: CrosschainAdapter.onBridgeReceived(...) itself currently revert NotImplemented() and is dead code — the Rhino bridge service does not call into the adapter; deposit detection is balance-based via SYNC_BRIDGED + _tryProcessBridgeNotification. Reports targeting onBridgeReceived as an attack surface, or arguing “the callback is broken / always reverts”, are OOS unless a PoC demonstrates a reachable code path through onBridgeReceived in the current deployed bytecode.

Vault entry / exit accounting

• Stealing or loss of user funds across the CooldownVault (Kaia) → Yearn → StrategyOriginVault → OriginVault flow (the user-facing SuperEarnRouter (Kaia) is OOS — see “Out of Scope — Contracts” — and router-resident defects are evaluated only when they propagate into CooldownVault accounting per the 3-condition rule)
• Whitelist or access-control bypass on OriginVault / RemoteVault / CooldownVault / CustomVault
• Share-supply manipulation breaking the 1:1 invariant in CooldownVault
• FIFO claim-reservation bypass in CooldownVault / OriginVault redemption queues
• predeposit / retrieveDebt accounting bug that leaves debt unrepayable or double-paid
• CustomVault.totalAssets() mispricing through the registered ICustomStrategy aggregation path (the registered providers themselves are out of scope, but accounting bugs in CustomVault’s aggregation are in scope)
• RemoteVault.totalAssets() mispricing or _calculateCustomStrategyAssets() accounting drift driven by an in-vault bug (not by a defect in the registered, OOS, custom-strategy implementation)
• StrategyOriginVault.estimatedTotalAssets() / prepareReturn() / liquidatePosition() mispricing that propagates a wrong harvest P&L into the Kaia Yearn vault.

Common surfaces

• Reentrancy across vault → bridge → vault and router → vault → strategy boundaries that produces concrete fund-loss / accounting-drift on an in-scope contract. Generic “function X is missing nonReentrant” reports against user-facing or operator-only paths are covered by SE-P12 and SE-P14 respectively and are OOS without a reachable exploit PoC.
• Decimal handling errors in the in-scope conversion paths (USDT 6-decimal ↔︎ 18-decimal OriginVault share token; the USDT/USDC conversion glue in RemoteVault.totalAssets() / _calculateCustomStrategyAssets(); share/asset conversion in CustomVault) that produce a reproducible token-unit drift. 1-wei dust, view-only stale reads, or hypothetical “if a non-stablecoin / non-6-decimal asset were added” framings are OOS (see SE-P13 / SE-P15 and the Category Medium criteria).
• Storage-collision or initialization issues in upgradeable proxies. __gap sizing alone (SE-P10) and “anyone can call initialize() on an already-initialized proxy” (SE-P7) are OOS — eligible reports must demonstrate a concrete storage collision under a realistic upgrade path, or an initialize() front-run against a not-yet-initialized fresh deployment.
• Rounding / over-/underflows where the PoC demonstrates a token-unit loss to a user / treasury / in-scope contract, sized at or above the Category Medium threshold (see the Severity Classification tables). Reports claiming “1-wei rounding compounds over time” without a PoC that materialises a concrete cumulative loss on the current code are OOS.
• USDOKycedCA mint/redeem queue manipulation (Kaia) that produces a real token-unit mismatch. The USDC↔︎USDT variable-naming inheritance from OpenEden’s API (SE-P19) and the intentional CEI deviation in claim() (SE-P16) are not by themselves findings.

• Items listed in the “Known Issues / Acknowledged Design Decisions” section below — these are acknowledged as intentional design, deliberately excluded from the codebase, or operationally mitigated. Re-reports without a materially different exploit path are not eligible.
• Theoretical vulnerabilities without proof, demonstration, or runnable PoC
• Vulnerabilities exclusively exploitable via front-running on a public mempool, when the contract uses standard MEV-aware patterns (2-step request/claim, minOut, etc.)
• Findings that require a privileged role (governance, management, keeper, strategist) to act against the protocol — see Trust Assumptions
• Centralization / “no timelock” / “owner can do X” findings — already mitigated via 4/5 (Governance) and 2/3 (Management) Gnosis Safes
• Findings that require modification of the deployed Yearn V2 Vault.vy / Registry.vy Vyper code
• Findings against external protocols’ implementations (Morpho, Pendle, Curve, Uniswap, OpenEden, Ethena, Neutrl, Cap, Fluid, CCIP, Orakl, Rhino)
• Findings against any contract listed under “Out of Scope — Contracts” above
• Generic best-practice issues without exploit impact (gas optimization, code style, redundant code, missing event — note: see SUA-10 for CooldownVault’s deliberate non-strict-ERC4626 stance)
• Compiler-version pinning, unlocked pragma, or other meta-issues
• Vulnerabilities in imported libraries (OpenZeppelin 5.3.0 non-upgradeable, OpenZeppelin 4.9.4-upgradeable aliased via @openzeppelin/contracts-upgradeable-4.9.4, Chainlink CCIP, Orakl, Uniswap v3/v4 peripherals — see Build Environment table for exact pins) that do not have a SuperEarn-specific exploit path
• Permanent freeze where the only avenue is governance failure (governance is multi-sig)
• Findings that require a temporary / permanent depeg of underlying stablecoins (USDT, USDC, USDO) — temporary depeg is anticipated; permanent depeg is treated as systemic risk
• Findings that hinge on bridge-service operational behaviour (Rhino smart deposit address rotation, CCIP delivery timing) without a contract-level invariant violation
• Findings that propose adding USDC bridging or that argue “USDC should be crosschain-routable”. The protocol’s crosschain transfers are USDT-only by design (bridgeToken is immutable); USDC is sourced locally on Ethereum by swapping bridged USDT via UniversalSwapRouter.

The patterns below are routinely produced by AI / static-analysis tools (Slither, MythX, 4naly3er, GPT-based “audit” agents, automated CTF crawlers) and are pre-filed Out of Scope before review. If an automated tool produced a finding that matches one of the rows below, the program owner has already classified it as OOS — do not submit. Each row maps to the controlling SE-P / SUA / SSA / SA2 / Trust-Assumption / OOS clause in the rest of this document; cite that clause if you wish to argue your finding is materially different from the listed pattern.

A finding that is not literally listed below but whose root cause maps in meaning to any clause in this document (SE-P1–SE-P32, SUA-, SSA-, SA2-*, Trust Assumptions, OOS bullets, Periphery & Helper OOS) is OOS by the same matching rule. Submitting an AI-tool report that turns out to be one of these patterns may affect the researcher’s standing in this program.

The following items are referenced by Certik audit IDs (see reports 2026.02.19-certik.pdf / 2026.04.07-certik.pdf / 2026.04.28-certik.pdf in superearn-io/superearn-audit-reports). Each item is either acknowledged as intentional design, deliberately not present in the codebase, or mitigated operationally. Re-reports of these items will be marked Out of Scope and are not eligible for a bounty unless the report demonstrates a materially different exploit path against the current code.

• You can find the full list at the following link: https://github.com/superearn-io/superearn-core-public/blob/main/BUG_BOUNTY.md

The following are assumed to behave correctly and are out of scope:

• Governance / Management / Revenue multisigs are trusted not to act maliciously. The protocol uses a 4/5 Gnosis Safe for GOVERNANCE_ROLE (Kaia: 0x694B81Db...d5f05, Ethereum: 0xce6917FF...897f2f) and a 2/3 Gnosis Safe for MANAGEMENT_ROLE, with ProxyAdmin ownership held by the Governance Safe on both chains. The protocol does not currently use an on-chain timelock on top of the multisig — this trade-off is documented and acknowledged in prior audits. A finding that requires the multisig to behave adversarially, or that only argues “no timelock”, is out of scope.
• Keepers (LightKeeper, CrosschainKeeper) are trusted to call the operations they are authorized for in a timely manner. A finding that requires a malicious keeper to drain a strategy through an authorized path is out of scope (a finding where an unauthorized address can call a keeper-only function is in scope).
• Strategists are trusted within the bounded execution allowlist of CustomStrategy. A finding that requires the strategist to act maliciously within the allowlist is out of scope; a finding that lets the strategist escape the allowlist or assetsChangeTolerance is in scope.
• All strategies are internally developed and operated. Findings that assume an externally-controlled or malicious strategy contract (e.g., a rogue strategy abusing predeposit()/instantRedeem() to drain CooldownVault idle liquidity) are out of scope. New external strategies will undergo separate review before being authorized.
• Yearn V2 Vault.vy and Registry.vy are trusted and unmodified.
• External protocols (Morpho, Pendle, OpenEden, Ethena, Neutrl, Cap, Fluid, Curve, Uniswap, CCIP, Orakl, Rhino) are trusted within their documented behaviour.
• Stablecoin issuers (USDT, USDC, USDO) are trusted; permanent depeg is out of scope.
• OpenEden KYC dependency: USDOKycedCA calls into OpenEden’s USDOExpress.instantMint, which requires the protocol’s address to remain on OpenEden’s KYC allowlist. Findings that hinge on OpenEden delisting the protocol’s address are out of scope.
• Permissioned entry-points on OriginVault (whitelist), CooldownVault (authorizedAddresses), and the role-based gates on RemoteVault are intentional. Bypassing them is in scope; abusing them as an authorized entity is generally out of scope unless the abuse circumvents an additional invariant.

SuperEarn supports good-faith security research. Activities conducted in compliance with this program are treated as authorized; SuperEarn will not pursue, support, or encourage legal action against a researcher for security research that:

• Stays within the in-scope contract list and program rules above
• Reproduces the finding on a fork / local devnet rather than against the live protocol beyond the minimum needed to demonstrate it
• Does not access, modify, or move user funds, off-chain systems, or another user’s positions
• Reports the issue privately and exclusively through the program’s designated submission channel within 24 hours of discovery
• Avoids degrading service availability and respects user privacy

Specifically, when these conditions are met:

• SuperEarn will not initiate civil action and will not pursue claims under the U.S. Computer Fraud and Abuse Act (CFAA), Digital Millennium Copyright Act (DMCA), or analogous computer-misuse / unauthorized-access statutes in other jurisdictions for the in-scope research activity itself.
• If a third party (e.g. an external infrastructure provider) initiates legal action against a researcher who has acted in good faith under this program, SuperEarn will make a good-faith effort to clarify that the activity was authorized.

This safe harbor:

• Covers only conduct directly governed by this program. It does not authorize violation of any other law, contract, or third-party right unrelated to security research conducted under this program.
• Does not cover exploitation beyond the minimum needed to demonstrate impact, theft or movement of user funds, public disclosure prior to remediation, or interaction with off-chain components and external protocols listed as out of scope.
• Does not override applicable sanctions law. Researchers in jurisdictions subject to comprehensive U.S./EU/UN sanctions are not eligible to participate.

If you are unsure whether a planned action is covered, ask via the designated submission channel before taking the action. SuperEarn will treat such pre-clearance requests confidentially.

• Make every effort not to damage or restrict the availability of the protocol’s mainnet contracts, RPC endpoints, or related infrastructure. Reproduce findings on a fork (Foundry / Hardhat) or local devnet first
• Do not exploit a discovered vulnerability against the live protocol beyond the minimum necessary to demonstrate the issue
• Do not move user funds, do not interact with another user’s positions, and localize all on-chain testing to your own addresses
• Do not perform DoS / DDoS, social engineering, phishing, or spam
• Do not access or modify off-chain systems (RPC, indexer, frontend, keeper bots) — these are out of scope and out-of-scope interactions void the bounty
• Perform testing only within the in-scope contract list
• If you find chained vulnerabilities, only the highest-severity vulnerability in the chain will be paid
• Do not break any law and stay within the defined scope
• Vulnerability details must not be communicated to anyone outside of the program team without prior written consent

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the SuperEarn team
• No vulnerability disclosure, including partial disclosure, is permitted while the report is open
• Do not publish, blog, tweet, or discuss findings publicly until the SuperEarn team has confirmed remediation and approved disclosure

• You must be the first reporter of a given vulnerability
• The vulnerability must be a qualifying vulnerability per the scope and severity classification above
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through the bug-bounty platform / channel designated for this program
• Submit a clear textual description of the report along with steps to reproduce, attachments such as screenshots, and a runnable proof-of-concept (Foundry test, script, or similar) where applicable
• You must not be a current or former employee, contractor, or auditor of SuperEarn or its affiliates
• Use ONLY the email under which you registered your bug-bounty account; mismatched identities void the bounty
• Provide detailed but to-the-point reproduction steps; the SuperEarn team must be able to reproduce the issue independently
• AI-generated reports without a runnable PoC will not be accepted under this program