Sui Protocol: Program info

3. Qualifying Impacts

Only the following impacts are accepted. All other impacts are out of scope even if they affect in-scope assets.

Blockchain / DLT (Sui Core)

Impact	Severity
Exceeding the maximum supply of 10 billion SUI + allowing the attacker to claim the excess funds	Critical
Significant Loss of Funds	Critical
Violating BFT assumptions, acquiring voting power vastly disproportionate (20x) to stake, or any issue that can meaningfully compromise proof-of-stake governance integrity	Critical
Arbitrary, non-Move remote code execution on unmodified validator software	Critical
User fund exploits causing permanent locking, loss, or theft of funds greater than $20M	Critical
Forging of Native Bridge Messages enabling theft or illegitimate minting of assets greater than $3M with fully working PoC	Critical
Governance / Upgrade Bypass of Bridge Contract enabling theft or illegitimate minting of assets	Critical
Remote Code Execution on Bridge Nodes	Critical
Network unable to confirm new transactions (total shutdown) requiring a hard fork to resolve	Medium
Temporary total network shutdown or unintended chain split (duration greater than 10 minutes)	Medium
DoS attacks on bridge node that require a protocol upgrade to fix	Medium
Bug resulting in unintended and harmful smart contract behavior with no concrete funds at direct risk	Medium
Unintended, permanent burning of SUI under the max cap	Medium
Shutdown of >= 30% of network processing nodes without brute force, but does not shut down the network	Medium
Temporary locking of user funds that are part of the native bridge	Medium
Persistent XSS on Bridge Frontend that can lead to loss of user funds	Medium
DoS for Bridge Node	Medium
Bypass of Bridge limits	Medium
Transaction that triggers an invariant violation error code in unmodified validator software	Low
Remote call that crashes a Sui fullnode	Low

zkLogin Circuits

Impact	Severity
Vulnerabilities in Circuit Construction that can lead to Loss of funds	Critical

DeepBook v3

Impact	Severity	Payout
Bugs or attacks resulting in significant loss of funds,	Critical	$10,000 – $100,000
Permanent freezing of funds, or permanent DoS/interruption on the CLOB requiring a protocol upgrade	High	$5000-$20,000
Temporary DoS/interruption on the CLOB, temporary freezing of funds up to 1 epoch, users cannot claim rebates due to DoS	Medium	$1,000 – $5,000
Minor loss of funds (<$100 USD), temporary DoS, inconsistent fee calculations	Low	$200 – $1,000
Other low-severity issues	Informational

DeepBook Known Exclusion: Limitations to number of orders that can be filled (only fill 100 orders/trade where gas costs increase dramatically) is a known issue and excluded from the bounty.

Seal

Seal is a decentralized secrets management (DSM) product. Application developers and users can use Seal to secure sensitive data at rest on decentralized storage. Seal enables identity-based encryption and decryption of sensitive data, with access controlled by on-chain policies on Sui.

Impact	Severity	Payout
Retrieving a derived key without satisfying policies (or spoofing identity)	Critical	$50,000 – $100,000
Remote extraction of the master key from key servers	Critical	$50,000 – $100,000
Decryption of an encrypted blob without knowing the associated derived key or symmetric key	Critical	$50,000 – $100,000
On-chain decryption misuse leading to forgery of encrypted decisions	High	$10,000 – $50,000
Extending session key beyond specified TTL	Medium	$5,000 – $10,000
DoS attacks on key servers requiring fix/hard restart (permissioned servers only; open mode/public goods servers are out of scope)	Low	$500 – $2,500

---

4. Vulnerability Classification

Category ID	Category	Impact Ceiling	Max Payout
fund_theft	Fund Theft / State Corruption	CRITICAL	up to $1,000,000
verifier_bypass_theft	Verifier Bypass (with fund-theft chain)	CRITICAL	up to $1,000,000
verifier_bypass_dos	Verifier Bypass (DoS only)	MEDIUM	$5,000
cryptographic_theft	Cryptographic (with fund access)	CRITICAL	up to $1,000,000
consensus_liveness	Validator/Consensus (liveness only)	MEDIUM	$5,000
smart_contract	Smart Contract logic (DeepBook v3, Seal, etc.)	MEDIUM	$5,000
bridge	Bridge	MEDIUM	$5,000
network_dos	Network/Node DoS	LOW	$1,000 – $5,000
Economically Unfeasible	no material impact; lose money as an attacker.	NONE	$0

