Walrus Protocol: Program info

The Walrus Bug Bounty Program is designed to encourage security researchers to help identify vulnerabilities that affect the security, reliability, and economic integrity of the Walrus decentralized storage protocol. Walrus uses two-dimensional erasure coding ("Red Stuff"), a Sui-based control plane for node lifecycle and blob management, and an economic model based on staking and governance.

Scope

• Smart Contracts and On-Chain Logic:

  • Sui Move contracts governing blob registration, storage resource management, shard migration, and staking/governance.

• Core Protocol Components:

  • The "Red Stuff" encoding/decoding algorithms and data commitment mechanisms.
  • Availability certificate generation and verification.

• Storage Nodes and Aggregators:

  • Storage node REST APIs: sliver storage, metadata handling, recovery protocols.
  • Aggregator HTTP APIs: blob upload and download paths.
  • Denial of service through crafted requests (not brute-force flooding).

• Economic and Incentive Mechanisms:

  • Pricing and payment mechanisms for storage and write operations.
  • Fee enforcement (including protections against zero or near-zero cost storage).
  • Commission rates and staking reward calculations.

Scope Details

• Smart contracts: Code in contracts/ (development branch) is in scope unless it is clearly marked as work-in-progress (for example, with a TODO comment indicating the code is part of an incomplete feature). Code deployed on mainnet or testnet (mainnet-contracts/, testnet-contracts/) is in scope unless it is already fixed in the development branch or being fixed with an open PR.
• Storage nodes and aggregators: Vulnerabilities must be externally triggerable against an unmodified storage node or aggregator running the latest mainnet release. The attacker must interact only through public APIs or the Sui blockchain; vulnerabilities that require direct access to the node's filesystem or internal network are out of scope.
• Rewards: All severities use ranges. The final payout within each range is determined at the Walrus team's discretion based on impact, exploitability, and the attacker model (see Severity Guidelines).

Attacker Model and Severity Adjustment

The attacker model significantly affects severity classification. In decreasing order of severity:

1. Free attacks: The attacker only needs a Sui account and network access (no cost beyond gas fees). These receive the highest matching severity rating.
2. Attacks that cost money: The attacker must purchase storage resources or stake tokens. Severity may be reduced by one level if the cost of the attack is proportional to the damage caused.
3. Attacks requiring malicious or compromised storage nodes: The attacker must operate or compromise a storage node. Severity is reduced by at least one level, since this is a significantly higher barrier.

The Walrus team retains final discretion over severity classification and payout amount. The examples below are guidelines.

Severity Guidelines

Critical (USD 20,000-100,000)

• Theft of funds (for example, accumulated rewards) exceeding $100,000 in notional value from the Walrus system contract.
• Unauthorized or unintended deletion or irreversible corruption of other users' stored blob data.
• Any vulnerability that, if exploited on mainnet, could result in loss of funds exceeding $100,000.

High (USD 5,000-20,000)

• Economic abuse: storing data while paying zero or near-zero fees, bypassing fee controls or staking requirements.
• Integrity and availability breaches: forging availability certificates or subverting the recovery mechanism such that legitimate data cannot be recovered.
• Economic manipulation: partially manipulating fee payments, commission rates, or staking rewards to gain an unfair advantage.
• Authentication and authorization flaws: impersonating a storage node or bypassing access controls, even if not directly causing data loss.
• Full DoS of the network with no recovery without a hard fork.

Medium (USD 2,000-5,000)

• Denial of service of the aggregator through crafted requests (not brute-force flooding).
• Partial economic manipulation with limited financial impact.
• Vulnerabilities that degrade availability or performance for specific users or blobs.

Low (USD 500-2,000)

• Minor information disclosure from storage nodes or aggregators (for example, internal metadata that does not compromise data integrity).
• Denial of service affecting a single storage node but not the broader network.
• Edge-case bugs in encoding, recovery, or contract logic with minimal practical impact.

Payout Structure

