Ecosystem Stack for Tron by OpenZeppelin

TBL
1

Ecosystem Stack for Tron by OpenZeppelin – Building Secure Foundations for Developers

Basic Information

Project Name: Ecosystem Stack for Tron
Project Track: infra-security
Team Name: OpenZeppelin

Social Info

X (Twitter): @OpenZeppelin
Website: https://www.openzeppelin.com

Project Overview

Project Goal:
Bring OpenZeppelin’s open-source smart contract libraries, developer tooling, and documentation to the TRON ecosystem, enabling developers to build and deploy secure, audited smart contracts on TRON with the same confidence as on Ethereum and other leading ecosystems.

Unique Value Proposition:
OpenZeppelin is the global leader in smart contract security and open-source standards, trusted by the Ethereum Foundation, Arbitrum, Polkadot, Stellar, and Starknet, and securing over $30 trillion in total value transferred since 2018.
With over 650 thousand Contracts Wizard users and 2.7 million yearly documentation views, OpenZeppelin provides the most widely adopted and battle-tested smart contract library in the industry.
By bringing these standards and tools to TRON, we aim to accelerate developer confidence and adoption, improve security, and strengthen the ecosystem’s position among leading blockchains.

tron-wizard
tron-wizard2789×2141 277 KB

Illustrative example of OpenZeppelin Contracts Wizard customized for Tron.

Through this project, we will:

  • Port, test, and ensure compatibility of the OpenZeppelin Contracts Library and Open Intents Framework (OIF) for TRON.
  • Integrate TRON TRC contracts into the OpenZeppelin Contracts Wizard and Documentation.
  • Add support for OpenZeppelin Upgrades Plugins in Hardhat and Foundry, contingent on TRON compatibility.
  • Develop a new TronBox Upgrades Plugin within the OpenZeppelin Upgrades repository to ensure native integration with TRON’s toolchain.
  • Drive developer adoption through tutorials, hackathons, and co-marketing initiatives.

Project Demo:
Repositories and live demos for TRON will be published progressively as milestones are completed. These updates will be included in public repositories, including but not limited to those listed below:

Expected Completion Date: All main releases will be completed by February 2026, with maintenance, support, and developer adoption efforts continuing through September 2026. Options for continued development and extended maintenance and support will also be available.
Current Progress (%): 0% (Kickoff pending)

Technical & Governance Details

Project Test Instructions:
Developers will be able to test the TRON-adapted OpenZeppelin Contracts and tools directly from public GitHub repositories.
All code will be open-source and will include automated test suites and documentation for TRC-compatible deployments.

Technical Details:

  • Language: Solidity for TVM, TypeScript and JavaScript for tooling
  • Scope: OpenZeppelin Contracts Library, Open Intents Framework contracts, Wizard integration, Documentation, and Upgrades Plugins support for Hardhat, Foundry and TronBox
  • Testing: ≥90% code coverage, CI/CD pipeline integration, public PR reviews
  • Audits: Smart contracts audited by the OpenZeppelin Security Research team

Smart Contract Links:
To be published in OpenZeppelin’s public repositories, including but not limited to:

How is the Project Governed?:
Centralized open-source governance under OpenZeppelin, with community contribution via GitHub pull requests and public release candidate reviews.

Funding & Business Model

Revenue Model:
Open-source public good for the TRON ecosystem; a grant will be required to support development and maintenance.

Interested in TRON Having a Stake?:
Yes, collaboration and ecosystem alignment will be maintained through biweekly syncs with the TRON core team, as well as coordination via GitHub issues and pull requests.

Preferred Collaboration Method:
Biweekly syncs, GitHub collaboration, and joint developer activations with TRON and its community.

Ecosystem Impact

Partnerships:
OpenZeppelin collaborates with leading ecosystems including Ethereum, Arbitrum, Polkadot, Stellar, Starknet, and Uniswap. We are now extending these standards and developer tools to TRON. Please refer to our dune-dashboards for metrics on our impact across these and other ecosystems.

Time on TRON:
Development begins upon approval by TRON’s core team.

Project Milestones
The following milestones and timelines assume project approval on October 2025.

Project Milestones:

