Report a Finding, a Correction or a Missing Step
The desk reads every message and replies to the ones it can act on. This page says what to include so a report is usable on the first pass, and states plainly which requests are outside what this site does.
Write to [email protected]. English only, plain text preferred, and no attachments larger than a log file. There is no form on this page and no account to create, which is deliberate: a mailbox is the lowest-friction channel that leaves both sides a record.
Corrections to a procedure
These are the most valuable messages the desk receives. To be actionable, a correction needs four things: the page, the specific step, what you observed instead of the expected result, and any artefact that supports it. A transaction signature is the strongest artefact available for anything on chain, because it lets the desk read the same record you did.
If a step has stopped working because an interface or a program changed, saying roughly when you noticed is useful. It narrows the search considerably, and it distinguishes a step that was always wrong from one that used to be right.
A gap in the coverage
If there is a testing question this site does not answer, describe the question rather than the article you want. The desk would rather understand the problem someone is stuck on than receive a title. Questions that arrive more than once tend to become pages, and questions the desk cannot answer honestly do not, which is the filter that keeps the material useful.
Three things the desk cannot do
- Assess a specific product for you. QA Ground publishes methods rather than verdicts on named tools. If you send a product and ask whether it is trustworthy, the reply will point you at the acceptance criteria template and the dry run design sheet, because those are what would actually answer your question.
- Recover lost funds. Confirmed transactions on Solana cannot be reversed by anyone, including the desk, the network and the venue. If funds have moved, the useful work is preserving evidence and understanding what happened, and the incident review template is where that starts.
- Handle your keys. Never send a seed phrase, a private key, a keystore file or a screenshot containing any of them, to this desk or to anyone else. Any message containing one will be deleted without being read further, and you should treat the key as compromised and move whatever it holds to a key generated fresh.
Reporting a suspected security problem
If you have found something that looks like a security defect in a tool other people use, the desk is not the right first recipient. Report it to whoever operates the tool, give them a reasonable window to respond, and keep your evidence. If you want help structuring the report so it is actionable, the intake fields listed in the reproduction procedure are a workable outline and cost nothing to fill in.
Response times and expectations
This is a small desk. Corrections with an artefact attached get looked at first, because they can be checked without a conversation. General questions may not receive an individual reply, and messages that appear to be automated outreach are deleted unread. Nothing sent here is treated as confidential unless you say so and the desk agrees, and no message should include anything you would not want written down.