Responsible disclosure & bug bounty policy

Scope

What we pay

Reward basis: demonstrated impact on our systems or customers. Amounts are in USD.

Rules of engagement

1. First valid report wins. No payout is issued for duplicates or for issues we already know about. Payout scope: one per root cause, independent of how many endpoints it hits.
2. Prove it, then stop. Access only your own accounts and data. On any test that would expose someone else's data: stop at first proof, report, and do not pivot, download or persist.
3. Do not degrade the service. Prohibited: load testing, automated fuzzing at volume, and testing of proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
4. Give us time. No publication until the issue is fixed and 30 days have elapsed. You get notified when a fix is deployed.
5. Severity is ours to set. We rate impact as it applies to our own systems, with the Bugcrowd Vulnerability Rating Taxonomy as reference. Amounts are discretionary within the ranges above, and payment goes out by PayPal or USDT.

What we do not pay for

Maximum accepted severity for these: Low or Informational. We review them and fix anything worth fixing; no bounty is issued, regardless of a Critical or High label on the report.

• Session persistence after logout, password change or password reset, lasting until the session token expires
• Absent or “weak” security headers, e.g. CSP, HSTS, X-Frame-Options, Referrer-Policy, with no working exploit
• Clickjacking on pages exposing no sensitive action
• Non-session cookies and the attributes they carry
• Username or email enumeration, including timing and error-message side channels
• Observations on rate limits, login or forgot-password flows without a shown account takeover
• Subjective password-policy points: length, complexity, common-password lists, no forced rotation
• 2FA unavailable, or two-factor authentication not required
• Self-XSS and other XSS that only the attacker can execute in their own session
• CSRF on non-sensitive forms (login, logout, language, etc.)
• Open redirects without token or credential leakage
• Software version, server banner, stack trace or path leaks free of sensitive data
• SPF, DKIM or DMARC configuration reports
• Automated-scan output missing a proof of concept
• DoS, resource-exhaustion or brute-force attempts, or any load-generating test
• Social-engineering or phishing attempts on our staff or customers; physical attacks of any kind
• Third-party flaws in services we use, e.g. payment processors, Telegram, Cloudflare, email providers
• Outdated library versions lacking a working exploit on our deployment
• Exploits requiring a rooted phone, a man-in-the-middle position or a compromised device
• Best-practice recommendations, purely theoretical risks and duplicate reports of known issues

Policy last updated 2026-10-17.