TRON API: USDT-TRC20-Zahlungen über REST

Tether hatte bis April 2026 etwa 190 Milliarden Dollar USDT ausgegeben. TRON trug etwa 45 % dieses Supplies, rund 85 Milliarden Dollar, mit Ethereum knapp dahinter bei etwa 40 %; die beiden Chains haben die Führung seit Ende 2025 mehrmals getauscht. Auf TRON selbst ist das Bild eindeutig: USDT machte 98,6 % des Stablecoin-Werts der Chain in Q1 2026 aus. Wer sagt, TRC-20 bedeutet USDT, für alle praktischen Zwecke.

Supply ist nur die halbe Geschichte. Transfer-Volumen sagt Ihnen, wofür eine Chain genutzt wird, und TRONs USDT-Volumen näherte sich im ersten Quartal 2026 2 Billionen Dollar. Ethereums USDT tendiert zu DeFi-Collateral und institutioneller Abwicklung. TRONs ist die Version, die Menschen tatsächlich bewegen: Börsen-Deposits, Überweisungen, Auszahlungen an Auftragnehmer in Ländern, wo ein Dollar-Guthaben das lokale Bankkonto schlägt.

Für eine Integrationsentscheidung ist die Konsequenz klar. Wählen Ihre Nutzer ein Deposit-Netzwerk aus einem Dropdown, wird TRC-20 der meistgewählte Eintrag sein, und Support-Tickets wegen falscher Netzwerke sinken, wenn Ihr Standard dem entspricht, was Nutzer erwarten. Bauen Sie TRON zuerst; das geteilte Request-Schema erlaubt Ihnen, die anderen Chains später ohne neuen Code hinzuzufügen.

TRON misst zwei Ressourcen. Bandwidth deckt schlichte Transfers ab und ist bis zu 600 Punkten am Tag kostenlos. Energy hat kein kostenloses Kontingent und greift, wann immer ein Smart Contract läuft, weshalb ein USDT-Transfer, ein TRC-20-Contract-Aufruf, immer mehr kostet als reines TRX zu senden.

TRON hat keinen einzelnen Gas-Preis. Das Netzwerk misst zwei separate Ressourcen, und zu wissen, welche Ihre Transaktion verbraucht, ist der Unterschied zwischen vorhersehbaren Gebühren und überraschenden Support-Tickets.

Bandwidth wird bei jeder Transaktion berechnet und folgt der Byte-Größe. Jedes Konto bekommt 600 kostenlose Punkte am Tag; ein reiner TRX-Transfer wiegt 250 bis 300 Bytes, sodass gelegentliche TRX-Transfers gar nichts kosten. Jenseits des kostenlosen Kontingents verbrennt das Netzwerk 0,001 TRX pro Punkt, rund 0,35 TRX für einen typischen TRC-20-Transfer.

Energy greift nur, wenn ein Smart Contract läuft, und hat kein tägliches Freikontingent. Ein USDT-Transfer ist ein Contract-Aufruf, der TRC-20-Contract aktualisiert seine interne Guthabentabelle, braucht also Energy zusätzlich zu Bandwidth. Seit Governance-Proposal #104 im August 2025 in Kraft trat, kostet eine Energy-Einheit 100 Sun, halbiert von 210. Ein Transfer an eine Adresse, die bereits USDT hält, braucht etwa 64.000 Energy, was 6,4 TRX entspricht. Ein Transfer an eine Adresse, die nie USDT gehalten hat, schreibt einen neuen Storage-Eintrag, und neuer State kostet etwa doppelt so viel Energy wie ein Update: rund 134.000 Einheiten, oder 13,4 TRX.

Vor dem Senden machen zwei Tools die Zahlen greifbar. Der TRON-Fee-Calculator berechnet Bandwidth, Energy und die TRX-Gesamtsumme für eine bestimmte Transaktion, und GET /api/v2/tron/chainparameters gibt die Live-Einheitenpreise zurück, sodass Ihr Code nie eine Konstante einbrennt, die die nächste Governance-Abstimmung ändert. Der Fee-Guide behandelt die Mechanik ausführlich.

Jeder TRC-20-Transfer braucht Energy, und die Energy muss irgendwoher kommen. Für die meisten Sender ist die Quelle das eigene TRX-Guthaben. Diese Annahme bricht in zwei häufigen Situationen, und beide erzeugen operativen Schmerz, bis Sie sie strukturell fixen.

