Was ist eine TRC20-Adresse?

Eine TRC20-Adresse ist eine TRON-Kontoadresse, die zum Senden und Empfangen von TRC20-Token verwendet wird, allen voran USDT. Sie beginnt mit dem Buchstaben T und ist 34 Zeichen lang, zum Beispiel TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. Strenggenommen gibt es keinen eigenen „TRC20-Adresstyp”: Jede TRON-Adresse kann TRX, TRC10-Token und TRC20-Token gleichermaßen halten. Wenn eine Exchange nach Ihrer „USDT-TRC20-Adresse” fragt, ist damit Ihre normale TRON-Adresse gemeint.

Das Format sieht den 0x-Adressen, die Sie von Ethereum oder BSC kennen, überhaupt nicht ähnlich, und TRON fügt eine Besonderheit hinzu, die Entwickler mehr verwirrt als alles andere: Dieselbe Adresse hat eine zweite, hexadezimale Schreibweise, die mit 41 beginnt. Dieser Guide führt durch die Kodierung, die Hex-vs-Base58-Frage, den Unterschied zwischen Wallet- und Contract-Adressen, Validierungscode und wie Sie TRON-Adressen im großen Stil per API erstellen.

Das Format: T plus 33 Zeichen, Base58Check

Eine TRON-Adresse ist in ihrer menschenlesbaren Form Base58Check-kodiert. Base58 ist dasselbe Alphabet, das auch Bitcoin verwendet: alle Ziffern und Buchstaben außer 0, O, I und l, die weggelassen wurden, weil sie im Druck leicht zu verwechseln sind. Eine gültige TRON-Adresse:

• beginnt mit T
• ist exakt 34 Zeichen lang
• enthält nur Zeichen aus dem Base58-Alphabet

Der Teil „Check” bedeutet, dass die Kodierung eine eingebaute Prüfsumme trägt. Unter der Base58-Oberfläche besteht eine Adresse aus 25 Bytes: einem Präfix-Byte 0x41, einer 20-Byte-Kontokennung und 4 Prüfsummen-Bytes. Ein einziges falsch getipptes Zeichen bricht die Prüfsumme, sodass eine Wallet den Tippfehler ablehnen kann, bevor eine Transaktion signiert wird. Das ist wichtig, denn anders als bei Ethereums optionaler EIP-55-Groß-/Kleinschreibung ist die Prüfsumme in einer TRON-Adresse nicht optional. Jede gültige Adresse hat eine.

TRC-20 vs. ERC-20 vs. BEP-20 im Vergleich

USDT allein existiert auf allen drei Netzwerken, sodass die Formate täglich in Auszahlungsformularen und Support-Tickets aufeinandertreffen. Was sie unterscheidet, mit Zahlen Stand Mitte 2026:

Die mittleren Zeilen erklären, warum dieser Artikel ständig vor EVM-Chains warnt statt vor TRON selbst. Eine ERC-20- und eine BEP-20-Adresse sind derselbe String, sodass nichts in der Adresse Sender oder Validator verrät, welche Chain gemeint ist; eine TRON-Adresse kann nie mit einer von beiden verwechselt werden. Der Fehler, den TRON-Nutzer tatsächlich machen, liegt in den Gebühren- und Netzwerkzeilen: das falsche Netzwerk in einem Exchange-Dropdown auszuwählen oder zu unterschätzen, was das Weiterleiten von Einzahlungen kostet.

Die Timing-Zeilen verdienen einen Zeitstempel. BSC erreichte seine 0,45-Sekunden-Blockzeit mit dem Fermi-Hard-Fork im Januar 2026, die zweite Blockzeit-Kürzung innerhalb eines Jahres, während TRON seit dem Start alle 3 Sekunden einen Block produziert und Ethereum seit dem Wechsel zu Proof of Stake 12-Sekunden-Slots hält. TRONs Finalitätsfenster von 19 Blocks, etwa 57 Sekunden, ist das, was die meisten Exchanges abwarten, bevor sie eine TRC20-Einzahlung gutschreiben, weshalb „gesendet” und „gutgeschrieben” auch dann eine Minute auseinanderliegen, wenn alles funktioniert.

Wie eine TRON-Adresse abgeleitet wird

