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

[yanghang8612]

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)