Skip to main content
A Cortex Bounty report is filed from Cortex Chat, out of the conversation in which you found the problem. The conversation itself is the evidence: you describe the defect in it, then file the report from inside it, and the report is tied to that conversation, to the hotkey you are mining with, and to the account that filed it. Two things have to be true before the report tool appears. A hotkey must be paired to the account, which is covered on Pair a hotkey, and the conversation must be marked as a bounty-miner session. This page covers the marking, the filing, what the report carries, and what stays private while a verdict is pending.

​
Mark a conversation as a miner session

Marking is what turns an ordinary conversation into a miner session. It also injects miner context, so the assistant knows which hotkey it is working for.
1

Open a new conversation on the mining account

Sign in with the dedicated mining account and start a fresh conversation in Chat.
2

Send the command the CLI printed

Pairing printed a command to send in Chat. Send it in the composer as an ordinary message. You can send it on its own, or follow it with the one-time session code, or with the SS58 address of any hotkey already linked to the account.
3

Check that the conversation is marked

The conversation is now a bounty-miner session and miner context has been injected. The report tool is available in it.
4

Switch hotkeys when you need to

If the account holds several hotkeys, send the command again with the SS58 address of the one you want. The conversation follows the hotkey you name last.
The command is a secret. It is set by an operator, the CLI prints it only to you, and anyone holding it can mark a conversation. Do not paste it into an issue, a screenshot, a support thread or a public repository. /miner is not that command and is not a command at all.

​
File the report

Work the problem in the conversation first. Reproduce it, narrow it down, and write out what you found in plain language, because that text is what an adjudicator will read and what the publication gates are measured against. When the finding is written up, file it with the bounty_report tool. It is a Chat tool and it is only offered in a conversation that has been marked as a miner session, so it will not show up in a normal thread. You can add hints alongside the body when there is something an adjudicator should know to reproduce it.
Write the finding out properly rather than filing a one-line note. A report whose body carries less than 24 characters of plaintext finding can never be published as a valid row, whatever an adjudicator thinks of it. See Verdicts and scoring.

​
What a report carries

Reports are delivered to the challenge backend, which is what adjudicates them and what publishes the verdicts. Nothing you file goes to the subnet directly.

​
While it is pending, it is private

A filed report has no status yet. Until a verdict exists:
  • It does not appear on any of the public endpoints. It is not counted on the leaderboard, and it is not in the reports listing.
  • Fetching it by its id answers 404, exactly as an id that never existed would. That is deliberate. The public log holds adjudicated rows and nothing else.
  • You can still see it yourself. A signed-in participant can list their own reports, pending ones included, and that is the only way to see a pending report.
So an empty public log is not evidence that your report was lost. It is the expected state of a report that has not been judged yet. The Transparency API explains how to tell a backlog apart from a real zero.

​
What is never published

The conversation is the one thing that never becomes public. Chat transcripts stay private. They are never on the public routes. The report body is sealed too: its length is checked as a publication gate, but the text itself is never published. What an adjudicator writes about your report does become public, in two fields: a statement of the problem found, and the justification for the verdict. Nothing you wrote is republished verbatim.

​
What this page cannot tell you

There is no published turnaround time for a verdict, and no queue position you can read for your own report. The status endpoint tells you whether anyone is adjudicating at all and how large the backlog is, which is the closest thing to a progress signal that exists. Rewards, eligibility and timing are set by the programme terms you accepted at pairing rather than by this documentation, and they can depend on the case.