The Tron Bug Bounty Program is aimed at discovering potential technical vulnerabilities in the mainnet with the help of TRON’s community members, especially those who specialize in global network security, to sustain TRON mainnet as the most secure public blockchain in the industry and to provide secure and stable infrastructure and services to DApps deployed on the mainnet. We take the security of TRON mainnet very seriously. If you have made an important discovery of potential bugs, please contact us and join the TRON Bug Bounty Program as soon as possible and we will surely offer generous rewards!

Scope Updates

April 10, 2019

Changes - Odyssey-v3.5.1

• (#2045)Refactor of sync & adv module, increase code readability and system scalability.

• (#2028)RocksDB will be an option for the storage engine in the java-tron. The detail of the Rocksdb is described in this document. (https://github.com/tronprotocol/documentation/blob/master/TRX_CN/Tron-doc.md#471-rocksdb)

• You can use RocksDB as storage engine when you want to back up the database without the node application stopped, you can check the usage of Rocksdb engine in the document. It has more tuning parameters for faster-synchronizing block and takes up less disk space when compared with the LevelDB.

• The database needs to be reset if the DB engine has been changed, but a tool can be used for converting Leveldb data to Rocksdb data, the instructions about this tool can be found here: https://github.com/tronprotocol/documentation/blob/master/TRX_CN/Tron-doc.md#4714-leveldb-database-convert-to-rocksdb-database-english-verison

• Add fast-forward feature and the miss rate of the block can be decreased by setting the forward node.

February 28, 2019

Changes - Odyssey-v3.5.0.1

• (#1873) Solved the Compatibility Problem between Backup and DUP_WITNESS

• (#1907) Optimize duplicate check of transaction, Increase processing speed

• (#1893) Transfertoken function security improvement

• (#1893) ADDRESS and ORIGIN instruction security improvements

• (#1929) Improve the partial UNKNOWN execution results of the smart contract to a more detailed error type

• Log optimization

  • (#1865) log is printed in modules
  • (#1872) log configuration file (logbak. xml) can be specified by parameters --log-config

  • Http interface

  • (#2009) remove txid in response of triggersmartcontract

  • (#2008) fix a bug about updatewitness
  • (#2006) limit the body size in request
  • (#2023) Fixed an issue: in a specific case, the CPU single core usage rate reached 90%, but had no effect on the overall performance.

New Features - Odyssey-v3.5

• (#1903) Multiple signatures support and different permissions support in accout

  • An account can set different permissions.
  • Each permission has a threshold and can be managed by different accounts. Each account in a permission has a weight.
  • Each transaction created by an account should be authorized by a permisson in the account.
  • Transaction should be signed by the accounts in the permisson. The signatures are valid if the sum of weight of all signed accouts is equal or greater than the threshold of the permission.
  • The transaction will not be saved into block chain until the signatures become valid.
  • (#1876 )The upper limit of energy can be adjusted automatically by the current state of the network

• (#1905) Develop a new mechanism to listen event message from a queue

Treasure Map

Asset: https://github.com/tronprotocol/java-tron

What it does: Java-tron is the main TRON protocol implementation and the only TRON network client capable of mining and verifying transactions through a 27-node dPoS (delegated proof-of-stake) mechanism. Vulnerabilities found from java-tron may impact the TRON blockchain network integrity, especially if valid against a Super Representative node - a node capable of producing blocks and collecting mining rewards.

What to look for: The best way to look for vulnerabilities is running a java-tron node locally and starting experimenting with the APIs it exposes. There are multiple guides on https://github.com/tronprotocol/java-tron and https://developers.tron.network/docs that can help with the initial setup and API usage. We value these types of issues (but not limited to) with high priority:

• 1) economically-feasible way to DDoS the TRON network
• 2) disrupt the integrity of blockchain by sending malicious data to the network
• 3) slow down network performance by sending crafted API requests to network nodes. Unless approved by a TRON team member, no proof-of-concepts should be carried out directly on the mainnet. Hacking machines that host TRON nodes is not a valid form of attack on the blockchain. Local PoC and mainnet attack estimation should be enough information for most reports.

What it runs on: Anywhere an Oracle JVM (1.8) can run. However, we recommend an environment with at least 16 CPU cores for best results of syncing and communicating with the network.

SLA

Tron Foundation will make a best effort to meet the following SLAs for hackers participating in our program:

• Time to first response (from report submit) - 2 business days
• Time to triage (from report submit) - 2 business days
• Time to bounty (from triage) - 14 business days

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

Rewards

Please review our bounty table. Rewards are at the discretion of Tron, and we will not be awarding significant bounties for low severity bugs.

Examples of eligible bugs:

Critical

• bugs which can take control of java-tron nodes by remote execution of any code.
• bugs which can lead to private key leakage.

High

• bugs which can incur Denial of Service (DoS) in java-tron through P2P network.
• bugs which can incur Denial of Service (DoS) in java-tron through RPC-API.

Medium

• bugs which can incur Denial of Service (DoS) in java-tron through TRON Protocol.
• bugs allowing unauthorized operations on user accounts.

Description of Scope

Please test the latest released versions of each project available. Hackers should only look for bugs under the latest release version commit.
java-tron: https://github.com/tronprotocol/java-tron/releases

Testing Guidance and Tips

You may use the source code of both projects to help you discover bugs.
Additionally, please use our documentation to assist you in your testing.
https://github.com/tronprotocol/Documentation

Submission Requirements

1. Summary of the bug
2. Steps to reproduce
3. Working proof of concept
4. Impact is based on, but not limited to the following:
   • How easy is it to find the vuln?
   • How likely is it that this vuln could be exploited? Would the economic incentive make sense?
   • How much impact does it make on a decentralized network? How big is the range of parties affected?
   • Is any private user data exposed?
   • Is any private financial data exposed?

Out of Scope

These following locations are considered out of scope for the bug bounty rewards. If you find issues with these projects, PLEASE file issues on the respective repositories if possible.

• java-tron master, release, or any other branches of the repository. Hackers should only look for bugs under the latest release version commit. Not any individual branch/commit.
• tronscan.org : https://github.com/tronscan/tronscan-frontend
• tron.network
• tronlab.com
• Any third party partners
• Clickjacking on pages with no sensitive actions.
• Unauthenticated/logout/login CSRF.
• Attacks requiring MITM or physical access to a user's machine/device.
• Attacks requiring root level access to the machine/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.
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

Program Rules & Guidelines

• For a report which contains several bugs, if they share an origin of the same underlying bug or are interrelated, we will regard and reward these bugs as one single bug discovery.
• If several members report on the same bug, the reward will be awarded to the earliest submission verified by TRON Foundation.
• If a bug was reported on other public channels of TRON Foundation earlier, e.g. Github, Discord and etc., the report containing the same bug will be only regarded as an Informative report or Duplicate report.
• All rights of interpretation of reward amount are reserved to TRON Foundation.
• 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.
• 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.

Disclosure Policy

• Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
• Follow HackerOne's disclosure guidelines.

Legal

All rights of interpretation of the Bug Bounty are reserved to TRON. TRON Foundations decides whether to reward a bug disclosure and how much will be rewarded. Any individual or team participant should not violate any laws and regulations during testing.

Safe Harbor

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 Tron Foundation and our users safe!