Die Ableitung ist näher an Ethereum, als das Aussehen des Ergebnisses vermuten lässt:

1. Erzeugen Sie einen privaten Schlüssel auf der secp256k1-Kurve, derselben Kurve, die auch Bitcoin und Ethereum verwenden.
2. Berechnen Sie den öffentlichen Schlüssel und hashen Sie ihn mit Keccak-256.
3. Behalten Sie die letzten 20 Bytes des Hashes. Bis hierhin ist das genau das Ethereum-Verfahren.
4. Stellen Sie das Byte 0x41 (TRONs Mainnet-Präfix) voran, was 21 Bytes ergibt.
5. Hashen Sie diese 21 Bytes zweimal mit SHA-256 und nehmen Sie die ersten 4 Bytes als Prüfsumme.
6. Hängen Sie die Prüfsumme an und kodieren Sie die 25 Bytes in Base58.

Das führende T ist keine Konvention, die jemand aus Branding-Gründen gewählt hat; es ergibt sich aus der Mathematik. Jeder 25-Byte-String, der mit 0x41 beginnt, kodiert zu Base58-Text, der mit T beginnt.

Base58Check mit echten Zahlen

Kodierungen bleiben besser hängen, wenn man sie selbst nachvollziehen kann, daher hier die USDT-Contract-Adresse, zusammengesetzt aus ihren Teilen. Die 21-Byte-Payload ist das Präfix 41 plus die 20-Byte-Kontokennung:

payload:         41a614f803b6fd780986a42c78ec9c7f77e6ded13c
sha256(payload): 3a42512dd4f64e4d9dad3d5e6aa0ecf55adbd8a85979135cf211ba347278d029
sha256(again):   710277f5d80b170d90e2ec6c52caa368bc74b9226e3befe5c09825a0eedbfb68
checksum:        710277f5

Die Prüfsumme sind die ersten 4 Bytes des zweiten Hashes. Hängen Sie sie an die Payload an, und Sie haben 25 Bytes: 41a614f803b6fd780986a42c78ec9c7f77e6ded13c710277f5. Behandeln Sie diese Bytes als eine große Zahl, teilen Sie wiederholt durch 58 und ordnen Sie jeden Rest dem Base58-Alphabet zu. Das Ergebnis ist TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, die Adresse, die jede Wallet anzeigt.

Das Dekodieren läuft denselben Weg rückwärts: Base58 zu 25 Bytes, die letzten 4 abtrennen, die ersten 21 zweimal mit SHA-256 hashen und vergleichen. Schlägt der Vergleich fehl, wurde irgendein Zeichen bei der Übertragung verfälscht, und die Adresse darf nicht verwendet werden. Diese Prüfung ist der Grund, warum eine falsch getippte TRON-Adresse von jeder ordentlichen Wallet abgelehnt wird: Die Wahrscheinlichkeit, dass ein zufälliger Tippfehler trotzdem eine passende 4-Byte-Prüfsumme ergibt, liegt bei 1 zu 2^32, etwa eins zu vier Milliarden. Ethereums EIP-55 fängt einen Tippfehler zum Vergleich mit rund 15 Prüfbits ab, TRONs Schema ist also mit deutlichem Abstand das strengere der beiden.

Hex-Form (41…) vs. Base58-Form (T…): eine Adresse, zwei Schreibweisen

Hier kommt der Teil, den fast kein Erklärartikel abdeckt. Wenn Sie mit TRONs eigener Node-API oder Low-Level-Bibliotheken arbeiten, kommen Adressen hexadezimal zurück, beginnend mit 41. Der USDT-Token-Contract zum Beispiel:

Base58:  TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t
Hex:     41a614f803b6fd780986a42c78ec9c7f77e6ded13c

Beide Schreibweisen identifizieren dasselbe Konto. Die Hex-Form sind die rohen 21 Bytes (Präfix plus Kennung) ohne Prüfsumme; die Base58-Form umhüllt diese Bytes für den menschlichen Gebrauch mit der Prüfsumme. Wallets und Explorer zeigen T..., rohe Node-Antworten und signierte Transaktions-Payloads nutzen 41....

