Vulnerability Disclosure Policy

1. Reporting a vulnerability

1. a clear description of the vulnerability;
2. the affected component, host, contract address, dashboard, or endpoint;
3. reproduction steps, payloads, and expected versus actual behaviour;
4. impact assessment and any proof-of-concept material;
5. your contact details and preferred attribution name; and
6. whether you intend to publish or coordinate public disclosure.

2. Scope

1. all hostnames under *.matrex.io, including marketing, investor, issuer, admin, API, and documentation surfaces;
2. Matrex smart contracts deployed to mainnet (deployed mainnet address placeholder until token launch — the published contract address will be authoritative);
3. all Matrex-operated backend services, APIs, and webhooks;
4. all Matrex-operated dashboards (investor, issuer, administrator); and
5. infrastructure-as-code, build pipelines, and supply chain integrity for the above.

1. third-party services that Matrex integrates with (including Sumsub, Stripe, DocuSign, hosting providers, RPC providers, blockchain analytics vendors, and email vendors) — report vulnerabilities in those products directly to the vendor's own security programme;
2. social engineering, phishing, vishing, or pretexting against Matrex staff, customers, or contractors;
3. physical attacks against Matrex offices, data centres, or personnel;
4. denial-of-service testing, distributed denial-of-service testing, volumetric attacks, or resource-exhaustion tests against production;
5. spam, automated mass-account creation, or rate-limit probing against production systems;
6. self-XSS or attacks requiring full pre-existing compromise of the victim's device or account;
7. vulnerabilities that depend on outdated browsers, jailbroken devices, or non-default configurations;
8. missing security best-practice headers without a demonstrable exploit; and
9. reports generated solely by automated scanners without manual validation.

3. Rewards and recognition

4. Safe harbour

1. not initiate or recommend legal action against you in connection with your research;
2. not pursue civil action or notify law enforcement;
3. treat your research as authorised activity under the Computer Fraud and Abuse Act, the New Zealand Crimes Act 1961 sections 248–252, the United Kingdom Computer Misuse Act 1990, and equivalent statutes in other jurisdictions; and
4. treat your research as exempt from anti-circumvention claims under the Digital Millennium Copyright Act 17 U.S.C. § 1201 and equivalent statutes.

1. only test against in-scope systems;
2. avoid privacy violations, destruction of data, and interruption or degradation of service;
3. only access the minimum amount of data necessary to demonstrate the vulnerability;
4. not retain, copy, transfer, or otherwise use personal data accessed during testing beyond what is required to evidence the report, and securely delete it after reporting;
5. not exploit a vulnerability beyond what is necessary for confirmation;
6. give Matrex reasonable time to remediate before public disclosure; and
7. comply with applicable laws.

5. Test accounts

6. Disclosure timeline

1. Initial response — within five business days of receipt;
2. Triage and severity assessment — within ten business days;
3. Remediation target — ninety days from triage for valid findings, prioritised by severity. Critical findings affecting smart contracts, custody-adjacent flows, or authentication will be prioritised on a shorter clock;
4. Public disclosure — coordinated with the reporter. Matrex prefers joint disclosure after a fix is shipped and customers have been notified.

7. Contact

Security reports and questions about this policy should be sent to: