NovaCodeu/tron: a GPU vanity address generator for TRON wallets

What the tool does and how you run it

The project is a TRON wallet vanity address generator with a GPU acceleration path and a Windows GUI. The distribution is a zip: go to the Releases page, download `Tron.zip`, extract it and run `Tron.exe`. The minimum requirements listed are Windows 10 or 11 on 64-bit, an NVIDIA GPU with current drivers, and OpenCL support. There are two ways to drive it. You type a single target address, which the README describes as a 34 character TRON address beginning with T, set a prefix length and a suffix length between zero and ten, and press start. Or you load a rule file, one target address per line, and the tool works through the list. Results appear in a results area showing the address and the matching private key, and a button exports both to a text file. The GUI is bilingual, with a one-click switch between Chinese and English, and it reports the rate, the elapsed time and the result count while it runs.

How the key derivation is put together

The derivation code is published in the README as an excerpt, and it is worth reading closely rather than as marketing. The steps are: extract a hardware fingerprint to make a machine identifier, gather 256 bits of entropy from the operating system CSPRNG, fuse the machine identifier, the entropy and a timestamp into a seed, and derive a secp256k1 private key from that seed to get the TRON address. The excerpt puts it plainly.

std::string machineId = SHA256(cpuId + macAddr + diskSerial);
std::string entropy  = CSPRNG(32);
std::string seed     = SHA256(machineId + entropy + timestamp);
PrivateKey key = secp256k1::fromSeed(seed);
Address    addr = tron::addressFromKey(key);

The machine fingerprint is described as a 128-bit identifier built from a SHA-256 over the CPU identifier, the network card MAC address and the disk serial number, and the README argues that this makes each machine's key space unique and the derivation non-reproducible elsewhere. The generator is a collision search over that space, so the fingerprint is a starting point rather than the whole seed.

The performance numbers and what they mean for waiting

The GPU rates given are around 1.02 billion hashes per second on an RTX 5090, 600 to 800 million on an RTX 4090, 220 million on an RTX 3080 and 150 million on an RTX 4060 Ti. The figures the README gives for time are the more useful numbers, because they translate a hash rate into how long you wait. A six character suffix is a matter of minutes, seven is tens of minutes, eight is hours to overnight, ten is days. The README also lays out the difficulty tiers for lookalike addresses, with a two character prefix and a four character suffix described as easy, six as medium and eight as hard. That progression is the expected behaviour of a brute force search over an expanding space, and the recommended first run is deliberately modest: zero prefix digits, a six character suffix and a generation count of one, to confirm the program outputs something before you ask for a longer match.

The rule file format and the matching examples

The batch mode reads a plain text file where each line is a target address or rule, and the README gives an example.

TTTTTTTTTTZZZZZZZZZZ
TTTTTTTTTT8888888888
TG2CMGxnTPgQ6V58kiKd7wbyN8ewtAmY76

The matching rules work on both ends of the address. With a prefix length of zero and a suffix length of six, a target of TTTTTTTTTT8888888888 yields an address whose last six characters are 888888, and with a prefix length of two the first two characters match as well. The recommended values are a prefix of zero or two and a suffix of six to eight. The point to hold on to is that the prefix length and suffix length are the two numbers that determine the cost, and they are independent of how long the target address itself is.

The CUDA sources at the root of the repository

The repository is small and the file names describe the whole computation. There are four .cu files, which are the CUDA kernels: secp256k1_gpu.cu for the elliptic curve arithmetic, keccak256_sm89.cu for the hash, base58_t58.cu for the address encoding, and main_stride.cu for the parallel loop structure. Alongside them are a README, an English README, a LICENSE file and three screenshots. The absence of a build system, a CMake file or a makefile in the top-level listing is worth noticing. What you are given is a Windows binary plus the kernels, and the README's verification story is built around that binary rather than around a reproducible build, which is a real difference from the typical source-only project. The MIT licence is stated for the code and the README says the published binary is identical to the open source code.

Verifying the binary and the six checks

The README sets out six ways to check the release, which is unusual and worth taking seriously in principle. The first is a line-by-line audit of the source, the second a SHA-256 checksum computed locally and compared against the published value, the third that the tool is free with no commercialisation, the fourth submitting the zip to VirusTotal so that dozens of engines publish a verdict, the fifth observing that the program makes no network requests, and the sixth independently verifying that a generated address and its private key correspond using a third party such as a block explorer or a wallet import.

certutil -hashfile Tron.zip SHA256
Get-FileHash .\Tron.zip -Algorithm SHA256
4AA52408CC39134CB135C1C23E4A7F0A52DCC03AED21F0513E48BC87D5DC170D

The third line is the published digest to compare against, and the README says to compare your local result with it before using the file. The offline claim is the one to test yourself, because a program that handles private keys and claims to make no network calls is exactly the kind of claim that should be verified rather than accepted, and the README's own framing is that trust should come from your own checking.

Where this tool should not be used

Three limits are serious. The first is the lookalike address feature. The README describes generating an address whose prefix and suffix match a target, which is a legitimate vanity use when the target is your own, and a phishing primitive when the target belongs to someone else, and nothing about how the key was derived changes what the resulting address communicates to a person reading a transaction. The second is the key derivation design itself. Binding the seed to a machine fingerprint and a timestamp means the key cannot be regenerated from a backup phrase on another machine, and since the timestamp participates, running the tool twice does not reproduce the same key. That is a deliberate choice, defended in the README as preventing brute force, but the practical effect for a wallet holding real value is that a hardware failure or a disk replacement ends the account unless the private key was exported and stored separately, and the tool's export writes addresses and keys to a plain text file, which is a file to protect. The third is the environment: Windows only, an NVIDIA GPU, an English-only path, and a Visual C++ redistributable that must be installed or the program will not start.

Editorial conclusion

Read this repository if you are evaluating whether TRON vanity addresses are worth running on your own hardware, because the derivation code is published and the performance table gives realistic expectations for how long a given suffix length takes. Do not use the lookalike address feature to impersonate another address to a third party, since an address that resembles someone else's is a phishing primitive regardless of how the key was derived. Verify first that the release you downloaded matches the published SHA-256, that you understand that keys derived with the machine fingerprint binding cannot be regenerated on another machine, and that the version you run matches the source, because the repository publishes a Windows binary whose checksum the README gives.

Frequently asked questions

Official sources

1. License: MIT
2. NovaCodeu/tron on GitHub
3. Project website
4. README
5. Releases