Zwei praktische Konsequenzen. Erstens: Vergleichen Sie Adressen niemals als Strings, ohne die Kodierung zu normalisieren, sonst sehen TR7N... und 41a6... für Ihren Code wie unterschiedliche Konten aus. Zweitens: Wenn Sie das Präfix 41 von der Hex-Form entfernen, haben die verbleibenden 20 Bytes dieselbe Form wie eine Ethereum-Adresse, weshalb manche Bibliotheken zwischen TRON- und EVM-Darstellungen konvertieren können. Gleiche Form bedeutet nicht gleiches Konto: Ein auf beiden Netzwerken verwendeter Key erzeugt unabhängige Adressen, weil sich die Ableitung ab Schritt 4 unterscheidet.

Zwischen den beiden Formen konvertieren

Die Konvertierung ist kurz genug, um sie selbst zu schreiben, statt ein TRON-SDK einzubinden. Von Base58 zu Hex bedeutet dekodieren und die Prüfsumme verwerfen; die andere Richtung berechnet sie neu:

import bs58 from "bs58";
import { createHash } from "node:crypto";

const sha256 = (b) => createHash("sha256").update(b).digest();

function base58ToHex(address) {
  const raw = Buffer.from(bs58.decode(address));
  return raw.subarray(0, 21).toString("hex"); // 4 Prüfsummen-Bytes verwerfen
}

function hexToBase58(hex) {
  const payload = Buffer.from(hex, "hex"); // 21 Bytes, beginnt mit 41
  const checksum = sha256(sha256(payload)).subarray(0, 4);
  return bs58.encode(Buffer.concat([payload, checksum]));
}

Wählen Sie eine kanonische Form für die Speicherung und konvertieren Sie an den Grenzen. Base58 zu speichern hält Ihre Datenbank im Einklang mit dem, was Nutzer und Explorer anzeigen; Hex zu speichern passt zu dem, was rohe Node-Payloads enthalten. Beides funktioniert, aber beides in derselben Tabelle zu mischen ist, wie der Bug „gleiche Adresse, kein Match” entsteht, meist entdeckt beim Abgleich von Einzahlungen um 2 Uhr nachts.

Contract-Adresse vs. Wallet-Adresse

Sowohl Wallets als auch Smart Contracts leben unter T...-Adressen, und nichts im String unterscheidet sie. Die Unterscheidung ist am wichtigsten bei USDT:

• Ihre Wallet-Adresse ist der Ort, an dem Sie USDT empfangen. Sie gehört zu Ihrem privaten Schlüssel.
• Die TRC20-Contract-Adresse ist der Ort, an dem der Code des Tokens liegt. Für USDT auf TRON ist das TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.

Der Contract-Adresse begegnen Sie, wenn Sie einen benutzerdefinierten Token zu einer Wallet hinzufügen, wenn Sie auf Tronscan verifizieren, dass ein Token das echte USDT ist und keine Kopie mit demselben Namen, und wenn Sie den Token aus Code heraus aufrufen. Was Sie niemals tun dürfen: Token an die Contract-Adresse senden. Token-Contracts haben keinen Owner, der sie zurückschicken könnte, sodass Transfers an den Contract in fast allen Fällen unwiederbringlich verloren sind. Explorer kennzeichnen Contract-Konten mit „Contract”, das ist der schnellste Weg zu prüfen, mit welcher Art von Adresse Sie es zu tun haben.

Eine Adresse auf Tronscan verifizieren, Schritt für Schritt

Tronscan ist TRONs Block-Explorer und klärt die meisten Zweifel in unter einer Minute.

Fügen Sie die Adresse in die Suchleiste ein. Die Kontoseite zeigt den TRX-Kontostand, TRC20-Bestände und jeden ein- und ausgehenden Transfer. Eine brandneue Deposit-Adresse zeigt eine leere Seite, das ist normal; TRON-Konten werden durch ihre erste eingehende Transaktion aktiviert, „noch keine Daten” bedeutet also unbenutzt, nicht ungültig.

Prüfen Sie als Nächstes den Kontotyp. Contract-Konten tragen oben auf der Seite ein sichtbares „Contract”-Label. Geld geht an einfache Konten; stellt sich heraus, dass das Ziel, das Ihnen jemand gegeben hat, als Contract markiert ist, senden Sie nicht.