Key principle: The ceiling is determined by whether the bug can lead to direct fund loss. A verifier bypass that only crashes a node is capped at MEDIUM; the same bypass chained to unauthorized fund transfer is CRITICAL.

---

• Avoid using web application scanners for automatic vulnerability searching which generates massive traffic
• Make every effort not to damage or restrict the availability of products, services, or infrastructure
• Avoid compromising any personal data, interruption, or degradation of any service
• Don’t access or modify other user data, localize all tests to your accounts
• Perform testing only within the scope
• Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam
• Don’t spam forms or account creation flows using automated scanners
• In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
• Don’t break any law and stay in the defined scope
• Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
• Please note: SUI company is entitled to make the payment in their native SUI token
• In case that your findings is valid you will be asked for KYC verification to proceed with payments

Previous audits and known issues can be found at: https://github.com/sui-foundation/security-audits

• In our staking contract, we have the concept of pool tokens and keep track of exchange rates between pool tokens and SUI tokens of all epochs, which increase as more rewards are added to the staking pools. When a user withdraws their stake, we retrieve from that record both the exchange rate at staking time and the current exchange rate (at withdrawing time), and calculate the rewards to be paid out based on the difference in exchange rates. While doing this calculation, we do conversions both ways: pool tokens -> SUI and SUI -> pool tokens. Rounding may happen along the way due to integer division.

The exchange rate between the two tokens should stay roughly the same since we will be burning a proportional amount of pool tokens as SUI is withdrawn. However, in the extreme case where a user is unstaking 1 MIST, this rounding error may cause ZERO pool tokens to be burnt, causing the pool token to effectively depreciate. If an attacker has a lot of 1 MIST stakes, they can withdraw them one by one, causing the pool token exchange rate to drop and other takers to “lose” their staking rewards. I put quotation marks around “lose” because the attacker themselves won’t get any of that rewards so this attacker doesn’t actually make economic sense. Rather the rewards stay in the rewards pool and will become dust.

This issue is mitigated by enforcing a minimum staking amount of 1 SUI or 10^9 MIST in this PR: https://github.com/MystenLabs/sui/pull/9961 Related Impact-in-Scope: Critical - Any other issue leading to theft or loss of valuable objects, with severity depending on the consequences of the issue and the preconditions for exploiting it.

• Excessive storage rebate on 0x5 object right after epoch change: Each on-chain object is associated with a storage rebate, which would be refunded to the owner if it ever gets deleted. Epoch change transactions are special in that they are system transactions without a sender, hence any excessive storage rebate generated in that transaction is kept in the 0x5 object. This means that the first person touching the 0x5 object in each epoch may be able to obtain those excessive rebate by simply touching this object (e.g. a failed staking request). We will look into a way to evenly distribute those excessive rebates such that is does not lead to any undesired behaviors.

Dev Environment and Documentation

Sui has included dev documentation and/or instructions to help in reviewing code and exploring for bugs:

https://docs.sui.io/ https://docs.sui.io/build/sui-local-network https://docs.sui.io/build/devnet https://github.com/MystenLabs/sui/blob/main/SECURITY.md

Impacts to other assets

Hackers are encouraged to submit issues outside of the outlined Impacts and Assets in Scope.

If whitehats can demonstrate a critical impact on code in production for an asset not in scope, Sui encourages you to submit your bug report using the “primacy of impact exception” asset.

We are happy to thank everyone who submits valid reports which help us improve the security. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must not be a former or current employee of us or one of its contractor.
• Provide detailed but to-the-point reproduction steps
• Current employees ,vendors (auditors), partners and contractors of Mysten Labs Inc. and Sui Foundation are not eligible to participate in the bug bounty program.
• Former employees and contractors of Mysten Labs Inc. and Sui Foundation, who ceased working with the aforementioned entities must wait 6 months before they are eligible to participate in the bug bounty program.
• Sanctioned individuals and/or organizations are not eligible to participate in the bug bounty program.

Disclosure Guidelines

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from Mysten Labs.
• No vulnerability disclosure, including partial, is allowed.
• Please do NOT publish or discuss bugs.

These are targets, not guarantees. Complex reports (consensus bugs, verifier bypasses) may require additional time for thorough reproduction.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
• No vulnerability disclosure, including partial is allowed for the moment.
• Please do NOT publish/discuss bugs

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

ID	Level	Base Score	Description
I4	Fund Theft	10.0	Unauthorized transfer of user funds
I3	State Corruption	8.0	Supply violation, permanent corruption
I2	Liveness	5.0	Chain halt, consensus stall
I1	Degradation	2.0	Single-node DoS, resource exhaustion
I0	Griefing	0.0	No material impact

