Blog · 9. November 2026

USDT-Auszahlungen vor dem Mainnet testen: was Nile ändert und was eine Sandbox simuliert

Eine Auszahlungsintegration sollte ihren ersten Fehlschlag an einem Ort erleben, der billiger ist als das Mainnet, und auf TRON gibt es zwei solche Orte. Nile ist ein öffentliches Testnetz: eine echte Kette, auf der Transaktionen signiert werden und in Blöcken landen, mit eigenen Parametern. Eine Sandbox wie unsere kopiert die API über eine simulierte Kette, was das echte Netz aufgibt und die Ergebnisse gewinnt, die ein echtes Netz auf Anforderung nicht liefert. Wir haben die Kettenparameter von Mainnet und Nile am 3. September 2026 gelesen und am Tag darauf Transaktionen auf Nile signiert.

Was Nile mit dem Mainnet gemeinsam hat

Nile beantwortet denselben Aufruf getchainparameters wie das Mainnet, und die Parameter, die einen Transfer bepreisen, kamen identisch zurück. Energie kostet in beiden Netzen 100 sun je Einheit, ein Transfer, dem die Energie ausgeht, verbrennt TRX also in beiden zum selben Satz. Freie Bandbreite, die Gebühr für das Anlegen eines Kontos, die Memo-Gebühr und die drei Parameter der dynamischen Energie stimmen ebenfalls überein.

Was Nile ändert

Für jeden, der mit Energie umgeht, ist der erste Unterschied das Unstaken: Es dauert auf Nile einen Tag gegen vierzehn im Mainnet, ein Test, der TRX einfriert und dann abhebt, ist also dreizehn Tage früher fertig als dieselbe Abfolge in der Produktion. Die längste Sperre, die eine Delegation tragen kann, beträgt auf Nile 144,000 Blöcke, fünf Tage bei drei Sekunden je Block, gegen 864,000 Blöcke, dreißig Tage, im Mainnet. Eine Sperre von mehr als fünf Tagen lässt sich auf Nile überhaupt nicht proben; was eine Sperre verweigert ist in beiden Netzen gleich.

Acht der Parameter, die das Mainnet zurückgab, tragen auf Nile einen anderen Wert. Außer jenen zwei sind es das Wartungsintervall, die CPU-Obergrenze in der Tabelle und vier, die Blockproduzenten, Vorschläge und Vertragsfunktionen regeln. Wir haben keinen dieser sechs in einen Auszahlungsablauf zurückverfolgt.

Staken liefert auch eine andere Energiemenge, weil jedes Netz dasselbe Energielimit auf seinen eigenen Gesamtstake aufteilt und der Stake von Nile weit kleiner ist. In beiden unserer Läufe auf Nile am 4. September erschien der Stake, den wir delegierten, auf dem empfangenden Konto als 7,376 Einheiten Energie. Derselbe Stake im Mainnet kommt beim Gesamtwert, der einen Tag früher gelesen wurde, auf 958 Einheiten, Nile gibt also fast achtmal so viel aus. Ein gegen Nile bemessener Stake ließe eine Mainnet-Wallet zu kurz kommen.

Test-USDT ist ein anderer Vertrag

Auszahlungscode trägt die Adresse des USDT-Vertrags, den er aufruft. Am 27. Oktober 2026 haben wir eine Nile-Node nach dem Vertrag an der Mainnet-USDT-Adresse TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t gefragt, und die Antwort war ein leeres Objekt, {}: kein Vertrag an dieser Adresse im Testnetz. Test-Tokens auf Nile stammen aus einem anderen Vertrag an einer anderen Adresse, die Vertragsadresse gehört also in die Konfiguration neben die Node-URL, und ein Build, der sie fest einkodiert, ruft in einem der beiden Netze die falsche Adresse auf.

Wir haben nicht gemessen, was ein Transfer eines Nile-Test-Tokens an Energie kostet. Nile berechnet dieselbe Gebühr je Einheit, aber das Token ist ein anderer Vertrag, nichts auf Nile bestätigt also die Mainnet-Zahlen von rund 65,000 Einheiten an einen Halter und rund 131,000 Einheiten an eine Adresse ohne USDT. Test-TRX kommt aus Faucets, und sie rationieren es: Der Faucet, den wir im September genutzt haben, erlaubte eine Anfrage je Wallet und je IP alle 24 Stunden.

Eine signierte Transaktion bleibt außerdem in dem Netz, für das sie gebaut wurde. Jede TRON-Transaktion trägt einen Verweis auf einen jüngeren Block ihrer eigenen Kette, und unsere API prüft diesen Verweis gegen das Mainnet, bevor sie Energie kauft. Eine Transaktion für mode B, die gegen Nile gebaut wurde, wird mit einem 400 und details.reason auf ref_block_unknown abgelehnt. Antwortet die Kette auf unsere Prüfung nicht, wird die Bestellung ungeprüft angenommen und die Ablehnung der Node nach der Lieferung berechnet, bauen Sie also jede Transaktion gegen den aktuellen Mainnet-Block, bevor Sie sie senden.

