OpenZeppelin Upgrades Plugins for the TRON Virtual Machine (TVM).
| Package | What it is |
|---|---|
@openzeppelin/hardhat-tron-upgrades |
Transparent, UUPS, and beacon deployment/upgrades, preparation, import, reuse, and upgrade-safety validation for Hardhat on TRON |
@openzeppelin/tronbox-upgrades |
Upgrades plugin for TronBox |
Both packages reuse @openzeppelin/upgrades-core
for upgrade-safety validation (storage-layout compatibility, initializer rules,
unsafe-operation detection) rather than forking it. The TRON-specific work lives
in the deployment layer: TronWeb-backed deploys, 0x41-prefixed CREATE2 address
prediction (TIP-26), and network manifests keyed by TRON chain-ids.
The Foundry integration lives in its own repository — Foundry libraries are
installed from a repo root via forge install, so it cannot be an npm workspace
here.
Each plugin package is self-contained (TypeScript sources, fixtures, tests)
following the upstream openzeppelin-upgrades layout:
cd packages/hardhat-tron-upgrades
npm install
npm test # builds, boots a Dockerized TRON node, runs the suite
npm run test:examples # consumer E2E: installs the packed plugin like an npm userpackages/hardhat-tron-upgrades/examples/BoxUpgrades mirrors upstream's
examples: a standalone consumer project (own package.json) that installs the
plugin from a packed tarball and hosts the public-testnet scripts.
Every dependency comes from the npm registry, the bridge
(@openzeppelin/hardhat-tron) and the contracts library
(@openzeppelin/tron-contracts, ^5.6.0) included. The one tarball left under
vendor/ is this plugin's own: the example's lockfile resolves the plugin to
it, and test:examples then replaces that install with a fresh npm pack of
the checkout and verifies the two are byte-identical before running the
example suite, so the example always exercises the code under review rather
than the published release. A clean clone needs no sibling checkouts.
Requirements: Node.js ≥ 20, Docker running.
Current test coverage includes transparent/UUPS/beacon lifecycles, chain-first drift recovery, implementation reuse and preparation, kind inference, admin ownership transfer, expert validation/transaction options, deterministic clone address prediction, and tron-solc build-info validation.