Bug Bounty Program

XEX ("we," "us," "our," or the "Company") is committed to maintaining the highest standards of security for our platform, users, and their assets. We recognize that independent security researchers play a vital role in identifying vulnerabilities that may not be discovered through internal testing. The XEX Bug Bounty Program ("Program") provides a structured framework for security researchers ("Researchers" or "you") to report potential security vulnerabilities in exchange for monetary rewards. By participating in this Program, you agree to comply with all terms and conditions set forth herein. XEX reserves the sole and absolute discretion to modify, suspend, or terminate this Program at any time and for any reason without prior notice.

1. Program Scope

1.1 In-Scope Assets

The following assets and services are within the scope of this Program and are eligible for bug bounty rewards:

• Web Application: The XEX web application hosted at xex.to and app.xex.to, including all publicly accessible pages, authenticated user interfaces, account management features, trading interfaces, and administrative functions accessible to end users.
• API Endpoints: All public and authenticated REST API and WebSocket API endpoints provided by XEX for trading, account management, market data, and other platform functionality, as documented in XEX's official API documentation.
• Mobile Applications: Official XEX mobile applications distributed through the Apple App Store and Google Play Store, including all features and functionality available through the mobile interface.
• Smart Contracts: Any smart contracts deployed by XEX on public blockchain networks, including but not limited to token contracts, staking contracts, bridge contracts, escrow contracts, and any other on-chain programs authored and deployed by XEX.

1.2 Out-of-Scope Assets

The following are explicitly excluded from the scope of this Program. Reports involving out-of-scope items will not be eligible for rewards and may not receive a response:

• Third-Party Services: Vulnerabilities in third-party services, libraries, frameworks, plugins, or integrations that are not authored or maintained by XEX, even if they are used by or accessible through the XEX platform. Researchers should report such vulnerabilities directly to the responsible third party.
• Social Engineering: Attacks that rely on social engineering, phishing, pretexting, baiting, or other techniques targeting XEX employees, contractors, users, or partners. This includes any attempt to manipulate individuals into divulging confidential information or performing actions that compromise security.
• Physical Attacks: Any attack requiring physical access to XEX facilities, hardware, servers, network infrastructure, or employee devices.
• Denial of Service: Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks, resource exhaustion attacks, and any other attacks intended to disrupt the availability of XEX services for other users.
• Spam and Rate Limiting: Reports related to the absence of rate limiting on non-critical endpoints, email or SMS bombing, or other forms of spam.
• Content Injection Without Impact: Self-XSS, content spoofing, or text injection that does not demonstrate a realistic attack scenario or meaningful impact on other users.
• Previously Reported Vulnerabilities: Vulnerabilities that have already been reported by another Researcher or are already known to XEX.
• Theoretical Vulnerabilities: Purely theoretical vulnerabilities without a working proof of concept or demonstrated impact.

2. Eligible Vulnerabilities

Vulnerabilities are categorized by severity based on their potential impact on the confidentiality, integrity, and availability of XEX systems, user data, and user funds. XEX uses a modified version of the Common Vulnerability Scoring System (CVSS v3.1) as a guideline, with adjustments based on the specific context and risk to the XEX platform. The final severity classification and reward amount are determined solely by XEX.

2.1 Critical Severity ($10,000 – $100,000)

Critical vulnerabilities are those that could result in a direct and significant compromise of user funds, platform integrity, or core security mechanisms. Examples include, but are not limited to:

• Remote Code Execution (RCE) on XEX production servers or infrastructure, enabling an attacker to execute arbitrary commands or code.
• SQL injection or NoSQL injection vulnerabilities that allow unauthorized access to, modification of, or deletion of database records, including user data, balances, or transaction records.
• Authentication bypass allowing an attacker to access any user account without valid credentials, including but not limited to bypass of multi-factor authentication, session hijacking affecting arbitrary users, or complete authentication mechanism failure.
• Direct theft or unauthorized transfer of user funds, including manipulation of balances, withdrawal bypasses, or exploitation of smart contract vulnerabilities enabling fund extraction.
• Smart contract vulnerabilities that allow reentrancy attacks, unauthorized minting or burning of tokens, manipulation of oracle data to extract value, or bypassing of access controls on privileged contract functions.
• Cryptographic failures that compromise the integrity of transaction signing, key management, or encryption of sensitive data at rest or in transit.

2.2 High Severity ($2,500 – $10,000)

High-severity vulnerabilities could lead to significant compromise of user data, partial loss of funds, or elevation of privileges. Examples include:

