Track and Introduce ERC-7715 Execution Permissions to TRON

[iweb3Nomad]

Background

ERC-7715 standardizes wallet-facing JSON-RPC methods for requesting, listing, and revoking execution permissions. A DApp asks a wallet to grant a scoped permission to a DApp-controlled session account (to), so that the session account can later act on behalf of the granting account (from) within user-approved limits. The core methods are wallet_requestExecutionPermissions, wallet_revokeExecutionPermission, wallet_getSupportedExecutionPermissions, and wallet_getGrantedExecutionPermissions.

The request model is intentionally narrow at the wallet boundary and extensible at the permission layer: PermissionRequest carries chainId, optional from, to, permission, and rules; if from is omitted, the wallet may let the user choose which account grants the permission. permission and rules use base shapes such as BasePermission and BaseRule, with expiry as a defined rule, while concrete permission/rule registries are left to additional standards. isAdjustmentAllowed tells the wallet whether it may reduce or increase the requested permission before approval to match the conditions accepted by the user.

ERC-7715 is wallet-side but its execution path is tied to ERC-7710 and ERC-4337 concepts. A successful response includes context, an opaque identifier used for permission revocation or redemption, which ERC-7710 consumes as the permission context for redeemDelegation(...) calls; dependencies, an array of ERC-4337 factory/factoryData pairs for accounts that must be deployed before redemption; and delegationManager, the ERC-7710 contract address that receives redeemDelegation(...) calls. Revocation uses wallet_revokeExecutionPermission with a permissionContext parameter corresponding to the returned context.

The value is "scoped future execution through one wallet approval": recurring payments, subscriptions, games, automated swaps, limit orders, session keys, and agent workflows without asking the user to sign every individual transaction. On TRON this could enable bounded, revocable permissions for DApps and agents, but the Ethereum-specific redemption and deployment fields cannot be assumed to work unchanged. We propose to track ERC-7715 and introduce it to TRON as a TIP, tentatively referred to as TIP-7715, with the wallet RPC flow preserved where possible and TRON-specific execution semantics made explicit. Landing the wallet permission request layer first gives the ERC-7710 delegation track a shared negotiation interface.

Scope

• Follow the ERC-7715 wallet JSON-RPC methods as closely as possible: wallet_getSupportedExecutionPermissions, wallet_requestExecutionPermissions, wallet_getGrantedExecutionPermissions, and wallet_revokeExecutionPermission.
• Preserve the request/response shape where portable: chainId, optional from, to, permission, rules, context, and the extensible BasePermission / BaseRule model.
• Treat ERC-4337 dependencies (factory/factoryData) and ERC-7710 delegationManager as execution-layer fields that require explicit TRON support, replacement, or rejection.
• Define TRON-specific material only where necessary: address normalization, chain/network binding, TRX/TRC-10/TRC-20 asset representation, wallet-local vs. on-chain enforcement, and revocation semantics.
• Keep v1 focused on the wallet permission request layer; more complex execution-layer work such as smart-account deployment dependencies, canonical on-chain redemption, and batch execution can be deferred unless the TIP explicitly standardizes them.
• Avoid introducing unrelated signing, display, or transaction standards into this proposal.

Compatibility Topics for Discussion

• Wallet RPC compatibility. Whether TRON wallets expose the same ERC-7715 method names and request/response objects through the TRON DApp provider, or use a TRON-specific namespace. The closer the method names and shapes remain to ERC-7715, the easier it is for wallets, SDKs, and DApps to share tooling.

• Permission request fields. from is optional in ERC-7715 and allows wallet-side account selection; to identifies the DApp session account or delegated executor; isAdjustmentAllowed allows the wallet to reduce or increase the requested permission before approval; and context is returned for later revocation or execution. The TIP should preserve these meanings if the fields are retained, and state clearly when a field is TRON-specific or unsupported.

• Permission and rule registry. ERC-7715 deliberately leaves concrete permission and rule types to additional standards: all types inherit from BasePermission or BaseRule, and type-name collisions are a compatibility risk. TRON has native TRX, TRC-10 assets, TRC-20 contracts, TVM contract calls, and resource costs that do not map one-to-one to Ethereum examples. Open: whether TRON defines canonical types such as native-trx-allowance, trc10-token-allowance, trc20-token-allowance, and contract-call-permission, and which rules are required or recommended first (expiry, spend limits, rate limits, recipient/contract/method allowlists, energy/bandwidth limits).

• Dependencies and account deployment. In ERC-7715, dependencies is an array of ERC-4337 factory/factoryData pairs for accounts that must be deployed before a permission can be redeemed. TRON does not currently share that account-deployment model. Open: should TRON v1 require dependencies to be empty and reject requests that need factory/factoryData, or define a TRON-native deployment dependency mechanism in a later companion TIP.

• Delegation Manager and redemption. In ERC-7715, delegationManager is the ERC-7710 contract that receives redeemDelegation(...) with the permission context, execution mode, and encoded execution calldata. If TRON does not implement ERC-7710-compatible redemption, this field has no direct execution meaning. Open: whether TIP-7715 only standardizes the wallet permission request layer, replaces delegationManager with a TRON-native permissionManager, or sequences behind a TRON ERC-7710 track.

• Wallet-local permissions vs. on-chain enforcement. ERC-7715 is the request layer; enforcement depends on the wallet and execution framework. TRON should decide whether a minimal v1 permits wallet-local enforcement, requires an on-chain permission manager, maps to smart-account implementations, or integrates with TRON's native account permission system. TRON native permissions include owner, active, and witness permissions, weighted keys, thresholds, and operation allowlists; they authorize transaction operations/keys directly, while ERC-7715-style permissions are DApp-requested scoped capabilities.