Ihre eigene Deposit-Wallet-Flotte

Jede Wallet, die Gelder an eine Hot Wallet weiterleitet, braucht ihr eigenes TRX-Guthaben für den Sweep, und mit ein paar Tausend Wallets wird das Auffüllen zu einem eigenen Job, komplett mit eigenen Fee-Kosten für die Top-up-Transfers. Gesponserte Gebühren beseitigen diesen Job. Der empfohlene Weg dafür heute ist TronFuel, das Energy gebündelt von Stakern mietet – derselbe Mechanismus, den der Fee-Guide als bis zu 60 % Fee-Kosten-Reduktion gegenüber dem Verbrennen von TRX zum Marktpreis beschreibt. Chaingateways Legacy-Paymaster-Endpoints tun dasselbe und bleiben für bestehende Integrationen verfügbar.

Ihre Endkunden

Ein Nutzer hält 200 USDT in einer Self-Custody-Wallet und null TRX; das USDT kam von einer Börse oder von einer anderen Person, und niemand hat ihm gesagt, dass eine zweite Währung nötig ist, um es zu bewegen. Versucht er, Sie zu bezahlen oder abzuheben, scheitert der Transfer. Aus Sicht des Nutzers ist das Geld gefangen. Aus Sicht Ihrer Support-Warteschlange ist es ein wiederkehrendes Ticket, das kein FAQ-Eintrag vollständig entschärft, weil die Lösung, „kauf erst etwas TRX auf einer Börse“, genau die Reibung ist, die der Kunde mit Stablecoins vermeiden wollte. Ein gesponserter Transfer beendet das: Sie reichen den Transfer ein, der Sponsor deckt Energy und Bandwidth, die Kosten landen auf Ihrem Konto, und der Kunde erfährt nie, was TRX ist. Für Checkout- und Abhebungs-Flows entfernt diese eine Änderung den häufigsten Fehlermodus von TRC-20-Zahlungen.

Einen gesponserten Transfer bepreisen und erstellen

Bepreisen Sie eine gesponserte Transaktion zuerst, erstellen Sie sie dann:

# 1. Gebühr schätzen
curl -X POST https://app.chaingateway.io/api/v2/tron/paymaster/estimate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRC20", "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TDepositWallet", "to": "THotWallet", "amount": "500"}'

# 2. Paymaster-Anfrage erstellen
curl -X POST https://app.chaingateway.io/api/v2/tron/paymaster \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRC20", "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TDepositWallet", "to": "THotWallet", "amount": "500", "password": "YourWalletPassword"}'

GET /api/v2/tron/paymaster listet jede Anfrage, die Sie erstellt haben, und meldet ihren Status von pending bis completed oder failed, und GET /api/v2/tron/paymaster/balance zeigt das übrige Sponsoring-Guthaben – zusammen decken sie den Abgleich ab.

Einen Private Key zu importieren ist der schnellste Weg zur Produktion, aber manche Teams können Key-Material überhaupt nicht an einen Dritten schicken. Der Grund kann eine interne Policy sein, ein Regulator, oder ein Hardware Security Module, dessen Keys physisch nicht exportiert werden können. Die TRON API hat einen zweiten Modus, gebaut genau für diese Einschränkung.

Der Flow hat drei Schritte. Rufen Sie POST /api/v2/tron/transactions/trc20/build auf, oder /api/v2/tron/transactions/build für reines TRX, mit denselben Feldern, die Sie für einen normalen Send nutzen würden. Die API gibt die unsignierte Roh-Transaktion zurück. Signieren Sie dieses Payload, wo auch immer Ihre Keys leben: ein HSM, eine Air-Gapped-Maschine, ein Signing-Service hinter Ihrer eigenen Firewall. Reichen Sie dann das signierte Ergebnis über POST /api/v2/tron/transactions/broadcast ein, was es ans Netzwerk schiebt und den Transaktions-Hash zurückgibt.

# 1. Die unsignierte Transaktion bauen
curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/trc20/build \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TColdWallet", "to": "TRecipient", "amount": 1000}'

# 2. Lokal mit eigenem Tooling signieren, dann broadcasten
curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/broadcast \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"signed_transaction": "<die signierte Transaktion als JSON-String>"}'