• Stored or reflected cross-site scripting (XSS) that can be used to steal session tokens, perform actions on behalf of other users, or exfiltrate sensitive data from authenticated sessions.
• Cross-site request forgery (CSRF) that enables an attacker to perform significant state-changing actions on behalf of an authenticated user, such as initiating withdrawals, modifying security settings, or changing account credentials.
• Privilege escalation allowing a regular user to access administrative functions, other users' accounts, or restricted data not intended for their access level.
• Sensitive data exposure, including the disclosure of personally identifiable information (PII), financial records, API keys, private keys, or other confidential data through unprotected endpoints, insecure direct object references, or improper access controls.
• Server-side request forgery (SSRF) that can be used to access internal services, cloud metadata endpoints, or otherwise pivot within XEX's internal network.
• Insecure deserialization vulnerabilities that could be exploited to execute code, bypass authentication, or manipulate application logic.

2.3 Medium Severity ($500 – $2,500)

Medium-severity vulnerabilities expose information or enable actions that could facilitate further attacks or result in limited compromise. Examples include:

• Information disclosure vulnerabilities that reveal internal system information, stack traces, debug information, configuration details, or source code that could aid an attacker in planning further attacks.
• Insecure configurations, including but not limited to misconfigured CORS policies, overly permissive security headers, exposed administrative interfaces without adequate protection, or missing security-relevant HTTP headers.
• Business logic vulnerabilities that allow circumvention of intended restrictions, such as bypassing withdrawal limits, manipulating order matching, or exploiting race conditions in non-critical flows.
• Subdomain takeover vulnerabilities where an attacker could claim control of a subdomain used by XEX.
• Path traversal vulnerabilities that allow reading of files outside the intended directory, where the impact is limited to non-sensitive files.

2.4 Low Severity ($100 – $500)

Low-severity vulnerabilities represent minor security issues or best practice violations with limited direct impact. Examples include:

• Violations of security best practices that do not present an immediate exploitable vulnerability, such as missing security headers on non-sensitive pages, use of deprecated but not yet vulnerable libraries, or verbose error messages on non-critical endpoints.
• Minor information leaks, such as disclosure of software version numbers, server technology fingerprints, or non-sensitive configuration details.
• Clickjacking on pages with no sensitive actions.
• Cookie-related issues such as missing Secure or HttpOnly flags on non-session cookies.
• Open redirect vulnerabilities that require user interaction and do not facilitate token theft or credential capture.

3. Reward Tiers

The following table summarizes the reward tiers for eligible vulnerability reports. Actual reward amounts within each tier are determined by XEX based on the severity, impact, quality of the report, and novelty of the vulnerability. XEX's determination of the reward amount is final and binding.

Rewards are paid in USDT (Tether) or USDC (USD Coin) at XEX's discretion, deposited to the Researcher's XEX account. Researchers must have a verified XEX account in good standing to receive payment. XEX may, at its sole discretion, offer bonus payments for exceptionally well-written reports, novel vulnerability classes, or vulnerabilities with particularly high potential impact. Rewards are subject to applicable tax withholding and reporting requirements, and Researchers are solely responsible for any tax obligations arising from bounty payments.

4. Responsible Disclosure Rules

Participation in this Program is contingent upon strict compliance with the following responsible disclosure rules. Failure to comply with any of these rules may result in disqualification from the Program, forfeiture of any pending rewards, and potential legal action:

• Do Not Access Other Users' Data: Do not access, download, modify, or exfiltrate data belonging to any XEX user other than your own test accounts. If you inadvertently encounter another user's data during testing, immediately stop, do not record or store the data, and report the finding.
• Do Not Modify or Delete Data: Do not alter, delete, corrupt, or otherwise modify any data on XEX systems, including but not limited to user records, transaction data, configuration files, logs, or database entries.
• Do Not Perform Denial of Service: Do not conduct any testing that could degrade, disrupt, or deny service to XEX or its users, including load testing, stress testing, resource exhaustion, or any form of DoS or DDoS attack.
• Report Promptly: Report discovered vulnerabilities to XEX within twenty-four (24) hours of initial discovery. Do not continue testing or attempting to exploit a confirmed vulnerability beyond what is necessary to produce a minimal proof of concept.
• Provide Clear Reproduction Steps: Submit a detailed report including a clear description of the vulnerability, step-by-step reproduction instructions, the potential impact, any affected endpoints or parameters, and relevant screenshots, logs, or proof-of-concept code.
• Allow Time to Remediate: Do not publicly disclose, discuss, or share any details of a reported vulnerability for a period of ninety (90) calendar days from the date of your report, or until XEX has confirmed that the vulnerability has been remediated, whichever is later. Public disclosure before this period without XEX's written consent will result in forfeiture of any reward and may result in legal action.
• Use Dedicated Test Accounts: Conduct all testing using accounts that you own and control. Do not test against accounts belonging to other users or use compromised credentials obtained from data breaches or other illicit sources.
• No Automated Mass Scanning: Do not perform automated mass scanning that generates excessive traffic or could be mistaken for an attack. Targeted, controlled automated testing is permitted provided it does not degrade service.

5. Safe Harbor

XEX values the contributions of security researchers and will not pursue civil or criminal legal action against Researchers who discover and report vulnerabilities in good faith and in compliance with all of the following conditions:

