Tronbox

The skill is based on TronBox v4.5.0, generated at 2026-02-25.

TronBox is a Truffle-style framework for TRON: smart contract compilation, migrations, testing, and an interactive console. It supports both the native TRON Virtual Machine (TVM) and EVM-compatible chains (e.g. BTTC) via a separate config and the --evm flag. Migrations and tests use ethers v6 in EVM mode and TronWeb for TVM.

Core References

Features

Best Practices

Generation Info

• Source: sources/tronbox
• Git SHA: ead5d1b25c9818791a878d82adf7becea6dfd8b1
• Generated: 2026-02-25

TronBox Environment and Network Selection

Before migrate, test, or console, TronBox runs Environment.detect(config, callback) to set the resolver, artifactor, network, and deployer “from” address. Understanding this avoids “No network specified” and “Unknown network” errors when scripting or debugging.

Default network

• If config.network is not set and config.networks.development exists, config.network is set to 'development'.
• For test, the command also falls back to config.networks.test if development is missing.
• If neither is set, commands that need a network call the callback with an error.

Requirements

• config.networks must exist.
• config.network must be set (by CLI --network or the default above).
• config.networks[config.network] must exist, otherwise: Unknown network "X". See your tronbox configuration file for available networks.
• config.networks[config.network].network_id must be set, otherwise: You must specify a network_id in your 'X' configuration in order to use this network.

From address

If config.from is not set, Environment.detect calls tronWrap._getAccounts() and sets config.networks[config.network].from to the first account and config.networks[config.network].privateKey from TronWrap’s mapping. So the deployer/signer is the first account of the connected network when from is omitted.

Resolver and artifactor

If config.resolver is missing, it is set to new Resolver(config). If config.artifactor is missing, it is set to new Artifactor(config.contracts_build_directory). Migrate and test depend on these.

Usage for agents

• When generating or validating tronbox config, ensure the target network has network_id and either privateKey or fullHost (and let TronWrap supply from if needed).
• If a user sees “No network specified”, add or select a network (e.g. development or test) and ensure it has network_id.
• If they see “Unknown network”, the name in --network or the default must exist under networks in the correct config file (tronbox.js vs tronbox-evm-config.js for EVM).

<!-- Source references:

• sources/tronbox/src/lib/environment.js
• sources/tronbox/src/lib/commands/migrate.js
• sources/tronbox/src/lib/commands/test.js

-->

TronBox Artifacts and Resolver

Compiled contracts are written as JSON files in contracts_build_directory (default build/contracts/). The Resolver loads these artifacts and wraps them as contract abstractions for migrate, test, and console.

Artifact location and format

• Path: contracts_build_directory / <ContractName>.json.
• Normalized keys (ContractSchema): contractName, abi, bytecode, deployedBytecode, sourceMap, deployedSourceMap, source, sourcePath, ast, legacyAST, compiler, networks, schemaVersion, updatedAt.
• networks: { [networkId: string]: { address, ... } }. TVM stores address with 0x replaced by 41; EVM does the reverse when saving.

Resolver order

When you call artifacts.require(import_path) or the Resolver’s require(import_path, search_path), sources are tried in order:

1. EPM – Ethereum Package Manager (working_directory, contracts_build_directory). 2. NPM – node_modules under working_directory. 3. NPM – TronBox’s own node_modules (built-in). 4. FS – Filesystem: contracts_build_directory for artifact JSON; source resolution uses working_directory and import paths (e.g. ./contracts/Foo.sol).

First source that returns a result wins. For require, the raw JSON is normalized and turned into a Contract abstraction (provisioned with the config).

artifacts.require(import_path)

• Contract name: artifacts.require('ContractName') – looks up by contract name in build dir.
• Path: artifacts.require('./contracts/Foo.sol') – FS source can match by sourcePath to get the right contract name, then load the JSON.
• Error: “Could not find artifacts for X from any sources” if no source has the artifact.

resolve(import_path, imported_from, callback)

Used by compile and flatten to find Solidity source. Tries EPM, NPM, FS; callback (err, body, resolved_path). FS resolves relative imports from imported_from’s directory.

Usage for agents

• Use artifacts.require('ContractName') or artifacts.require('./path/to/Contract.sol') in migrations and tests; do not read JSON from disk manually.
• Ensure contracts are compiled before migrate/test so build/contracts contains the expected .json files.
• When generating or merging artifact-like objects, include at least contractName, abi, bytecode, and networks; Schema.normalize accepts legacy keys like contract_name, binary, unlinked_binary.