Zwei Dinge, bevor Sie diesen Modus wählen. Eine gebaute TRON-Transaktion läuft nach einem kurzen Fenster ab, der Sign-and-Broadcast-Schritt muss also zügig passieren statt über Nacht in einer Queue zu liegen. Und die operative Verantwortung verschiebt sich: Ihre Seite besitzt die Signing-Bibliothek und ihre Updates. Was Sie gewinnen, ist, dass Chaingateway nie ein Secret sieht. Deposit-Monitoring bleibt in beiden Fällen unberührt, da das Beobachten einer Adresse keinen Key braucht. Viele Produktions-Setups mischen beide Modi, importierte Keys für Betriebs-Wallets mit geringem Wert, Self-Signing für den Treasury-Pfad.

Einen Explorer nach eingehenden Transfers zu pollen verschwendet Requests und trifft das Timing trotzdem falsch. Chaingateway pusht stattdessen. Registrieren Sie einen Webhook, und Ihr Backend erhält ein POST für Transaktionsstatus, Bestätigungen und Guthabenänderungen. Setzen Sie ein persönliches Secret in Ihrem Konto, und jede Zustellung trägt einen X-Signature-Header – ein base64-kodiertes HMAC-SHA256 der txid des Payloads –, sodass Sie den Absender verifizieren können. Fehlgeschlagene Zustellungen landen in einer Failed-Notifications-Liste, und POST /api/v2/tron/webhooks/notifications/{id}/retry sendet jede erneut.

GET /api/v2/tron/webhooks/notifications gibt vergangene Benachrichtigungen zurück, praktisch, um Events nach einem schlechten Deploy erneut abzuspielen. Das Setup dauert wenige Minuten mit dem Webhook-Guide.

Sender mit hohem Volumen sollten TRX nicht auf ewig verbrennen. Frieren Sie TRX über POST /api/v2/tron/freeze ein, und das Netzwerk gewährt im Gegenzug Bandwidth oder Energy; routen Sie diese Ressourcen mit POST /api/v2/tron/delegate zu Ihrer Hot Wallet. Unfreeze und Undelegate kehren beide Schritte um, wenn Sie das Kapital zurückwollen.

Aktuelle Ressourcenpreise kommen von GET /api/v2/tron/chainparameters. Seit Proposal #104 liegt der Energy-Einheitenpreis bei 100 Sun, runter von 210, was den Break-even-Punkt zwischen Staken und Verbrennen verändert hat. Prüfen Sie den Live-Wert, bevor Sie einen Stake dimensionieren.

Die Rechnung begünstigt Staking mit wachsendem Volumen, weil verbranntes TRX weg ist, während gestaktes TRX nur geparkt ist. Als grober Wert Mitte 2026 generierte ein Stake in der Größenordnung von 5.000 TRX etwa die Energy für einen USDT-Transfer pro Tag. Ein Geschäft mit 50 Transfers am Tag bräuchte einen Stake in den niedrigen Hunderttausenden TRX, um seine Energy vollständig aus dem Staken zu decken. Behandeln Sie das als Größenordnungen statt als Angebot: Ihr täglicher Ertrag hängt davon ab, wie viel TRX das gesamte Netzwerk gestakt hat, und dieses Verhältnis driftet. Der Fee-Calculator und der Chain-Parameters-Endpoint geben Ihnen die heutigen Eingaben für die Rechnung.

Delegation macht Staking operativ sauber. Halten Sie den Stake auf einer Treasury-Adresse, die nie Kundenverkehr berührt, und delegaten Sie ihre Energy dann an die Hot Wallets, die die tatsächlichen Sends erledigen. Wird eine Wallet stillgelegt, undelegaten Sie und richten die Ressourcen auf ihren Nachfolger; das gestakte TRX selbst bewegt sich nie. Ein Vorbehalt für die Treasury-Planung: Nach dem Unfreeze bleibt TRX für eine Wartezeit von rund zwei Wochen gesperrt, bevor es wieder ausgebbar ist, ein Stake ist also keine Reserve mit sofortigem Zugriff. Dimensionieren Sie ihn nach dem Steady-State-Volumen und decken Sie Spitzen stattdessen mit gemieteter Energy ab.

