Security and Vulnerability Disclosure

1. Scope

This policy applies to the Qstamp website at qstamp.org, the Qstamp SDK published on npm as @quantovainc/qstamp and its source code, the Qstamp contract templates, and the network endpoints operated by Quantova Inc.

Systems operated by third parties, including Cloudflare, GitHub and npm, are not in scope. Issues in those systems should be reported to their operators.

2. Cryptographic standards

• SHA3 as specified in FIPS 202 for fingerprints, leaves, trees and commitments
• SHA2 with a 256 bit output as specified in FIPS 180 revision 4 where an existing system requires it
• ML DSA 65 as specified in FIPS 204 for transactions and validator finality certificates
• SLH DSA as specified in FIPS 205, available for long lived accounts
• Hash trees following RFC 9162 with distinct domain prefixes for leaves, nodes and commitments

3. Engineering controls

• Strict validation of receipts with exact field sets and canonical encodings
• Verification that fails closed and never reports a valid result without checking content
• Signing seeds handled only as wipeable byte buffers
• A single, exactly pinned dependency with no installation scripts
• Contract code admitted to the QVM only with an attested compiler signature

4. Operational security

• The website and the network endpoints are served over encrypted connections, and the website uses strict browser security headers.
• Requests pass through Cloudflare, which provides protection against attack and automated abuse.
• Server logs are analysed by an internal monitoring system to detect attacks, abuse and scraping, and the IP addresses involved may be blocked at our firewall or through Cloudflare, as described in the Privacy Policy.
• Access to server logs and monitoring records is restricted to authorised Quantova personnel.

5. Review

The SDK and the contract templates were reviewed before release, covering cryptographic design, code and integration with the network, and the findings were resolved or documented. Quantova Inc does not claim that an independent external audit of the SDK or the contract templates has been completed. Organisations should consider commissioning an independent audit before relying on Qstamp in production, and organisations that deploy the contract templates are responsible for having their own deployments audited.

6. Reporting a vulnerability

Please report suspected vulnerabilities to [email protected]. Include a description of the issue, the affected component and version, the steps needed to reproduce it, its potential impact and how we can contact you. The same contact is published in the security.txt file of this website.

Please include personal data of other people only where it is strictly necessary to show the issue.

7. Rules for research

When researching and reporting a vulnerability, please follow these rules.

• use only accounts, keys and test funds that belong to you, and use the test network wherever possible
• do not access, copy, modify or delete data that belongs to others beyond the minimum needed to show the issue, and stop and report at once if you encounter personal data
• do not degrade or interrupt our services, and do not carry out denial of service testing
• do not use social engineering, phishing or physical attacks
• do not run automated scanning at a volume that burdens our services
• keep the details confidential until we have confirmed a fix or agreed a disclosure date with you
• comply with the law that applies to you

8. What you can expect

We aim to

• acknowledge your report within three business days
• give you an initial assessment within ten business days
• keep you informed of our progress
• coordinate disclosure with you once a fix is available, and credit you if you wish

These are aims, not guarantees, and complex issues may take longer. We do not pay rewards for reports unless we have agreed to do so in writing.

9. Safe harbour

If you make a good faith effort to comply with this policy, we will consider your research authorised, we will not bring legal action against you in respect of it and we will not report it to law enforcement authorities. If a third party brings legal action against you for research that complied with this policy, we will make it known that the research was authorised by us.

This safe harbour applies only to systems operated by Quantova Inc. It cannot authorise research on systems operated by others.

10. Out of scope

Denial of service testing, social engineering, physical attacks, testing of systems not operated by Quantova Inc, reports from automated scanners without a demonstrated security impact, and reports about missing best practices without a demonstrated security impact are outside the scope of this policy.

11. Misuse of our services

If you believe that a Qstamp service is being used for abuse rather than that it contains a vulnerability, please report it to [email protected] under the Acceptable Use Policy.