• Currency: Rewards may be paid in USD or WAL tokens at the discretion of the Walrus Foundation.
• Reward adjustments: Final payout within the severity range is determined based on impact, ease of exploitation, attacker model, and potential damage. Multiple reports on the same root cause will be consolidated and only the first valid report is eligible for a reward.
• Data integrity and economic bugs: Vulnerabilities that allow unauthorized deletion of data or storage at near-zero cost are weighed more heavily within their severity range.
• Eligibility: Only vulnerabilities affecting the latest mainnet release or testnet deployment of Walrus are eligible. Bugs in development-branch code that has not been deployed are only eligible if they affect code that is expected to be deployed as-is (see Scope).
• Payout timeline: The Walrus team aims to confirm severity within 14 business days of a valid report and issue payment within 30 business days of confirmation.

Out of Scope

• Denial-of-service (DoS) through network-layer flooding or brute-force traffic that does not exploit a protocol-level vulnerability.
• Third-party libraries or platforms unmodified from their official release, unless the integration introduces a vulnerability.
• Issues found only in unsupported test environments with no production impact.
• Social engineering, phishing, or non-technical attacks.
• Vulnerabilities requiring physical access to a node or relying solely on user misconfiguration.
• Theoretical impacts without a proof of concept or demonstration.
• Smart contract code in the development branch that is clearly marked as work-in-progress (TODO, WIP) or that has never been deployed.
• The wal_exchange contract (testnet-only, intentionally kept simple).
• The subsidies contract (no longer used, replaced by walrus_subsidies).
• CSRF with no state-modifying security impact.
• Missing HTTP security headers or cookie flags without demonstrated impact.
• Server-side non-confidential information disclosure (IPs, server names, stack traces).
• Lack of SSL/TLS best practices.
• SPF/DMARC misconfigurations.
• UI/UX issues that do not materially affect security or availability.
• Automated scanner reports without demonstrated impact.

• Do not use web application scanners or automated tools that generate massive traffic against production infrastructure.
• Make every effort not to damage or restrict the availability of products, services, or infrastructure.
• Do not compromise personal data or degrade any service.
• Do not access or modify other users' data; restrict all testing to your own accounts and resources.
• Perform testing only within the defined scope.
• Do not exploit DoS/DDoS vulnerabilities, social engineering attacks, or spam.
• Do not spam forms or account creation flows with automated scanners.
• For chained vulnerabilities, only the vulnerability with the highest severity is eligible for a reward.
• Do not break any law and stay within the defined scope.
• Do not share details of any vulnerability with anyone who is not on the HackenProof team or an authorized employee of the Walrus team without prior written permission.
• Do not submit reports generated by running generic LLM prompts against the codebase. Such reports will be discarded without review.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express written consent from the Walrus team.
• No vulnerability disclosure, including partial disclosure, is allowed at this time.
• Do not publish or discuss bugs publicly.

We are happy to thank everyone who submits valid reports that help us improve security. However, only reports meeting the following requirements are eligible for a monetary reward:

• You must be the first reporter of the vulnerability.
• The vulnerability must be a qualifying vulnerability within the defined scope.
• Any vulnerability must be reported no later than 24 hours after discovery and exclusively through hackenproof.com.
• You must provide a clear textual description of the vulnerability along with steps to reproduce the issue. Include attachments such as screenshots or proof-of-concept code as necessary.
• You must not be a current or former employee of Mysten Labs, the Walrus Foundation, or any of their contractors.
• You must use the email address under which you registered your HackenProof account. Reports from other addresses are not eligible for a bounty.
• Provide detailed but concise reproduction steps.

Proof-of-concept requirements:

• The PoC must be externally triggerable against an unmodified storage node, aggregator, or Sui smart contract.
• The PoC must be reproducible using a local test environment set up with the instructions in the appendix, or demonstrable against testnet/mainnet.
• For medium severity and above, a working PoC is mandatory. Reports without a PoC will be closed.