Sui Protocol: Program info

Experimental features are not guaranteed to be deployed to the Sui mainnet. These features are often in early stages of development and may undergo significant changes or even be discontinued. We are eager for whitehats to focus on code that already is live in mainnet, or will be soon.

Experimental features are those specifically mentioned in this exclusion list, as well as any features labeled as experimental in the source code, not in testnet or related documentation. This tag serves to notify researchers that the feature is subject to special rules under the bug bounty program.

Payout Reduction

All payouts for vulnerabilities identified within the experimental feature will be ineligible for a bug bounty.

List of Experimental Features

• Policy defined for account alias addresses

5. Impact Scoring Matrix

Composite Score = Impact_Type x Privilege_Required x Attack_Complexity x Scope

Impact Type (I) — Primary Weight

Privilege Required (P)

Attack Complexity (C)

Scope (S)

Severity Tiers from Composite Score

Worked Examples

Base Tiers (Sui Core)

Component-Specific Tiers

DeepBook v3

Seal

DoS-Specific Hard Caps

Regardless of composite score, DoS bugs are subject to these ceilings:

Category Hard Caps

These override the composite score when applicable:

Note: For chain vulnerabilities (multiple linked bugs), only the vulnerability with the highest severity is paid.

7. Severity Downgrade Rules

These rules are applied during triage.

The following receive $0 and may be closed without further triage:

1. Griefing — no material loss to any party.
2. Intentional design features — e.g., bridge rate limiter 48-hour bypass, package linkage override (flat per-MoveCall ResolvedLinkage), Seal MVR immutability.
3. AI/LLM-generated reports — detected via generic phrasing, hallucinated function names, incorrect code references, or boilerplate structure without project-specific detail.
4. No PoC provided — theory-only submissions without compilable code.
5. Third-party protocols — Cetus, Turbos, Navi, or any non-Mysten code.
6. Mainnet / public testnet testing — prohibited; violations may result in program ban.
7. Deprecated components — DeepBook v2, old bridge contracts.
8. Duplicate reports — $0 per first-filer rule (see Section 10).
9. Fix PR predates submission — $0-$500 token payout at most.
10. Known false positive families — see below.
11. Experimental features — see Section 17.

Out-of-Scope Impacts

The following impact types are excluded regardless of asset:

Smart Contract / Blockchain:

• Impacts requiring attacks the reporter has already exploited, leading to damage
• Impacts requiring access to leaked keys or credentials
• Impacts requiring access to privileged addresses (governance, strategist) except where contracts have no privileged access
• Mentions of secrets/keys/tokens in GitHub without proof of production use
• Incorrect data supplied by third-party oracles (oracle manipulation/flash loan attacks are NOT excluded)
• Impacts requiring basic economic and governance attacks (e.g., 51% attack)
• Lack of liquidity impacts
• Sybil attacks
• Centralization risks

Web / Frontend:

• Theoretical impacts without proof or demonstration
• Physical access to victim device required
• Local network access to victim required
• Reflected plain text injection (reflected HTML/JS injection NOT excluded)
• Self-XSS
• CAPTCHA bypass using OCR without impact demonstration
• CSRF with no state-modifying security impact
• Missing HTTP security headers without demonstrated impact
• Server-side non-confidential information disclosure (IPs, server names, stack traces)
• User/tenant enumeration or existence confirmation
• Un-prompted in-app user actions not part of normal workflows
• Lack of SSL/TLS best practices
• DDoS only
• UX/UI impacts that don’t materially disrupt platform use
• Browser/plugin defects required for exploitation
• Leakage of non-sensitive API keys (Etherscan, Infura, Alchemy, etc.)
• Browser bugs required for exploitation (e.g., CSP bypass)
• SPF/DMARC misconfigured records
• Missing HTTP headers without demonstrated impact
• Automated scanner reports without demonstrated impact
• Non-future-proof NFT rendering

Known False Positive Families

These patterns recur frequently and are rejected on sight:

9. Quality Bonuses

High-quality submissions may receive payout bonuses at the triage team’s discretion. Factors that positively influence payout include:

• Working E2E PoC with transaction digests from local network execution
• Root cause analysis with a correct and viable fix suggestion
• Multiple complementary PoCs (e.g., both unit test and network-level evidence)
• First report of a previously unseen vulnerability class

10. Duplicate Policy

• First-filer rule: The first valid report receives the bounty. All subsequent reports for the same vulnerability receive $0.
• Same root cause + same code path = duplicate, even if the description, attack vector, or PoC approach differs.
• Independent rediscovery is noted in triage records but does not change payout.
• HackenProof submission timestamp determines filing priority.
• Reporters who consistently submit duplicates may have their quality score reduced, affecting future payout modifiers.

11. Evidence Requirements

Mandatory (All Submissions)

• Compilable PoC code (Move test, Rust test, or script)
• Numbered reproduction steps
• Affected version (git commit hash or release tag)
• Affected file paths and line numbers
• Concrete impact description (not “could theoretically”)
• Any medium or higher severity vulnerability must come with a working PoC demonstrable on a local test environment

Increases Payout

Does NOT Count as Evidence