<!-- Source references:

• sources/tronbox/src/components/Resolver/index.js
• sources/tronbox/src/components/Resolver/fs.js
• sources/tronbox/src/components/Artifactor.js
• sources/tronbox/src/components/ContractSchema/index.js

-->

TronBox CLI Reference

Entry point: tronbox (or ./tronbox.dev for development). Global options (e.g. --quiet) may apply where documented.

Commands and options

Config resolution

• Default (TVM): tronbox.js or tronbox-config.js (found via find-up from cwd).
• EVM: --evm forces use of tronbox-evm-config.js only.

Network default

For migrate, test, and console: if no --network is given and networks.development exists, development is used; otherwise test may fall back to networks.test. If no network is set, commands that need a network will error.

Usage for agents

• Prefer tronbox compile --all before migrate/test when contract sources may have changed.
• Use --evm consistently for EVM chain (compile, migrate, test, console) and ensure tronbox-evm-config.js exists.
• Private keys: use env vars (e.g. PRIVATE_KEY_MAINNET) and document source .env && tronbox migrate --network mainnet in config comments; never commit keys.
• tronbox flatten contracts/Foo.sol outputs a single concatenated Solidity file; useful for verification or auditing.

<!-- Source references:

• sources/tronbox/src/lib/commands/*.js
• sources/tronbox/README.md

-->

TronBox Compile

TronBox compiles Solidity contracts from contracts_directory (default contracts/) and writes artifacts to contracts_build_directory (default build/contracts/).

Commands

• tronbox compile – Compile only changed contracts (compares sources to existing build).
• tronbox compile --all – Compile every contract under contracts_directory.
• tronbox compile --evm – Use EVM config (tronbox-evm-config.js) and compilers.solc.
• tronbox compile --quiet – Suppress non-error output.

Compiler settings come from config: TVM uses top-level solc; EVM uses compilers.solc (see core-config).

Build output

• Artifacts are written as .js files in contracts_build_directory.
• Each artifact contains: contract_name, abi, bytecode, deployedBytecode, sourcePath, sourceMap, deployedSourceMap, ast/legacyAST, compiler (name/version).
• Link references in bytecode use placeholders (e.g. __LibraryName_________________________) until libraries are deployed and linked at migrate time.

Incremental vs full

• Without --all, the compile step uses a profiler to compare source mtimes and content to existing artifacts; only changed files and their dependents are compiled.
• With --all, all sources under contracts_directory are passed to the compiler. Use when you want a clean slate or when dependency detection might miss changes.

Usage for agents

• Run tronbox compile --all before migrate or test when contract sources may have changed, or when scripting from a clean checkout.
• Use the same config (TVM vs EVM) as the rest of the workflow; --evm must match tronbox-evm-config.js.
• Artifacts are required for migrate, test, and console; ensure build/contracts exists and is populated before those commands.

<!-- Source references:

• sources/tronbox/src/lib/commands/compile.js
• sources/tronbox/src/components/WorkflowCompile.js
• sources/tronbox/src/components/Compile/index.js

-->

TronBox Configuration

TronBox is configured via a JavaScript file in the project root. Config is resolved with find-up from the current working directory.

Config file names

• TVM (default): tronbox.js or tronbox-config.js (Windows/Command Prompt fallback).
• EVM: tronbox-evm-config.js. Used when running commands with --evm.

Config is loaded with Config.detect(options); when options.evm is true, only tronbox-evm-config.js is searched.

Export shape

The file must export an object that can be merged into the config (e.g. config.merge(static_config)). Important top-level keys:

• networks (required): { [networkName: string]: NetworkConfig }
• solc or compilers.solc: compiler settings (see below)
• build_directory, contracts_directory, contracts_build_directory, migrations_directory, test_directory: optional path overrides (resolved relative to config working_directory)

Network config (TVM)

Per-network keys (all optional; many are getters from network_config and must be set under networks[name], not on the root config):

Example:

module.exports = {
  networks: {
    development: {
      privateKey: '0000...0001',
      userFeePercentage: 0,
      feeLimit: 1000 * 1e6,
      fullHost: 'http://127.0.0.1:9090',
      network_id: '9'
    },
    shasta: {
      privateKey: process.env.PRIVATE_KEY,
      userFeePercentage: 50,
      feeLimit: 1000 * 1e6,
      fullHost: 'https://api.shasta.trongrid.io',
      network_id: '2'
    }
  },
  solc: { /* optimizer, evmVersion, etc. */ }
};