# Milestone Duration Timeline Description
1 Solidity Contract Libraries Support 3 months October 2025 –> December 2025 Analyze the TRON Virtual Machine (TVM) architecture to identify possible Solidity incompatibilities caused by energy-based metering, modified opcodes, and custom precompiles. Review and test OpenZeppelin’s Solidity contracts (openzeppelin-contracts) alongside existing TRC implementations (TRC-10, TRC-20, TRC-721, etc.) to detect and resolve edge cases. Deliver a comprehensive guide with mitigation steps, and publish the first version of OpenZeppelin Contracts for TRON, ensuring compatibility with the Open Intents Framework (OIF) contracts (ERC-7683 and related standards) to support secure intent execution and cross-chain payments across networks.
2 Wizard & Documentation Integration 1 month January 2026 Add a dedicated TRON section to the OpenZeppelin Contracts Wizard and Documentation, enabling developers to bootstrap TVM smart contract creation through a user-friendly interface and AI assistant. This integration will include code generation templates, Remix and IDE integration, and a deployment workflow. The documentation will detail contract types, interfaces, and best practices for TRON dApps, ensuring all templates are fully tested, audited, and TRC-compliant.
3 OpenZeppelin Upgrades Plugin Integrations (Hardhat & Foundry) 1 month - In parallel with Milestone 2 January 2026 Include support for OpenZeppelin Upgrades Plugins for Hardhat and Foundry, to enable secure deployment and management of upgradeable smart contracts on TVM. These integrations will provide proxy administration, upgrade validation, and safety checks using existing Hardhat and Foundry frameworks. Work on extending Hardhat or Foundry to support TRON if any incompatibility is detected is excluded from this scope; integration will proceed once compatibility is confirmed.
4 OpenZeppelin Upgrades Plugin Integration (TronBox) 1 month February 2026 Develop and maintain an OpenZeppelin Upgrades Plugin for TronBox as part of the OpenZeppelin Upgrades repository. This will extend the existing upgrade framework to TRON’s native development environment, enabling developers to deploy and manage upgradeable smart contracts directly from TronBox using the same proxy patterns and safety checks available in Hardhat and Foundry. The work will include development, testing, and documentation of the new plugin, followed by dedicated maintenance and support to ensure long-term compatibility with TronBox updates.
5 Maintenance & Support 8 months February 2026 –> September 2026 Provide continuous maintenance and support for all TRON deliverables, including the Contracts Library, Wizard, Documentation, and Upgrades Plugins (Hardhat, Foundry, TronBox). Ensure updates remain in sync with new Solidity Library releases (openzeppelin-contracts), with full testing, smart contract auditing, and CI/CD coverage.
6 Developer Enablement 8 months February 2026 –> September 2026 Drive developer adoption and engagement through dedicated onboarding, tutorials, and community events. This includes quarterly technical workshops, hackathon participation, and developer office hours in collaboration with the TRON team. OpenZeppelin will publish step-by-step guides, host webinars, and promote integration examples through co-marketing campaigns and social media. A Technical Account Manager will coordinate biweekly syncs to ensure alignment, gather community feedback, and support early-stage TRON projects adopting the OpenZeppelin Ecosystem Stack.
7 Strategic Advisory 12 months October 2025 –> September 2026 Provide ongoing strategic and technical advisory to the TRON core team through biannual leadership meetings (at months 5 and 11) and continuous collaboration on developer experience, protocol design, and ecosystem priorities. This includes early input on protocol-level features such as account abstraction, hooks, and cross-chain intents, as well as recommendations on developer tooling and language enhancements. OpenZeppelin will share best practices from its work across EVM and non-EVM ecosystems, helping align TRON’s roadmap with emerging trends and community needs.

Project in 5 Years:
OpenZeppelin’s standards will underpin secure smart contract development across TRON, powering DeFi, governance, and cross-chain interoperability with the same rigor and security trusted throughout the global blockchain ecosystem.

As our involvement progresses, we can extend the collaboration to include new standards and tools aligned with TRON’s roadmap.

Other potential areas of collaboration could include standard implementations related to:

  • Privacy and confidentiality
  • Real-world assets
3 Likes
2

Welcome to TBL, it’s quite an interesting submission you’ve going on here, was an exciting read from start to finish.
I’m curious, who will own long-term maintenance funding after the grant period?

2 Likes
3

