Whitechain: Program info

Documentation (including all L1&L2 addresses)

IN-SCOPE VULNERABILITIES: WEB, API & NODE INFRASTRUCTURE

We welcome reports demonstrating a reproducible security impact on the assets explicitly listed in this program.

Web Applications, APIs & Storage

• Business logic vulnerabilities resulting in unauthorized actions or bypass of security controls.
• Broken authentication, account takeover, and exploitable session management or password reset vulnerabilities.
• Broken access control, including IDOR, privilege escalation, and unauthorized access to administrative functionality.
• Remote code execution, command injection, SQL injection, XXE, and other exploitable injection vulnerabilities.
• Server-side request forgery (SSRF).
• Local or remote file inclusion, path traversal, and arbitrary file read or write.
• Cross-site scripting (XSS) affecting other users.
• Cross-site request forgery (CSRF) resulting in security-sensitive actions.
• Exposure of sensitive non-public information, credentials, or secrets with demonstrated security impact.
• Unauthorized access to, modification of, or deletion of storage objects.
• Other vulnerabilities demonstrating a concrete impact on confidentiality, integrity, or availability.

JSON-RPC & Node Interfaces

• Unauthorized access to privileged RPC methods or node management functionality.
• Crafted requests or P2P messages that trigger a reproducible node crash, persistent synchronization failure, or disproportionate resource consumption.
• Vulnerabilities in execution-layer or consensus-layer processing that cause acceptance of invalid data, incorrect state transitions, or chain divergence.
• Security control bypasses affecting the listed RPC endpoints or explicitly listed P2P interfaces.

Vulnerabilities in third-party components are eligible where they demonstrably affect an in-scope Whitechain deployment. The presence of a dependency or a reference in the repository does not independently bring other assets into scope.

OUT-OF-SCOPE FINDINGS

• Findings affecting assets, networks, contracts, or services not explicitly included in the program scope.
• Hypothetical vulnerabilities, unverified scanner output, or version-based claims without a reproducible proof of concept.
• Missing security headers, cookie flags, TLS hardening, or other best-practice recommendations without demonstrated security impact.
• Public login panels, open ports, enabled HTTP methods, software banners, stack traces, or path disclosures without an exploitable security consequence.
• Access to intentionally public blockchain data, public RPC methods, or public storage objects.
• Exposed public identifiers or API keys without demonstrated unauthorized access or other security impact.
• Self-XSS, cosmetic content spoofing, or response modifications affecting only the researcher's own browser.
• Open redirects, clickjacking, account enumeration, or rate-limit bypasses without demonstrated additional security impact.
• Login/logout CSRF or CSRF affecting anonymous forms without a security-sensitive consequence.
• Normal faucet usage, accumulation of test tokens, or exhaustion of faucet allocations without a separate security vulnerability.
• Expected transaction reverts, invalid-input rejection, normal synchronization delays, or failures caused solely by insufficient local resources.
• Attacks requiring pre-existing administrative access, compromised private keys, physical access, or control over the victim's device, unless that access is obtained through an in-scope vulnerability.
• Mobile applications and browser extensions, unless explicitly added to the asset list.
• Known OP Stack issues, technical edge cases, structural limitations.

TESTING RULES & DENIAL OF SERVICE

Protocol-level denial-of-service vulnerabilities are eligible, but disruptive testing against shared infrastructure requires prior written authorization.

• Demonstrate availability issues on a researcher-controlled local environment or an environment explicitly designated by the Whitechain team.
• Obtain prior written authorization before attempting to crash, overload, or disrupt any shared Whitechain node or public service. Authorization must specify the targets, testing window, and traffic limits.
• Volumetric DDoS, unrestricted request flooding, transaction spam, and deliberate exhaustion of shared infrastructure are prohibited.
• Social engineering, phishing, unsolicited messaging, and destructive modification or deletion of other users' data are prohibited.
• Use researcher-controlled accounts, wallets, and data wherever possible, and stop once the impact is demonstrated.

PROOF OF CONCEPT & TESTNET IMPACT

Reports must identify the affected asset, reproduction steps, relevant software version or configuration, and demonstrated security impact.

Local proofs of concept are accepted when they reproduce the relevant in-scope software and configuration. Clearly document any differences from the Whitechain deployment.

For resource-exhaustion findings, include the attacker's required resources, the impact on the affected node, and recovery requirements.

Severity is assessed by the demonstrated security impact. Test tokens having no monetary value does not automatically invalidate a protocol vulnerability; hypothetical mainnet losses alone do not establish severity.

• 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
• All communication regarding the program must take place exclusively through the HackenProof platform. Contacting the project team directly through support channels, social media, or any other external communication channels is strictly prohibited. Researchers who violate this rule may be disqualified from the program and may face account suspension.

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
• ONLY USE the EMAIL under which you registered your HackenProof account (in case of violation, no bounty can be awarded)
• Provide detailed but to-the point reproduction steps
• AI-generated reports without runable PoC are not accepted under this program.

• 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
• Platform-Only Disclosure: Disclosure is only possible through the HackenProof Disclosure function
• Researchers must not contact the project team directly regarding any findings, questions, or bounty-related matters. All communication must be conducted through the HackenProof platform only
• Researchers may request disclosure (Limited or Full) within the report ticket
• We reserve the right to approve, redact, or deny disclosure requests at our sole discretion
• Mutual Required: Any publication requires explicit mutual agreement. Reports must remain Private until the status is officially changed to "Public" on the HackenProof platform by the team.