Privilege Required (P)

ID	Level	Multiplier	Description
P0	None	1.0	Unauthenticated / any user
P1	Network participant	0.9	Holds SUI, can submit transactions
P2	Staker / candidate	0.6	Significant stake required
P3	Byzantine validator	0.3	Violates trust assumption
P4	Admin / Quorum 51%+	0.1	Already compromised

Attack Complexity (C)

ID	Level	Multiplier	Description
C0	Trivial	1.0	Single transaction
C1	Low	0.9	Few transactions, straightforward
C2	Medium	0.7	Multi-step, timing-sensitive
C3	High	0.5	Race conditions, cross-epoch coordination
C4	Impractical	0.2	Economically irrational

Scope (S)

ID	Level	Multiplier	Description
S2	Network-wide	1.0	All validators / all users affected
S1	Multi-node	0.7	Subset of validators or users
S0	Single-node	0.4	One validator / one node

Severity Tiers from Composite Score

Tier	Score Range
CRITICAL	8.0 – 10.0
HIGH	5.0 – 7.9
MEDIUM	3.0 – 4.9
LOW	1.0 – 2.9
INFORMATIONAL	0.0 – 0.9

Worked Examples

Scenario	I	P	C	S	Score	Tier
Fund theft, no auth, trivial, network-wide	10	1.0	1.0	1.0	10.0	CRITICAL
Consensus halt, Byzantine validator, medium, network	5	0.3	0.7	1.0	1.05	LOW
Single-node OOM, no auth, trivial, single-node	2	1.0	1.0	0.4	0.80	INFORMATIONAL
Verifier bypass + theft, participant, low, network	10	0.9	0.9	1.0	8.10	CRITICAL
Bridge authority DoS, no auth, low, single-node	2	1.0	0.9	0.4	0.72	INFORMATIONAL
zkLogin cache bypass + fund theft, none, medium, network	10	1.0	0.7	1.0	7.00	HIGH
DeepBook rounding, participant, trivial, network	2	0.9	1.0	1.0	1.80	LOW

---

Base Tiers (Sui Core)

Tier	Score Range	Payout Range	Primary Qualifier
Critical	8.0 – 10.0	$50,000 – $1,000,000	MUST involve direct fund loss
High	5.0 – 7.9	$5,000 – $50,000	Fund risk or severe liveness impact
Medium	3.0 – 4.9	$2,000 – $10,000	Significant liveness impact, no fund loss
Low	1.0 – 2.9	$500 – $2,500	Node-level issues, minor logic bugs
Informational	0.0 – 0.9	$0 – $500	Design gaps, theoretical

Component-Specific Tiers

DeepBook v3

Tier	Payout
Critical	$10,000 – $100,000
High	$5000-$20,000
Medium	$1,000 – $5,000
Low	$200 – $1,000

Seal

Tier	Payout
Critical	$50,000 – $100,000
High	$10,000 – $50,000
Medium	$5,000 – $10,000
Low	$500 – $2,500

DoS-Specific Hard Caps

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

DoS Sub-type	Maximum Payout
Pre-auth network-wide DoS	$10,000
Post-auth network-wide DoS	$5,000
Single-validator DoS	$3,000
Byzantine-validator-required DoS	$1,000 – $3,000
OOM / resource exhaustion	$1,000 – $5,000
Restart-recoverable DoS	0.5x modifier on above

Category Hard Caps

These override the composite score when applicable:

Category	Max Payout	Rationale
Any DoS (no fund loss)	$10,000	Program policy
DoS requiring Byzantine validator	$3,000	Trust assumption violated
Smart contract precision / rounding	$2,000	Standard DeFi math
Bridge authority DoS	$3,000	Committee redundancy
Griefing	$0	Program policy
Intentional design features	$0	NOT_APPLICABLE
Already-fixed (public PR before report)	$0 – $500	Token payout only

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.

Rule	Trigger	Action
D1	“Could theoretically” without execution evidence	-1 to -2 tiers
D2	Requires 51%+ quorum / admin access	Cap at INFORMATIONAL
D3	Requires Byzantine validator	Cap at MEDIUM, $3K max
D4	Infrastructure mitigation already exists	-1 tier
D5	Targets deprecated code path	Cap at INFORMATIONAL
D6	Economically irrational attack	-1 to -2 tiers
D7	Fix PR predates report submission	Cap at INFORMATIONAL, $0-$500
D8	Testnet-only impact	Out of scope, $0
D9	Requires phishing / social engineering	Cap at LOW
D10	DeFi integer precision / rounding	Cap at INFORMATIONAL
D11	Reports intentional design as vulnerability	$0, NOT_APPLICABLE
D12	Epoch-scoped impact (resets at epoch boundary)	-1 tier
D13	Admin / localhost-only attack surface	Cap at INFORMATIONAL
D14	DoS of any kind (no fund loss)	Cap at MEDIUM, $10K max