Was die Sandbox simuliert

Unsere Sandbox antwortet unter https://sandbox.nrg.market/v1 und führt denselben Code wie die Produktion aus, über Testgeld, eine simulierte Kette und simulierte Energieverkäufer. Schlüssel dort beginnen mit nrg_test_ und kommen aus dem Sandbox-Dashboard, wo man sich selbst registriert. Die beiden Umgebungen teilen nichts: getrennte Datenbanken, Guthaben, Webhooks und Secrets. Funktioniert die Integration dort, ändern Sie die Basis-URL und den Schlüssel; der API-Ablauf ist in beiden derselbe.

Testgeld kommt ohne Faucet an. Die Bestätigung der E-Mail schreibt ein Startguthaben gut, und POST /v1/sandbox/deposit schreibt mehr gut, auf demselben Weg, den eine echte Einzahlung nimmt: eine deposit-Zeile in den Kontobewegungen mit einer txid, die mit sandbox- beginnt, und ein echter Webhook deposit.credited. In der Produktion existiert dieser Weg nicht und antwortet mit 404.

Ein Testnetz erzeugt auf Anforderung kein bestimmtes Ergebnis. Die Sandbox verdrahtet einige Adressen mit festem Verhalten, so wie Testkartennummern funktionieren: gültige TRON-Adressen ohne privaten Schlüssel dahinter. Der Empfänger bestimmt die Energieart und was nach ready geschieht; der Absender bestimmt, wie der Kauf und die Delegation ablaufen.

Die beiden Seiten kombinieren sich, ein Stapel, der den scheiternden Absender mit gewöhnlichen mischt, endet also als partially_completed, ohne dass etwas Besonderes verlangt wurde (was dieser Status für die Rechnung bedeutet). Die Szenario-Absender werden von jedem Kunden der Umgebung geteilt, wenn also das Timing das Testobjekt ist, nehmen Sie eine frische eigene Absenderadresse: Sie bekommt die gewöhnlichen 2 bis 8 Sekunden, und ihre Delegationen sind privat.

Die Preise in der Umgebung sind die Live-Preise. Der Sandbox-Tarif folgt dem der Produktion mit etwa zwei Minuten Abstand, im schlimmsten Fall drei, eine dort geprobte Schätzung liefert also den Preis, den die Produktion zwei oder drei Minuten früher nannte. Mode B braucht keinen echten Schlüssel: Die simulierte Kette prüft keine Signaturen, eine mit einem beliebigen Wegwerfschlüssel signierte Transaktion wird also so geparst, wie die Produktion sie parst, und durchläuft broadcasting, broadcasted und confirmed, wobei sich die Übertragung in etwa drei Sekunden bestätigt.

Was nur das Mainnet zeigt

Die Sandbox kann den Teil nicht beweisen, den die Kette erledigt: Auf ihr kommt Energie nie wirklich irgendwo an, und eine dort bestätigte Delegation ist eine Tatsache über unseren Simulator. Auch Nile kann es für unseren Dienst nicht klären, weil wir auf keinem Testnetz Energie verkaufen. Ob echte Energie auf einer echten Wallet landet und ob der Transfer dann ohne Verbrennen von TRX durchgeht, erfahren Sie in der Produktion.

Einige Zweige lassen sich in keiner der beiden Umgebungen durch irgendeine Anfrage erzeugen: 503 capacity_unavailable und die Positionsfehler broadcast_failed, transaction_reverted und broadcast_window_missed. Jeder hängt vom Energieangebot ab, von der Kette oder davon, dass der Dienst von uns pausiert wird. Schreiben Sie diese Behandlung nach dem Vertrag und den Webhook-Bodys, und prüfen Sie sie als Code, der nie gelaufen ist.

Ein guter Teil der Produktion kostet nichts beim Üben. POST /v1/estimate nimmt bis zu 500 Empfänger und liefert dieselben kind, energy_units und warnings, die eine Bestellung berechnen würde, und POST /v1/webhooks/{webhook_id}/test schickt Ihrem Empfänger eine echte signierte Zustellung. POST /v1/orders kostet in jedem Modus echtes TRX, was eine erste Live-Bestellung mit einem Transfer zur letzten Probe macht und zur einzigen, die das Eintreffen der Energie zeigt.

Jede Szenario-Adresse in diesem Beitrag antwortet in der Umgebung, über Testgeld und Ihren eigenen nrg_test_-Schlüssel: öffnen Sie das Sandbox-Dashboard und stellen Sie einen aus →