Vulnerability Disclosure Policy

1. Overview

2. Assets in Scope

2.1 Smart contracts (RISE Chain)

2.2 Smart contracts (Ethereum mainnet)

• Bridge adapter (LayerZero)
• RISE-USDC vault

2.3 Web / API / Infrastructure

3. Out of Scope

Reports against these are closed as out of scope.

3.1 Assets

• Testnet contracts and UI.
• Deprecated or unreleased contracts.
• Third-party dependencies operated outside RISE Trade: LayerZero core protocol, oracle providers (Pyth, Chainlink, RedStone), RPC providers, wallet providers (MetaMask, Rabby, etc.).
• Public info already disclosed in past audit reports [TBD].
• Subdomains, mirror sites, or community frontends not listed in Section 2.

3.2 Vulnerability types (not in scope)

• Requires physical device access.
• Social engineering of RISE staff or community.
• Phishing or typosquatting domains.
• Email spoofing when SPF/DKIM/DMARC correctly configured (validate first).
• No clear security impact (missing headers without exploit, verbose errors without sensitive data, version disclosure).
• Self-XSS or attacks needing prior full device compromise.
• Clickjacking on pages without sensitive actions.
• CSRF on logged-out pages or without state change.
• Open redirects without security impact.
• Brute-force on user passwords (wallet signature only; no passwords).
• Outdated browser issues, missing CAA, suboptimal TLS ciphers without exploit.
• Rate limiting on non-state-changing endpoints.
• Tab-nabbing without security impact.
• Automated scanner reports without proof of impact.
• Theoretical vulnerabilities without PoC.
• MEV within published protocol rules (public-mempool front-running, sandwich via valid bids).
• Viewing another user's order history, trade/fill history, open orders, positions, PnL, funding payments, liquidations, balances, deposits or withdrawals.
• Retrieving that data by wallet address or account ID from the public API, WebSocket feed, RPC, block explorers or indexers without authentication.
• Linking wallets, sub-accounts or session signers, or reconstructing a user's trading activity from on-chain data.
• Findings requiring another user's seed phrase, private keys, device, email, or credentials.
• Issues only occurring under extreme or unrealistic market conditions.
• Non-security bugs (UI glitches, minor performance issues, display inaccuracies without financial impact).
• Reports based solely on third-party CVEs without a demonstrated exploit path in an in-scope asset.

Exposure of genuinely non-public data (email addresses, API secrets, session signer private keys, internal credentials) remains in scope.

3.3 Out-of-scope activities

• DoS attacks (network, application, economic).
• Production stress testing.
• Spam, fraud, or abuse of user accounts.
• Data exfiltration beyond minimum to demonstrate impact.
• Attacks on RISE team, infra providers, or third parties.

If unsure, contact security@riselabs.xyz before acting.

4. Vulnerability Categories

4.1 Smart contract

• Reentrancy
• Access control failure
• Arithmetic/overflow/underflow/precision loss
• Oracle manipulation (price feed, funding rate, mark price)
• Liquidation engine logic error
• Margin/collateral accounting error
• Funding rate manipulation
• Liquidation cascade/shortfall socialization bug
• Flash loan attack vector
• Signature replay/malleability
• Bridge/cross-chain message replay or forgery
• Upgrade/proxy admin misuse
• Storage collision in upgradeable contract
• Front-running of privileged operations
• Governance takeover

4.2 Web / API

• Authentication/authorization bypass
• SSRF
• Stored or reflected XSS with security impact
• API parameter tampering causing unauthorized state change
• Rate-limit bypass enabling account/fund manipulation
• Order book manipulation via API edge case
• WebSocket message forgery
• Indexer poisoning (data integrity)

4.3 Infrastructure

• Sequencer halt or censorship bug
• RPC method exposure (unsafe debug methods in production)
• Bridge relayer compromise vector
• Key management failure
• Container or deployment misconfiguration

5. Severity Classification

Baseline: Immunefi Vulnerability Severity Classification System v2.3. Final severity set by RISE security team based on demonstrated impact and exploit cost.

5.1 Smart contract severity

5.2 Web / API severity

5.3 Impact in scope (perp DEX clarifications)

Demonstrable on mainnet fork or RISE Chain mainnet:

