HackMD - Collaborative Markdown Knowledge Base

``` tip: 1193 title: TRON Provider JavaScript API author: Aaron.Luo discussions to: category: status: Draft created: 2022-09-26 ``` ## Table of Contents - [Table of Contents](#table-of-contents) - [Summary](#summary) - [Abstract](#abstract) - [Security Considerations](#security-considerations) - [Handling Adversarial Behavior](#handling-adversarial-behavior) - [Backwards compatibility](#backwards-compatibility) ## Summary This protocol specifies a JavaScript TRON provider，it is used to ensure the consistency of interaction between TRON wallets and TRON DApps. ## Abstract A common convention in the TRON web application (“dapp”) ecosystem is for key management software ("wallets") to expose their API via a JavaScript object on the web page. This object is called “the Provider”. This protocol normalizes the TRON provider's API and is designed to be event-driven, independent of the method being called. The Providers can be easily extended by defining new methods and event types. This protocol recommends using `window.tron` as the Provider object. Historically, some TRON wallet Providers provide tronWeb object, and this protocol recommends that the Providers still provide tronWeb object to avoid DApps needing to do additional compatible development for the Providers of this protocol. ## Security Considerations The Provider is intended to pass messages between a TRON wallet and a TRON DApp application. It is not responsible for private key or account management; it merely processes messages and emits events. Consequently, account security and user privacy need to be implemented in middleware between the Provider and its TRON wallet. The Provider can be thought of as an extension of the wallet, exposed in an untrusted environment, under the control of some third party. #### Handling Adversarial Behavior Since Provider is a JavaScript object, consumers can generally perform arbitrary operations on the Provider, and all its properties can be read or overwritten. Therefore, it is best to treat the Provider object as though it is controlled by an adversary. It is paramount that the Provider implementer protects the user, wallet by ensuring that: - The Provider does not contain any private user data. - The Provider and wallet programs are isolated from each other. - Set a limit for the Provider's requests rate to the wallet. - The wallet validate all data sent from the Provider. ## Backwards compatibility Before this protocol was finalized, some wallets implemented non-canonical versions. In order to be compatible with the historical DApps, wallets can be compatible with non-standard versions on the premise of implementing this protocol.