Cyfrin CodeHawks
HomeCyfrinSoloditUpdraftSupport
  • 👋Intro to Cyfrin Codehawks
  • ✏️Glossary
  • ⁉️FAQs
  • 🛡️Hawks (auditors)
    • What is a Competitive Audit?
    • Quick Start
    • The Kick-Off Period
    • How to Present Your Findings
    • How to Evaluate a Finding Severity
    • How to Determine a Finding Validity
    • How to Write a PoC
    • Appeals
    • Payouts
    • How Does XP Work?
  • 👩‍⚖️Judging
    • The Judging Process
    • How Community Judging Works
    • Community Judging Eligibility
    • Disqualification Criteria
    • Payouts and Rewards
  • 👩‍💻Protocol teams (sponsors)
    • The Auditing process
    • Case Studies
    • Request an Audit
  • 🦅First Flights
  • 🫂Create and Submit a First Flight
  • 🛠️Tools
  • Learn blockchain security
  • Twitter
  • LinkedIn
  • GitHub
  • Support
Powered by GitBook
On this page
  • Choosing between submitting single or multiple reports
  • How to adequately explain and prove your findings
  • How to format your report

Was this helpful?

Edit on GitHub
  1. Hawks (auditors)

How to Present Your Findings

PreviousThe Kick-Off PeriodNextHow to Evaluate a Finding Severity

Last updated 10 months ago

Was this helpful?

At Cyfrin CodeHawks, ensuring a streamlined and standardized process for reporting vulnerabilities is paramount. This ensures your submissions are explained clearly, facilitates fair judging, and gives you better chances to submit a valid finding and earn rewards.

All finding submissions are handled directly through the CodeHawks web platform to ensure a simple and streamlined process.

Choosing between submitting single or multiple reports

Once you've determined the and its , refer to the following report format:

  • Medium or High Severity Findings: Submit individually.

  • Low Findings (Low risk or Non-critical): Compile into a single report per auditor or team

How to adequately explain and prove your findings

The auditors are responsible for validating the findings. A detailed explanation and justification of the potential impact are crucial for a top-quality submission. The depth of the proof required correlates with the potential value of the submission.

Insufficient proof is when a judge needs to invest additional time in research or coding to verify the claims made in the submission. Providing a coded for your findings is highly recommended. This aids the judges immensely in swiftly and accurately verifying your claims.

Submissions deemed to lack sufficient evidence may risk .

How to format your report

When documenting a finding, adhere to the following structure:

## Summary

(Provide a brief overview of the vulnerability.)

## Vulnerability Details

(Delve deep and elaborate on the identified issue, including where it exists in the codebase.)

## Impact

(Describe the potential consequences of this vulnerability. How could it harm the protocol or users?)

## Tools Used 

(List any tools or software that aided in the identification of the vulnerability.)

## Recommended Mitigation

(Suggest ways to resolve or mitigate the identified vulnerability.)

🛡️
severity of your finding
validity
proof of concept (POC)
invalidation