It is tempting to simply include a link to your GitHub repo in your assets in scope table, however, it is better to provide more detail because it helps whitehats to select impacted assets more efficiently.
It it typically best to link to a block explorer that shows the smart contract code. They should appear with the original source code and thus should be, for EVM block explorers at least, Exact Match Verified. With that said, there are special cases where Similar Match Verified contracts are allowed. For example, if they are a proxy and the implementation contract is also included in the assets in scope table and is Exact Match Verified.
If you only have smart contracts, it’s best to provide us the GitHub repo so we can include it as reference. This is especially important if you require a PoC. In general, more documentation is best because it allows security researchers to spend less time looking for information and more time looking for bugs. It is also important that you include the correct commit numbers so that whitehats know which version of the codebase to work on.
Furthermore, we recommend that you specify which folders in the Github repository are in scope. If you do not do this, whitehats might submit bug reports for testnet or mock folders that offer little benefit but are technically in scope of the bug bounty program.
For blockchain, it is best to list components separately where possible. For example, specific libraries, adapters, and a consensus engine can be split apart.
If there are any testnet folders or mock files, please make sure to let us know so we can highlight that they are out-of-scope.
For Web/App assets, you should list the specific subdomains, if any, that you would like to include in your bug bounty program. These are normally just app, but we’ve also encountered many bug bounty hunters bringing up takeovers in other subdomains, so we encourage you to list any subdomain containing deployment addresses or other sensitive information. Pages are normally included as in-scope. No links to GitHub or any other similar site are required.
For mobile apps that are available for download, please provide links to where the files can be downloaded. These can be links to F-Droid, Google Play, or the App Store for iOS.