Suchen Sie bei Token nach der Contract-Adresse statt nach dem Namen. Die Eingabe von „USDT” bei Tronscan liefert den echten Token umgeben von Nachahmungen mit demselben Ticker, und auf TRON kann jeder einen Token namens USDT deployen. Der echte liegt unter TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, hat sechs Dezimalstellen, und seine Tronscan-Seite zeigt ein Issuer-Label und eine Halterzahl im zweistelligen Millionenbereich. Ein unbekannter Token, dessen Seite ein paar hundert Halter und keinen verifizierten Issuer zeigt, ist nicht der Asset, für den Sie ihn halten.

Letzter Schritt nach jedem Transfer: Suchen Sie die Transaktions-ID. Die Detailseite listet Absender, Empfänger, Token-Contract, Betrag und den Bestätigungsstatus. Sobald die Transaktion nach dem 19-Block-Fenster als bestätigt angezeigt wird, ist sie final.

Netzwerke nicht verwechseln

USDT existiert gleichzeitig auf mehreren Chains: als TRC20-Token auf TRON, als ERC-20-Token auf Ethereum, als BEP-20-Token auf BSC. Gleicher Ticker, getrennte Contracts, inkompatible Netzwerke.

TRON ist hier tatsächlich der freundliche Fall, weil sich die Formate sichtbar unterscheiden: Eine T...-Adresse lässt sich nicht in ein Ethereum-Auszahlungsformular einfügen, ohne an der Validierung zu scheitern, und eine 0x...-Adresse scheitert auf TRON. Das Risiko liegt in den Auszahlungsmenüs der Exchanges, wo Sie das Netzwerk aus einem Dropdown neben dem Adressfeld wählen. Wählen Sie „ERC20” und fügen Sie eine TRON-Adresse ein, blockiert das eine gute Exchange. Aber wenn Sie Adressen auf mehreren Netzwerken besitzen und zufällig die falsche einfügen, die zum gewählten Netzwerk passt, kann kein Validator Sie retten. Nennen Sie das Netzwerk überall explizit, wo Sie eine Adresse anzeigen oder entgegennehmen. Für die EVM-Seite dieses Problems, bei der eine Adresse gleichzeitig auf vielen Chains existiert, siehe Was ist eine BEP20-Adresse?.

Address Poisoning: der Angriff, den Prüfsummen nicht erkennen

Jede bisher beschriebene Prüfung fängt Versehen ab. Address Poisoning ist vorsätzlich, und es funktioniert genau deshalb, weil die vergiftete Adresse vollkommen gültig ist.

Der Ablauf: Ein Angreifer beobachtet Ihre On-Chain-Aktivität und generiert dann eine Vanity-Adresse, deren erste und letzte Zeichen mit einer Adresse übereinstimmen, mit der Sie regelmäßig transagieren. Eine TRON-Adresse zu erzeugen, die zum Beispiel bei vier führenden und vier abschließenden Zeichen eines Ziels übereinstimmt, ist eine Frage der Rechenzeit, nicht des Brechens irgendeiner Kryptografie. Der Angreifer platziert diese Doppelgängerin dann in Ihrer Transaktionshistorie, entweder indem er einen Staubbetrag TRX sendet, oder eleganter, indem er ausnutzt, dass TRC20-Contracts Null-Wert-Transfers erlauben: Ein transferFrom von 0 USDT kostet den Angreifer wenig und erscheint in Ihrer Historie, als hätten Sie mit der Adresse interagiert.

Die Auszahlung kommt Wochen später, wenn Sie „die übliche Adresse” aus Ihrer Transferhistorie kopieren statt aus Ihren eigenen Aufzeichnungen. Wallets und Explorer kürzen Adressen auf ihre ersten und letzten Zeichen, genau die Zeichen, die der Angreifer angeglichen hat, sodass die Fälschung auf den ersten Blick richtig aussieht. Verluste durch dieses Muster sind nicht theoretisch; in einem 2024 breit berichteten Fall sendete ein Ethereum-Nutzer rund 68 Millionen Dollar in WBTC an eine vergiftete Adresse. TRONs billige Transaktionen machen den Seeding-Schritt dort sogar noch günstiger.

