Track and Introduce ERC-7710 Smart Contract Delegation to TRON

[yanghang8612]

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 (Track and Introduce ERC-7579 Minimal Modular Smart Accounts to TRON #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 (Track and Introduce ERC-4337 Account Abstraction Using Alt Mempool to TRON #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 (Track and Introduce ERC-7579 Minimal Modular Smart Accounts to TRON #880) and ERC-4337 (Track and Introduce ERC-4337 Account Abstraction Using Alt Mempool to TRON #881) tracking issues
• Native account model: TIP-16, TIP-105; TIP-1271, TIP-712
• TRON native resource delegation (terminology contrast): #671, TIP-476 (#476)

[TonyStank911]

The terminology collision is a real concern — TRON developers already say "delegation" for Stake 2.0 resource delegation. Has the team picked a disambiguating name? "Permission delegation" was suggested in the body but feels slightly clinical. Would "capability delegation" or simply "TIP-7710 / permission grants" work better for end-user wallet UIs?

[yanghang8612]

@TonyStank911 Direction:

• Standard normative name: "permission delegation." Explicit, technically accurate, and the term ERC-7710 itself uses (manager validates "the supplied authority"). "Capability delegation" carries an academic OS-research connotation TRON wallet devs haven't been primed on; "delegation grant" reads better in copy than "capability grant" anyway.
• Mandatory disambiguation section at the top of the TIP — one paragraph explicitly contrasting TIP-7710 permission delegation (application-layer authority over a smart account) with native resource (energy/bandwidth) delegation under Stake 2.0 / TIP-476 / Introduce delegating resource usage right #671. Without this note implementers will conflate them within a month.
• Wallet UI guidance (non-normative): suggest wallets surface this as "App permissions" or "Session permissions" rather than "Delegations". Stake 2.0 keeps the "Delegate" verb users already know; TIP-7710 takes a distinct surface.
• For SDK / dev-facing material, "permission delegation" is canonical; unqualified "delegation" should be discouraged in TIP-7710 contexts.

[ouy95917]

The body asks whether TRON-7710 should hard-require ERC-7579 (#880) or define only the minimal execution interface it needs. From a shipping standpoint, hard-requiring 7579 means 7710 can't land until 7579 does — long sequence given 7579 hasn't started discussion yet. Team preference?

[yanghang8612]

@ouy95917 Preference:

• Soft requirement, not hard. TIP-7710 references TIP-7579 (Track and Introduce ERC-7579 Minimal Modular Smart Accounts to TRON #880) as the canonical execution-mode source, but normatively requires only the minimal subset of execution-mode semantics that redeemDelegations actually consumes — the two-byte mode prefix, single/batch encoding, and the calldata layout for executor invocation. That's a 30-line normative section, not the full 7579 surface.
• This buys decoupled shipping: TIP-7710 can land before TIP-7579 reaches Final, against the same execution-mode encoding both commit to. When 7579 lands, 7710's reference becomes the full normative pointer rather than the minimal extract.
• Risk in hard-coupling: scope cascade. Every 7710 question becomes blocked on a 7579 question; the AA / delegation / modular-account stack ends up in a single mega-TIP. Splitting them with a shared execution-mode commitment gives interop without the dependency.
• Caveat / enforcer pattern stays explicitly out of scope for V1 — the source ERC excludes it, and adopting MetaMask's specific enforcer model would prematurely lock TRON wallets to one delegation-framework vendor. Revisit in a companion TIP after the ecosystem converges.

[EllenWhitmore]

The lack of any delegation standard is already causing real damage. Unlimited approvals are still the default across the ecosystem, and the same class of incident keeps repeating — users get drained because of permissions they forgot about long ago. Wallets are doing what they can on the management side, but as long as the protocol doesn't offer scoped, time-bound, revocable permissions, we're mostly just cleaning up afterwards.

It's also the missing piece for a lot of the patterns people keep asking about — session-style interactions, recurring actions, agent-driven automation. Without a shared schema for "what exactly is being delegated," our confirmation screens can't really say anything meaningful, and every project ends up reinventing its own version.

A standard redeemDelegations interface with caveats would finally let wallets build a proper permission center and show users what they've actually granted, to whom, until when. Hope this can move forward as quickly as possible.

[BlackChar92]

Support the soft-requirement approach for TIP-7579. TIP-7710 should probably standardize only the minimal execution-mode subset it needs, otherwise permission delegation gets blocked on the entire modular-account track.

One suggestion for V1: even if caveats/enforcers stay implementation-defined, the TIP could include a non-normative wallet display checklist — delegate, manager/verifyingContract, target smart account, expiry/revocation status, allowed targets/selectors if available, spending limits if available, and batch-execution capability.

That would avoid standardizing a caveat framework too early while still helping wallets present “App permissions” or “Session permissions” safely.

[valiskybe]

Support the soft-dependency approach. TIP-7710 should not be fully blocked on TIP-7579.

For V1, I think “discoverable, revocable, and trackable” should be a core goal, not just execution. If a user grants permission to an app, the wallet must be able to find that permission later, show whether it is still valid, and provide a revocation path.

Otherwise, this risks becoming another form of long-lived opaque permission, just more complex than unlimited approvals. Even if V1 does not standardize a full caveat/enforcer framework, it should at least fix the base fields needed for wallet tracking: delegator, target account, delegate, verifying contract, chain, expiry, unique identifier or nonce, and revocation status.

[yanghang8612]

@EllenWhitmore The drain-from-forgotten-approval pattern is exactly what this has to beat, not reproduce — a delegation with no revocation story is just unlimited approval with extra steps. V1 will require a revocation path plus an on-chain-observable revocation status, so a wallet's permission center can always answer "is this still live, to whom, until when?" And agreed the missing shared schema for "what exactly is being delegated" is why every confirmation screen is currently bespoke — fixing that schema is the part worth standardizing.

[yanghang8612]

@BlackChar92 The soft-requirement approach is what I'm planning — 7710 standardizes only the minimal execution-mode subset it needs so it isn't blocked on the full 7579 track. Your display checklist (delegate, manager/verifyingContract, target account, expiry/revocation status, allowed targets/selectors, spending limits, batch capability) maps cleanly onto V1: the core tracking fields become normative, and the richer items (selectors, spending limits) sit as an advisory display tier since they depend on caveat data that stays implementation-defined. That keeps us from standardizing a caveat framework prematurely while still giving wallets a safe "App permissions" view.

[yanghang8612]

@valiskybe Agreed this should be a core V1 goal, not just execution — elevating it from implied to explicit. Even with the caveat/enforcer framework out of V1, the base tracking field set you list will be normative: delegator, target account, delegate, verifyingContract, chainId, expiry, a unique id/nonce, and revocation status. That's the minimum a wallet needs to find a granted permission later, show whether it's still valid, and offer a revocation path — without it, this does risk becoming another long-lived opaque permission, which is the exact failure mode it's meant to fix.

[yanghang8612]

Progress update: TIP-7710 was discussed at Core Devs Community Call 63.

The meeting summarized 7710 as letting an account delegate part of its control to another contract, and explicitly tied it to EIP-7702 at the protocol level — which is still in progress on TRON (#728) and not yet a formal TRON standard. ERC-7710 itself is also still Draft upstream. So the agreed posture is to keep monitoring and let the broader discussion — especially the 7702 dependency and the 7579 (#880) execution layer — mature before moving 7710 toward formal standardization.

That's consistent with the soft-dependency approach in this thread: 7710 commits only to the minimal execution-mode subset it needs, and the "discoverable / revocable / trackable" tracking-field set stays the V1 priority. Next step: monitor 7702 (#728) and 7579 (#880); continue refining the tracking / revocation schema here.

[CharlesShafer]

Agree with the cautious posture decided at Core Devs Call 63. Since ERC-7710's true power at the wallet level relies heavily on protocol-level account transitions like EIP-7702 (#728) and modular accounts like TIP-7579 (#880), letting these mature first is the logical path forward.

In the meantime, keeping the soft-dependency approach and focusing V1 on defining the "discoverable, revocable, and trackable" base schema (delegator, delegate, verifyingContract, expiry, nonce, revocation status) is excellent. It allows wallet developers to start aligning their internal schemas for session/permission tracking early, even before the full execution layer is activated.

[yanghang8612]

Thanks @CharlesShafer — agreed. Letting EIP-7702 (#728) and TIP-7579 (#880) mature first while V1 fixes the "discoverable, revocable, trackable" base schema (delegator, delegate, verifyingContract, expiry, nonce, revocation status) is the path, and it lets wallet teams start aligning their session/permission-tracking schemas now against a stable minimal surface.