Compiler config

• TVM: use top-level solc (e.g. optimizer, runs, evmVersion). Solidity version can also be set per network under networks[].compilers.solc.version in some flows, but the main compile path uses root-level solc and compilers.solc.
• EVM: use compilers.solc with version and optional settings:

compilers: {
  solc: {
    version: '0.8.6',
    settings: { optimizer: { enabled: true, runs: 200 }, evmVersion: 'istanbul' }
  }
}

Default paths (relative to working directory)

• build_directory: build
• contracts_directory: contracts
• contracts_build_directory: build/contracts
• migrations_directory: migrations
• test_directory: test

Usage for agents

• When generating or editing a TronBox project, ensure networks exists and the target network has network_id and either privateKey/mnemonic and fullHost (TVM) or EVM-compatible options.
• Use tronbox-evm-config.js and --evm for EVM chain (e.g. BTTC); use tronbox.js and no --evm for TVM.
• Do not set config.network_id or config.privateKey directly; set them under config.networks[networkName].

<!-- Source references:

• sources/tronbox/src/components/Config.js
• sources/tronbox/README.md
• sources/tronbox/test/evm/tronbox.js, test/evm/tronbox-evm-config.js

-->

TronBox Console

The console is an interactive REPL that runs in a TronBox environment with contract abstractions and network access. It uses the same config and Environment.detect as other commands.

CLI

tronbox console              # Start with development network
tronbox console --network <name>
tronbox console --evm        # Use EVM config

Network selection follows the same rules as migrate/test; TronWrap is initialized with the chosen network and --evm if set.

REPL context

• artifacts – Resolver: artifacts.require('ContractName') to load contract abstractions.
• config – Resolved config (with network, provider, paths).
• Contract abstractions – Once required, use .deployed(), .at(address), .new(...) and contract methods as in migrations/tests.
• tronWeb / ethers – Available per mode (TVM vs EVM) for low-level calls.

Subcommands (e.g. compile, migrate, test) are available in the console except excluded ones (console, init, flatten, unbox). The prompt shows the current network, e.g. tronbox(development)>.

Usage for agents

• Use the console for ad-hoc contract calls and inspection; for scripting, prefer migration scripts or test files.
• Ensure the network in config has valid credentials and network_id so Environment.detect and TronWrap init succeed.
• In EVM mode, use --evm and the same config as tronbox migrate --evm / tronbox test --evm.

<!-- Source references:

• sources/tronbox/src/lib/commands/console.js
• sources/tronbox/src/lib/console.js
• sources/tronbox/README.md

-->

TronBox Contract Abstraction

Contract abstractions are created via contract(binary) (used internally when you call artifacts.require('ContractName')). The result is a class-like object with ABI, bytecode, and network state used for deploy and calls.

Creating an abstraction

• artifacts.require('ContractName') or artifacts.require('./path/Contract.sol') returns the abstraction (see core-artifacts-resolver). Contract.initTronWeb() is called so TronWrap is set before use.

Key methods

• new(...args) – Deploy a new instance. Last argument can be an options object (e.g. feeLimit, callValue, or EVM value). Returns a Promise that resolves to the deployed contract instance. Fails if bytecode has unlinked libraries (deploy libraries first and link).
• at(address) – Return an abstraction instance bound to address. Call deployed() on the result to load methods.
• deployed() – Return a Promise that resolves to the same contract with ABI methods attached (e.g. contractInstance.methodName(args) for view/call, or send with options). Resolves against the current network_id; fails if the contract has no address on that network.
• call(methodName, ...args) – Invoke a contract method (view or state-changing; TronWrap routes to call vs send by ABI). Last argument can be an options object (e.g. from, feeLimit, callValue).
• link(libraryContractOrName, address) – Set a library link for bytecode (used before deploy). Can pass a contract abstraction or (name, address).
• setNetwork(network_id) – Set the network id for address/lookup.
• defaults(class_defaults) – Set default options merged into deploy/call options.

Properties

• contractName, abi, bytecode, deployedBytecode, address (when deployed), network, networks, transactionHash, binary (bytecode with links applied), links.

Usage for agents

