Tester des paiements USDT avant le réseau principal : ce que Nile change et ce qu'un bac à sable simule
Une intégration de paiements devrait rencontrer son premier échec quelque part de moins cher que le réseau principal, et sur TRON il y a deux endroits de ce genre. Nile est un testnet public : une vraie chaîne où les transactions sont signées et arrivent dans des blocs, tournant sur des paramètres à elle. Un bac à sable comme le nôtre copie l'API par-dessus une chaîne simulée, ce qui abandonne le vrai réseau et gagne les issues qu'un vrai réseau ne produira pas sur demande. Nous avons lu les paramètres de chaîne du réseau principal et de Nile le 3 septembre 2026 et signé des transactions sur Nile le lendemain.
Ce que Nile partage avec le réseau principal
Nile répond au même appel getchainparameters que le réseau principal, et les paramètres qui tarifent un transfert sont revenus identiques. L'énergie coûte 100 sun l'unité sur les deux réseaux : un transfert qui manque d'énergie brûle donc des TRX au même tarif sur chacun. La bande passante gratuite, les frais de création d'un compte, les frais de mémo et les trois paramètres d'énergie dynamique concordent aussi.
| Paramètre de la chaîne, lu le 3 septembre 2026 | Réseau principal | Nile |
|---|---|---|
Frais d'énergie en sun par unité, getEnergyFee | 100 | 100 |
Bande passante gratuite par compte, getFreeNetLimit | 600 | 600 |
Frais de création de compte en sun, getCreateAccountFee | 100,000 | 100,000 |
Frais de mémo en sun, getMemoFee | 1,000,000 | 1,000,000 |
Seuil d'énergie dynamique, getDynamicEnergyThreshold | 5,000,000,000 | 5,000,000,000 |
Facteur d'augmentation de l'énergie dynamique, getDynamicEnergyIncreaseFactor | 2,000 | 2,000 |
Facteur maximal de l'énergie dynamique, getDynamicEnergyMaxFactor | 34,000 | 34,000 |
Délai de dégel en jours, getUnfreezeDelayDays | 14 | 1 |
Plus long verrou de délégation en blocs, getMaxDelegateLockPeriod | 864,000 | 144,000 |
Intervalle de maintenance, getMaintenanceTimeInterval | 21,600,000 | 1,800,000 |
Plafond de temps CPU d'une transaction, getMaxCpuTimeOfOneTx | 80 | 160 |
Ce que Nile change
Pour qui manie de l'énergie, la première différence est le dégel : il prend un jour sur Nile contre quatorze sur le réseau principal, si bien qu'un test qui gèle des TRX puis les retire se termine treize jours plus tôt que la même séquence en production. Le plus long verrou qu'une délégation puisse porter est de 144,000 blocs sur Nile, cinq jours à trois secondes par bloc, contre 864,000 blocs, trente jours, sur le réseau principal. Un verrou de plus de cinq jours ne peut pas du tout être répété sur Nile ; ce qu'un verrou refuse est identique sur les deux réseaux.
Huit des paramètres renvoyés par le réseau principal portent une valeur différente sur Nile. Outre ces deux-là, ce sont l'intervalle de maintenance, le plafond CPU du tableau, et quatre qui régissent les producteurs de blocs, les propositions et les fonctionnalités des contrats. Nous n'avons suivi aucun de ces six dans un flux de paiement.
Le gel donne aussi une quantité d'énergie différente, parce que chaque réseau divise la même limite d'énergie entre son propre gel total, et que celui de Nile est bien plus petit. Dans nos deux passages sur Nile du 4 septembre, le gel que nous avons délégué est apparu sur le compte qui reçoit comme 7,376 unités d'énergie. Le même gel sur le réseau principal, au total lu un jour plus tôt, revient à 958 unités : Nile en distribue donc près de huit fois plus. Un gel dimensionné sur Nile laisserait un portefeuille du réseau principal à court.
| Énergie issue du gel | Réseau principal, 3 septembre 2026 | Nile, 4 septembre 2026 |
|---|---|---|
Limite d'énergie de tout le réseau, TotalEnergyLimit | 180,000,000,000 | 180,000,000,000 |
Gel total pour l'énergie, TotalEnergyWeight | 18,770,236,993 | 2,440,088,105 |
| Énergie sur le compte qui reçoit pour 100 TRX délégués | 958 unités, calculé | 7,376 unités, mesuré |
L'USDT de test est un autre contrat
Le code de paiement porte l'adresse du contrat USDT qu'il appelle. Le 27 octobre 2026, nous avons demandé à un nœud Nile le contrat à l'adresse USDT du réseau principal, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, et la réponse a été un objet vide, {} : aucun contrat à cette adresse sur le testnet. Les jetons de test de Nile viennent d'un autre contrat à une autre adresse : l'adresse du contrat a donc sa place dans la configuration à côté de l'URL du nœud, et une version qui la fixe en dur appellera la mauvaise adresse sur l'un des deux réseaux.
Nous n'avons pas mesuré ce que coûte en énergie un transfert d'un jeton de test de Nile. Nile facture les mêmes frais par unité, mais le jeton est un autre contrat : rien sur Nile ne confirme donc les chiffres du réseau principal d'environ 65,000 unités vers un détenteur et d'environ 131,000 unités vers une adresse sans USDT. Les TRX de test viennent de faucets, et ils les rationnent : celui que nous avons utilisé en septembre autorisait une requête par portefeuille et par IP toutes les 24 heures.
Une transaction signée reste aussi sur le réseau pour lequel elle a été construite. Toute transaction TRON porte une référence à un bloc récent de sa propre chaîne, et notre API vérifie cette référence auprès du réseau principal avant d'acheter la moindre énergie. Une transaction en mode B construite sur Nile est refusée avec un 400 et details.reason à ref_block_unknown. Quand la chaîne ne répond pas à notre vérification, la commande est acceptée sans contrôle et le refus du nœud après livraison est facturé : construisez donc chaque transaction sur le bloc courant du réseau principal avant de l'envoyer.
Ce que simule le bac à sable
Notre bac à sable répond à https://sandbox.nrg.market/v1 et fait tourner le même code que la production sur de l'argent de test, une chaîne simulée et des vendeurs d'énergie simulés. Les clés y commencent par nrg_test_ et viennent de l'espace client du bac à sable, où l'inscription est en libre-service. Les deux environnements ne partagent rien : bases de données, soldes, webhooks et secrets séparés. Quand l'intégration marche là-bas, vous changez l'URL de base et la clé ; le flux de l'API est le même sur les deux.
L'argent de test arrive sans faucet. Confirmer l'e-mail crédite un solde de départ, et POST /v1/sandbox/deposit en crédite davantage par le même chemin qu'un vrai dépôt : une ligne deposit dans les mouvements avec un txid qui commence par sandbox-, et un vrai webhook deposit.credited. En production, ce chemin n'existe pas et répond 404.
| Argent de test dans le bac à sable | Selon le contrat de l'API |
|---|---|
| À la confirmation de l'e-mail, ou à la première connexion Google | 10000 TRX |
Un appel à POST /v1/sandbox/deposit | jusqu'à 100000 TRX |
| Appels de dépôt par client et par jour UTC | 10 |
Un testnet ne produira pas une issue particulière sur demande. Le bac à sable câble quelques adresses sur un comportement fixe, à la manière des numéros de carte de test : des adresses TRON valides sans clé privée derrière. Le destinataire décide du type d'énergie et de ce qui se passe après ready ; l'expéditeur décide de la manière dont l'achat et la délégation se déroulent.
| Adresse | Rôle | Ce que fait le bac à sable |
|---|---|---|
TLLmUhBYgU125KkPpeTdP1vz1zqhoZwn9v | Destinataire | Ne détient aucun USDT, donc kind: double. Elle n'est pas non plus activée, et reste vide quel que soit le nombre de transferts qui y arrivent. |
TDUvBqzR3cYY6zYopYdJ9jWrxQRs9QmvQM | Destinataire | Aucun transfert n'apparaît jamais. L'élément attend à ready, passe à expired à send_before et est facturé, comme en production. |
TKLeQhXSUba1GG1wdznyMc49oqModZ8Fbm | Destinataire | Sur la liste noire USDT : la commande est refusée avec 422 blacklisted_recipient. |
TQ6ey8qT87bnzBJXj7gVTGCkrU4wUJ1EWQ | Expéditeur | L'achat échoue chez tous les vendeurs. L'élément finit en failed avec purchase_failed, et la réservation est libérée. |
TYWZsWdM9u8QKJTi6XEmenpvCPwg1xmPCC | Expéditeur | Le premier vendeur est indisponible et le basculement réussit. Rien dans la réponse ne le dit. |
TNhq25t5XTEuk3mC9cTcAGB5rr3xuCkGyr | Expéditeur | La délégation se confirme après environ 25 secondes, pour le code qui doit attendre. |
| Toute autre adresse valide | L'un ou l'autre | Un destinataire qui détient des USDT, et une délégation qui se confirme en 2 à 8 secondes. |
Les deux côtés se combinent : un lot qui mêle l'expéditeur en échec à des expéditeurs ordinaires finit donc en partially_completed sans rien demander de spécial (ce que ce statut veut dire pour la facture). Les expéditeurs de scénario sont partagés par tous les clients de l'environnement : quand c'est le timing qui est testé, utilisez une adresse d'expéditeur neuve à vous : elle reçoit les 2 à 8 secondes ordinaires, et ses délégations lui sont privées.
Les prix de l'environnement sont les prix réels. Le tarif du bac à sable suit celui de la production avec environ deux minutes de retard, trois au pire : une estimation répétée là-bas renvoie donc le prix que la production affichait deux ou trois minutes plus tôt. Le mode B n'a besoin d'aucune vraie clé : la chaîne simulée ne vérifie pas les signatures, si bien qu'une transaction signée par n'importe quelle clé jetable est analysée comme la production l'analyse et traverse broadcasting, broadcasted et confirmed, la diffusion se confirmant en environ trois secondes.
Ce que seul le réseau principal montre
Le bac à sable ne peut pas prouver la part qui revient à la chaîne : aucune énergie n'y arrive jamais réellement, et une délégation confirmée là-bas est un fait sur notre simulateur. Nile ne peut pas non plus le trancher pour notre service, parce que nous ne vendons d'énergie sur aucun testnet. C'est en production que vous apprenez si de l'énergie réelle arrive sur un vrai portefeuille, et si le transfert passe ensuite sans brûler de TRX.
Certaines branches ne peuvent être produites dans aucun des deux environnements par aucune requête : 503 capacity_unavailable, et les erreurs d'élément broadcast_failed, transaction_reverted et broadcast_window_missed. Chacune dépend de l'offre d'énergie, de la chaîne, ou de la mise en pause du service par nous. Écrivez cette gestion d'après le contrat et les corps de webhook, et relisez-la comme du code qui n'a jamais tourné.
Une bonne part de la production ne coûte rien à tester. POST /v1/estimate accepte jusqu'à 500 destinataires et renvoie les mêmes kind, energy_units et warnings qu'une commande calculerait, et POST /v1/webhooks/{webhook_id}/test envoie à votre récepteur une vraie livraison signée. POST /v1/orders coûte de vrais TRX dans tous les modes, ce qui fait d'une première commande réelle d'un seul transfert la dernière répétition et la seule qui montre l'énergie arriver.
Chaque adresse de scénario de cet article répond dans l'environnement, sur de l'argent de test et votre propre clé nrg_test_ : ouvrez l'espace client du bac à sable et délivrez-en une →