Abelian Vulnerability Disclosure Policy

Version 1.0 · Last updated 29 Sep 2026 · Maintained by Abelian Foundation

Abelian is a post-quantum, privacy-preserving Layer-1 blockchain. Its security depends on independent researchers reviewing and testing its code. This policy explains what you can test, how to report what you find, what we will do in return, and the legal protection we give to good-faith research.

If you think you have found a vulnerability, please report it to us privately using the channels in Section 4. Do not exploit it on mainnet.

1. Our commitments

If you follow this policy, we will:

• treat your research as authorised and not take legal action against you for it (see Section 8);
• confirm we have received your report within 3 business days;
• give you an initial assessment, including a proposed severity, within 10 business days;
• update you at least every 14 days until the issue is resolved;
• work with you on the timing and content of any public disclosure;
• credit you publicly if you want to be credited; and
• consider a reward (see Section 7).

2. Scope

In scope

All public, non-archived repositories under github.com/pqabelian, including:

We also accept reports on the Abelian protocol design and its cryptographic constructions, and on released binaries built from these repositories.

Limited scope

The following are in scope only for vulnerabilities that do not need active testing against live systems (for example, issues you can see through normal use or in public source code):

• pqabelian.io and other websites operated by Abelian Foundation
• Public infrastructure operated by the Foundation, e.g. seed nodes, RPC endpoints, block explorer

Out of scope

• Systems we do not operate, including exchanges, mining pools, third-party wallets, explorers and bridges. Please report these to their operators. If the root cause is in Abelian code, report it to us too.
• Vulnerabilities in third-party dependencies that do not have a demonstrable impact on Abelian.
• Social engineering, phishing or physical attacks against our team, contributors or users.
• Volumetric denial-of-service attacks against any live system. You may report DoS vulnerabilities found through source review or local testing.
• Reports from automated scanners that have no demonstrated impact, and best-practice findings with no security impact (for example missing HTTP headers or SPF/DMARC configuration).
• Issues that need a compromised device, a malicious operating system or physical access to a user's machine, unless Abelian software makes them materially worse.

3. Rules of engagement

Permitted

• Reviewing public source code, specifications and documentation.
• Building and running Abelian software on systems you control, and testing only on local or private test networks you control. Testing on a public testnet or other live systems requires separate written authorisation for the specific activity from a party with authority over the affected systems.
• Analysing public blockchain data, as long as you do not publish information that identifies real users.
• Writing proof-of-concept code and tests that run only in these environments.

Not permitted

• Exploiting any vulnerability on mainnet. This includes broadcasting transactions that exploit a flaw, minting or moving funds you are not entitled to, and mining blocks to demonstrate an issue.
• "Rescuing" funds by exploiting a vulnerability, even with good intentions. This policy does not authorise whitehat fund-recovery operations. Report the issue to us instead.
• Accessing, modifying or keeping other people's funds, keys, seed material or personal data. If you come across any by accident, stop, do not keep a copy, and tell us in your report.
• Disrupting live nodes, the network or Foundation infrastructure, or degrading service for users.
• Publishing vulnerability details before the disclosure date determined under Section 6. Confidential sharing with professional advisers, an appropriate vulnerability coordinator or another affected vendor for remediation is permitted on a need-to-know basis; protect sensitive information and coordinate with us where practicable. Do not disclose third-party confidential information without authority or submit the same issue elsewhere to evade these disclosure terms.
• Demanding payment, or threatening disclosure, as a condition of sharing details. Reports made that way fall outside this policy. Asking about reward eligibility or using the disclosure process in Section 6 is not, by itself, a prohibited demand or threat.

If you are not sure whether something is allowed, ask us first at the address in Section 4.

4. How to report

Preferred: GitHub private vulnerability reporting on the affected repository, where enabled (Security → Report a vulnerability). This keeps the report confidential and lets us work with you on a private fix. Do not report vulnerability details through public issues, pull requests or discussions.

Email or fallback: security@pqabelian.io. Please put "SECURITY" in the subject line. Prefer GitHub private reporting for sensitive technical details; ordinary email is not an end-to-end encrypted reporting channel. If that option is unavailable, email a brief description without secrets or sensitive personal data so we can arrange an appropriate way to receive the details.

Please include:

1. the affected component(s), with the repository, file and line references, and the commit or version;
2. a description of the vulnerability and its root cause;
3. its impact, and the conditions an attacker would need;
4. steps to reproduce, or a proof of concept that runs only on systems and local or private test networks you control;
5. any mitigation you suggest; and
6. how you would like to be credited (name, handle or anonymous).

Reports in English are preferred. One vulnerability per report helps us triage faster, unless several issues share a root cause.