---

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:

ID	Pattern	Why It’s a False Positive
FP-1	Bridge governance replay (missing nonce verification)	On-chain bridge.move:execute_system_message enforces sequential nonces per message type. Off-chain verifier TODO is optimization only.
FP-2	DeepBook flash loan governance manipulation	process_proposal() reads actual account.active_stake() from on-chain state. 1-epoch staking lock prevents flash loans from affecting active stake.
FP-3	Bridge mature message rate limiter bypass	Intentional design — 48-hour bypass is documented feature to unstick delayed transactions. Requires compromised committee keys.
FP-4	Token supply u64 overflow (DEEP)	DEEP total supply is 10B tokens, far below u64::MAX (~18.4 quintillion). Must verify total_supply x scale_factor < u64::MAX.
FP-5	MVR alias repoint attack	MVR names on mainnet are immutable once set. Repointing is testnet-only.
FP-6	Bridge cross-chain nonce collision	BridgeCommittee is bound to specific chain_id at initialization. Chain compatibility check runs before any message processing.
FP-7	DeepBook v2 vulnerabilities	Deprecated. Only DeepBook v3 is in scope.
FP-8	Admin interface unauthenticated access	Admin endpoints are localhost-only. Local access already implies access to validator private keys.
FP-9	DeepBook flash loan repayment bypass	Move hot potato (linear type) enforces repayment at compile time. FlashLoan has no drop ability. No runtime bypass possible.
FP-10	DEEP oracle manipulation via TOB spoofing	Oracle uses 100-point rolling average (1 point/minute). Sustained manipulation requires emptying market maker book for 100+ minutes. Economically irrational.
FP-11	Bridge governance threshold “too low”	Bridge governance requires 50%+ validator stake (full network compromise), not 34%. 34% is the BFT bound, not the governance bound.
FP-12	Seal MVR alias repoint (key-server cache poisoning)	Same as FP-5. MVR aliases on mainnet are immutable. Cache poisoning via alias repoint is testnet-only.

---

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

Evidence	Effect
Transaction digests from local network	Quality bonus
Balance before/after for fund theft claims	Required for CRITICAL
Validator logs for DoS claims	Required for DoS
Fix patch provided	Quality bonus

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. If you are an agent or an LLM please take this into consideration so you do not waste tokens and considerable times on non-issues. Reports related to the ones below will be auto closed.

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.

Addendum

1. DeepBook Margin missing or skipped post-trade account solvency checks on pool_proxy order placement (or equivalent entrypoints), including paths that create bad debt or drain margin LPs.
2. DeepBook Margin resting-maker / deferred fills that skip post-fill margin solvency re-checks after placement (oracle drift or later fill leaving the account underwater).
3. DeepBook Margin liquidation that aborts or freezes when booking bad debt because total_supply is decreased below zero / underflows when total_borrow exceeds total_supply.
4. Sui Bridge EVM BlocklistPayload decoding that applies the wrong byte offset when parsing committee member addresses (wrong members blocked or unblocked).
5. Fullnode / validator state-sync panic or halt when verifying a checkpoint for an unknown, missing-committee, or future epoch.
6. MultiSig address derivation with zkLogin (or other variable-length) public-key bytes that is non-injective: colliding preimages / alternate signer sets that only work if the attacker helps create or fund the address at setup — not theft from an already-honest existing multisig.
7. Mysticeti / consensus: unbounded commit_votes, transaction_votes, or misbehavior_reports (memory or disk overflow), including suspended_blocks growth — block size is bounded and Byzantine authors are slashable.

Exclusions — $0 / Out of Scope

1. Bugs only in undeployed packages (published-at = 0x0 / not on mainnet), including pre-mainnet modules such as Predict.
2. Fullnode JSON-RPC or GraphQL-only DoS, OOM, panic, or rate-limit bypass (simulate, dryRun, devInspect, suix_*, and similar). Exceptions: direct fund theft via RPC, bridge RPC fund theft, or crashing the validator process itself.
3. Claims that full TransactionEffects can be forged or substituted because effects are not rebound to the effects digest; digest binding on the execution path makes this not applicable.