• In migrations and tests use artifacts.require('ContractName') then deployer.deploy(Contract) or contract.new(...args) / contract.at(address).then(c => c.deployed()).
• For view calls use instance.methodName(args) after deployed() or at(address).then(c => c.deployed()); the abstraction exposes each ABI function as a callable that returns a Promise.
• Unlinked library error: deploy the library, call deployer.link(Lib, Consumer) (or contract.link(Lib, Lib.address)), then deploy the consumer.

<!-- Source references:

• sources/tronbox/src/components/Contract/index.js
• sources/tronbox/src/components/Contract/contract.js

-->

TronBox Migrations and Deployer

Migrations are numbered scripts in the migrations/ directory that run in order to deploy and link contracts.

Migration files

• Location: migrations_directory (default migrations/).
• Naming: Prefix with a number; extension .js or .es/.es6. Example: 1_initial_migration.js, 2_deploy_contracts.js.
• Sorting: Sorted by the numeric prefix; only migrations after the last completed one are run (unless --reset).

Migration function signature

Each migration file is executed in a VM context and must export a function that receives the deployer (and optionally other args). The function can be sync or async (return a Promise).

module.exports = async function (deployer) {
  await deployer.deploy(MyContract, ...constructorArgs);
  await deployer.deploy(Lib);
  deployer.link(Lib, Consumer);
  await deployer.deploy(Consumer, ...args);
};

The migration is invoked as fn(deployer, options.network, options.networks[options.network].from).

Context in migration files

The following are injected into the migration script context (so you can use them without requiring):

• deployer – Deployer instance (passed as the first argument).
• artifacts – Resolver: use artifacts.require('ContractName') to get contract abstractions (same as in tests).
• tronWrap / tronWeb – TronWrap (TronWeb) instance for the current network.
• waitForTransactionReceipt – Helper bound to tronWrap for waiting for a tx receipt.
• ethers – (EVM only) The ethers object from the TronWrap/ethers integration.

Deployer API

• deploy(contract, ...args) – Deploy a single contract. contract is from artifacts.require('Name'). Optional last argument can be an options object (e.g. feeLimit, userFeePercentage, or EVM value).
• deploy([contract, ...args], [contract2, ...]) – Deploy multiple contracts (deployMany).
• link(library, destinations) – Link a deployed library to one or more contract names/abstractions. destinations can be a single contract or array.
• then(fn) – Queue a custom step; fn receives the deployer. Use for one-off deployment logic or ordering.

All of these return a thenable and can be awaited. Steps are run in sequence.

Example (EVM-style with constructor args and value):

const MyContract1 = artifacts.require('./MyContract1.sol');
const MyContract2 = artifacts.require('./MyContract2.sol');
const ConvertLib = artifacts.require('./ConvertLib.sol');
const MetaCoin = artifacts.require('./MetaCoin.sol');

module.exports = async function (deployer) {
  await deployer.deploy(MyContract1, 1);
  await deployer.deploy(MyContract2, 2, { value: 1 });
  await deployer.deploy(ConvertLib);
  deployer.link(ConvertLib, MetaCoin);
  await deployer.deploy(MetaCoin, 10000);
};

Migrations contract (optional)

TronBox can optionally use a Migrations contract to record the last completed migration number. If artifacts.require('Migrations') exists and is deployed, after each migration it will call setCompleted(number). Projects can run without a Migrations contract; the runner will skip the “Saving successful migration to network” step if Migrations is not required or not deployed.

Running migrations

• tronbox migrate – Run pending migrations on the selected network (default: development if present).
• tronbox migrate --network &lt;name&gt; – Use the given network from config.
• tronbox migrate --reset – Re-run all migrations from the start.
• tronbox migrate --from N – Run from migration number N.
• tronbox migrate --to N – Run only up to migration number N.
• tronbox migrate --evm – Use EVM config and ethers.

Before running, the migrate command compiles contracts and runs Environment.detect; ensure the chosen network has a valid network_id and credentials.

Usage for agents

• Use artifacts.require('ContractName') or artifacts.require('./Path.sol') in migrations; do not require from disk paths for contract abstractions.
• For libraries, deploy the library first, then deployer.link(Library, Consumer) before deploying the consumer.
• Prefer async migration functions and await deployer.deploy(...) for clarity and correct ordering.
• When generating migrations for EVM, pass EVM options (e.g. value) in the last argument object; for TVM use feeLimit, userFeePercentage, etc.