• Source code review alone (reading code is not reproduction)
• Theoretical attack paths without execution
• Screenshots with annotations but no execution output
• Unit test output alone for network-level claims (unit tests bypass gas metering, object ownership, verifier enforcement, and transaction size limits)
• Automated scanner reports without demonstrated impact

Use this template when submitting via HackenProof. Reports that follow this structure are triaged faster and receive more accurate severity assessments.

Required Fields

## Title
<!-- One-line summary: [Component] — [Root Cause] — [Impact] -->
<!-- Example: "sui-execution — DepthFormula::add() no-op on unit-variant enums — validator SIGABRT" -->

## Vulnerability Category
<!-- Pick ONE from: fund_theft, verifier_bypass_theft, verifier_bypass_dos,
     cryptographic_theft, consensus_liveness, smart_contract, bridge,
     network_dos, griefing -->

## Affected Component
<!-- Repository name + file path(s) + line number(s) -->
<!-- Example:
     - Repository: MystenLabs/sui
     - File: crates/sui-execution/src/verifier.rs
     - Lines: 142-158
-->

## Affected Version
<!-- Git commit hash or release tag. "latest" is not accepted. -->
<!-- Example: commit abc1234 or release v1.57.3 -->

## Root Cause
<!-- 2-3 sentences explaining the code-level root cause.
     Reference specific function names, types, and logic errors.
     Do NOT just describe symptoms — explain WHY the bug exists. -->

## Impact
<!-- What can an attacker achieve? Be specific:
     - For fund theft: whose funds, how much, what conditions
     - For DoS: what crashes, how long, recoverable?
     - For logic bugs: what invariant is violated, what state is corrupted
     Do NOT use "could theoretically" — describe concrete impact. -->

## Attack Prerequisites
<!-- What does the attacker need?
     - Authentication level (none / SUI holder / staker / validator / admin)
     - Network conditions (single tx / multi-step / timing-sensitive)
     - Economic cost of attack
-->

## Reproduction Steps
<!-- Numbered steps. Each step = one command or action.
     Must be reproducible on a local network from a clean state. -->
1.Clone repository at commit `<hash>`
2....
3....

## Proof of Concept
<!-- Inline the COMPLETE, compilable PoC code below.
     Do NOT link to external gists or repos — inline everything.
     Accepted formats: Move test module, Rust test, shell script. -->

// or ```rust or ```bash
// COMPLETE compilable PoC here

## Execution Output
<!-- Paste actual stdout/stderr from running the PoC.
     For fund theft: include balance before + after.
     For DoS: include crash log or resource measurements.
     For network bugs: include transaction digests. -->

## Suggested Fix (Optional)
<!-- Diff or description of how to fix the root cause. -->

Formatting Tips

• Title format: [Component] — [Root Cause] — [Impact]. A good title lets the triage team classify the report before reading the body.
• Inline all code. Do not link to external gists, pastebin, or Google Drive. Linked code slows triage and may not be accessible.
• One vulnerability per report. If you found multiple bugs, submit each separately. Multi-vulnerability reports are split during triage and may lose context.
• Pin the version. Always specify the exact git commit hash or release tag. Reports against “latest” or “main” cannot be reliably reproduced if the code changes between submission and triage.
• Show execution output. Paste actual terminal output from running your PoC. Reports with only source code analysis and no execution evidence are automatically downgraded (see Rule D1).
• Be precise about impact. “This could crash the network” is not useful. “Sending this 300-byte payload to the P2P endpoint causes the state-sync task to panic, killing the process” is useful.

What Happens After Submission

1. Intake — report is parsed, attachments are inventoried, safety scan runs.
2. Classification — vulnerability is categorized and matched to a reproduction playbook.
3. Reproduction — PoC is executed in a sandboxed environment. Both unit tests and end-to-end network tests are run.
4. Verification — results are adversarially reviewed against the claimed impact. Negative case tests confirm the vulnerability is real.
5. Scoring — severity is computed using the Impact Scoring Matrix and adjusted by Downgrade Rules.
6. Response — you receive a triage verdict with our assessed severity and payout determination.

16. Known Issues

The following are known issues that have already been identified and addressed. Reports for these receive $0.

Staking Pool 1-MIST Rounding

In our staking contract, we keep track of exchange rates between pool tokens and SUI tokens. When a user withdraws their stake, we calculate rewards based on the difference in exchange rates. Rounding may happen due to integer division. In the extreme case where a user is unstaking 1 MIST, zero pool tokens may be burnt, causing the pool token to effectively depreciate. If an attacker has many 1 MIST stakes, they can withdraw them one by one, causing the exchange rate to drop and other stakers to “lose” rewards. However, the attacker themselves gains nothing — the rewards remain as dust in the pool.

Mitigation: Minimum staking amount of 1 SUI (10^9 MIST) enforced via PR #9961.

Excessive Storage Rebate on 0x5 After Epoch Change

Each on-chain object is associated with a storage rebate. Epoch change transactions are system transactions without a sender, so any excessive storage rebate generated is kept in the 0x5 object. The first person touching 0x5 in each epoch could obtain those excessive rebates (e.g., via a failed staking request).

Status: Under investigation for even distribution of excessive rebates.

DeepBook Order Fill Limit

Limitation to number of orders that can be filled (only fill 100 orders per trade, where gas costs increase dramatically with respect to a normal order) is a known design constraint and excluded from the bounty.