5. What happens after you report

We may ask you to review our fix. If you do, your confirmation will cover only the specific code revisions you reviewed. We track any hardening suggestions you make alongside a report separately from the fix for the original vulnerability.

6. Coordinated disclosure

• Please report privately and keep the details confidential until the disclosure date determined under this section.
• Our normal target is an agreed disclosure date within 90 calendar days after receipt of the initial report. This does not guarantee that a fix will be available by that date. Either side may request an extension to protect users, for example while exchanges, pools and node operators upgrade. An extension must be agreed in writing and include a specific reason and a revised disclosure date. Status updates continue during an extension.
• If no disclosure date or extension has been agreed by day 90, either side may publish after giving the other at least 30 calendar days' written notice of the publication date; no further approval is required. If an agreed extension expires without a replacement disclosure date or extension, the same notice process applies. We will discuss earlier disclosure when active exploitation or another urgent user-protection need makes it appropriate. A delay in remediation does not automatically extend the disclosure timeline.
• We will usually publish a security advisory with a root-cause analysis, and GitHub Security Advisories on the affected repositories. We will share our draft with you in advance. You may publish your own write-up after the disclosure date. Each side shares its draft with the other at least 5 business days before publishing, for factual review only. Neither side has to adopt the other's conclusions.
• Coordinate publication of working exploit code and operational attack instructions separately from the advisory. Minimise avoidable harm and document any agreed, time-limited delay of those details, including a review date. Such a delay does not postpone the advisory's disclosure date unless separately agreed under this section.
• We may share details in confidence, before public disclosure, with parties who need to act (for example exchanges, mining pools or affected projects).

7. Rewards

Abelian Foundation may give discretionary rewards for original, in-scope reports that follow this policy. There is no fixed reward table. When we decide on a reward, we consider:

• the severity and real-world impact (see the table below);
• the quality of the report, including clarity, root-cause analysis, a proof of concept and suggested fixes;
• whether the issue affects mainnet as deployed; and
• whether you helped verify the fix.

The examples below are illustrative, not fixed severity ceilings. We assess demonstrated impact and exploitability in context, including whether an issue can scale across nodes, persistently disrupt service, compromise sensitive material, or affect funds or consensus. We will explain our assessment to the reporter.

Eligibility. To receive a reward you must:

• be the first to report the issue to us;
• not be an employee or contractor of the Foundation, or an immediate family member of one;
• not be subject to sanctions, or ordinarily resident in a comprehensively sanctioned country or territory; and
• be legally able to receive the reward.

Payment. Rewards are normally paid in stablecoin agreed with you. Before payment we ask you to sign a short award agreement. We also carry out identity, sanctions and wallet checks, and confirm your payment address through an authenticated channel. You are responsible for any taxes on the reward.

Offering a reward is at our discretion. Once we have agreed a reward with you in writing, we will pay it on the agreed terms.

Reward eligibility and acceptance of an award agreement are separate from permission to submit a report and from the safe harbour in Section 8. Declining a reward or not qualifying for one does not by itself remove protection for research otherwise covered by this policy.

8. Safe harbour

To the extent of our authority over the systems and rights concerned, when you research and report in good faith and in line with this policy, we consider your research to be:

• authorised under applicable anti-hacking and computer-misuse laws. We will not bring or support any civil claim, or initiate or support any criminal complaint, against you for that research, or for accidental good-faith breaches of this policy;
• authorised under applicable anti-circumvention laws, and we will not bring a claim against you for circumventing technology measures; and
• exempt from any restriction in the Abelian Terms and Conditions that would otherwise prevent the research, for the limited purpose of that research.

If a third party brings legal action against you for research that complied with this policy, we will make it known that your research was authorised by us.

Limits. This safe harbour applies only to systems and activities within this policy. It does not authorise harmful activity, activity on systems we do not control, or exploitation on mainnet. We cannot give protection on behalf of third parties, including exchanges, other projects or law-enforcement authorities. A later, unrelated breach of this policy or of any agreement with us does not retrospectively remove protection for research that complied with this policy.

If you are unsure whether your research complies with this policy, please ask us before you continue.

9. Recognition

With your permission, we credit researchers in our security advisories and on our Security Acknowledgements page.

10. Personal data

We use personal information you give us only to handle your report, process any reward, meet our legal obligations and keep records. We handle it in line with applicable data protection law, including Hong Kong's Personal Data (Privacy) Ordinance (Cap. 486).

11. Changes to this policy

We may update this policy from time to time. The version in effect on the date you submit a report applies to that report. Policy changes will not retrospectively withdraw authorisation or safe harbour for research conducted in compliance with the policy then in effect.

Last updated: 29 Sep 2026