Die Gegenmittel sind unglamourös und funktionieren. Kopieren Sie Adressen nie aus Ihrer Transaktionshistorie; kopieren Sie sie aus Ihrem eigenen Adressbuch, Ihrer Datenbank oder dem Empfangsbildschirm des Empfängers. Beim Verifizieren vergleichen Sie mehr als acht Zeichen, oder besser: vergleichen Sie den gesamten String einmal und verlassen Sie sich danach auf eine Allowlist. Für Plattformen gilt strukturell: Auszahlungsziele stammen aus Ihrer Datenbank, einmal eingegeben und verifiziert, und werden nie aus der On-Chain-Historie abgeleitet. Und die Test-Transaktions-Gewohnheit gilt auch hier: ein kleiner Transfer, auf Tronscan als vom vorgesehenen Empfänger erhalten bestätigt, kostet ein paar TRX und schlägt jede visuelle Prüfung.

Eine TRC20-Adresse im Code validieren

Eine erste Prüfung ist ein regulärer Ausdruck gegen das Base58-Alphabet:

const TRON_FORMAT = /^T[1-9A-HJ-NP-Za-km-z]{33}$/;

Der Regex fängt falsche Länge und verbotene Zeichen ab, aber nicht Tippfehler innerhalb des Alphabets. Dafür verifizieren Sie die Prüfsumme:

import bs58 from "bs58";
import { createHash } from "node:crypto";

const sha256 = (buf) => createHash("sha256").update(buf).digest();

function isValidTronAddress(address) {
  if (!/^T[1-9A-HJ-NP-Za-km-z]{33}$/.test(address)) return false;

  const decoded = Buffer.from(bs58.decode(address));
  if (decoded.length !== 25 || decoded[0] !== 0x41) return false;

  const payload = decoded.subarray(0, 21);
  const checksum = decoded.subarray(21);
  const expected = sha256(sha256(payload)).subarray(0, 4);
  return expected.equals(checksum);
}

Eine bestandene Prüfung beweist, dass der String eine wohlgeformte TRON-Adresse ist. Sie beweist nicht, dass das Konto On-Chain existiert oder dass jemand dessen Key besitzt, und sie kann nicht zwischen Wallet und Contract unterscheiden. Für die Contract-Frage fragen Sie die Chain ab oder prüfen Sie den Explorer.

Woher Wallet-Adressen kommen: HD-Ableitung auf TRON

Wenn eine Wallet-App Ihnen Sekunden, nachdem Sie zwölf Wörter notiert haben, eine TRON-Adresse gibt, steckt das dahinter: Die Wörter sind ein BIP-39-Mnemonic, das sich zu einem Seed expandiert. Aus dem Seed leitet BIP-32 einen Baum von Schlüsselpaaren ab, immer derselbe Baum für dieselben Wörter. BIP-44 weist dann jeder Blockchain über einen registrierten Coin-Type einen eigenen Zweig zu, und der von TRON ist 195, sodass der Standardpfad für Ihre erste TRON-Adresse m/44'/195'/0'/0/0 lautet.

Der Coin-Type ist das Detail, das man sich merken sollte. Ethereum liegt bei Coin-Type 60, TRON bei 195, und beide Zahlen erscheinen auf einer gehärteten Ebene des Pfads. Dieselben Seed-Wörter, völlig unterschiedliche Schlüsselbäume. Deshalb liefert dieselbe Recovery-Phrase in einer EVM-Wallet eine 0x-Adresse und in einer TRON-Wallet eine unabhängige T-Adresse, und deshalb kann keine der beiden Wallets die Gelder der anderen sehen. Wenn Sie eine Phrase in einer reinen Ethereum-Wallet wiederherstellen und Ihr TRON-Kontostand scheinbar weg ist, ist nichts verloren; die Wallet hat den Zweig 195 einfach nie abgeleitet. Stellen Sie dieselben Wörter in einer Wallet mit TRON-Unterstützung wieder her, und die Adresse — und der Kontostand — tauchen wieder auf.

