Bug Bounty Programme

ZABET1 rewards security researchers who find and responsibly report vulnerabilities in our platform. This page sets out what is in scope, how rewards are decided, how to submit a report and the rules that protect both sides.

Last updated: 6 October 2026

1. Introduction

We run a real-money platform. People trust us with their funds, their identity documents and their play history, and we would rather hear about a weakness from a researcher than from a player who has lost money because of it.

So we welcome reports from the security community. If you have found a way to break something on zabet1.com — read data you should not be able to read, move funds you do not own, take over an account, bypass a control — we want to know, we will fix it, and where the finding is genuine and new we will reward you for it.

This programme is open to anyone, with the exceptions listed in section 7. There is no application process: find something, report it, and we will take it from there.

2. Rewards

Rewards are paid in USDT. There is no fixed minimum and no fixed maximum, and the amount is decided by ZABET1 at our discretion after we have reproduced and assessed the issue.

We deliberately do not publish a price list. What we pay depends on how much real damage the issue could do, how reliably it can be exploited, how much of the platform or how many users it touches, and how clear and complete your report was. A well-written report that hands us a working reproduction is worth more to us than a vague one describing the same bug, and we pay accordingly.

We set the severity, not the reporter. If you disagree with our assessment, tell us why — if your reasoning shows an impact we missed, we will revise it.

3. In scope

• The zabet1.com website and its subdomains.
• Registration, login, session handling, password reset and phone or email verification.
• Account and profile flows, including KYC document upload and identity verification.
• Wallet flows: deposit address generation, withdrawal requests, withdrawal address handling, transaction history and balance logic.
• Bonus, promotion, affiliate and rewards logic, including wagering and eligibility checks.
• Public and authenticated APIs used by the site.
• The game-launch integration — how sessions and launch tokens are issued and validated when a game is opened.
• Business-logic flaws anywhere in the above, even where no classic vulnerability class applies.

If you are unsure whether an asset belongs to us, ask before testing it.

4. Out of scope

The following are not eligible for reward, and in some cases are not permitted at all:

• Physical attacks against offices, staff or hardware.
• Social engineering or phishing of our staff, our providers or our players.
• Denial of service, distributed denial of service, load testing, and any volumetric or resource-exhaustion technique.
• Vulnerabilities in third-party services we do not control — game studios, payment processors, hosting providers, chat widgets. Report those to the vendor. Tell us too, so we can chase them, but the reward is theirs to pay.
• Missing best-practice security headers, missing cookie flags, weak TLS configuration or similar hardening items with no demonstrated exploit.
• Self-XSS, and anything that requires the victim to paste code into their own console or actively assist the attack.
• Output from automated scanners submitted without proof that the finding is actually exploitable here.
• Missing rate limiting with no demonstrated impact.
• Clickjacking on pages with no state-changing action, missing SPF/DMARC records, email enumeration and username enumeration without further impact.
• Bugs requiring a rooted, jailbroken, malware-infected or otherwise fully compromised device, or a man-in-the-middle position the attacker cannot realistically obtain.
• Vulnerabilities in outdated browsers or platforms no longer supported by their vendor.
• Purely cosmetic issues, broken links, typos and content complaints. Send those to support.

5. How to report

Send your report by email to [email protected]. Please write in English, use one email per issue, and put the severity you believe applies in the subject line.

That is our general address rather than a dedicated security mailbox, and it is deliberate: it is a monitored address that we know people read, which matters more than the word in front of the @. Put SECURITY and the severity at the start of the subject line so your report is routed correctly and not treated as a support ticket.

A report we can act on contains:

1. A short summary of the issue and what an attacker gains from it.
2. The exact affected URL, endpoint or parameter.
3. Step-by-step reproduction instructions, precise enough that we can follow them without guessing.
4. The account, test data, request or payload used.
5. Your assessment of the impact, and any prerequisites the attack needs.
6. Supporting evidence — screenshots, request and response captures, or a short video.

6. Response times

We aim to acknowledge reports as follows, counting from when the email reaches us:

Acknowledgement means we have received the report and started looking at it. Validation, remediation and any reward decision take longer, and how much longer depends on the complexity of the fix. We will keep you updated as the report moves through triage, and we will tell you when the issue is resolved.

If you have not heard from us within these windows, send a follow-up rather than assuming the report was ignored — mail does occasionally go astray.

7. Rules of engagement and safe harbour

These rules exist so that research can happen without anyone getting hurt. Follow them and you are protected; ignore them and you are not.

• Test only against your own account. Register an account for testing and confine your work to it.
• Do not access, modify, delete or exfiltrate other users' data. If you can prove an issue with a single record you already have access to, stop there. Proving you could read one row is enough; downloading the table is not research.
• Stop as soon as you have confirmed the issue. Do not pivot deeper, do not escalate further than needed to demonstrate impact, and do not establish persistence.
• No denial of service, no load or stress testing, no brute forcing against production, and nothing that degrades the service for players.
• Do not target our staff, our providers or our players — no phishing, no pretexting, no attempts to obtain credentials from people.
• Do not manipulate funds beyond what is needed to prove the flaw. If a bug lets you credit a balance, credit the smallest amount that demonstrates it, report it, and do not withdraw it.
• No extortion. Refusing to disclose details until payment is agreed, threatening publication or disclosure to third parties to force a payout, or attaching any ransom condition to a report ends the relationship immediately and takes the matter out of this programme.
• Keep it confidential. Give us a reasonable period to fix the issue before disclosing anything publicly, and coordinate the timing and content of any publication with us first.
• Obey the law. Nothing in this programme authorises activity that is illegal where you are or where our systems are.

In return: if you conduct your research in good faith and follow the rules above, ZABET1 will not pursue legal action against you for that research, and we will not report it to law enforcement. If a third party brings a claim over activity that complied with this policy, we will make it known that your work was authorised under this programme.

This safe harbour covers your research only. It does not cover accessing other people's data, disrupting the service, retaining data you obtained, or any activity outside the scope in section 3.

8. Eligibility

• Rewards go to the first reporter of a genuinely new, valid, reproducible issue.
• Duplicates are not rewarded. Neither are issues we already know about — whether found internally, already in remediation, or previously reported by someone else.
• One reward per underlying issue. Several reports that all trace back to the same root cause are treated as one finding.
• Reports that do not include enough information to reproduce the issue may be closed if we ask for detail and do not receive it.
• Current and former ZABET1 employees and contractors, and staff of our service providers, are not eligible.
• Researchers in countries subject to sanctions that prevent us from making a payment are not eligible to receive one.
• You must supply a valid USDT address and confirm the network. We are not responsible for funds lost to an address or network you provided incorrectly.
• You are responsible for any taxes due on a reward in your own jurisdiction. We do not withhold, advise on or report tax on your behalf.
• Participation does not create employment, partnership or any ongoing relationship with ZABET1.

9. Changes to the programme

We may change, suspend or end this programme, and may revise its scope, severity definitions and rules, at any time. The current version is always the one on this page, dated at the top. Reports already submitted are assessed under the version that was published when they were sent.

10. Contact

Security reports: [email protected], with SECURITY at the start of the subject line. Everything else — account, deposits, withdrawals, bonuses — is handled faster through support or the help centre, so please use those rather than sending an ordinary query here. For how we handle personal data, including any data contained in a report you send us, see our privacy policy.