<!-- Source references:

• sources/tronbox/src/components/Migrate/index.js
• sources/tronbox/src/components/Deployer/index.js
• sources/tronbox/src/components/Require.js
• sources/tronbox/test/evm/migrations/2_deploy_contracts.js

-->

TronBox Testing

TronBox runs tests with Mocha. Tests live in test_directory (default test/) and are discovered by file extension (default .js). Contract abstractions are available via artifacts.require().

Commands

• tronbox test – Run all tests under test/.
• tronbox test test/file.js – Run one or more files (positional).
• tronbox test --file test/file.js – Run a single file.
• tronbox test --network &lt;name&gt; – Use the given network (default: development or test).
• tronbox test --compile-all – Recompile all contracts before running.
• tronbox test --evm – Use EVM config and ethers.

If neither development nor test network is configured, the test command errors; configure at least one in tronbox.js (or EVM config).

Test globals

In test files the following are injected:

• contract(name, tests) – Mocha describe wrapper; runs before/beforeEach/afterEach for snapshotting and cleanup. tests(accounts) receives the accounts array.
• contract.only / contract.skip – Same as Mocha’s describe.only / describe.skip.
• artifacts – artifacts.require('ContractName') or artifacts.require('./Path.sol') returns the contract abstraction for the current build.
• config – Resolved TronBox config object.
• tronWeb / tronWrap – TronWeb (TronWrap) instance for the selected network.
• waitForTransactionReceipt – Helper bound to tronWrap for waiting for a transaction receipt.
• ethers – (EVM only) The ethers object from TronWrap.
• assert / expect – Chai assertions.

Tests run against a temporary build directory; artifacts are not written to the project’s build/contracts. Before tests, migrations are run with reset: true to deploy a fresh set of contracts.

Discovery

• All files matching config.test_file_extension_regexp (default .js) under test_directory are collected.
• Solidity tests (.sol) are supported: they are compiled with the project and test contracts, then executed via the same runner.

Usage for agents

• Use artifacts.require('ContractName') in tests; do not require contract abstractions from disk paths.
• Use contract('ContractName', (accounts) => { ... }) so the runner can set up and tear down state.
• For EVM tests use --evm and access ethers and EVM-style options (e.g. value) on deployments and calls.

<!-- Source references:

• sources/tronbox/src/lib/commands/test.js
• sources/tronbox/src/lib/test.js
• sources/tronbox/src/lib/testing/testrunner.js
• sources/tronbox/src/lib/testing/testresolver.js

-->

TronBox Deploy Command

tronbox deploy is an alias for tronbox migrate. It uses the same builder and runner as migrate.

Use tronbox migrate (or tronbox deploy) with the same options: --network, --reset, --from, --to, --compile-all, --evm, --quiet. There is no separate deploy flow or config.

<!-- Source references:

• sources/tronbox/src/lib/commands/deploy.js
• sources/tronbox/src/lib/commands/migrate.js

-->

TronBox EVM Mode

TronBox can target EVM-compatible chains (e.g. BTTC) instead of the native TRON Virtual Machine (TVM). In EVM mode, the stack uses ethers v6 and a separate config file.

Enabling EVM mode

• Config file: Use tronbox-evm-config.js in the project root. When any command is run with --evm, only this file is loaded (not tronbox.js).
• CLI flag: Pass --evm on compile, migrate, test, and console.

Example:

tronbox migrate --network bttc --evm
tronbox test --evm
tronbox console --evm

EVM config shape