6. Rewards

Amounts are maximums, not guarantees. Final reward, if any, is set at RISE's sole discretion based on severity, demonstrated impact, report quality and originality. Duplicate, out-of-scope, or Section 7-violating reports are not eligible. Low/Informational findings may be credited without monetary reward.

7. Rules of Engagement

7.1 Permitted

• Read public state of in-scope contracts.
• Simulate transactions against in-scope contracts on mainnet fork.
• Submit transactions on RISE Chain mainnet only to minimum extent needed to demonstrate impact.
• Test in-scope web/API endpoints with low-volume manual techniques.
• Use your own accounts and funds.

7.2 Prohibited

• Accessing, modifying, or exfiltrating other users’ non-public data (public on-chain data excluded, see Section 3).
• Automated scanners against production without prior written approval.
• DoS of any form (network, application, economic, gas-grief).
• Social engineering of RISE staff, contractors, or community moderators.
• Physical attacks on infrastructure or personnel.
• Public disclosure before coordinated timeline expires.
• Exploiting beyond minimum needed to prove impact (e.g. draining funds beyond one demo transaction).
• Holding findings as ransom or threatening disclosure for payment.
• Participating if under OFAC/EU/UK sanction or resident in sanctioned jurisdiction.

7.3 If user funds are at risk

If issue is actively exploited or places funds at immediate risk:

1. Stop the test. Do not exploit further.
2. Contact us immediately: security@riselabs.xyz with subject prefix [URGENT].
3. If email delayed, DM founder on Twitter: @risextrade.
4. Do not disclose to any third party.

War room engaged within 8 hours.

Any finding you assess as Critical must also use this [URGENT] path, even if not yet exploited. Non-urgent reports follow the standard SLA in Section 10.

7.4 Safe harbor

If you act in good faith, follow this policy, avoid privacy violations and service disruption, and give us a reasonable opportunity to investigate and remediate, RISE will not pursue legal action against you for your research. If a third party initiates legal action against you for activity conducted in accordance with this policy, we will make it known that your actions were authorized.

Safe harbor does not extend to conduct that:

• Harms users or risks or compromises user funds.
• Intentionally degrades platform availability.
• Violates applicable law.
• Involves extortion, ransom demands, or premature public disclosure to pressure resolution.

8. Proof of Concept Requirements

Report must let engineers reproduce within 30 minutes.

8.1 Smart contract findings

• Affected contract address and function.
• Foundry/Hardhat test demonstrating exploit against mainnet fork pinned to specific block.
• Trace output showing state change (balances before/after, event logs).
• Brief root-cause explanation.
• Suggested fix or mitigation (optional).

8.2 Web / API findings

• Affected URL, method, parameters.
• Request/response capture (sanitize secrets).
• Step-by-step reproduction.
• Screenshot or video for visual bugs (XSS, CSRF).
• Browser/OS/version when relevant.

8.3 Required fields in every report

• Title (one-line summary).
• Severity (initial assessment).
• Vulnerability category (Section 4).
• Affected asset (Section 2).
• Impact statement (what attacker can do, with what cost, against which victim).
• Steps to reproduce.
• PoC (code or trace).
• Suggested remediation (optional).

9. Reporting Process

9.1 How to submit

Preferred:

• Email: security@riselabs.xyz

Do not submit via:

• Public GitHub issues.
• Discord, Telegram, or community channels.
• Twitter DMs to staff (except urgent fallback in 7.3).

9.2 What happens next

1. Acknowledgment within 7 business days by RISE security team. [URGENT] reports (7.3) handled within 8 hours.
2. Triage within 3 weeks of acknowledgment: severity confirmation, scope check, duplicate check. Severity disagreements explained and discussed.
3. Fix and deploy: as quickly as possible, prioritized by severity and complexity. Critical handled as an incident; Medium/Low typically ship in a scheduled release. Timelines may vary with technical complexity, release timing, and operations.
4. Post-fix coordination: confirmed fix communicated, disclosure timeline agreed.
5. Recognition: added to Hall of Fame after disclosure window.

9.3 Duplicate handling

First researcher to submit a unique, reproducible finding is credited. Timestamps from intake system.

10. Response SLA