-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TIP-1193: TRON Provider JavaScript API #466
Comments
This is very helpful, I see that |
@nobodywhen
|
Seems like a good idea, will need to read more into the docs, as long as it does not immediately break existing tronlink integration it should be fine. Everyone is using tronweb and it looks like this will still expose it. |
@dmf3030 |
This is a great improvement !!! |
Looks great, TokenPocket will support this API when the proposal is fully discussed |
thank you !! |
Gg |
Table of Contents
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 that the key management software ("wallets") exposes 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 call method. The Provider can be easily extended by defining new methods and event types.
This protocol recommends using
window.tron
as the Provider.
Historically, some TRON wallets provide tronWeb object, and this protocol recommends that the Provider will still provide tronWeb object to avoid additional compatible development of TRON DApps for the Provider of this protocol.
Specification
API
The Provider must implement and expose the API and property defined in this section. All API and property entities must adhere to the types and interfaces defined in this section.
API: request
Example
Parameters
RequestArguments.method
.RequestArguments.params
.
Returns
tron.request
must be handled such that the returned Promise either resolves with a value per the requested method’s specification, or rejects with an error.4900
.tron.request
request is directed at a specific chain, and the Provider is not connected to that chain, but is connected to at least one other chain. If rejecting for this reason, the Promise rejection error code must be4901
.method
intron.request
request. If rejecting for this reason, the Promise rejection error code must be4200
.Error Code
The structure that returns the error is as follows:
message
message
of the Provider Error section, or themessage
in the method's specificationcode
code
of the Provider Error section, or thecode
in the method's specificationdata
Provider Error
Property
Property: tronWeb
wallet needs to import tronWeb library, instantiate tronWeb, The Provider provides instantiated tronWeb for DApps.
Example
Constraints
tron.tronWeb
needs to meet the following requirements:tron.tronWeb
Property: is[WalletName]
This is a non-normative property, but wallet implementation is recommended.
In actual development, the DApp may need to determine what wallet is currently providing the Provider, so as to facilitate the compatible development of different wallets by the DApp.
For example:
isTronLink
,isTokenPocket
,isTrustWallet
, etc.This protocol does not limit the specific property name, nor does it require the implementation of this property.
Example
Events
The Provider must implement the following event handling methods:
on
removeListener
These methods must be implemented according toNode.js EventEmitter API.
Event: connect
If the Provider becomes connected, the Provider must emit the event named
connect
.This includes when:
disconnect
event was emitted.This event must be emitted with an object of the following form:
eth_chainId
.Example
Event: disconnect
If the Provider becomes disconnected from all chains, the Provider must emit the event named disconnect with value error:
ProviderRpcError
object according to the Provider Error specification.Example
Event: chainChanged
If the chain to which the Provider is connected changes, the Provider must emit a
chainChanged
event and emit an object of typeProviderConnectInfo
that explicitly informs the new chainId value.Example
Event: accountsChanged
If the Provider's current account changes, the Provider must emit the
accountsChanged
event and the currently available account address in the form ofaccounts: string[]
.Example
Security Considerations
The Provider is intended to pass messages between a TRON wallet and a TRON DApps. 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 the 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:
Backwards compatibility
Before this protocol was finalized, some wallets implemented non-normative versions. In order to be compatible with the historical DApps, the wallets can be compatible with non-normative versions on the premise of implementing this protocol.
The text was updated successfully, but these errors were encountered: