Track and Introduce ERC-7710 Smart Contract Delegation to TRON

Background

ERC-7710 standardizes how a smart account (the delegator) grants another address (the delegate) the right to act on its behalf, mediated by a Delegation Manager contract. A delegate redeems authority by calling:

function redeemDelegations(
  bytes[]   calldata _permissionContexts,
  bytes32[] calldata _modes,
  bytes[]   calldata _executionCallData
) external;

The manager validates the supplied authority, then executes the requested actions against the delegator using ERC-7579 execution modes. The standard intentionally does not fix the delegation data structure or the "caveat" (restriction) mechanism — those are left to implementations (e.g., MetaMask's Delegation Framework, which signs delegations with EIP-712 and enforces caveats via enforcer contracts). It uses ERC-1271 as the contract-signature-validation hook, is compatible with but does not require ERC-4337, and lists ERC-7715 as one way to obtain delegations.

The value is "long-lived sessions and delegated permissions through a single signature": session keys, subscriptions, scoped spending allowances, and automated agents — without re-signing each action. On TRON this enables scoped, revocable permissions for DApps and agents on top of smart accounts. We propose to track ERC-7710 and introduce it to TRON as a TIP (proposed TIP-7710); because redemption executes through the modular-account execution interface, it should follow the ERC-7579 track.

Scope

• Follow the ERC-7710 redeemDelegations interface and the delegate → manager → delegator redemption flow.
• Reuse ERC-7579 execution modes and ERC-1271 / TIP-1271 (as the contract-signature-validation hook) rather than re-defining them. Note that only the redeemDelegations ABI and execution modes are portable; the delegation data structure, _permissionContexts, caveats, and signature format are framework-specific and out of the source ERC's scope.
• Keep TRON-specific material as non-normative notes; decide explicitly whether TRON standardizes anything beyond the source ERC.

Compatibility Topics for Discussion

• "Delegation" terminology collision. On TRON, "delegation" already means native resource (energy/bandwidth) delegation via Stake 2.0 (DelegateResourceContract; see #671, TIP-476 (#476)). ERC-7710 delegation is capability/permission delegation — the TIP must disambiguate naming (e.g., "permission/capability delegation") and add an explicit contrast note to avoid ecosystem confusion.
• Target accounts vs. native permissions. ERC-7710 redeems against a smart-contract delegator that supports ERC-7579-style execution, via the Delegation Manager. TRON's native permission system (TIP-16/TIP-105) instead authorizes transaction operations/keys directly, without a manager intermediary — so it is an adjacent but distinct mechanism, not a redemption target, unless the TIP deliberately proposes a bridge. Open: where do native permissions end and contract-level delegation begin (when to use which)?
• Dependency on ERC-7579 and ERC-1271. Whether TRON-7710 hard-requires the ERC-7579 track (#880) or defines only the minimal execution interface it needs so it can ship without full 7579 adoption; and noting that TIP-1271 covers only the contract-signature-validation hook — EOA signatures, typed-data hashing, and permission-context verification remain framework-specific.
• Relationship to ERC-4337. 7710 is compatible with but does not require 4337; whether the 7710 track should be sequenced after the ERC-4337 track (#881) or proceed independently on plain TVM smart accounts.
• Caveats: out of scope, or a separate companion? ERC-7710 deliberately leaves caveats (spend limits, target/selector allowlists, expiry) out of scope. A standardized caveat/enforcer library would itself be normative, so the choice is: keep TIP-7710 minimal and implementation-defined (mirroring the source ERC), or define a caveat library as a separate optional companion TIP — and if so, which caveats are the priority set (spend limits over TRX/TRC-20/TRC-10, time windows, target allowlists).
• Delegation Manager deployment and signing. Whether there is a canonical Delegation Manager deployment for TRON and who governs it; and full domain binding for delegation signatures — not just TIP-712 chainId (block.chainid & 0xffffffff) but also verifyingContract/Manager domain binding and TRON address normalization — plus how revocation/expiry are represented and checked.
• ERC-7715 companion (requesting permissions). Whether TRON tracks ERC-7715 (the wallet-facing method to request permissions/delegations), and whether a TRON-7715 would be a straight port, an adaptation for non-4337 TVM smart accounts, or deferred — plus the wallet UX needed for users to safely review and grant caveat-bounded delegations.

References

• ERC-7710: https://eips.ethereum.org/EIPS/eip-7710 · ERC-7715: https://eips.ethereum.org/EIPS/eip-7715
• Related TRON tracks: ERC-7579 (#880) and ERC-4337 (#881) tracking issues
• Native account model: TIP-16, TIP-105; TIP-1271, TIP-712
• TRON native resource delegation (terminology contrast): #671, TIP-476 (#476)

Start by reading ERC-7710 together with the related ERC-7579 issue #880, ERC-4337 issue #881, and TIP-1271, TIP-712, TIP-16, and TIP-105. Review the open compatibility questions around execution, permissions, terminology, caveats, signing, and deployment. Done means the TRON-specific scope and dependencies are resolved well enough to draft a TIP-7710 proposal.