• The Researcher complies with all terms and conditions of this Program, including the responsible disclosure rules set forth in Section 4 above.
• The Researcher acts in good faith and does not exploit the vulnerability beyond the minimum extent necessary to demonstrate its existence and confirm its impact through a proof of concept.
• The Researcher does not intentionally access, store, or exfiltrate data belonging to other users, does not degrade or disrupt XEX services, and does not cause damage to XEX systems or infrastructure.
• The Researcher does not publicly disclose the vulnerability before the expiration of the disclosure period described in Section 4 without the prior written consent of XEX.
• The Researcher is not located in, or acting on behalf of any entity in, a jurisdiction subject to comprehensive economic sanctions imposed by the United States, the European Union, or the United Nations.
• The Researcher has not previously been banned or removed from the Program for violating these terms.

This safe harbor provision does not apply to violations of law that are independent of the Researcher's participation in this Program. XEX reserves the right to determine, in its sole discretion, whether a Researcher's conduct qualifies for safe harbor protection, and such determination is final and non-appealable. Safe harbor protection may be revoked retroactively if XEX later discovers that the Researcher engaged in conduct that violates these terms.

6. Submission Process

Vulnerability reports must be submitted by email to:

Email: security@xex.to

XEX provides a PGP public key for encrypted email submissions. The PGP key is available at https://xex.to/.well-known/security.txt and on major public keyservers. Researchers are strongly encouraged to encrypt sensitive vulnerability reports, particularly those involving critical or high-severity findings.

Each submission must include the following information:

• Vulnerability Description: A clear and concise description of the vulnerability, including the affected asset(s), the vulnerability class (e.g., XSS, CSRF, RCE), and the root cause of the issue.
• Steps to Reproduce: Detailed, step-by-step instructions for reproducing the vulnerability, including all required URLs, parameters, payloads, headers, and authentication details. Reports that cannot be reproduced by XEX's security team may not be eligible for a reward.
• Impact Assessment: An assessment of the potential impact of the vulnerability, including the types of data or assets at risk, the potential for exploitation at scale, and any mitigating factors.
• Proof of Concept: Any supporting evidence, including screenshots, screen recordings, HTTP request/response logs, exploit code, or other materials that demonstrate the vulnerability. Proof-of-concept code should be minimally invasive and should not include destructive payloads.
• Researcher Information: Your name (or pseudonym), contact email address, and XEX account identifier for reward payment purposes.

XEX will acknowledge receipt of valid submissions within three (3) business days. Initial triage and severity assessment will typically be completed within ten (10) business days. XEX may request additional information, clarification, or collaboration during the evaluation process. The Researcher agrees to cooperate in good faith with XEX during the investigation and remediation of the reported vulnerability.

7. Exclusions

The following categories of reports are not eligible for rewards under this Program, and XEX is under no obligation to respond to or acknowledge such reports:

• Automated Scanner Output: Reports generated solely by automated vulnerability scanners (such as Nessus, Qualys, Burp Suite automated scan, OWASP ZAP, or similar tools) without manual validation, analysis, or demonstrated proof of exploitability. Researchers must manually verify and contextualize any findings from automated tools before submission.
• Known Vulnerabilities: Vulnerabilities that are already known to XEX, have been previously reported, or are currently being remediated. XEX maintains an internal vulnerability tracker and will compare all incoming reports against known issues.
• Recently Disclosed Zero-Days: Vulnerabilities in third-party software or libraries that have been publicly disclosed within the preceding thirty (30) days ("0-day vulnerabilities"), where XEX has not yet had a reasonable opportunity to apply available patches or mitigations. Reports of such vulnerabilities will be accepted for informational purposes but will not be eligible for a reward.
• Third-Party Dependencies: Vulnerabilities in third-party software, libraries, or services used by XEX that are not within XEX's control to remediate. Researchers should report such vulnerabilities to the responsible upstream maintainer or vendor. XEX may, at its discretion, provide a courtesy reward for reports of critical vulnerabilities in dependencies that directly and significantly affect XEX users.
• Duplicate Reports: Only the first valid report of a given vulnerability is eligible for a reward. If multiple Researchers independently discover and report the same vulnerability, the reward will be granted to the Researcher who submitted the first complete and valid report, as determined by XEX's records. Duplicate reports will be acknowledged but will not receive a reward.
• Non-Qualifying Issues: Reports that do not describe a security vulnerability, including feature requests, usability complaints, performance issues, typos, or general questions about security practices.
• Sanctioned Individuals: Reports from individuals or entities that are located in, organized under, or residents of jurisdictions subject to comprehensive sanctions, or that are listed on any applicable sanctions list, are not eligible for rewards.

By participating in this Program, you acknowledge that you have read, understood, and agree to all terms and conditions set forth herein. XEX reserves the right to amend, modify, suspend, or terminate this Program and any of its terms at any time, at its sole discretion, with or without notice. Any disputes arising from or related to this Program shall be resolved in accordance with the dispute resolution provisions of the XEX Terms of Service.