TRX Wallet Demo Setup: Address Binding + Multi-Tier Referral Network Full Record

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

Recently I helped a client deploy a demo system built around TRX wallet addresses. The client runs blockchain training courses and wanted a hands-on sandbox where students could practice. After getting the source code, I ran it on the testnet first. The core logic is: students register, bind a TRX address, receive demo points after wallet verification, and then build a six-level referral relationship through invite codes. The whole system does not touch real funds; it only demonstrates address interaction and points rewards. Below are the pitfalls and configuration notes I picked up during the deployment.

1. Function Test: Address Binding and Referral Network

Once the backend was running, I registered three test accounts to simulate a regular user, an inviter, and an invitee. The registration flow is standard: phone number plus verification code. The source already integrates an SMS interface, but it defaults to demo mode, so you can skip with a fixed code.

1.1 Address Binding and Wallet Verification

The user center has a “Bind Address” entry where you enter a TRX address. The system validates the format: TRX addresses usually start with T and are 34 characters long, and the source uses a regex for basic validation. After binding, a verification task is generated: the user sends 1 TRX to a system-designated demo address on the testnet, and the backend marks the address as “activated” after receiving the callback.

A pitfall here: testnet and mainnet API nodes cannot be mixed. The first time I deployed, I set the node to mainnet, so the test transfer callback never arrived. After switching to the Shasta testnet node, the callback worked. If you are doing pure teaching demos, you can disable real-transfer verification and use a “simulate activation” button, but the client wanted to keep the real address interaction flow, so I kept the callback logic.

1.2 Six-Level Referral Network

Each user gets an invite code after registration. When a subordinate user fills in the code, a relationship chain forms. The source supports six levels, stored in a separate invite_tree table. From the backend, I can see each user’s team size and sub-levels clearly, which is good for explaining referral models.

However, these six levels are only for data demonstration and do not involve any real fund distribution. The client’s training focuses on “relationship-chain data structure” and “points reward algorithm,” not revenue models. The reward ratios in the source can be adjusted flexibly; by default the inviter gets different weights per level.

1.3 Points Reward Rules

The system has a built-in points reward logic: after address verification, the user gets 15 demo points; unverified gets 1.5. Inviters receive extra weighted points based on the verification status of subordinate users. Reward values can be changed in the backend, and a total cap can be set, such as limiting the demo to 8,000 points to prevent test data from bloating.

Highlight: The main value of this source code is that it integrates blockchain address interaction, referral relationship chains, and points distribution into one backend. It is suitable for teaching demos or secondary development. By turning the real transfer into simulated points, it can quickly become an internal corporate training system.

2. Deployment Environment and Backend Configuration

My deployment environment was CentOS 7.9 + Nginx 1.24 + PHP 7.4 + MySQL 5.7. PHP needs the bcmath, openssl, curl, and mbstring extensions. The source front and back ends are not separated, and the template uses the ThinkPHP 5 framework, so there is a hard PHP version requirement. PHP 8.1 throws errors directly, so I had to downgrade to 7.4.

2.1 Database and Rewrite Rules

After importing the SQL file, check the core tables first: users, user_address, invite_tree, points_log, and config. The config table holds key parameters such as node address, testnet switch, and reward ratios. Nginx rewrite rules must be configured correctly, otherwise backend routes will return 404. Here is a common rewrite rule for ThinkPHP 5:

try_files $uri $uri/ /index.php?$query_string;

For Apache, just place the .htaccess file.

2.2 Backend Control Panel

The default backend path is /admin, and the account password is pre-written in the database. After logging in, look at the “System Settings” and “Reward Settings” menus first. System settings let you change the site name, demo address, and TRX node. Reward settings let you adjust registration points, verification points, and invite weights. I recommend setting all values small first, testing, then scaling up, to avoid points overflow.

2.3 Multi-language and Customization Advice

The source is in Chinese by default, but the language pack structure is clean: there are separate files under the lang directory, and adding a language is just copying a file and changing the keys. For customization, if you want to connect it to a real business system, I suggest extracting the TRX address verification module into a separate service instead of coupling it with the main business. Also, querying the referral relationship chain slows down at large data volumes, so add an index on the pid field of the invite_tree table.

3. Target Audience and Use Cases

This system suits two groups: blockchain training teachers who want to demonstrate address binding and referral relationships to students, and developers new to ThinkPHP 5 who want to learn how to handle address callbacks, hierarchical relationships, and points logs. I do not recommend using it directly in production, because security audits, risk control, and data isolation are not implemented. It is fine for practice, but commercial use would require a lot of additional code.

4. FAQ

Q: The homepage opens after deployment, but registration throws a 500 error. How to debug?
A: Check the error log in runtime/log first. It is likely a wrong database connection configuration, or the SMS interface is not disabled. I encountered a case where the sms_switch in the config table was enabled by default but the interface was not configured, causing registration to fail. Switch SMS verification to demo mode first.

Q: After address verification, points are not credited and there is no backend record. Why?
A: First check whether the callback address is reachable from the public internet. If deployed on a local VM, the TRX testnet node cannot callback to your intranet address. Change the callback to a public server or an intranet-penetration address. Also check whether the points_log table has write permission.

Q: Can I change it to a pure simulation environment without sending real TRX?
A: Yes. In the backend, disable the real verification switch, or change the verification logic to manual review. After the user binds an address, the admin clicks “Simulate Activate” in the backend, and the points reward flow is still triggered. This is safer for training scenarios.

Q: Does a six-level referral relationship pose compliance risk?
A: If it is only data demonstration with no real fund distribution and clearly labeled “for technical learning purposes,” the risk is low. However, I recommend keeping the levels within three tiers and making points non-withdrawable and non-exchangeable, serving only as demo data. Consult legal advice before formal commercial use.

Disclaimer: This article is for technical education only. The system described is a simulation environment for learning blockchain address interaction and referral data structures. It does not involve real funds, real payouts, or financial transactions. Please use it in compliance with applicable laws and regulations, and perform your own security and compliance review before deployment. This article is not a commercial promotion or offer of any financial product.

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

#TRX wallet #address binding #referral network demo #blockchain demo #ThinkPHP 5 source code