Zilliqa is enabling new decentralized business models which remove middlemen and inefficiencies. The trustless connections formed on Zilliqa’s blockchain are creating new ways of interacting and trading with each other and we’ve only just begun unfolding the possibilities.

Security is paramount to our business and we invite you to test and help secure our primary publicly facing assets - focusing on our cryptocurrency platform and smart contract language/implementation. We appreciate your efforts and hard work in making the internet (and Zilliqa) more secure. We look forward to working with the researcher community to create a meaningful and successful bug bounty program. Good luck and happy hunting!

Response Targets

Zilliqa will make a best effort to meet the following response targets for hackers participating in our program:

| Type of Response | SLA in business days |

| ------------- | ------------- |

| First Response | 2 days |

| Time to Triage | 5 days |

| Time to Bounty | 2 days |

| Time to Resolution | depends on severity and complexity |

We’ll try to keep you informed about our progress throughout the process.

Disclosure Policy

• Please do not discuss any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.

• Follow HackerOne's disclosure guidelines.

Program Rules

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.

• Submit one vulnerability per-report, unless you need to chain vulnerabilities to provide impact.

• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).

• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.

• Social engineering (e.g. phishing, vishing, smishing) is prohibited.

• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

Test Plan and Guidance

Setting up local network

To set up a local network, please refer to the readme at https://github.com/Zilliqa/Zilliqa.

Testing on the testnet

• The endpoint of the testnet is at https://dev-api.zilliqa.com.

• API to interact with testnet can be found at https://dev.zilliqa.com/docs/apis/api-introduction

• To create a testnet wallet and request for testnet $ZIL, you can use the testnet wallet at https://dev-wallet.zilliqa.com

Documentation

• Core protocol: https://dev.zilliqa.com/docs/contributors/contribute-buildzil

• SDK: https://dev.zilliqa.com/docs/dev/dev-started-introduction/

• Scilla smart contract: https://scilla.readthedocs.io/

For staking related testing

Please refer to the following blog https://blog.zilliqa.com/security-bug-bounty-programme-for-seed-node-staking-contract-kicks-off-today-expert-inputs-needed-27c81d96934b for reference and more information.

For ZilBridge related testing

• Introduction to ZilBridge:

  • https://www.google.com/url?q=https://blog.zilliqa.com/switcheo-zilliqa-bridge-will-be-a-game-changer-for-builders-hodlers-ebe7fce7bce1&sa=D&source=editors&ust=1629214275460622&usg=AOvVaw0mFi-O0B0c3LizFLGqXrFA

• Readme for ZilBridge smart contracts

  • https://github.com/Switcheo/switcheo-tradehub-zil/blob/feat/switcheo/README.md

• Please refer to https://docs.zilswap.io/how-to/zilbridge/beta-testing on how to get started on using the ZilBridge.

  • ZilBridge Beta testing portal (Testnet): https://zilswap.io/bridge

  • Please note that once the ZilBridge mainnet is up, you will be required to switch to the Testnet mode via ZilPay wallet in order to conduct your testing on the testnet.

• Eligible reports will only cover the source code of Zilliqa’s smart contracts and ZilBridge UI. It does not cover any issue relating to re-organization on Ethereum Ropsten testnet or bridge relayer that can affect bridge functionality.

• Non-security functional bugs will not be eligible for a reward.

Private keys in unit tests

There are private keys coded within unit tests and examples such as the non-exhaustive list below. These are non-sensitive and should not be reported as exposure of keys. Note that example codes from past git history are also considered non-sensitive.

• https://github.com/Zilliqa/gozilliqa-sdk/blob/master/account/wallet_test.go

• https://github.com/Zilliqa/gozilliqa-sdk/blob/master/account/account_test.go

• https://github.com/Zilliqa/Zilliqa/blob/master/constants.xml

• https://github.com/Zilliqa/Zilliqa/blob/master/constants_local.xml

• https://github.com/Zilliqa/Zilliqa-JavaScript-Library/tree/dev/examples

• https://github.com/Zilliqa/Zilliqa-JavaScript-Library/tree/dev/packages/<zilliqa-js-*>/test

  • This is referring to all packages in https://github.com/Zilliqa/Zilliqa-JavaScript-Library/tree/dev/packages

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Production versions of Zilliqa and Scilla are out of scope for this bounty program

• Distributed denial of service

• Clickjacking on pages with no sensitive actions

• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions

• Attacks requiring MITM or physical access to a user's device.

• Previously known vulnerable libraries without a working Proof of Concept.

• Comma Separated Values (CSV) injection without demonstrating a vulnerability.

• Missing best practices in SSL/TLS configuration.

• Any activity that could lead to the disruption of our service (DoS).

• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

• Rate limiting or brute force issues on non-authentication endpoints

• Missing best practices in Content Security Policy.

• Missing HttpOnly or Secure flags on cookies

• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)

• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]

• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application, or server errors).

• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.

• Tabnabbing

• Open redirect - unless an additional security impact can be demonstrated

• Reporting of private keys that are part of unit tests

• Issues that require unlikely user interaction

• Cache-control related issues

• Issues that are already reported or already acknowledged by the team in the public domain eg. Github Issue tracker

• Non-sensitive private keys in unit tests. Some examples listed on “Test Plan” section under “Private keys in unit tests”

• Eclipse attack on the network

• Hosting infrastructure of security testnet (AWS, Kubernetes)

• Exposure of internal IP address or domains

• Installation Path Permissions

Safe Harbor

When conducting your vulnerability research, please be reminded to act in accordance with the Computer Fraud and Abuse Act (CFAA), and/or similar state laws, and to be lawful, helpful to the overall security of the Internet, and conducted in good faith.

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep Zilliqa and our users safe!