• networks – Same key, but per-network options use EVM semantics: fullHost as RPC URL (e.g. https://rpc.bt.io), gas, gasPrice, network_id, privateKey.
• compilers.solc – version and optional settings (e.g. optimizer, evmVersion).

Example tronbox-evm-config.js:

module.exports = {
  networks: {
    bttc: {
      privateKey: process.env.PRIVATE_KEY_BTTC,
      fullHost: 'https://rpc.bt.io',
      gas: 8500000,
      gasPrice: '500000000000000',
      network_id: '1'
    },
    development: {
      privateKey: process.env.PRIVATE_KEY_DEV,
      fullHost: 'http://127.0.0.1:8545',
      network_id: '9'
    }
  },
  compilers: {
    solc: {
      version: '0.8.6',
      settings: { /* optimizer, evmVersion */ }
    }
  }
};

Migrations and tests in EVM mode

• deployer.deploy(Contract, ...args, options) – Last argument can include value (and other ethers tx overrides) for EVM.
• Contract abstractions – Use ethers under the hood; same artifacts.require, .deployed(), .at(), .new().
• Context: Migration and test context expose ethers when in EVM mode; use it for custom provider/signer logic if needed.

Version note

From TronBox 4.5.0, EVM mode uses ethers v6 (replacing web3 v4). Migration scripts, tests, and console use ethers in EVM mode.

Usage for agents

• For EVM chains, create tronbox-evm-config.js and always pass --evm for compile/migrate/test/console.
• Do not mix TVM and EVM config: use one config file per mode and the appropriate flag.
• When generating migration or test code for EVM, use ethers-compatible patterns (e.g. value in wei, gas options).

<!-- Source references:

• sources/tronbox/src/components/Config.js (EVM_CONFIG_FILENAME, options.evm)
• sources/tronbox/test/evm/tronbox-evm-config.js
• sources/tronbox/CHANGELOG.md (4.5.0, 4.0.0)

-->

TronBox Flatten

The flatten command concatenates one or more Solidity files and their dependencies (following import statements) into a single output, with imports removed. Order is topological by dependency; cycles in the dependency graph cause an error.

Command

tronbox flatten <files...>

• files – One or more contract source paths (e.g. contracts/Foo.sol). Required; no config file is required for flatten (Config.detect is called with {}).
• Output is written to stdout. Redirect to a file for verification: tronbox flatten contracts/Foo.sol > Flattened.sol.

Behavior

• Resolves imports using the same resolver as compile (contracts dir, node_modules, etc.).
• Special case: tronbox/console.sol is resolved from the TronBox package.
• Each included file is printed as // File: <path> followed by the file content with import lines stripped.
• Relative imports are resolved from the importing file’s directory; the dependency graph is built via @solidity-parser/parser and sorted with tsort. Duplicates are omitted.

Errors

• Missing or unreadable file: “File X doesn't exist or is not a readable file.”
• Parse error: “Could not parse X for extracting its imports.”
• Cycle: “There is a cycle in the dependency graph…” with listed files.

Usage for agents

• Use for block explorer contract verification (paste a single file) or for auditing.
• Always redirect stdout when saving: tronbox flatten contracts/MyContract.sol > MyContract_flat.sol.
• Flatten does not use --evm or network config; it only needs the project’s contract and import layout.

<!-- Source references:

• sources/tronbox/src/lib/commands/flatten.js
• sources/tronbox/src/components/Flatten/index.js

-->

TronBox Init and Unbox

init

Usage: tronbox init (no arguments).

• Creates a new project in the current directory. The directory must be empty (only .DS_Store is ignored); otherwise the command exits with an error.
• Interactive: user can choose “Create a sample project” (javascript), “Create a MetaCoin project” (javascript-metacoin), or “Quit”.
• Non-interactive: set env vars TRONBOX_CREATE_JAVASCRIPT_PROJECT_WITH_DEFAULTS or TRONBOX_CREATE_JAVASCRIPT_METACOIN_PROJECT_WITH_DEFAULTS or TRONBOX_QUIT.
• Files are copied from the package’s sample-projects/javascript or sample-projects/javascript-metacoin. Then npm install is run if package.json exists.

Use when scaffolding a new TronBox app in an empty folder. Do not pass a template name to init; for templates use unbox.

unbox

Usage: tronbox unbox <box-name-or-url>.

• Downloads a “TronBox Box” (project template) and extracts it into the current directory.
• Box can be a name (resolved from a known registry/GitHub) or a URL (e.g. GitHub repo). Config files in the box may be named tronbox.json or tronbox-init.json and are normalized during unbox.

Use when starting from a community or official template (e.g. from GitHub tronsuper or similar). Prefer unbox for named templates and init for the built-in sample or MetaCoin project.

Usage for agents

• Run tronbox init only in an empty directory; suggest the user create a new folder and cd into it first.
• For a custom template or third-party box, use tronbox unbox <url-or-name> and then adjust config (networks, compiler) as needed.
• After init or unbox, remind the user to set privateKey or mnemonic via env and run tronbox compile then tronbox migrate (or --evm for EVM).

<!-- Source references:

• sources/tronbox/src/components/Init/index.js
• sources/tronbox/src/lib/commands/init.js
• sources/tronbox/src/components/Box (unbox)
• sources/tronbox/README.md

-->