Skip to main content
Sign in Menu

Web3 PoC guidelines

  • Updated

Summary

As a security researcher, it’s inevitable that you will need to provide a PoC (Proof of Concept) for your bug report. Almost all bug bounty projects on Immunefi require it in some form, especially for high and critical bounties. 

PoCs are meant to be minimally or zero-invasive. In general, it’s important to not engage in unauthorized disclosure, make changes, or access sensitive information beyond what is necessary to submit the report. Violation of any of these rules will, in almost all cases, result in an immediate and permanent ban from the Immunefi platform. 

Are PoCs for web2 bugs the same as for web3 bugs?

No. Web3 PoCs need to be runnable code that demonstrates that a bug/vulnerability and impact are real without actually exploiting the vulnerability in a live environment. Web2 PoCs do not have that requirement, and can even be in the form of a video, screenshots, or logs.

Are PoCs a must for hunting smart contract bugs on Immunefi? 

Yes. Most projects on Immunefi, especially those with smart contract assets in scope, require a PoC for bug reports to be valid and in-scope. Without a PoC, it can sometimes be impossible to tell whether there’s any bug at all, or most importantly, whether there’s any impact. 

A well-written PoC makes it unambiguous that there’s a bug and that an impact is real. Once a project receives a submission with an excellent PoC, they are able to analyze, respond, and pay out a bug bounty much faster. 

How do I learn more about how to write a PoC? 

There are many excellent learning resources on writing a PoC, including some articles we’ve written ourselves. 

Do you have any recommended resources for writing PoCs quickly and effectively? 

We recommend you read our article Immunefi PoC Templates. In the article, we introduce the concept of templated PoCs. With Immunefi’s PoC template repository, you can use pre-written code blocks to easily and quickly build PoCs for any bugs that you find–without having to start totally from scratch.

For example, the repository provides pre-built templates for common vulnerability types like reentrancy, token manipulation, flash loans, and oracle price manipulation. These templates integrate design patterns commonly repeated across different protocols.

Is exploiting the vulnerability on the actual contracts (public testnet or mainnet) acceptable as PoC?

Absolutely not. This goes against the rules of Immunefi and will likely result in you being banned permanently from the platform. Do not test on public testnet or mainnet.

How do I ensure my PoC accurately matches the on-chain state of the chain (and contracts)?

The smart contract PoC should always be made by forking the mainnet using tools like Hardhat or Foundry.

What if it's not feasible to fork the mainnet for my PoC?

If forking the mainnet state is not feasible, using the project’s existing test suite is an acceptable alternative. However, the test conditions must accurately reflect the state of the deployed code. If the conditions do not match, the project may request additional PoCs to ensure accuracy.

Can I use screenshots or a recording to as my web3 PoC to show the vulnerability?

No. The PoC should contain runnable code for the exploit demonstration. Screenshots of code are not acceptable. The whitehat can choose any framework or language to write a PoC. The whitehat should mention all the dependencies, configuration files, and environmental variables that are required in order to run that PoC, or any other requirements to run the test.

I wrote a working PoC with working, runnable code, but it was rejected. Why?

One possible reason is that your PoC failed to include clear print statements and or comments that detail each step of the attack and display relevant information, such as funds stolen/frozen etc. It is necessary to include such information so that the reviewer can thoroughly understand and replicate the attack scenario.

How do I share the configuration files etc. that should go with my PoC?

You can upload the PoC containing all the configuration files directly to Google Drive and share the link in the submission on the Immunefi Dashboard.

Can I share my PoC in the submission as a comment without any links or additional attachments?

Yes. If the PoC is simple enough that it doesn’t require any configuration files, then it can be shared in the submission itself by pasting out the code in the comment.

Other than runnable code, what else can I add to make my PoC complete?

You should ideally determine and provide data on the amount of funds at risk, which can be determined by calculating the total amount of tokens multiplied by the average price of the token at the time of the submission. 

What other requirements are necessary to follow for submitting a PoC?

You must comply with any additional guidelines specified by the bug bounty program the whitehat is submitting a bug report to. If there is any unreasonable requirement by the project, use the request help feature to ask for assistance.

Can I submit a partial PoC first, and then update/complete it after submission?

Your PoC must be complete/functional at the time of submission. Do not submit a partial or incomplete PoC, or your report may be closed. 




Related articles

Comments

0 comments

Article is closed for comments.