Reporting a vulnerability
Report security issues here rather than through the general contact form, so they reach the right people immediately.
What to include in a report
- The affected system, URL or contract address.
- A clear description of the issue and its potential impact.
- Reproduction steps, and a proof of concept where you have one.
- Any logs, requests or transaction hashes that help us verify quickly.
- How you would like to be credited, or that you prefer anonymity.
Safe harbour
We will not pursue legal action against researchers who follow this policy in good faith. To stay within it, please:
- Do not access, modify or delete data belonging to anyone else.
- Do not degrade service availability — no denial-of-service or volumetric testing.
- Do not use social engineering, physical intrusion or credential stuffing against staff or clients.
- Stop testing as soon as you have confirmed a vulnerability, and report it.
- Give us reasonable time to remediate before any public disclosure.
If you operate a bug bounty with rewards, state the scope and reward ranges here. If you do not pay bounties, say so plainly — researchers prefer clarity over ambiguity.
Out of scope
- Findings from automated scanners without a demonstrated exploit path.
- Missing security headers with no proven impact.
- Vulnerabilities in third-party services we do not control.
- Issues requiring physical access to a user unlocked device.
- Social engineering of our staff or clients.
- Client production systems, unless that client has separately authorised testing.
How we secure our own work
If you are a client with an incident
Contact the emergency contact you want published rather than the general security address, and mark it urgent. Incident runbooks delivered with your platform include the escalation path and the decisions that need making in the first hour.
Clients on a support retainer have a separate escalation route agreed in their contract, which takes precedence over this page.