Writing a Great Report

A clear, reproducible report is the difference between a fast payout and a rejection. Triage reproduces your finding before it reaches the project, so give them everything they need to confirm it.

#Required fields

Every submission should include:

• Title — a concise summary of the issue.
• Asset — the affected asset or component (must be in scope).
• Proposed severity — your assessment (Critical / High / Medium). Triage sets the final severity.
• Description — the nature of the vulnerability.
• Steps to reproduce — precise, ordered steps.
• Proof of concept — see standards below. A working PoC is mandatory.
• Impact statement — what an attacker can actually achieve.
• Suggested remediation — optional, but appreciated.

Submissions missing required fields are auto-rejected before review.

#Proof-of-concept standards by asset type

The bar depends on what you're testing:

• Smart Contracts — a runnable PoC against a local fork. This is strict: steps and logs alone are not enough.
• Blockchain / DLT — a runnable local PoC is mandatory; written steps and logs alone are insufficient.
• Web & Apps — reproducible steps with supporting evidence: screenshots, screen recordings, and/or HTTP request/response traces.

Never test against mainnet or a public testnet. PoCs must run on a local fork only — even a minimal PoC on a public testnet can leak the bug. Public exploitation is a serious violation that can result in a permanent ban. See Publication & Disclosure.

#How severity is decided

Severity is driven by real-world impact, not just whether your finding matches a rule on paper:

• A finding with greater real-world impact than its rule-classified level can be elevated.
• A finding that matches scope on paper but demonstrates no real-world impact (for example, vulnerable code that isn't live) may be downgraded or declined.

Lead with impact. Show exactly what an attacker gains — funds at risk, data exposed, control gained — and back it with your PoC.

#First to report wins

The first valid report of an issue earns the reward; duplicates earn nothing. A duplicate is the same root cause or vulnerable code path as an earlier valid report — not merely similar symptoms. The earliest valid submission wins.

#Why reports get rejected

Common rejection reasons:

• The PoC doesn't work or isn't reproducible.
• The target is out of scope.
• It's a duplicate of an earlier valid report or a declared known issue.
• No real issue / invalid.
• Spam or low-quality submissions (no real PoC, fabricated, or auto-generated filler).

A short, vague report is far more likely to be closed. If your description or PoC looks thin, expand it before submitting — the platform will warn you when a report looks too short.

#Submission limits

To keep the queue healthy, each researcher may have up to 8 active reports at once and submit up to 5 new reports per 48 hours. Reports that have reached acceptance, payment, or a terminal state no longer count against your active limit.