Vulnerability Disclosure Policy

Date of Revision: 09 August 2026

A Chinese translation is available at /security/zh. Where the two differ, this English version governs.

DZMM welcomes reports from security researchers. This policy explains how to report a vulnerability in our Services, what we will do with your report, and what protection you have when you follow it.

We pay for what we accept — from 10 USDT for a genuine low-impact defect up to 50,000 USDT for the most serious. All rewards under this policy are paid in USDT; the full schedule and its conditions are in Section 8. Read Section 4 before you start testing: the rules there are conditions of both the safe harbour and any reward.

1. Scope

This policy covers:

a) The DZMM web application served at www.dzmm.ai and dzmm.io, including the API endpoints it calls;

b) The official DZMM mobile applications, where you obtained them through our official distribution channels.

Everything else is out of scope, including:

• Any host, address, or service not listed above, including our internal, corporate, and build infrastructure;
• Alias and mirror domains that resolve to the applications above — test on www.dzmm.ai instead;
• Beta, staging, and preview environments;
• Third-party services we use but do not operate, such as payment processors, content delivery networks, email providers, and AI model providers. Report those to the provider concerned.

If you are not sure whether something is in scope, ask us before you test it.

2. How to Report

Email [email protected] with [SECURITY] at the start of the subject line, so that your report is routed out of the general support queue on arrival.

Include:

a) A description of the vulnerability and the security impact you believe it has;

b) The exact URL, endpoint, or app screen affected;

c) Step-by-step instructions to reproduce it;

d) The email address of the test account you used;

e) Any proof-of-concept code, request logs, or screenshots.

Please send one vulnerability per email. Reports in English or Chinese are equally welcome.

A report sent without the subject prefix still reaches us; it will simply be slower to pick up.

3. What We Will Do

a) Acknowledgement: we will confirm receipt within 3 business days.

b) Assessment: within 10 business days we will tell you whether we accept the report, how we rate its severity, and which reward tier we believe it falls in.

c) Updates: while a fix is in progress we will update you at least every 14 days.

d) Resolution: we will tell you when the fix is live so that you can verify it.

If you have not heard from us within 5 business days, please resend your email rather than assume it was ignored.

4. Rules for Testing

Our Services hold private, intimate conversations belonging to real people. Protecting that data takes priority over the completeness of your proof of concept. When testing, you must:

• Use only accounts you created yourself. Never sign in to, access, or interact with another user's account.
• Prove it against your own data. Demonstrate an access-control flaw across two accounts you control, or against content you placed yourself. Nothing in this policy permits you to read another user's account, and we could not permit it if we wanted to: that data belongs to them, and it is not ours to hand out.
• If you reach someone else's data anyway, stop. It happens, and it does not by itself put you outside this policy. Stop at once, do not copy or retain what you saw, and tell us promptly what you reached and how. Continuing to retrieve after that point is a choice, and it forfeits the protection in Section 5 and any reward.
• Do not modify or delete data that is not yours.
• Do not degrade the Services. No denial-of-service testing, no load or stress testing, and no scanning at a rate that affects other users.
• Do not target people. No social engineering, phishing, or physical intrusion directed at our users, staff, contractors, or suppliers.
• Go no further than the demonstration requires. No pivoting to other systems, no establishing persistence, no installing tooling on our infrastructure.
• Keep the report confidential until the disclosure deadline, which is the earlier of the day we ship a fix and the ninetieth day after your report. That single date governs everywhere in this policy, including the reward condition in Section 8. After it passes you are free to publish, and we are glad to coordinate with you.
• Comply with the law, both in your jurisdiction and in ours.

The reward is for the capability, not for the loot. Our highest tier covers remote code execution and mass extraction of our database, and it is paid on a convincing demonstration that you could do it — against accounts and content you control, or against a target we agree with you beforehand. A row count, a schema or directory listing, a record you planted in your own second account and then reached through a session that should not reach it: any of those settles it. You do not need to touch a real user's data, and you must not. Extracting user data at scale forfeits both the reward and the safe harbour, no matter what you found.

If you believe your finding cannot be shown without going further than this section allows, that is the moment to stop and write to us. We will agree a demonstration with you — a seeded account, a marker record, a window in which to run it. Asking costs you nothing and never lowers your tier; we grade the capability you establish, not the damage you were willing to do.

5. Safe Harbour

If you make a good-faith effort to follow this policy while researching a vulnerability, we will:

• Treat your research as authorised for the purposes of the security-testing restrictions in Section 6 of our Terms of Service — specifically, interfering with or circumventing security features and attempting unauthorised access;
• Not bring or support legal action against you in relation to it, and not refer you to law enforcement for it;
• Not suspend the test accounts you created for the research. Accounts used for anything beyond the research remain subject to our Terms.

That authorisation reaches no further. The rest of our Terms apply to you as they do to any other user — including Section 6.1, Geographic Restrictions: if the Services are not available where you are, this policy does not make them available to you, and we still cannot pay you. And it never extends to another user's account or data.

We cannot waive rights held by third parties. If a third party brings action against you for research carried out under this policy, we will make it known that your actions were authorised by us.

If you are unsure whether a particular action is covered, ask us first. We would much rather answer a question beforehand than argue about it afterwards.

6. Reports We Do Not Accept

The following are normally closed without further action unless you can demonstrate a concrete security impact:

• Output from automated scanners with no working proof of concept;
• Missing or misconfigured security headers, cookie flags, or TLS options, with no demonstrated exploit;
• Missing SPF, DKIM, or DMARC records;
• Absence of rate limiting, with no demonstrated impact;
• Self-XSS, and clickjacking on pages with no state-changing action;
• Version disclosure, banner grabbing, and outdated dependencies with no working exploit against our Services;
• Denial of service, resource exhaustion, and volumetric attacks;
• Social engineering and physical security;
• Issues that require a rooted, jailbroken, or otherwise compromised device, or a physically compromised account;
• Account enumeration on endpoints where it is inherent to the feature;
• Credentials from third-party breach dumps, without evidence that they work on our Services.

Model output is not a security vulnerability. Persuading an AI model to produce content our guidelines prohibit is a content moderation matter — send it to [email protected] as an ordinary support request, without the security subject prefix. Prompt injection is in scope where it crosses a security boundary: reading another user's data, performing an action as another user, or extracting server-side secrets.

7. Reports Made Under Threat

Asking what a finding is worth, once you have described it to us, is a normal part of this process and is welcome.

What we will not do is negotiate under pressure. Reports that withhold details pending payment, that threaten disclosure to the public or to a third party in order to obtain payment, or that attach an invoice we did not agree to, will be closed and no reward will be paid. Where a threat is made we treat it as an extortion attempt and respond accordingly.

8. Rewards

These are maximums, not fixed prices. What we actually pay depends on the impact you demonstrate, how much of it is reachable by an ordinary attacker without unusual prerequisites, and how complete your report is. We will explain how we arrived at a figure.

The line we grade against sits between 2,000 and 10,000: above it you have shown you could reach our users' private conversations, their accounts, or their money; below it you have shown you could reach the perimeter of that. Ingenuity of technique does not move a report across the line — demonstrated reach does. Note that the line is about what you established you could do, never about what you actually took: see Section 4.

You are not expected to cross it to get paid for having got that far. If you are at the perimeter and the next step would break the rules in Section 4, stop there and tell us: we grade what you demonstrated, and we would rather pay the tier below than have you prove the tier above at our users' expense.

Conditions:

• First complete report only. Where several people report the same underlying issue, the reward goes to the first report that let us reproduce it. Duplicates and reports of an issue we already knew about are not rewarded.
• One reward per underlying issue, however many entry points it has.
• The finding must be in scope as defined in Section 1, and must not be on the list in Section 6.
• Section 4 is a condition of payment. Breaking those rules forfeits the reward, including where the finding itself was genuine. In particular, extracting user data at scale is never rewarded — see the note at the end of Section 4.
• Disclosing before the deadline in Section 4 forfeits the reward. Disclosing after it does not, even if no fix has shipped yet — the ninety days are yours by right, not by our leave. If the fix lands later, you are still paid when it does.
• We pay after the fix is live, in USDT, to a wallet address you give us. We settle the network with you before sending, and we cover the transfer fee — for the smaller awards we will pick a network where the fee does not swallow the reward, or hold the amount and combine it with your next one if you would rather. We do not pay by bank transfer or in any other currency. Any tax due is yours to handle.
• We cannot pay current or former DZMM staff and contractors, or anyone in a jurisdiction where making the payment would be unlawful for us.
• The assessment and the amount are our decision.

With your permission we will also credit you by name or handle in our acknowledgements. You may decline the credit and still take the reward, or take the credit and decline the reward.

9. Changes to This Policy

We may update this policy. The revision date above reflects the current version, and the version in force when you submit a report is the one that applies to it.

10. Contact

[email protected] — for a vulnerability report, prefix the subject line with [SECURITY].

The same address handles account problems, content complaints, and everything else; send those without the prefix.