Hi @manfred_jr, thanks for the comment and quick review!

At the end of the proposed 1-year engagement, there is an opportunity for renewal, either to continue with new developments in standards and tooling that are strategic to Tron, or to transition into a maintenance agreement with reduced development and audit efforts.

The maintenance agreement would essentially extend Milestone 5 above on Maintenance and Support. Based on our experience with other ecosystems, we typically renew this phase through new yearly agreements or extensions of the initial engagement.

This stage focuses on stability, security, and support at a lower cost, while ensuring the contracts library and tooling remain secure and up to date. It includes keeping TRC standard implementations aligned with their counterparts in our Ethereum openzeppelin-contracts library.

We estimate Maintenance and Support to represent only a small fraction of the initial development effort. The audit component would similarly be limited to any diffs between the ERC and TRC implementations. This scope would also cover documentation and tooling updates.

For reference, OpenZeppelin has maintained its Solidity libraries for over a decade and continues to sustain multi-year partnerships with ecosystems such as Arbitrum, Polkadot, Starknet, and Stellar. These renewals typically combine long-term support with new opportunities for collaboration and ecosystem growth.

3 Likes
4

Thanks for sharing @OpenZeppelin and keeping community informed about your submission here :slight_smile:

2 Likes
5

Thanks for your reply.
I’m wondering, the renewal decision, will it be made automatically after one year or only if TRON DAO approves?

1 Like
6

Good Service bro anything new project ?

7

First time poster, welcome to the TronDao forum.

1 Like
8

Generally, the renewal would follow a new approval process, as it would be treated as a separate agreement, or at least require a new order form under the initial agreement. We could begin renewal discussions before the initial engagement comes due to ensure continuity.

9

Welcoming you to the tbl, please how in total figure is you’re funding request, thank you

1 Like
10

When exactly would you prefer to start renewal discussions?

1 Like
11

Hi @manfred_jr, this is something we could cover during our biannual leadership meetings (at months 5 and 11). These meetings include conversations on strategic next steps for our partnership, including whether to continue with new developments or focus on maintenance and support.

12

Ok I clearly get that

1 Like
13

Hello @OpenZeppelin , considering TRON utilizes Solidity and it is EVM compatible, what are the main benefits of bringing TRON support to OZ libraries?

I know developers already utilize OZ libraries without an official integration/support.

Would you please help to elaborate on how developers and the TRON community benefit from it?

Is there an specific set of features orcontracts devs cannot use as of now but will be supported after this?

Thanks!

2 Likes
14

Hi @SimbadMarino, thanks for the question!

Even though TRON is Solidity-compatible, developers often face differences in opcodes, gas models, and toolchain behavior when deploying contracts. From our discussions with the TRON team, we understand this can make it difficult for developers to confirm full compatibility and trust that everything will work as expected.

Our goal is to make that experience seamless, opening our Ecosystem Stack for TRON to the thousands of Ethereum developers who already trust OpenZeppelin in their secure development journey.

By reviewing, testing, and integrating TRC-compatible contracts and tools, we’ll ensure for TRON the same level of quality and security that developers already rely on from OpenZeppelin across other ecosystems. This will help TRON developers build with confidence and connect TRON to the global community that already trusts OpenZeppelin’s libraries and tooling.

4 Likes
15

@OpenZeppelin

  1. Do you plan to provide a TRON-specific version of the OpenZeppelin Upgrades libraries and plugins, or would TRON projects be expected to adapt the existing Ethereum libraries themselves?
  2. Your contracts are battle-tested on Ethereum mainnet. What’s your threat model for TRON specifically, given TVM/EVM differences? What new classes of bugs or economic attacks do you think appear on TRON that don’t on Ethereum?
  3. From your side, what would ‘success’ look like 12–24 months after integrating with TRON?
  4. Many TRON projects already use home-grown or TronBox-style proxies. Do you have a recommended migration path from existing TRON upgradeable contracts into OpenZeppelin’s proxy patterns, and can your tooling detect unsafe or incompatible legacy layouts?
  5. Do you foresee a particular issue when porting utilities like safeTransfer, Clones or create2 for TRON?
  6. The dev community is constantly pushing to implement EIP-4337 & EIP-7702 on TRON, which role are you expecting to take on these particular EIP ports on TRON? Do you expect any particular blocker from the tron protocol side?