• Address representation. ERC-7715 examples assume Ethereum Address values, i.e. 20-byte hex addresses normally rendered in EIP-55 checksum form. TRON addresses may be Base58Check, 21-byte hex addresses with leading byte 0x41, or ABI-level 20-byte values after removing the TRON leading byte, so direct reuse of Ethereum address assumptions can cause mismatches in from, to, token addresses, contract allowlists, and permission manager addresses. Open: the canonical authored form for TRON permission requests/responses, whether wallets accept multiple encodings for matching, and whether user-facing displays prefer Base58Check.

• Multi-signature approval flow. ERC-7715 models permission approval as a wallet decision and does not define multi-signer approval flows. TRON accounts can require weighted multi-signature approval for account operations, so a wallet_requestExecutionPermissions request for a from account may require more than one signer before the permission is considered granted. Open: whether wallets abstract this into a single approval result, expose partial approval state to DApps, or require the permission request to fail until the account's threshold is satisfied.

• Chain ID and network binding. ERC-7715 uses EIP-155-style chainId to bind a permission request to a chain, and the returned context is later used for revocation or redemption. TRON has Mainnet, Nile, Shasta, and private networks, plus TRON-specific chain ID conventions in related signing flows. Open: whether permission requests use an existing TRON chain ID convention, CAIP-2 style identifiers, or another TRON network identifier, and whether context should bind both account and network to prevent cross-network permission reuse.

• TRX, TRC-10, and TRC-20 assets. ERC-7715 only defines the envelope for permission data; concrete token permissions are expected to be defined separately, with Ethereum examples naturally centered on native-token and ERC-20-style allowances. TRON needs equivalent representation for native TRX, TRC-10 token IDs, TRC-20 contracts, and TVM value fields. TRON uses sun as the base unit (1 TRX = 10^6 sun). Open: whether TRC-20 follows ERC-20-style allowance patterns, how token metadata is resolved and trusted, how TRC-10 token IDs are represented, and how call_value, call_token_value, and token_id are handled for contract-call permissions.

• Contract-call permissions and TVM resources. ERC-7715 can carry contract-call permissions as a permission type, but the source ERC does not standardize the full shape of target, selector, parameter, or value constraints. TRON smart contract calls are ABI-compatible at the calldata level, while the outer transaction container and resource model are TRON-specific. Open: whether contract-call-permission supports target contract allowlists, selectors, parameter constraints, TRX/TRC-10 value limits, and energy/bandwidth bounds; and whether batch execution is in v1 scope.

• Revocation semantics. ERC-7715 revokes by passing permissionContext, corresponding to the granted permission's context, to wallet_revokeExecutionPermission. TRON must decide whether revocation is wallet-local, on-chain, or both; whether revocation requires a TRON transaction; and how DApps discover revoked, expired, partially used, or active permissions.

• User consent and safety. In its Security Considerations, ERC-7715 states that wallets must clearly display requested permissions and warn users against granting dangerous permissions. TRON wallets need equivalent review surfaces for future execution authority, including the granting account, session account, network, asset, amount, target contract, allowed method, limits, and expiry. Open: when wallets should reject unknown or overly broad permission types, how strongly they warn on unlimited or long-lived permissions, and what security requirements apply to session keys, delegated executors, permission managers, and stored permission state.

• Naming and documentation. What the formal TRON TIP title should be, and how it should reference ERC-7715 as the upstream standard. Ethereum-specific terms such as delegationManager may need TRON alternatives such as permissionManager, with a clear note separating source ERC semantics from TRON adaptation guidance.

Suggested Minimal v1 Scope

• Permission capability discovery.
• Permission request.
• Granted permission query.
• Permission revocation by permissionContext.
• BasePermission, BaseRule, and expiry compatibility.
• TRX and TRC-20 permission examples.
• Contract-call permission with target and method allowlists.
• TRON address and chain/network identifier guidance.
• Wallet-local enforcement, unless a TRON-native permission manager is standardized in the same proposal.

References

• ERC-7715: https://eips.ethereum.org/EIPS/eip-7715
• ERC-7715 discussion: https://ethereum-magicians.org/t/erc-7715-grant-permissions-from-wallets/20100
• ERC-7710: https://eips.ethereum.org/EIPS/eip-7710
• ERC-4337: https://eips.ethereum.org/EIPS/eip-4337

[myzykj]

Thanks for opening this discussion. After reading through ERC-7715, my understanding is that one key question for TRON is whether the first version should only cover the wallet permission negotiation layer, or also define the execution/redeem layer.

From my current understanding, a conservative v1 could be:

1. Keep the ERC-7715 wallet RPC method names and the portable request/response fields where possible, to maximize tooling compatibility.
2. Add TRON-specific rules for address formats, chain/network identifiers, TRX/TRC-10/TRC-20 assets, and contract-call permissions.
3. Require dependencies to be empty for now, since TRON does not have the same ERC-4337 factory deployment model.
4. Consider leaving delegationManager unsupported in v1, or defining a TRON-native permissionManager in a separate execution-layer proposal.

Some questions that may be useful for the discussion:

• Should TRON wallets keep the ERC-7715 RPC method names, or use a TRON-specific namespace?
• Should v1 allow wallet-local enforcement, or require an on-chain permission manager from the beginning? (This affects whether permissions survive wallet changes or require on-chain state.)
• Which permission types should be prioritized first: native-trx-allowance, trc20-token-allowance, trc10-token-allowance, or contract-call-permission?

Would be interested to hear thoughts from wallet, SDK, and smart-account implementers.