Der Index am Ende des Pfads zählt hoch: .../0/1 ist Ihre zweite TRON-Adresse aus denselben Wörtern, .../0/2 die dritte. Persönliche Wallets kommen selten über eine Handvoll hinaus. Bei Plattformen ist es umgekehrt, und für sie ist die sicherere Konstruktion, pro Kunde unabhängig generierte Keys per API zu registrieren, weil dann keine einzelne Phrase jede Deposit-Adresse im System kontrolliert.

So erhalten Sie eine TRC20-Wallet-Adresse

Es gibt zwei Wege, und welcher für Sie richtig ist, hängt davon ab, ob Sie eine Adresse für sich selbst oder viele Adressen für eine Anwendung möchten.

Der Wallet-Weg (eine Adresse, persönliche Nutzung)

Installieren Sie eine Wallet, die TRON unterstützt: TronLink ist die Standard-Browser-Wallet des Netzwerks, Trust Wallet deckt Mobile ab, Ledger deckt Hardware ab. Erstellen Sie ein Konto, notieren Sie die Recovery-Phrase offline und öffnen Sie den Empfangsbildschirm. Die dort angezeigte T...-Adresse ist Ihre TRC20-Wallet-Adresse für USDT und jeden anderen TRON-Token. Es gibt keine Gebühr für ihre Erstellung und keinen Registrierungsschritt; die Adresse funktioniert in dem Moment, in dem die Wallet sie generiert.

Der API-Weg (viele Adressen, für Anwendungen)

Eine Plattform, die Einzahlungen pro Kunde verbucht, braucht eine Adresse pro Kunde, und sich tausendfach durch eine Wallet-UI zu klicken ist keine Option. Mit der Chaingateway-REST-API generieren Sie Keys in Ihrer eigenen Umgebung und registrieren sie für das TRON-Netzwerk. Die Authentifizierung erfolgt per Bearer-Token:

curl -X POST https://app.chaingateway.io/api/v2/tron/addresses/import \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "TYourGeneratedTronAddress",
    "privatekey": "<generated secp256k1 private key, hex>",
    "password": "<encryption password for this key>"
  }'

Mit dem Header X-Network: testnet zielt derselbe Aufruf auf das TRON-Testnet, sodass der gesamte Flow zuerst mit kostenlosem Test-TRX getestet werden kann. Das spätere Senden von Token läuft über POST /api/v2/tron/transactions/trc20. Der Quickstart führt durch beide Aufrufe; ein 7-tägiger Test ohne KYC-Onboarding deckt die Testphase ab, und die Pläne stehen auf der Preisseite.

TRC20-Einzahlungen entgegennehmen: der Webhook-Flow

Sobald jeder Kunde eine Adresse hat, bleibt das Problem, Einzahlungen zu bemerken, ohne Tronscan zu pollen. Das Muster:

1. Weisen Sie jedem Kunden eine eigene TRON-Adresse zu und speichern Sie die Zuordnung in Ihrer Datenbank.
2. Registrieren Sie einen Webhook. Erreicht ein TRC20-Transfer die Adresse, wird Ihr Endpoint mit den Transaktionsdaten aufgerufen.
3. Verifizieren Sie die HMAC-Signatur des Webhooks und verbuchen Sie dann den Kunden.

Zustellungen sind signiert, und eine Zustellung, die Ihr Endpoint verpasst hat, ist nicht verloren: GET /api/v2/tron/webhooks/notifications/failed listet, was nie durchkam, und POST /api/v2/tron/webhooks/notifications/{id}/retry sendet es erneut. Nach einem Ausfall listet GET /api/v2/tron/webhooks/notifications vergangene Benachrichtigungen zum Abgleich. Details und Signatur-Code stehen im Webhooks-Guide.

Ein TRON-spezifischer Punkt: Empfangen ist kostenlos, aber das Weiterleiten von Einzahlungen kostet Energy und Bandbreite. Seit Proposal #104 den Energy-Preis von 210 auf 100 Sun gesenkt hat, kostet ein USDT-Transfer etwa 6,4 TRX an eine aktive Adresse und etwa 13,4 TRX an eine leere, wenn Sie ohne gestaktes Energy zahlen. Planen Sie die Konsolidierungskosten mit dem TRON-Gebührenrechner; regelmäßige Sender senken den laufenden Verbrauch, indem sie TRX für Energy staken, was die API mit POST /api/v2/tron/freeze abdeckt.