1 Like
16

Hi @aziztron. Thank you for the follow up.

1. Do you plan to provide a TRON-specific version of the OpenZeppelin Upgrades libraries and plugins, or would TRON projects be expected to adapt the existing Ethereum libraries themselves?

We plan to provide TRON specific support for OpenZeppelin Contracts Upgradeable together with a TRON compatible version of the OpenZeppelin Upgrades Plugins. This work will be performed alongside the openzeppelin-contracts and Upgrades Plugins integration, with the objective of ensuring that TRON developers can use upgradeable patterns natively without needing to adapt Ethereum tooling themselves.

Our commitment is to deliver these libraries and plugins so that they work reliably within TRON’s environment, and to maintain them throughout the duration of our engagement. As we progress with the integration, we will map any TVM specific differences to ensure safe and predictable upgrade flows.

2. Your contracts are battle-tested on Ethereum mainnet. What’s your threat model for TRON specifically, given TVM/EVM differences? What new classes of bugs or economic attacks do you think appear on TRON that don’t on Ethereum?

Our threat model for TRON will follow the same principles we apply across all EVM compatible environments, enhanced by a review of the documented differences between the TVM and the EVM. As part of this process, we will assess potential risks related to opcode behavior, fee and execution semantics, precompiled contracts, and address derivation rules.

We will define system wide invariants, evaluate integration risks, and rely on our audited, battle-tested OpenZeppelin Solidity contracts to minimize the attack surface and focus our audit efforts on environment differences.

During the research and smart contract audit phases, we will map any TRON specific execution layer considerations. Any issues identified will be surfaced early and addressed jointly with the TRON team.

3. From your side, what would ‘success’ look like 12–24 months after integrating with TRON?

Success for us means that OpenZeppelin’s Contracts, Upgrades Plugins, and developer tooling become the default foundation for new TRON development. Over 12–24 months, we would aim to see:

  • Broad adoption of OpenZeppelin libraries across new TRON deployments.
  • Developers using the TRON compatible Upgrades Plugins and Wizard in their workflows.
  • A steady increase in TVL from contracts built on OpenZeppelin libraries, trending toward adoption levels seen on major EVM chains.

We will track this adoption through our public Dune metrics dashboard: https://dune.com/openzeppelin/openzeppelin-contracts-metrics.

4. Many TRON projects already use home-grown or TronBox-style proxies. Do you have a recommended migration path from existing TRON upgradeable contracts into OpenZeppelin’s proxy patterns, and can your tooling detect unsafe or incompatible legacy layouts?

Yes, our Upgrades Plugins already include safety checks (storage layout, initializer protections, etc.) to verify that a contract is safe to upgrade. As we extend the Upgrades Plugins for TRON, including support for Hardhat, Foundry and TronBox, we will adapt those checks to TRON, enabling detection of unsafe or incompatible layouts and offering a clear migration path to standardized OpenZeppelin patterns.

5. Do you foresee a particular issue when porting utilities like safeTransfer, Clones or create2 for TRON?

We do not anticipate fundamental blockers, but we will validate each utility against TRON’s VM behavior. Utilities such as safeTransfer, Clones, and create2 rely on specific execution and address derivation assumptions, and TRON’s TVM, while EVM aligned, has some differences we will have to address during implementation.

If we identify deviations that impact correctness or determinism, we will adjust our implementations accordingly. Any protocol level limitations will be surfaced early and addressed jointly with the TRON team.

6. The dev community is constantly pushing to implement EIP-4337 & EIP-7702 on TRON, which role are you expecting to take on these particular EIP ports on TRON? Do you expect any particular blocker from the tron protocol side?

Our focus will be to provide contract level support for smart account patterns within the TRON ecosystem, including the components of EIP-4337 and EIP-7702 that are already part of, or become part of, the openzeppelin-contracts library during the duration of our engagement. We will port the relevant account abstraction contracts and extend our developer guidelines accordingly, based on our existing documentation for smart accounts and delegation patterns (references: 1, 2).

If we identify any protocol level blockers during the research and compatibility review phase, they will be addressed jointly with TRON.

2 Likes
17

Thanks @OpenZeppelin !

It is helpful.

1 Like