Chaingateway unterstützt die Standard-Token-Typen auf TRON. USDT, USDC und DAI funktionieren sofort mit automatischer Dezimalstellen-Handhabung. Für ein selbst gelauchtes Token übergeben Sie dessen Contract-Adresse, und die API behandelt es wie jedes andere TRC-20. Das Request-Schema wird über Chains hinweg geteilt, sodass der ERC-20-Aufruf auf Ethereum, BNB Smart Chain, Polygon oder Arbitrum exakt wie Ihr TRC-20-Aufruf aussieht, mit einem anderen Pfadsegment.

Das Netzwerk ist auf etwa 2.000 Transaktionen pro Sekunde ausgelegt, was für Zahlungs-Workloads aus vielen kleinen Transfers passt. Gebühren bleiben niedrig genug, dass Mikrozahlungen tragfähig bleiben, wenige TRX pro Token-Transfer statt einer Gebühr, die die Zahlung auffrisst. TRON hält einen größeren Anteil am zirkulierenden USDT als jede andere Chain, sodass die Gegenparteien Ihrer Nutzer bereits dort sind, und das Wallet-Ökosystem rund um TRC-20 ist reif genug, dass Tooling selten im Weg steht.

Typische Integrationen sehen so aus: ein Checkout-Flow, der USDT annimmt und die Bestellung nach Bestätigung gutschreibt; ein Börsen-Backend, das Tausende Deposit-Adressen beobachtet und Abhebungen aus einer Hot Wallet verarbeitet; Auszahlungssysteme, die Airdrops oder Vesting-Pläne fahren; Abo-Abrechnung, die jeden Monat in Stablecoins abrechnet; Remittance-Dienste, die Wert innerhalb von Minuten über Grenzen hinweg bewegen. Dieselbe API deckt jedes Muster ab. Was sich ändert, ist, welche Endpoints Sie kombinieren.

Jeder Endpoint auf dieser Seite akzeptiert den Header X-Network: testnet. Damit läuft der identische Request gegen das TRON-Testnet: gleiche Pfade, gleiche Payloads, gleiche Response-Formen. Test-TRX kommt kostenlos von öffentlichen Faucets, eine komplette Probe kostet also nichts – eine Deposit-Adresse erstellen, einen TRC-20-Transfer daran senden, den Webhook empfangen, die HMAC-Signatur verifizieren, in eine Hot Wallet fegen.

Proben Sie den Webhook-Pfad mindestens einmal Ende zu Ende. Die klassischen Integrationsfehler, eine Signaturprüfung gegen die falsche Payload-Kodierung oder eine Firewall, die die Zustellung still verwirft, treten auf Testnet exakt so auf wie in Produktion, wo sie echte Deposits statt Test-Token kosten. Live gehen bedeutet danach, einen Header zu löschen; der Quickstart zeigt den ganzen Zyklus.

Zwei Fehlerklassen wollen entgegengesetzte Behandlung. Eine 4xx-Antwort bedeutet, dass der Request selbst falsch ist: ein fehlender oder abgelaufener Bearer-Token, eine fehlerhafte Adresse, ein Betrag, den die sendende Wallet nicht deckt. Loggen Sie ihn und beheben Sie die Ursache, aber wiederholen Sie ihn nicht unverändert, weil identischer Input identische Ablehnung produziert. Eine 5xx-Antwort oder ein Netzwerk-Timeout sagt nichts über Ihren Input aus; wiederholen Sie diese mit exponentiellem Backoff und einer Obergrenze.

Der Randfall, für den es sich zu konstruieren lohnt, ist der Timeout nach einem Send. Ihr HTTP-Client hat aufgegeben, doch die Transaktion könnte trotzdem broadcastet worden sein. Denselben Transfer reflexartig erneut zu feuern, ist, wie doppelte Auszahlungen passieren. Prüfen Sie zuerst, was tatsächlich rausging: GET /api/v2/tron/transactions listet die über Ihr Konto erstellten Transfers. Senden Sie nur erneut, wenn der erste Versuch nachweislich fehlschlug. Für Fee-bezogene Fehlschläge gibt es ein noch günstigeres Muster: Prüfen Sie GET /api/v2/tron/chainparameters und die Ressourcen der Wallet vor dem Senden, und verwandeln Sie so einen Laufzeitfehler in einen Preflight-Check.