Skip to content

Latest commit

 

History

History
62 lines (54 loc) · 2.92 KB

tip-1102.md

File metadata and controls

62 lines (54 loc) · 2.92 KB
Raw
tip: 1102
title: Opt-in account exposure
author: Aaron <aaronluotron@gmail.com>
discussions to: https://github.com/tronprotocol/tips/issues/463
category: Interface
status: Final
created: 2022-09-05

Table of Contents

Simple Summary

This protocol is used to describe the communication between a DApp and a wallet. It allows the wallet to determine what information and when to provide it to the DApp.

Motivation

Currently, there is no such protocol on TRON. This leads to inconsistent implementation of DApps connected to TRON, which objectively increases the development workload of DApp developers. The goal of this proposal is to standardize the method for DApps to obtain user information from the wallet. Description of the proposal: Wallet will not disclose any account information until the user agrees, so as to ensure the security of the user's information. Ethereum's EIP-1102 is a similar protocol that can be followed.

Specification

eth_requestAccounts

Examples

try {
  await tron.request({method: 'eth_requestAccounts'});
} catch (e) {}

Returns

If successful, an array will be returned, the array has one element, which is the address of the current account, like： ['TQKLs3GzCNLjzyCvaPWSrqcpUGUhadxm7P'].

If it fails, an error code and an error message will be returned. See the Error Code section for details.

Error Code

Code Message Description
-32002 Other requests are being processed current DApp is processed, it cannot execute the current request
-32602 Invalid params invalid parameters, or added additional parameters
4001 User rejected request the user has rejected this request
4200 Unsupported method unsupported method

Constraints

  • The wallet must define an eth_requestAccounts method.
  • If Promise is resolved, the wallet must return an array containing at least one account.
  • If no account is available, the wallet must reject the Promise and return an error message
  • If the user rejects, the wallet must reject the Promise and return an error message.
  • If the user can no longer accept the Promise, for example, the user interface is closed and the user interface cannot be invoked again, the wallet must reject the Promise and return an error message.

Backwards Compatibility

This protocol has no impact on existing wallets and DApps, but it is recommended that all wallets and DApps implement this protocol. It is also recommended to implement this protocol for DApps that have already implemented other similar functional protocols.