Program Overview

Program Rules

Only test against assets explicitly listed in scope
Do not access, modify, or delete data belonging to other users - create your own test accounts
Do not publicly disclose vulnerability details until we confirm the issue is patched and deployed
Do not perform denial-of-service (DoS/DDoS) attacks against any OOOSec infrastructure
Do not use automated scanners or tools that generate excessive traffic or degrade service availability
Do not attempt phishing, social engineering, or any physical attacks against OOOSec team members or users
Do not test against third-party services we integrate with
Submit one vulnerability per report — do not bundle unrelated issues
Provide clear, reproducible steps with a working proof of concept (PoC)
Do not exploit any vulnerability beyond the minimum required to demonstrate impact
Reports generated solely by AI/automated tools without manual validation will be considered spam
Bug reports covering previously-discovered or known issues are not eligible for reward
If you discover a vulnerability affecting a third-party component, notify the component owner before reporting

Eligibility

You must comply with all applicable local and international laws
You must reside outside of countries restricted by OFAC sanctions and UNSC resolutions
Government-issued identification may be requested for critical severity submissions

We use a 4-tier severity model based on real-world impact:

Severity	Description
Critical	Direct access to sensitive user data, authentication bypass, privilege escalation to admin, remote code execution, unauthorized fund movement
High	Significant data exposure, stored XSS affecting other users, IDOR with sensitive data access, authorization flaws between roles
Medium	Limited data exposure, CSRF on state-changing actions, information disclosure that aids further attacks
Low	Minor security issues with limited impact, verbose error messages leaking internal details, minor misconfiguration

All submissions must include:

Reports without sufficient reproduction details may be closed as informational.

Program Rules

Only test against assets explicitly listed in scope

Do not access, modify, or delete data belonging to other users - create your own test accounts

Do not publicly disclose vulnerability details until we confirm the issue is patched and deployed

Do not perform denial-of-service (DoS/DDoS) attacks against any OOOSec infrastructure

Do not use automated scanners or tools that generate excessive traffic or degrade service availability

Do not attempt phishing, social engineering, or any physical attacks against OOOSec team members or users

Do not test against third-party services we integrate with

Submit one vulnerability per report — do not bundle unrelated issues

Provide clear, reproducible steps with a working proof of concept (PoC)

Do not exploit any vulnerability beyond the minimum required to demonstrate impact

Reports generated solely by AI/automated tools without manual validation will be considered spam

Bug reports covering previously-discovered or known issues are not eligible for reward

If you discover a vulnerability affecting a third-party component, notify the component owner before reporting

Severity Classification

We use a 4-tier severity model based on real-world impact:

Severity	Description
Critical	Direct access to sensitive user data, authentication bypass, privilege escalation to admin, remote code execution, unauthorized fund movement
High	Significant data exposure, stored XSS affecting other users, IDOR with sensitive data access, authorization flaws between roles
Medium	Limited data exposure, CSRF on state-changing actions, information disclosure that aids further attacks
Low	Minor security issues with limited impact, verbose error messages leaking internal details, minor misconfiguration

Proof of Concept Requirements

All submissions must include:

A clear description of the vulnerability and its security impact

Step-by-step reproduction instructions that our team can follow

Screenshots, screen recordings, or HTTP request/response logs as evidence

For web vulnerabilities: the affected URL, parameters, and payload used

Any necessary environment details (browser, OS, wallet type)

Reports without sufficient reproduction details may be closed as informational.