# Intro to Cyfrin Codehawks CodeHawks is a **leading competitive smart contract audit marketplace powered by** [**Cyfrin**](https://cyfrin.io). CodeHawks works to **protect DeFi, Protocols, their users, and funds** from smart contract exploits through private and public smart contract security auditing competitions, joined by industry-leading auditors world-wide. ### The Problem CodeHawks Solves Digital value exchange enabled by decentralized finance and smart contracts requires outstanding security and best practices to reach mainstream adoption. *Over $250B is locked in the DeFi ecosystem, and in the past six months alone, over $1B has been lost in more than 100 DeFi exploits.*\ \ Last year, 6% of the Total Value Locked (TVL) in DeFi was stolen, resulting in the loss of hundreds of millions of dollars in users and protocols funds and, inherently, faith in the entire ecosystem. Furthermore, finding, hiring, and working with expert and reliable auditors has been extremely rudimental until now. Protocols were forced to perform word-of-mouth research, with little to no possibility of ensuring the quality of their audits. **CodeHawks solves this** by bridging together top-notch Blockchain security experts and Protocols in an eco-system built to create security in web3. ### Why CodeHawks? [CodeHawks](https://codehawks.com), powered by [Cyfrin](https://cyfrin.io), brings together top-notch global auditors and a community of thousands of security researchers to ensure the highest security standards when securing your codebases. | Feature/Attribute | CodeHawks | Competitors | | --------------------------- | ---------------------------- | ------------------------------------ | | **Pricing** | Low platform fees | Higher platform fees | | **Process Transparency** | Full Transparency Throughout | Sometimes Opaque | | **Types of Audits Offered** | Competitive & Private | Typically One Type | | **Referral Program** | Generous 15% Referral Fee | Usually Lower or No Referral Program | | **Audit Speed** | Quick Turnaround | Often Slower | | **Post-Audit Support** | Long-term Code Safeguarding | Typically Limited to Initial Audit | | **Additional Services** | Education, long term support | Often Limited to Auditing | | **Customer Support** | 24/7 Dedicated Support | Limited Support Hours | ### How CodeHawks works There are three core components in every CodeHawks smart contract auditing competition: 1. **Sponsors (protocols)**: Organizations or entities that implement smart contracts. 2. **Judges**: World-leading experts who oversee the audit process and ensure its integrity. 3. **Hawks (auditors)**: Professionals who conduct the actual audit of the smart contracts ### For Sponsors Protocols approach Cyfrin CodeHawks with their audit requirements. They have the flexibility to choose between: * **Public Competitive Audits**: A dynamic audit process where multiple auditors compete to identify vulnerabilities. * **Private Competitive Audits**: A more traditional approach where a selected auditor or team reviews the smart contract. Learn more about all the [Cyfrin security solutions](https://cyfrin.io/pricing) and its ecosystem. ### For Hawks (Auditors) The Hawks, our Auditors, lie at the heart of the CodeHawks ecosystem. They: * Engage in competitive audits, showcasing their expertise. * Get [paid for their findings](/hawks-auditors/payouts). * Build a network to find private auditing opportunities. * Are sometimes eligible to become [community judges](https://github.com/Cyfrin/codehawks-docs/blob/main/broken-reference/README.md). If you're interested in becoming a Hawk on CodeHawks, start by visiting our [Quickstart guide](/hawks-auditors/quick-start) ### For Judges Judges are the team, community, and protocol members dedicated to reviewing Hawks submissions, deduplicating, validating, testing, and ensuring the highest quality standards when selecting them. They are responsible for ensuring our top-notch security reports by revising, testing, and verifying thousands of security researchers' submissions every year. To learn more about our [judging process](/judging/the-judging-process) or [evaluation criteria](/judging/disqualification-criteria) - visit the dedicated sections. # Glossary Find the definition of commonly used terms on CodeHawks.
nSLOC nSLOC stands for 'Normalized Source Lines of Code', a custom measurement we use (among other things) to evaluate the complexity of a codebase. To get the NSLOC count of a file: 1. For all functions, reduce any multiline function declarations to a single line. 2. Remove all comments 3. Remove all empty lines 4. Count the remaining lines
PoC - Proof of Concept A proof of concept (PoC) is a demonstration or experiment that seeks to validate the feasibility, functionality, and potential of a particular idea, concept, or method. Typically used in the early stages of development, a PoC demonstrates that a concept or theory has practical potential for real-world application. It doesn't aim to represent a finished product or solution. Instead, verifying that a specific idea can be developed into a functional prototype or product is a foundational step.
QAs - Quality Assurance QA reports are essential software development and testing documents that highlight the status, progress, and potential issues of a particular product or system under evaluation. Here's a brief overview of what a QA report might entail.
Finding Any submission done by a Hawk (auditor) to a contest reporting a bug or potential exploitation vector in a smart contract or codebase
Complexity The complexity of a code base or smart contract, calculated using [Solidity Core Metrics](https://github.com/Consensys/solidity-metrics), taking into consideration: * nSLOC * Number of contracts And other parameters
Sponsor Any protocol's team or developers willing to make their smart contracts more secure and their users safe by sponsoring a [smart contract auditing competition](broken://pages/pZpQPcXVi677BCQyW6vQ) on Codehawks.com
Hawks The unique community of auditors on [codehawks.com](https://codehawks.com)
# FAQs Find answers to the most frequently asked questions on CodeHawks. ### **⚙️ General** ***
What is Cyfrin CodeHawks? Codehawks is a smart contract competitive audits platform helping protect some of the world’s largest protocols, thousands of users, and billions of TVL through crowdsourced security pre and post-deployment security solutions.
What is a competitive audit? Protocols and organizations host competitions to find vulnerabilities in their smart contracts. Auditors uncover vulnerabilities and bugs in a project’s codebase to earn a reward. Competitions incentivize security auditors to conduct more comprehensive audits by offering rewards based on the severity of the bugs they discover.
How can I host a competition on CodeHawks? Fill out [this form](https://cyfrin.io/get-an-audit) to contact us. One of our experts will contact you within 48 hours to walk you through every step of the process and find the right security solution for your protocol or organization's needs.
How is a contest prize pool determined? The total prize pool of a contest is calculated based on the number of lines of code in the codebase's scope, without counting comments and empty lines.
How do I get rewarded? Rewards are paid out in USDC through the ZKsync chain. Once a judge deems a submission valid, a reward will be assigned and credited to the zkSync wallet address indicated by the user on their profile once the competition ends. **Note**: crediting the reward won't be possible without a ZKsync wallet connected to the user profile.
Where can I find invoice information for my winnings? **Address:** 9066 CASCADA WAY #102\ NAPLES, FL. 34114\ UNITED STATES\ \ **Tax ID:**\ 92-1600150\ \ **Company Name:**\ Cyfrin Inc.
How do I KYC to receive a reward? Specific competitions will need auditors to KYC to receive their rewards. Once the contest ends, if you're not KYC'd yet, you'll receive an in-platform notification and an email with all the steps you'll need to take to complete the KYC process and unlock your rewards.
### 🤝 Competitive Audits ***
What is a first flight? CodeHawks First Flights is a Cyfrin flagship initiative. Smart contract auditing contests written to simulate real-world protocols, designed to introduce the next generation of developers to security audits.
Do we have to wait until the start date to see the code? Yes, codebases are made public only once the contest has started. You can find the starting date and time for every contest in the related contest page on [codehawks.com](https://codehawks.com) #### How is nSLOC calculated? nSLOC stands for 'Normalized Source Code', which is a custom measurement used (among others) when evaluating the complexity of a codebase. To get the NSLOC count of a file: 1. For all functions, reduce any multiline function declarations to a single line. 2. Remove all comments 3. Remove all empty lines 4. Count the remaining lines
### 📃 **Submissions** ***
Is "X" a valid submission? To determine if "X" is a valid submission, it must be evaluated against the criteria provided by CodeHawks. A valid submission typically represents a vulnerability in the codebase. The submission should fall into one of the categories: High, Medium, Low, Gas, or Informational. However, it's essential to note that if more than 85% of your findings are invalid, you will be disqualified from the competition. For instance, if you submit one valid finding and six invalid ones, only 14.3% of your submissions are valid, leading to disqualification. Additionally, any findings associated with the "[4naly3er](https://github.com/Picodes/4naly3er)" tool, run at the start of each competition, are ineligible for rewards. The submission format should also align with the latest format provided on the website. The guidelines used to evaluate the findings' validity can be found in the [How to Determine a Finding Validity](/hawks-auditors/how-to-determine-a-finding-validity)documentation.
I’m unsure of the severity of my submission, what should I do? If you're unsure of the severity of your submission, consider the following steps based on the information provided by CodeHawks: 1. **Review the Categories:** Revisit the definitions of the severity categories provided by CodeHawks: * **High:** Funds are directly or nearly directly at risk. * **Medium:** Funds are indirectly at risk, or protocol functionality or availability is disrupted. * **Low, Gas, Informational:** * **Low:** Funds are not at risk, but a function might be incorrect, or the state might not be handled appropriately. * **Gas:** Refers to gas optimizations. * **Informational:** Pertains to code style, maturity, code smells, comment correctness, etc. 2. **Judge's Discretion:** Remember that determining the severity involves some subjectivity. The final categorization is up to the judges' discretion. If the protocol you're auditing has specific criteria that should be followed. 3. **Seek Feedback:** Before finalizing your submission, consider discussing it with peers or mentors on our [Discord](https://discord.gg/cyfrin) server who have experience in the field. They might provide insights that can help you gauge the severity of your findings. 4. **Provide Detailed Information:** When submitting, provide comprehensive details about the vulnerability. This includes a summary, vulnerability details, potential impact, tools used, and recommended mitigation. The more information you provide, the easier for the judges to assess the severity accurately. 5. **Stay Updated:** As CodeHawks evolves, the basis for findings and their categorizations might change. Always refer to the latest guidelines on the CodeHawks website to ensure you're up-to-date with their criteria. Lastly, even if you're unsure, submitting your findings is better. The judges will review it and assign the appropriate severity based on their assessment. For more information consult [How to Evaluate a Finding Severity](/hawks-auditors/how-to-evaluate-a-finding-severity). #### **What happens if I choose the wrong severity?** The severity of findings has an element of subjectivity. The judges will review your submission and may re-categorize it based on their assessment. There isn't a direct penalty mentioned for misclassifying the severity. However, consistently misclassifying or misrepresenting findings could impact your credibility in the competition. For more information consult [How to Evaluate a Finding Severity](/hawks-auditors/how-to-evaluate-a-finding-severity).
What happens if one of my submissions is invalid? If "Y" is an invalid finding and you have many invalid findings, it can count against you. Specifically, if more than 85% of your findings are invalid, you will be disqualified from the competition. This system is designed to allow some leeway for invalid submissions but aims to prevent participants from spamming the system with numerous invalid findings. Refer to the [How to Determine a Finding Validity](/hawks-auditors/how-to-determine-a-finding-validity) to make sure your findings respect our validity guidelines.
### **👩‍⚖️ Judging** ***
Who are the CodeHawks judges? Judging is conducted by a dedicated panel of members from the Cyfrin team and engineers from the sponsoring protocol. This approach ensures impartiality and minimizes potential bias and conflicts of interest.
What is community judging? Community judging allows eligible CodeHawks auditors to earn rewards for judging other users' submissions. This drastically speeds up triage and turnaround times while giving auditors another chance to climb the leaderboard and showcase their skills.
How long does judging take? The duration for judging varies based on the size of the codebase and the number of submissions received. Specific timelines for each contest will be announced on our [**Twitter page**](https://twitter.com/CodeHawks) and within the appropriate contest channel on our [Discord](https://discord.gg/cyfrin).
Can I help Judge? Currently, we do not have a community judges initiative in place. However, it's on our roadmap for future implementation. Our primary concern is to ensure that any system we introduce maintains the highest standards of impartiality and transparency. We've observed conflicts of interest arising on other competitive platforms when community members were involved in judging. We aim to create a judging process everyone can trust and feel comfortable with.
I don’t agree with the judgment, what can I do? The judging period of every contest is immediately followed by a 48-hour Appeals Period. This period allows auditors an opportunity to raise objections and voice concerns they have with the preliminary judgments. The Appeals Period will be clearly announced via [Twitter](https://twitter.com/CodeHawks) and [Discord](https://discord.gg/cyfrin) See the [Appeals](/hawks-auditors/appeals) page for more information.
What is a finding? A finding represents a vulnerability in the codebase. Findings are categorized into different levels of severity: 1. **High:** This category indicates that funds are directly or nearly at risk. 2. **Medium:** In this category, funds are indirectly at risk, or protocol functionality or availability is disrupted. 3. **Low, Gas, Informational:** * **Low:** Funds are not at risk, but a function might be incorrect, state might not be handled appropriately, etc. * **Gas:** Refers to gas optimizations. * **Informational:** Pertains to code style, maturity, code smells, comment correctness, and similar aspects. It's important to note that these categories involve some subjectivity, and the judges determine a finding's category. If a protocol has specific criteria, then that should be followed. Additionally, at the beginning of each competition, the "[4naly3er](https://github.com/Picodes/4naly3er)" tool will be run, and any findings associated with this tool are ineligible for rewards. The basis for findings may evolve as CodeHawks progresses. For more information on findings and how to evaluate their severity, consult the [How to Evaluate a Finding Severity](/hawks-auditors/how-to-evaluate-a-finding-severity)guide.
# What is a Competitive Audit? A smart contract security auditing competition or contest is where security researchers, Hawks, review a smart contract or codebase to identify vulnerabilities, inefficiencies, and potential issues. Auditors then submit their findings to be rewarded based on their [validity](/hawks-auditors/how-to-determine-a-finding-validity), quality, and [severity](/hawks-auditors/how-to-evaluate-a-finding-severity). {% hint style="info" %} **Don't want to miss any of our competition announcements?** Make sure to follow us on [Twitter](https://twitter.com/CyfrinAudits?s=20) and join our [Discord](https://discord.gg/cyfrin) server! {% endhint %} ### **How does a Cyfrin CodeHawks auditing competition work?** Every smart contract auditing competition is comprised of seven periods:
1. Competition announcement This is the initial phase in which we announce the upcoming competition, detailing the smart contract(s) to be audited. Learn how to subscribe and submit your first vulnerability following the [quick start guide](/hawks-auditors/quick-start).
2. Kick-off This is the official start of the competition, and it will last 48 hours. From now on, participants can access the contract repo on the contests page and begin looking for bugs, issues, and vulnerabilities. Findings can be submitted through the contest page on the web portal. During [the kick-off](#id-2.-kick-off) period, auditors can also raise issues with the codebase, the scope, or any other contest's details.
3. Auditing Auditors delve deep into the provided smart contract(s), using their expertise to uncover vulnerabilities, inefficiencies, and other issues and recommendations. In the next phase, these findings are submitted to judges for assessment. This period is time-bound, ensuring a level playing field. The time allotted for a competition is determined mainly by the size of the audited code base.
4. Community judging and lead judging Once the auditing period concludes, the [community judging](/judging/how-community-judging-works) period will start, followed by the lead judging period, during which the Cyfrin CodeHawks team or appointed [judges](/judging/the-judging-process) will review the submissions. This will validate the findings, rank them based on severity, and prepare for the appeals phase. The length of this period is primarily determined by the number of submissions received.
5. Appeals For **48 hours** after the initial judging, auditors can raise concerns and [appeals](/hawks-auditors/appeals) about the decisions made during the judging phase. This window allows the community to ensure transparency and fairness.
6. Rewards After addressing escalations, the final results are announced, and rewards are distributed to auditors based on the quality and significance of their findings. [Payouts](/hawks-auditors/payouts) are distributed within 72 hours of the escalation period's closure and are currently paid in USDC on ZKsync.
*** # Quick Start Cyfrin CodeHawks Quick Start Guide for Auditors Welcome to Cyfrin CodeHawks! Here's a quick and easy guide to get you started as an auditor and submit your first vulnerabilities. ### **1. Create an account on CodeHawks** First, create a new account by visiting [codehawks.cyfrin.io](https://codehawks.cyfrin.io) and clicking the "sign up" button in the top right corner:
### 2. Subscribe to your first CodeHawks competition Navigate to the competitions page and look for "Live" or "Upcoming" contests:
{% hint style="success" %} **Don't want to miss any of our competition announcements?** Make sure to follow us on [Twitter](https://twitter.com/CyfrinAudits?s=20) and join our [Discord](https://discord.gg/cyfrin) server! {% endhint %} Clicking on a competition will open its details page, with important information such as: * [Prize pool](/hawks-auditors/payouts) severity breakdowns * Start and end dates * [nSLOC](/glossary) and scope * Scoring * Link to the GitHub repository (if the competition is live)
Every contest also comes with details that will help you understand: * The codebase * Scope * compatibilities * How to get the codebase up and running New contests are announced almost every week. When you find a contest that fits your skills, click on the subscribe button to join it:
### 3. Submit your first finding vulnerability Once you've found your first vulnerability, navigate to the competition page, and click on the submit "submit a vulnerability" button:
To submit your vulnerability, you'll be asked to insert: * Title - a <250 character descriptive title of your submission * Severity - a matrix of likelihood and impact characterizing your finding. Read [How to Evaluate a Finding Severity](/hawks-auditors/how-to-evaluate-a-finding-severity)for a full explanation. * Description - a detailed description of the vulnerability found and how to reproduce it. Learn more on [How to Present Your Findings](/hawks-auditors/how-to-write-and-submit-a-finding)on the dedicated guide. ### 5. Await for the judging results **After the auditing period ends, judges will evaluate each submission carefully to determine its validity, severity, and overall quality.** **Judging is done in two steps:** * [Community Judging](/judging/how-community-judging-works) - a period where all [eligible community judges](/judging/community-judging-eligibility) can evaluate others' submissions * [Lead judging](/judging/the-judging-process) - a period where the lead judge confirms or not the community judges' decisions and issue the final pre-appeal judgments. Every phase will be communicated on the platform and via announcements on [Discord](https://discord.gg/cyfrin). Learn more about [the judging process](/judging/the-judging-process). ### 6. Appeal to the judge's results For 48 hours following judging, [appeals](/hawks-auditors/appeals) will be accepted to contest judgments. This period will be clearly announced across all channels. \ During the 48 hours, interactions will be enabled on your GitHub submissions. During this time, you may leave comments detailing your escalation for re-assessment. ### 7. Get rewarded Once the final report is released, results will be announced, and [payouts](/hawks-auditors/payouts) will be sent to the winners. {% hint style="warning" %} Rewards are paid out in USDC through the ZKsync chain. Crediting the reward won't be possible without a ZKsync wallet connected to the user profile. {% endhint %} # The Kick-Off Period The Kick-Off period is designed to introduce participants to the contest, clarify the codebase and rules, and provide a moment for any immediate questions or concerns. This 48-hour window is vital for all participants and the fairness of a competitive audit. ### Key events of the kick-off period
1. Contest Commencement Announcements An official announcement will mark the start of the Kick-Off period. This will signify the beginning of the competition and provide all necessary details about the upcoming events during the Kick-Off.
2. Kick-Off Live Stream (optional) During the Kick-Off live stream, participants will: * Be given a thorough walkthrough of the codebase. This will help in understanding the structure, functionalities, and intricacies of the code you'll be auditing. * Have the opportunity to interact with sponsors and team members. They will be available to answer questions about the competition, the codebase, or related topics. **Note**: We highly recommend attending the live stream. It's a valuable opportunity to gain insights and clear up any uncertainties before diving into the audit.
3. Clarification & Feedback Window For the entire duration of the 48-hour Kick-Off period, participants can: * Seek clarifications on the contest specifications. If there's any part of the spec you're unsure about, this is your time to get clarity. * Discuss and provide feedback on any known issues with the spec. If you spot inconsistencies, ambiguities, or potential problems, you're encouraged to bring them up. By the end of the Kick-Off period, the contest spec will be finalized based on the discussions and feedback.
### Important Notes * **Finalization of Contest Spec**: After the 48-hour Kick-Off period, no changes to the contest spec will be accepted. Make sure to voice any concerns or suggestions during this window. * **Decisions & Judgments**: All decisions related to the competition will be based on the finalized contest spec. Ensure you're familiar with the final version to align your auditing strategy accordingly. # How to Present Your Findings 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 [severity of your finding](/hawks-auditors/how-to-evaluate-a-finding-severity) and its [validity](/hawks-auditors/how-to-determine-a-finding-validity), 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 [proof of concept (POC)](/hawks-auditors/how-to-create-and-submit-a-poc) 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* [*invalidation*](/judging/disqualification-criteria)*.* ### **How to format your report** When documenting a finding, adhere to the following structure: ```markdown ## 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.) ``` # How to Evaluate a Finding Severity When identifying vulnerabilities in a codebase, it's crucial to assess the potential impact and risk associated with them. Findings, or vulnerabilities, are separated into three categories: * **High** * **Medium** * **Low severity** These severities help stakeholders prioritize and address the issues appropriately. For auditors, finding higher-severity findings will increase their ranking in the contest leaderboard and [payout](/hawks-auditors/payouts). ### How to evaluate a finding severity The severity of a finding can be categorized as **High**, **Medium**, or **Low** and is determined based on several factors: 1. **Impact on the protocol:** How severe would the potential damage be if the vulnerability were exploited 2. **Likelihood of exploitation:** How probable would an attacker exploit this vulnerability? 3. **Degree of judge/protocol subjectivity**
Impact
HighMediumLow
HighHH/MM
LikelihoodMediumH/MMM/L
LowMM/LL
{% hint style="warning" %} **Subjectivity in Classification** While the Impact vs Likelihood matrix provides a structured approach, there remains a degree of subjectivity in classifying findings. The judge's discretion is pivotal in determining a finding's category. If the protocol under audit stipulates particular criteria, then those guidelines should be the benchmark for classifying findings. {% endhint %} #### How to evaluate the impact of a finding Impact refers to the potential harm or consequence to the users or the protocol due to the vulnerability. * **High Impact**: * Funds are directly or nearly directly at risk. * There's a severe disruption of protocol functionality or availability. * **Medium Impact**: * Funds are indirectly at risk. * There's some level of disruption to the protocol's functionality or availability. * **Low Impact**: * Funds are not at risk. * However, a function might be incorrect, the state might not be handled appropriately, etc. #### How to evaluate the l**ikelihood of exploitation of a finding** Likelihood represents the probability of the impact occurring due to the vulnerability.
High likelihood It's highly probable to happen. For instance, a hacker can call a function directly and extract money.
Medium likelihood It might occur under specific conditions. For example, a peculiar ERC20 token is used on the platform.
Low likelihood It is unlikely to occur. An example might be if a hard-to-change variable is set to a unique value on a specific block.
{% hint style="info" %} **Note**\ There are instances where the likelihood is deemed "computationally infeasible". For example, "An attacker could guess the user's private key". The author must demonstrate that their finding is computationally feasible in such scenarios. {% endhint %} ### Examples of High, Medium, and Low severity findings #### High Severity Findings **Properties:** * Direct impact on the funds or the main functionality of the protocol. * The attack path is straightforward. * The vulnerability is easily exploitable, leading to significant damage. **Example:**\ [See Detailed High Severity Finding](https://solodit.xyz/issues/boostsetlockstatus-should-update-the-callers-rewards-first-hans-none-meta-markdown_) For more examples of High severity findings, visit [Solodit](https://solodit.xyz/). #### Medium Severity Findings **Properties:** * Indirect impact on the funds or the protocol's functionality. * The attack path isn't straightforward and needs specific conditions to be met. * Though the vulnerability might cause harm, exploiting it is challenging. **Example:**\ [See Detailed Medium Severity Finding](https://solodit.xyz/issues/the-off-chain-mechanism-must-be-ensured-to-work-in-a-correct-order-strictly-cyfrin-none-cyfrin-stake-link-markdown) For more examples of findings on medium severity, visit [Solodit](https://solodit.xyz/). #### Low Severity Findings **Properties:** * Minimal impact on the funds or the protocol's main functionality. * The vulnerability doesn't lead to tangible real-world damage. * The path to exploit is either non-existent or highly improbable. **Example:**\ [See Detailed Low Severity Finding](https://solodit.xyz/issues/l-06-erc1155action-returns-false-on-supportsinterface-with-the-real-erc1155-interface-code4rena-notional-notional-contest-git) For more severe findings, visit [Solodit](https://solodit.xyz/). {% hint style="warning" %} **Non-Acceptable Severity** As of August 18th, 2023, CodeHawks no longer accepts submissions with a severity of Gas, QA, or Informational. Ensure that the vulnerabilities you are submitting directly or indirectly impact the protocol and are not merely gas optimizations, quality assurance issues, or informational insights. {% endhint %} *** For more information on how to write and submit findings, refer to the [How to write and submit a finding](/hawks-auditors/how-to-write-and-submit-a-finding) guide. # How to Determine a Finding Validity For findings to be considered valid, they need to check all the properties listed below: * Submissions must be made during the official duration of the contest. * Valid submissions should identify legitimate vulnerabilities within the codebase. * Issues that fall under Gas/QA or Informational severity will not be eligible for rewards, even if they are accurate or correct. * Submissions should include sufficient details and proof to support the findings. For instance, while ChatGPT and AI can assist in bug finding, relying solely or primarily on AI responses often leads to poor reports. Reports suspected of this approach will likely be deemed invalid. ### Contest-specific validity guidelines There are two criteria to determine the validity of a finding within the context of a specific contest: * The official contest specification on the [CodeHawks](https://www.codehawks.com) contest's page * The code within the scope After a contest launch, Sponsors have a 48-hour [kick-off period](/hawks-auditors/the-kick-off-period) to address any ambiguities raised by auditors in Discord regarding the contest-specific validity guidelines. Once this window has passed, the official contest specification on Cyfrin CodeHawks will be updated with answers from the Sponsor, becoming the ultimate standard for determining the validity of an issue within the contest**.** {% hint style="warning" %} Sponsors are strictly prohibited from employing the "[Moving The Goalposts](https://youtu.be/KeswYJgf5mM?feature=shared\&t=19)" logical fallacy to invalidate submissions after these 48 hours. {% endhint %} Judges and Sponsors may only invalidate a submission if it fails to meet the contest's predefined criteria. ### Vague generalities Vague generalities are always judged as invalid submissions. Examples include: * "This function may have re-entrance; add re-entrance guard." * "This hash function may have a hash collision; do the hashing differently." Suppose an auditor identifies a vulnerability in a function. In that case, they are responsible for demonstrating its impact by creating a [proof of concept](/hawks-auditors/how-to-create-and-submit-a-poc) (PoC) exploit that can cause significant damage to the system or result in permanent grief or denial of service. However, if another auditor submits an actual exploit with a PoC that proves the vague generality to be accurate, only that auditor will be rewarded.\ \ Please refer to the dedicated guide for detailed instructions on what to include and how to [submit a finding](/hawks-auditors/how-to-write-and-submit-a-finding). To determine the validity of a finding, we provide several issue categories as a guideline. Please note that final determinations will always be at the discretion of the Judge. ### Findings that may be invalid The following is a high-level list of issues which are usually not considered valid. {% hint style="info" %} The following table is a rough guide and **does not represent concrete policy**. Each issue's validity **may vary**, pending conditions and circumstances. Final determinations are at the judge/protocol's discretion. {% endhint %} | Issue | Description | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | | Gas optimizations | Users/protocols may pay extra gas due to this issue. | | **Zero address checks** | Ensure input values are not zero addresses. | | **Admin Input/call validation** | Issues related to incorrect input by admins, call order mistakes, and assumptions breaking due to admin actions. | | **Front-running initializers** | If there's no irreversible damage or fund loss & the protocol can redeploy and initialize again. | | **User experience and design improvement** | Minor inconveniences or design opinions with no clear loss of funds indication. | | **User Blacklist** | A user being blacklisted causing harm only to themselves. | | **EIP compliance with no integrations** | If no external integrations exist and no adverse effects arise due to non-compliance with an EIP. | | **Users sending ETH/native tokens** | If contracts allow users to send tokens accidentally. | | **Loss of rewards** | Losing airdrops, liquidity fees, or other rewards not in the protocol design. | | **Incorrect values in View functions** | Considered low by default, unless used in a larger function resulting in fund loss. | | **Mock contracts issues** | Any issues found in mock contracts. | | **Slippage** | Issues showing definite fund loss with a detailed explanation. | | **EIP Compliance** | Issues regarding EIP compliance with essential external integrations. | | **Out of Gas** | Issues leading to Out of Gas errors due to malicious users or specific call flows. |
# How to Write a PoC A Proof of Concept (PoC) demonstrates a concept's feasibility. In the context of smart contract auditing, a PoC demonstrates a vulnerability or flaw in a smart contract. A well-crafted PoC can help developers understand the vulnerability and its implications, making it easier to address the issue. By following this guide and template, auditors can ensure that their PoCs are clear, concise, and effective in communicating vulnerabilities to judges. ### **Key elements of a good PoC**
1. Working test case This is the most direct way to demonstrate a vulnerability. It should be executable and should clearly show the flaw in action.
2. Line-by-line comments Each line of the test case should be accompanied by comments explaining what that specific line is meant to do. This helps understanding the flow and logic of the PoC.
3. Clear separation of actors Clearly define and separate the roles involved in the PoC. Common roles include: * Attacker: The entity exploiting the vulnerability. * Victim: The entity affected by the exploit. * Protocol: The system or platform in which the smart contract operates.
4. Detailed exploit scenario If writing a PoC in the form of a test case is challenging or too straightforward, then a detailed step-by-step exploit scenario can be provided. This should explain: * **Initial State**: Describe the initial state of the system. * **Step 1**: Describe the first action taken by the attacker. * **Step 2**: Describe the subsequent action and so on. * **Outcome**: Describe the result of the exploit. * **Implications**: Discuss potential consequences or implications of the exploit.
#### Recommendations: 1. Provide suggestions or fixes to address the vulnerability. 2. Link to the vulnerable smart contract, code, or any other relevant links or resources. ### **Proof of concept (PoC) template** ````markdown markdownCopy code## Proof of Concept for [Vulnerability Name] ### Overview: Briefly describe the vulnerability. ### Actors: - **Attacker**: Description of the attacker's role. - **Victim**: Description of the victim's role. - **Protocol**: Description of the protocol's role. ### Working Test Case (if applicable): ```solidity // Solidity code or test case demonstrating the vulnerability // Line 1: Explanation of line 1 // Line 2: Explanation of line 2 // ... ```` # Appeals At Cyfrin CodeHawks, we pride ourselves on providing a transparent and fair competition environment. The **Appeals Period** is a testament to this commitment. For 48 hours following judging, escalations will be accepted to contest judgments. This period will be clearly announced across all channels.\ During the 48 hours, interactions will be enabled on your GitHub submissions. During this time, you may leave comments detailing your escalation for re-assessment. ### Appeals eligibility criteria To enforce a fair and streamlined competition environment, to raise an appeal on a third-party submission (owned by other auditors), auditors must: 1. **Have at least one submission in the Contest they would be judging:** This assures the community judge that they will possess the context and familiarity with the code necessary to provide an accurate and valid submission assessment. 2. **Have earned at least $200 USDC from previous CodeHawks competitions:** This will further mitigate unqualified or inexperienced judges and serve as a Sybil defense mechanism. 3. **Have a total submission to valid submission ratio greater than or equal to 0.2** will ensure that only auditors who share Cyfrin's commitment to industry-leading quality can judge other submissions. **Note:** An auditor will always be eligible to appeal their own submissions. The above eligibility criteria apply to appealing the submissions of others only. ### Preliminary results release The unveiling of preliminary results takes place immediately after the conclusion of our judging process. This release serves as an initial insight into the standing of submissions and gives participants a sense of their performance. Once the preliminary results are made public, an **Appeal Period** of precisely two days commences. This window allows participants to: * Raise concerns regarding their submissions. * Provide additional insights or clarifications. * Challenge the preliminary findings if they believe there are discrepancies. ### How to raise an appeal To initiate an appeal, navigate to your judged submission with the red notification dot, on the CodeHawks portal:
Read the community judges and lead judge comments in the provided comment box:
Suppose you don't believe the judge's decision is correct or have any questions about the judging results. In that case, you can add a new comment stating, **in greater detail**, why you believe a given issue is valid or invalid. If you're challenging other entries, provide concise reasoning for any discrepancies identified. {% hint style="danger" %} **Low-effort appeals risk being disregarded.** {% endhint %} ### Important Points to Consider * **Quality Over Quantity**: While we appreciate thoroughness and attention to detail, we must ensure that appeals are well-reasoned and backed by substantial evidence. Appeals that appear hasty or lack clarity will be promptly closed. * **Frequency of Appeals**: Participants are encouraged to raise valid concerns. However, excessive appeals with little to no merit can lead to a situation where even valid concerns from the participant might be disqualified. We urge participants to be discerning and thoughtful in their approach. Lead Judges of a contest will be responsible for assessing appeals during the appeals phase. For any further feedback or concerns, participants can use our [Feedback Form](https://app.deform.cc/form/992e3c6a-b817-49f5-8075-1e50fb2e2d0f/). # Payouts Get transparency into how reward payouts are calculated Auditor payouts consist of shares of the prize pool calculated based on the [severity](/hawks-auditors/how-to-evaluate-a-finding-severity) and [number of findings](/hawks-auditors/how-to-write-and-submit-a-finding) an auditor submits during a smart contract auditing competition. Here's how rewards are calculated:
High / Medium Findings **Current Payout Calculation:** For competitive audits, the payouts are currently determined as: * **Medium-Risk Shares**: `1 * (0.9^(findingCount - 1)) / findingCount` * **High-Risk Shares**: `5 * (0.9^(findingCount - 1)) / findingCount` This calculation is subject to future adjustments to align with auditors' needs. **Example:** Given a **H/M Prize Pot** of **$30,000** and a **Final report** with **3 Highs** and **2 Mediums**: * **Auditor A** submitted: High A, B, Medium A * **Auditor B** submitted: High A, C, Medium A, B * **Auditor C** submitted: High A, Medium A, B, C The shares per finding would be: * **Medium A** (3 findings): `1 * (0.9^(3 - 1)) / 3 = 0.27` * **Medium B** (2 findings): `1 * (0.9^(2 - 1)) / 2 = 0.45` * **Medium C** (1 finding): `1 * (0.9^(1 - 1)) / 1 = 1` * **High A** (3 findings): `5 * (0.9^(3 - 1)) / 3 = 1.35` * **High B** (1 finding): `5 * (0.9^(1 - 1)) / 1 = 5` * **High C** (1 finding): `5 * (0.9^(1 - 1)) / 1 = 5` Total shares: * **Auditor A**: `1.35 + 5 + 0.27 = 6.62` shares * **Auditor B**: `1.35 + 5 + 0.27 + 0.45 = 7.07` shares * **Auditor C**: `1.35 + 0.27 + 0.45 + 1 = 3.07` shares The prize distribution would be: * **Auditor A**: `6.62 / 16.76 = 39.5%` of the prize pot = $11,850 * **Auditor B**: `7.07 / 16.76 = 42.2%` of the prize pot = $12,660 * **Auditor C**: `3.07 / 16.76 = 18.3%` of the prize pot = $5,490
Low Findings For this tier, the prize pool is considerably smaller. The current calculation for low-risk shares is: * **Low-Risk Shares**: `1 * (0.9^(findingCount - 1)) / findingCount` Given the smaller prize pool and the potential volume of findings in this tier, auditors should note that judges may disqualify low-effort submissions at their discretion. #### QA / Gas / Informational As of August 18th, 2023, CodeHawks has stopped accepting findings related to gas optimizations, quality assurance issues, and informational insights.
{% hint style="warning" %} Rewards are paid out in **USDC** through the **ZKsync chain**. Crediting the reward **won't be possible** without a ZKsync wallet connected to the user profile. Payouts may be within 0.0001 USDC margin of error. {% endhint %} *** ### Duplicate issues An issue is considered a duplicate if they have the same **root cause**. For example, the following two issues are duplicates: * **No zero address check results in loss of funds: high** * **Users can lose precision when it doesn't check for address(0): low.** These have the same **root cause** even though they are submitted with different severity levels and are considered duplicates. The following are not considered duplicates: * **Users can lose precision when it doesn't check for address(0): low.** * **Dividing before multiplying loses precision: low.** Since they have different root causes (checking the zero address vs dividing before multiplying), they are not considered duplicates. # How Does XP Work? **CodeHawks XP System** Welcome to the CodeHawks XP System documentation page. Our XP system is designed to give a better insight into the contributions and expertise of our auditors, while also serving as a more comprehensive measure than simply relying on monetary gains. Here, we detail how the system works, the advantages it presents, and what you can expect from it. *** **Why XP Over Only Gains-Based Leaderboard?** * **Holistic Measurement**: XP provides a fuller picture of an auditor's capabilities and contributions. While financial gains might indicate the financial success of submissions, XP provides an understanding of the consistent quality and relevance of an auditor's findings. * **Experience Indication**: XP is more indicative of an auditor's experience and the value they bring to the platform, rather than just their monetary success. * **Motivation for Newcomers**: New auditors have a fair chance to climb the leaderboard by focusing on the quality of their submissions, ensuring everyone has an opportunity to shine. *** **How to Earn XP** 1. **Submission-based XP**: * Earn XP for each valid submission based on its post-judging severity rating. * Default XP rewards: * Low: 2 XP * Medium: 20 XP * High: 100 XP > **Note**: XP values mentioned are current defaults and can change. The CodeHawks team will always communicate changes in advance. 2. **Team Submissions**: * If you're in a team, all members earn XP for valid submissions by the team. * There's a scaling mechanism for fairness: * Teams of ≤5 : Each member earns 100% XP * Team of 6 : Each member earns 90% XP * Team of 7 : Each member earns 80% XP * ... so on till Teams of 10+ where each member earns 50% XP 3. **First Flights**: * XP for First Flights is the same distribution by severity as a regular audit. * A contest's 'selected' finding will receive a further boost of 1.4x *** #### Difficulty Multipliers For contests in which few submissions are received, a modifier to XP rewards will be levied as follows: * **<=50** valid submissions: 3x bonus XP * **<=150** valid submissions: 2x bonus XP * **151+** valid submission: Default XP This is meant to reward those who persevere through the most difficult contests and secure the most complex protocols. *** **What Your XP Represents Now** Currently, the XP you amass symbolizes your expertise and contributions to the CodeHawks community. Although no specific leveling system exists right now, we're excited about future prospects. *** **What’s On The Horizon** With the XP system's evolution, anticipate more perks: * **Visual Recognition**: Flaunt badges or icons that spotlight your expertise. * **Community Involvement**: Be eligible for community voting and other exclusive opportunities. Stay connected for more upgrades to the XP system. We are committed to making CodeHawks a platform where every contribution, big or small, is recognized and celebrated. # The Judging Process The judging phase is critical to Cyfrin CodeHawks' competitive audits, ensuring its contests' integrity, transparency, and fairness. Here's an in-depth look at how the judging process works. ### How does the CodeHawks judging process work? We split the judging process into two phases: 1. [**Community judging**](#community-judging) 2. **Lead judging** Both happen after the contest's closed submission window, lasting an average of \~ three weeks. Once judging begins, further submissions through the CodeHawks Audit Portal will be disabled. #### Community judging All eligible community members can join the community judging phase as judges. Community Judges will use the CodeHawks portal to submit their assessments to the Lead Judge for each contest, to earn rewards based on their performances and accuracy. Find more information on Community Judging and how it works [here](/judging/how-community-judging-works). You can check out more eligibility information [here](/judging/community-judging-eligibility)! #### Lead judging A member of the Cyfrin team or an appointed, reputable, and esteemed community member may be invited to assist in judging. While submission volume certainly plays a part, the average judging period is \~2.5 weeks. *** The judging process at CodeHawks is meticulously designed to uphold the highest standards of fairness and clarity. We're continually evolving our methods to reflect the best practices and ensure that every participant receives thorough, unbiased feedback. For further inquiries or more detailed insights into our processes, please [get in touch with our dedicated support team](https://cyfrin.io/get-an-audit). # How Community Judging Works The judging phase will start upon the resolution of the submission period of a competitive audit. At this point, all[ eligible community judges](/judging/community-judging-eligibility) for a contest will receive an email advising them of the beginning of the judging phase and their [eligibility](/judging/community-judging-eligibility) to participate. This page teaches you how to participate in the community judging phase, evaluating others' submissions for a chance to earn [extra rewards](/judging/payouts-and-rewards). ### Judging Dashboard Navigate to the judging dashboard by clicking on the "judging" item on the top navbar.
From here, judges can see any contests they are eligible to judge. By hovering over the eligibility information icon, judges can see the [eligibility requirements](/judging/community-judging-eligibility) to participate in each contest's judgment. The duration of this period will be determined by several factors including, but not limited to: * **Number of submissions** * **Number of eligible judges** ### Community Judging Submission View Clicking 'Judge' will bring one to the Community Judging submission view. The community Judge will be faced with the Community Judging view. In this view, a judge will be randomly assigned one submission at a time, with another assigned after each judgment. There is no limit to the number of submissions a community judge can complete.
A community judge's role is to determine if each submission assigned is valid or invalid and categorize them as such using the radial buttons available in the top right. ### Submission Tags During the judging phase, participants might observe tags being added to their submissions. These tags serve as indicators and can denote various aspects, including: * **Valid Findings**: Recognized by tags like `finding-reentrancy-borrow-function`. * **Selected Findings**: Denoted by the `selected` tag. Following the conclusion of the community judging period, an assigned Lead Judge will assess the validity of judgments and ultimately determine the performance of community judges. ### Performance A community judge's performance is determined by comparing the accuracy of their submissions versus the Lead Judge's final verdicts. A community judge will receive +1 point if their judgment matches the Lead Judge's and -1 point if the assessments do not match. This simple system provides a grade of how accurate a community judge's assessments are and ultimately determines [rewards](/judging/payouts-and-rewards) for participants. **For example:** * The community Judge determines ten valid findings and five invalid * The Lead Judge's verdict matches 8 of the Community Judges' valid and 4 of the CJ's invalid judgments. The equation looks like this: **Valid Judgement Matches** - **Valid Judgement Mismatches** + **Invalid Judgement Matches** - **Invalid Judgement Mismatches** For example: 8 - 2 + 4 - 1 = 9 The community judge in this example would receive 9 points for their 15 judged submissions. # Community Judging Eligibility A few distinct criteria will be used to determine a user's eligibility to participate in community judging for a contest. To be eligible for community judging a competition, a potential judge must: 1. **Have at least one submission in the Contest they would be judging:** This assures the community judge that they will possess the context and familiarity with the code necessary to provide an accurate and valid submission assessment. 2. **Have earned at least $200 USDC from previous CodeHawks competitions:** This will further mitigate unqualified or inexperienced judges and serve as a Sybil defense mechanism. 3. **Have a total submission to valid submission ratio greater than or equal to 0.2:** This will ensure that only auditors who share Cyfrin's commitment to industry-leading quality can judge other submissions. ### First Flights The criteria for community judging in First Flights may differ from those outlined above. Fewer restrictions may be employed to pursue learning opportunities. # Disqualification Criteria We uphold a high standard of integrity and quality for our competitive audits. Our goal is to ensure a fair playing field for all participants while maintaining the credibility of our competitions. Below, we define the specific criteria that may lead to the disqualification of participants from our contests:
Issue validity Ensuring the authenticity and relevance of findings is crucial for the integrity of our competitions. * **Threshold for Validity**: Participants must maintain a validity rate of more than 15% for their findings. If over 85% of a participant's submissions are deemed invalid, they will face disqualification. **Examples**: * 1 valid, 6 invalids = 14.3% valid -> disqualified * 2 valid, 6 invalids = 25% valid -> qualified
Timeliness of submissions Promptness is key: * Submissions must be made within the designated competition window. * Any findings submitted after the competition window closes will not be considered.
ChatGPT & AI generated findings While AI tools like ChatGPT can be beneficial: * Submissions based primarily or solely on AI-generated responses often lead to subpar reports. * Participants suspected of relying excessively on AI for their submissions risk disqualification.
Excessive invalid appeals During the appeals process: * Participants are encouraged to raise valid concerns. * However, an overwhelming number of invalid appeal submissions can risk the invalidation of all of a participant's appeals. * The Threshold for this is currently at the Judge's discretion
Failure to adhere to the CodeHawks community guidelines Upholding our community values is paramount: * Participants must adhere to the community guidelines outlined on [CodeHawks](https://docs.codehawks.com/judging/www.codehawks.com), our [Twitter](https://twitter.com/CodeHawks) page, and [Discord](https://discord.gg/cyfrin) channel. * Any breach of these guidelines may result in disqualification from the current contest and risk the participant's eligibility for future competitions. Our disqualification criteria ensure the credibility and fairness of CodeHawks' competitive audits. Adherence to these rules is essential for maintaining our platform's and community's integrity. We urge all participants to familiarize themselves with these criteria and uphold the standards set forth by CodeHawks. If you have any questions or need further clarification, feel free to contact our team or consult our community guidelines on our official platforms.
# Payouts and Rewards {% hint style="warning" %} Rewards are paid out in USDC through the ZKsync chain. Crediting the reward won't be possible without a ZKsync wallet connected to the user profile. {% endhint %} The judging reward pool is set at 7.5**%** of the contest's total prize pool up to a cap of $15,000. Payment for the Lead Judge is calculated separately from a contest's total prize pool. Competitive Judges will be eligible for payouts based on their performance while judging a contest. The **Top 5 community judging participants by total point value** will receive equal portions of the judging pool (1.5% of the total contest prize pool). **Example:** * The contest is hosted for a $50,000 total prize pool. * 7.5% or $3,750 is allotted as a judging pool. * Community Judges are ranked by points earned during the judging period. * The top 5 Community Judges receive $750 each. **Example 2:** * The contest is hosted for a $250,000 total prize pool. * The judging pool is capped at $15,000. * Community Judges are ranked by points earned during the judging period. * The top 5 Community Judges receive $3,000 each. ***Please note: Payouts may be within 0.0001 USDC margin of error.*** # The Auditing process Cyfrin CodeHawks ensures the security of the protocols and teams we assist through an innovative private and community code review process. To learn more about how competitive audit works from an auditor's perspective, check out Auditors. Ensuring the security of protocols and their users is our top priority, and making the process for developers and protocol teams as smooth as possible is our second: This page outlines your journey to securing your code base and what you'll need to ensure complete coverage of your protocol. Here's what our auditing process looks like:
1. Request an audit Request an audit by going to [codehawks.com ](https://Codehawks.com)and submitting the "Request an Audit" form under “Request Audit” - you can schedule an audit with at least three days' notice. Our team will contact you within two days to arrange a screening call and assess the properties of your project and code base.
2. Screening interview and code base assessment The CodeHawks team will contact you to discuss your audit scope, expected timeline, and requirements necessary to initiate an audit. They will also provide recommendations on the [ideal auditing path to take.](broken://pages/pZpQPcXVi677BCQyW6vQ) Check out our [guidelines for more information on what is required to start an audit.](broken://pages/hSDgNIegfbSDhmKSuVXV)
3. Pricing and timelines The CodeHawks team will conduct an initial assessment of your code base and project, and provides you with a quote based on the length of time required for the audit and its complexity. You can learn more about [pricing and timelines on our guide](broken://pages/PXcDmcqca3ksbflYNwYo).
4. Code freeze At least, 2 days before the audit starts, protocol's teams are required to send CodeHawks the final: * commit * branch * known issues * contracts. After that a **code freeze is required** to establish a standard - This means that everyone will be looking at the same code for the entire duration of the audit. **Please note that this includes your own repository as a pull request can leak alpha information to our community.** Take a look at the [Preparing for an Audit guide](broken://pages/hSDgNIegfbSDhmKSuVXV) to learn more on what you'll need to get the auditing started
5. Audit begins In case of an auditing comeptition, we ask for a member(s) of your engineering team to be available on the [CodeHawks Discord ](https://discord.gg/cyfrin)server in order to answer Auditors questions via the dedicated channel. Each member will be given a special "sponsor" role to make sure you're recognisable. In any case, our community managers will be always available to help you in the process and answer auditors' questions.
6. Judging and appeal Immediately after the audit contest ends, the judging phase commences. The duration of the judging contest varies depending on the number of issues submitted. During this phase, security experts thoroughly evaluate the submissions.\ \ Once the judging phase is complete, the Appeal period begins. In this stage, security experts have the opportunity to flag any issues they believe were not categorized correctly during the initial judging, seeking a second opinion.\ \ To know more about the [Appeal period you can refer to this guide](#6.-judging-and-appeal).
7. Initial report A day or so after the appeal period ends, the CodeHawks team, will compile and meticulously organize a curated, de-duplicated list of all High, Medium and low-severity findings for your team. This compilation will enable your team to effectively prioritize and address these critical vulnerabilities **Note: The following steps are only present in protocols opting in for Competitive reviews or** [**Private Audits**](https://cyfrin.io)**.**
8. Mitigation phase - Fix the code First, our teams will agree on a suitable time frame to tackle these issues. Once we've set the time, your team can start implementing the necessary fixes in your code base. It's crucial to ensure that these vulnerabilities are addressed promptly and effectively to enhance the security of your systems. Additionally, you may opt for a Mitigation Review Contest, following your initial audit to verify your implementations. These are much faster than the initial audit phase! Through these steps, you'll be sure to strengthen your code and safeguard your applications against potential threats.
9. Final report Post-fix review, our team will meticulously review your code once more to compile a detailed final report, ensuring all the fixes have been implements and your code is ready to be shipped.


# First Flights CodeHawks First Flights is a Cyfrin flagship initiative to introduce the next generation of web3 developers to smart contract security audits. It goes beyond the traditional learning process by offering a format for emerging auditors to gain hands-on experience with real-world web3 security audits and **receive feedback and advice on their submitted findings.** We have created [CodeHawks First Flights](https://www.codehawks.com/first-flights) to upskill those learning smart contract auditing a ground to learn, network, get feedback, and test their newly-acquired skills in the open. {% hint style="success" %} **Want to learn smart contract development and security?** If you're just starting, join us at [Cyfrin Updraft](https://updraft.cyfrin.io), the ultimate smart contract learning platform, completely free. {% endhint %} *** ### What is a CodeHawks First Flight? First Flights are smart contract auditing challenges with smaller codebases and different reward mechanisms from our standard competitions. These make them the perfect testing and learning ground for any aspirant smart contract security auditor. The community even contributes some First Flight code bases! Visit [Community First Flights](/create-and-submit-a-first-flight) to learn more about how you can contribute. A new First Flight is announced monthly and will be available on the [CodeHawks](https://codehawks.com) platform for participation. Unlike the CodeHawks smart contract auditing competitions, First Flights does not offer monetary prize pools but grants participants experience earned by submitting findings. *** ### How to join a CodeHawks First Flight Joining a CodeHawks First Flight is the same as joining a proper auditing competition: 1. If you haven't already, create a new account on [codehawks.com](https://codehawks.com) 2. Subscribe to the upcoming competition by clicking on the subscribe button on the competition box 3. When the First Flight starts, you'll be notified via email, on the platform, and our [Twitter](https://twitter.com/codehawks) 4. The contest's codebase will be made public, and you can start analysing, testing, and auditing the codebase in scope! *** ### How CodeHawks First Flights work **Subscribe to and join the competition kickoff** * A new First Flight takes off every week * First Flights will be announced and detailed like a standard audit competition on [codehawks.cyfrin.io](https://codehaw.cyfrin.io), [Twitter](https://twitter.com/codehawks), and [Discord](https://discord.gg/cyfrin) server. * Thoroughly read the guidelines on the contest page to understand the scope and the codebase. * The scope of the codebase will be made public upon contest launch. * Deep dive into the smart contracts to find bugs and potential exploits vectors.
**Identify vulnerabilities and submit findings like a real auditor** * Participants must review the smart contract codebase, looking for bugs and potential exploit vectors. * After identifying vulnerabilities, participants will have to [write a PoC](/hawks-auditors/how-to-create-and-submit-a-poc) and [submit their findings](/hawks-auditors/how-to-write-and-submit-a-finding). * A live submission portal offers the same authentic experience of our standard CodeHawks competitive audits submission process.
**Receive feedback and learn faster.** * A judge will thoroughly review and test every finding, [evaluate its validity](/hawks-auditors/how-to-determine-a-finding-validity), and confirm or adjust the severity level. * After the [judging phase](/judging/the-judging-process), participants can [appeal](/hawks-auditors/appeals) the judge's decisions. * Receive direct feedback on your submissions and use this feedback to improve.
**Celebrate your achievements** * Upon finalization of results, [XP points](/hawks-auditors/how-does-xp-work) are awarded! * As participants accumulate XP, they can rise through the ranks on the leaderboards and gain recognition for their expertise. ### Why Join a First Flight? **1. The ultimate learning opportunity for aspirant smart contract auditors** Engage in a new challenge every week, ensuring constant exposure to different scenarios and learning from real-world use cases and experts' code bases. **2. Evolve your skills in real-world scenarios** The complexity of each Flight increases over time, ensuring that participants are consistently challenged and their skills progressively honed. **3. Earn CodeHawks XP and climb the leaderboard** While there is no monetary prize, participants are rewarded with [CodeHawks XP](/hawks-auditors/how-does-xp-work) for every vulnerability discovered, recognizing their efforts toward self-improvement. {% hint style="success" %} **Not feeling ready to join?** Join us at [Cyfrin Updraft](https://updraft.cyfrin.io) to kickstart your smart contract security and development career, completely free. {% endhint %} # Create and Submit a First Flight Community First Flights are Cyfrin's most recent expansion to our First Flight initiative. Community First Flights presents the perfect opportunity for those wanting to contribute a fun code base or strengthen the developer side of their skill set! ### Submission Criteria The rules are simple: 1. Create a fun project with a theme! (Holidays are popular) 2. Ensure the in-scope contracts are \~ 100-200 nSLOC 3. The project should have a maximum complexity of 200 In addition to the above, First Flights are meant to contain bugs! Make sure your project intentionally includes: * One or two easy-to-find bugs * One medium-difficulty bug * One hard-to-find bug * One High/Critical * One Low Be sure to write up an answer key detailing the intentional bugs you've placed in your code! The final piece required is to ensure your project has an appropriate README. Please use the template provided below and tell us about your protocol! {% file src="/files/TO0b1EGHEJZGQ9RmpMEG" %} Community First Flight README Template {% endfile %} ### How to submit a First Flight Once your repo is ready fill out this [form](https://app.deform.cc/form/4f8e7158-eb8a-457c-b15a-c3267514ec12) and, ping @**equious.eth** on [Discord](https://discord.gg/cyfrin). He will arrange the sharing of your code base privately. From here, your submission will be vetted, and you'll be provided any necessary feedback or adjustments that require implementation. ### When will my First Flight start? Submissions will be accepted on a first-come, first-served basis. A few things to note: * A submission must be fully vetted and accepted before being 'in line'. * First Flights are held twice/month. * In order to run the contest, we require at least three days' notice before the next expected First Flight. * Code bases ready with less notice than this will be scheduled for the next available First Flight. Cyfrin retains the right to shift to a **lottery selection process** should the pending submissions grow too large. # Tools A list of suggested tools from the Cyfrin CodeHawks auditors' community ### Auditor Tools These are auditor tools that you can use to help you audit smart contracts. * [Solodit](https://solodit.xyz/) <- (Use this once you start doing competitive audits!) ### Static Analysis * [Aderyn](https://github.com/Cyfrin/aderyn) * [4naly3er](https://github.com/Picodes/4naly3er) ### Symbolic Execution / Formal Verification Tools * [Manticore](https://github.com/trailofbits/manticore) * [Mythril](https://github.com/ConsenSys/mythril) * [Halmos](https://a16zcrypto.com/posts/article/symbolic-testing-with-halmos-leveraging-existing-tests-for-formal-verification/) * [Solidity Compiler](https://docs.soliditylang.org/en/v0.8.20/smtchecker.html) * [hevm](https://github.com/ethereum/hevm) * [EthBMC](https://github.com/RUB-SysSec/EthBMC) * [KEVM](https://github.com/runtimeverification/evm-semantics) * [Certora](https://www.certora.com/)