Track and Introduce ERC-7579 Minimal Modular Smart Accounts to TRON

Background

ERC-7579 defines minimal, standardized interfaces for modular smart contract accounts: how an account exposes execution, and how interoperable modules — validators, executors, hooks, and fallback handlers — are installed, removed, and invoked. Modules expose onInstall/onUninstall, accounts expose installation queries such as isModuleInstalled, and execution uses encoded execution modes (single vs. batch, a non-reverting try variant, and an optional delegatecall variant) with supported modes advertised via capability detection (supportsExecutionMode). The goal is interoperability — a validator or executor written once works across any compliant account instead of being locked to one wallet vendor.

ERC-7579 is account-side and standalone: it does not depend on, nor is required by, ERC-4337 — it provides a common module/execution interface that 4337-style smart accounts can adopt and that ERC-7710 delegation executes through. Smart-account interfaces on TRON are currently ad hoc, so we propose to track ERC-7579 and introduce it to TRON as a TIP (proposed TIP-7579); landing it first gives the account-abstraction and delegation tracks a shared foundation and lets TRON wallets/SDKs target one module interface.

Scope

• Follow ERC-7579 interfaces as closely as possible (account execution, module install/uninstall lifecycle, module-type taxonomy, capability queries).
• Preserve the execution-mode encoding so cross-chain module code and SDKs port to TVM with minimal address/RPC adapters.
• Provide TRON-specific material only as non-normative notes where TVM or TRON's native account model requires clarification.

Compatibility Topics for Discussion

• Relationship to ERC-4337, EIP-7702, and TRON native accounts. 7579 is agnostic to how an account is "activated" (a 4337 smart account, a 7702-upgraded EOA, or other), while TRON has a native account permission system — weighted multi-sig and per-operation permissions (TIP-16, TIP-105). Open: should a TRON 7579 account be a plain TVM contract, or should the standard describe how a native-permission account also exposes the 7579 module interface (hybrid model); should TRON support one activation path or several behind one interface; does adopting 7579 require any change to native permissions. See TIP-7702 (tracking issue #728).
• CALL / batch value semantics on TVM. Whether single and batch executions that move value behave identically on TVM, including TRX call_value and TRC-10 call_token_value/token_id — noting that TRC-20 transfers are ordinary calldata, not the execution value field, so only TRX/TRC-10 need value/token-id treatment in execution modes.
• DELEGATECALL semantics on TVM. The optional delegatecall execution mode runs module code in the account's own context and transfers no value; whether TVM DELEGATECALL storage/context semantics match EVM closely enough for module reuse.
• Subcall energy accounting. When an account fans out to multiple module calls in one transaction, how energy is metered under the EVM-compatible TVM subcall rules (e.g., the 63/64 forwarding behavior introduced in TIP-272).
• Validator modules vs. TIP-1271 / TIP-712. Whether validator modules implement TIP-1271 contract-signature validation and use TIP-712 digests for typed data — two distinct layers (1271 = validation interface, 712 = hashing/encoding) — and how TIP-712's TRON-specific encoding (0x41-prefix stripping, trcToken, chainId & 0xffffffff) is reflected in validator examples. A P-256/WebAuthn-capable validator is a natural example, noting TIP-7951 (#785) provides only the secp256r1 verification primitive (full passkey support also needs WebAuthn challenge/clientData/authenticatorData handling).
• Module-type and capability detection vs. TIP-165. How module-type identifiers and supportsExecutionMode/capability detection map onto TIP-165 interface detection.
• Module-install authorization. ERC-7579 leaves "who may install/uninstall modules" to the account; on TRON, whether native permissions (TIP-16 / TIP-105) can gate module installation, since an unchecked install is a critical attack surface.
• Fallback handlers vs. TVM fallback/receive. How 7579 fallback-handler routing interacts with TVM fallback/receive behavior on EVM-compatible contracts.

References

• ERC-7579: https://eips.ethereum.org/EIPS/eip-7579
• Related TRON tracks: ERC-4337 and ERC-7710 tracking issues; TIP-7702 (tracking issue #728)
• Native account model: TIP-16 (Account Multi-signature), TIP-105 (Multi-signature Permission Operation)
• TIP-1271, TIP-712, TIP-165, TIP-272, TIP-7951 (#785)

Start with ERC-7579 and compare its execution modes, module lifecycle, and capability detection with the linked TRON TIPs. Review the open compatibility questions around TVM value semantics, delegatecall, permissions, and native accounts. Done means the compatibility decisions are resolved and a TIP-7579 proposal can define the TRON-specific, non-normative guidance.