Questions et réponses
Ce que les intégrateurs demandent avant la première commande, par groupes et en bref. Là où la réponse relève du contrat et non d'une habitude, la documentation de l'API dit la même chose en détail.
Énergie et prix
Qu'est-ce que l'énergie TRON ?
Une ressource du réseau qui paie l'exécution des smart contracts. Avec assez d'énergie sur le portefeuille émetteur, un transfert USDT ne brûle presque aucun TRX.
Pourquoi est-ce moins cher que la combustion ?
Brûler valorise l'énergie au tarif du protocole, ~100 sun l'unité — un paramètre de la chaîne que le réseau révise de temps à autre ; il l'a abaissé cette année. Nous obtenons de l'énergie déléguée en volume et la vendons à une fraction de ce tarif ; le prix en vigueur en ce moment est sur la page des tarifs.
Voir tous les prix →
Et si je rate la fenêtre d'envoi ?
En mode A le débit reste : l'énergie a été livrée, et c'est la livraison que vous payez. En mode B nous n'émettons plus rien une fois la fenêtre fermée, la position échoue donc et la réservation revient entière. La fenêtre arrive avec chaque commande — construisez votre flux autour d'elle.
Puis-je acheter de l'énergie en volume pour un seul portefeuille ?
De 65,000 à 50,000,000 unités d'énergie par portefeuille en une seule commande, au tarif unitaire en vigueur au moment où la commande est créée. Une position par portefeuille, et la part de ce volume que le marché peut fournir à l'instant se demande librement avec POST /v1/estimate avant toute réservation.
Au-delà de 131,000 unités, la location doit durer une heure ou plus. Le caractère tout-ou-rien de la commande est décidé avant le premier achat (allow_partial) ; un manque après le premier achat est livré et facturé pour ce qui a été livré.
L'énergie en volume sur la page des tarifs →
Rater la fenêtre d'envoi coûte-t-il la même chose dans les deux modes ?
Non. En mode A l'énergie a été livrée, donc le débit reste — et en mode C aussi, où il n'y a aucun transfert à attendre et où la position expire simplement à la fermeture de la fenêtre. En mode B nous n'émettons plus rien une fois la fenêtre fermée : un transfert parti en retard trouverait un portefeuille dont l'énergie déléguée est déjà repartie, et brûlerait votre TRX. La position se ferme en failed avec broadcast_window_missed, la réservation revient entière, et l'énergie achetée pour elle est notre perte.
Argent et remboursements
Comment est-ce que je paie ?
Des crédits de service prépayés, libellés en TRX : envoyez des TRX à votre adresse personnelle, dépensez-les en services. Les prix sont figés à la création de la commande.
Quel jeton puis-je envoyer à mon adresse de dépôt ?
Des TRX, et rien d'autre. L'USDT envoyé à une adresse de dépôt n'est pas crédité automatiquement : nous ne prenons aucun risque de change et n'exploitons aucun service de conversion, alors il est mis de côté pour qu'une personne le regarde, et le créditer est notre décision, au cas par cas. Vous avez envoyé le mauvais jeton ? Écrivez-nous, et n'en envoyez pas davantage.
Au bout de combien de temps un dépôt est-il dépensable ?
Après 3 confirmations — une dizaine de secondes. Le solde est ensuite donné en trois parts : le total, ce qui est réservé pour les commandes en cours, et ce qui est disponible. Une commande se crée sur la part disponible, jamais sur le total.
Puis-je annuler une commande ?
Seulement avant le début de l'achat ; après, la réponse est order_not_cancelable, parce que l'énergie est déjà achetée. Une commande annulée libère toute sa réservation et ne débite rien.
Et les remboursements ?
Les libérations sont automatiques et ne demandent jamais de ticket. La règle est unique : l'énergie que nous n'avons pas livrée n'est pas facturée, et la réservation revient sur votre solde en crédits de service — une livraison échouée, une commande annulée avant le début de l'achat, la part non dépensée d'une journée d'Auto-refill. L'énergie livrée est facturée, utilisée ou non. Une exception : supprimer une règle Auto-refill avant que ses recharges aient couvert ce que nous avons payé d'avance à notre fournisseur pour son portefeuille fait facturer la part non couverte.
Sécurité et clés
De quelles clés avez-vous besoin ?
D'aucune. Le mode A ne voit jamais votre transaction. Le mode B en prend une que vous avez déjà signée, et nous ne pouvons pas en changer un octet.
Acceptez-vous un expéditeur en multisignature ?
En mode B, non : la transaction doit porter exactement une signature du propriétaire, avec Permission_id 0. Le jeu de clés d'un compte multisignature vit sur le réseau et change à notre insu, donc nous ne pouvons pas promettre que l'émission passera. En mode A, rien de votre façon de signer ne nous parvient : le transfert, c'est vous qui l'émettez.
Que conservez-vous, et pendant combien de temps ?
En mode B votre transaction signée est gardée chiffrée et effacée 7 jours après que la commande a atteint un statut final. Les commandes, les écritures du registre et les dépôts restent : c'est de la comptabilité, et c'est ce que nous sommes tenus de garder. Rien d'autre de vous n'est ici — ni clés privées, ni phrases de récupération, ni garde de vos fonds.
Intégration
Y a-t-il des limites ?
120 commandes par minute et par clé, jusqu'à 500 transferts par commande groupée. Au-delà, vous recevez un Retry-After, pas un rejet silencieux.
Que veut dire completed, au juste ?
Que l'énergie a été livrée — pas que votre transfert est parti. L'engagement, c'est la livraison, et la commande se ferme dessus : en mode A, completed peut arriver avant que vous ayez envoyé quoi que ce soit. Guettez l'apparition de send_before sur la commande plutôt que le mot ready : en interrogeant toutes les deux secondes, vous pouvez ne jamais voir ready.
Comment fonctionne l'idempotence ?
Une Idempotency-Key est liée aux octets bruts du corps avec lequel elle est arrivée. La même clé et un corps identique octet pour octet vous rendent la même commande ; la même clé avec un autre corps est un conflit ; une requête refusée par la validation ne consomme pas la clé, vous pouvez donc la rejouer avec la même clé une fois le corps corrigé. Sérialisez le corps une seule fois et renvoyez exactement ces octets : un autre ordre de clés ou une espace en trop, c'est déjà un autre corps.
Puis-je vérifier une adresse sans rien payer ?
Oui, et c'est gratuit. GET /v1/address-check dit ce que nous savons d'un portefeuille, et POST /v1/estimate chiffre jusqu'à 500 destinataires selon les règles qu'appliquerait une commande — y compris lesquels d'entre eux sont sur la liste noire du contrat du jeton. Ni l'un ni l'autre ne réserve quoi que ce soit ni ne débite quoi que ce soit.
Votre compte
Un portefeuille peut-il rester approvisionné tout seul ?
Oui — une règle Auto-refill : une adresse plus un budget quotidien. L'énergie se recharge après chaque transfert ; le budget est un plafond quotidien ferme.
À combien régler balance.low ?
Le nombre est un réglage à vous — balance_low_threshold_trx dans PATCH /v1/settings ; balance.low est l'événement qu'il déclenche. La bonne mesure est à peu près votre volume d'une journée : l'alerte arrive alors un jour avant que les commandes ne commencent à recevoir insufficient_balance, au lieu d'arriver à la place du premier refus. Nettement plus bas, l'événement devient un constat après coup ; nettement plus haut, du bruit. Zéro le coupe.
Mon équipe d'exploitation peut-elle avoir un accès en lecture seule ?
Oui. Un compte accueille autant de personnes que vous en invitez, chacune avec l'un des quatre rôles — viewer, member, admin, owner — et chaque rôle fait tout ce que fait le précédent. Un viewer lit le solde, le grand livre, les commandes et le tarif, et ne peut rien dépenser ; un member crée des commandes et des estimations ; un admin gère les clés API, les webhooks, les réglages et l'équipe ; l'owner est le compte lui-même. Une invitation accorde viewer, member ou admin ; l'owner est le compte et n'est pas invité. Les invitations et les rôles vivent dans le tableau de bord, et ne régissent que lui : une clé API appartient au compte, pas à une personne, et porte l'accès complet quel que soit qui l'a créée.
Y a-t-il un bac à sable, ou un volume minimum ?
Pas de volume minimum, pas d'abonnement, rien à payer pour l'inactivité. Un bac à sable existe : https://sandbox.nrg.market/v1 est la même API sur de l'argent de test et un réseau simulé, et sandbox-app.nrg.market délivre les clés nrg_test_… correspondantes. Il prouve votre côté de l'intégration — formats de requête, statuts, webhooks, délais — mais pas que l'énergie arrive on-chain ; cela ne s'apprend qu'en production. Sur l'hôte de production, les endpoints de consultation, une estimation et un test de webhook ne coûtent toujours rien.
https://sandbox.nrg.market/v1
sandbox-app.nrg.market