[Discussion] Native Singleton Predeployments for TRON

Summary

Developers and protocols across blockchain ecosystems rely on permissionless singleton contracts to collectively increase security, build trust across the ecosystem, and improve the interoperability of tooling and development frameworks. This is the case in the Ethereum ecosystem, where general-purpose contracts are deployed, improved, and reused by the community and by protocols alike, for example, the deterministic deployment proxy contract allow developers and smart wallets to deploy contracts seamlessly using only bytecode and a salt.

On EVM chains, deploying a singleton contract usually relies on one of the following methods:

• Keyless deployment (Nick's method): deployment is executed in a trustless manner from a single-use account that nobody controls. This mechanism depends on two properties TRON does not share with Ethereum: the pre-signed transaction is RLP-encoded (TRON transactions are protobuf-encoded, so the identical byte string cannot be constructed or broadcast), and the resulting contract address is derived from sender + nonce (TRON derives it differently, see Analysis below). Either difference alone would break the mechanism; together, they make it unusable on TRON as-is.
• Permissioned deployment (e.g. CreateX): support for a new chain is added by the maintainer manually deploying the contract there on request. This is technically feasible on TRON, but produces a different contract address than the existing EVM deployments, defeating the purpose of a shared multi-chain address. (CreateX itself is fully permissionless to use once deployed, what's permissioned is only the process of bringing it to a new chain.)

The goal of this discussion is to gather community feedback on wether we should pursue the predeployment of such contracts to improve TRON multi-chain interoperability as well as trade-offs of doing/not doing it.

Motivation

TRON developers and frameworks have no default, trusted alternative to the well-known singletons available in the Ethereum ecosystem. This leaves them with two options: trust a third-party deployment (commonly unaudited), or audit and deploy the singleton themselves. That cost multiplies across every independent team that needs the same contract, and the problem compounds quickly. This is a real, documented pain point in the TRON ecosystem, comments like this recur across independent development teams.

Beyond the redundant audit cost, independently deployed singletons break interoperability for development frameworks like TronBox and Hardhat, increasing development effort and the risk of introducing bugs that a single shared, audited implementation would avoid.

Analysis

Both mechanisms fail, but for different reasons.

Permissioned deployment fails at the address level. Per TRON's own core repository (discussed in #835), CREATE derives addresses differently on each chain:

Ethereum's formula depends on the deployer's address and a persistent nonce; TRON's depends on the transaction's own hash and an internal per-transaction counter. A factory can be deployed on TRON, but it will never land at the same address as its Ethereum counterpart.

Keyless deployment fails earlier, before address derivation is even relevant: Nick's method relies on broadcasting one identical, RLP-encoded raw transaction across every target chain. TRON transactions are protobuf-encoded, so that transaction can't be constructed or broadcast on TRON at all.

Discussion Goal

This issue is not a proposal to implement native singleton predeployments, it's meant to gather community feedback on whether doing so is worth pursuing at all, given the constraints outlined above. Specifically:

• Is a native predeploy path an acceptable mechanism for establishing canonical singletons on TRON? (considering the "blessing" aspect of it)
• Which singletons, if any, would justify this?
• Are there governance or security concerns specific to TRON that make protocol-level predeployment less desirable than the status quo (third-party deployments, per-team redeployment)?

Proposed Singletons

The below list showcase some popular and valuable singletons from the Ethereum ecosystem that might be worth exploring for a potential predeployment:

• Deterministic Deployment Proxy Factory
• CreateX
• Permit2
• Multicall3
• ERC-1820 Universal Registry , a generic on-chain interface registry, not scoped to any single standard. One of the earliest examples of this deployment pattern on Ethereum.
• ERC-6492 Universal Signature Validator , general-purpose signature verification that works uniformly whether or not the signing wallet is deployed yet, independent of account implementation.
• Stealth Address Announcer
• Stealth Address Registry

Note: This is by no means a final list, if the community reaches consensus on proceeding with singleton predeployments a final one must be drafted

Start with the Analysis section and the linked TRON core discussion in #835, then review the cited deployment mechanisms and proposed singleton list. Gather community feedback on whether protocol-level predeployment is acceptable, which contracts merit inclusion, and the governance or security trade-offs. Done means an agreed direction and a drafted final singleton list if the community supports proceeding.