TRON-Konto nicht aktiviert: was es blockiert und wie man es behebt
Eine Adresse ist ein Schlüsselpaar, solange das Netz kein Konto für sie hat. Mehr steckt hinter „TRON-Konto nicht aktiviert“ nicht, und genau das überrascht die Leute: Die Adresse ist wohlgeformt, die Wallet zeigt sie an, der QR-Code lässt sich scannen — und die Kette hat noch nie von ihr gehört. Für ein Auszahlungsteam taucht dieser Zustand an zwei verschiedenen Stellen auf — bei der sendenden Wallet und bei der Adresse, die bezahlt wird — und nur eine davon ist eine Abweisung.
Was Aktivierung tatsächlich ist
Eine TRON-Adresse wird offline aus einem Schlüsselpaar abgeleitet. Bei ihrer Entstehung wird nirgendwo etwas registriert, und das Netz erfährt von ihr erst, wenn eine Transaktion einen Kontoeintrag für sie anlegt. Unsere eigene Prüfung nimmt das wörtlich: Wir fragen eine Node nach dem Konto hinter der Adresse, und eine leere Antwort ist das, was activated: false bedeutet. Nicht „wir konnten es nicht finden“ und nicht „es sieht neu aus“ — dort ist kein Konto.
Der gewöhnliche Weg, wie eines entsteht, ist ein eingehender TRX-Transfer: TRX an die Adresse senden, und das Netz legt das Konto an, während es diesen Transfer ausführt. Ein Konto anzulegen ist nicht kostenlos. Was es kostet, ist ein Chain-Parameter und keine Zahl, die es lohnt auf eine Seite zu drucken, lesen Sie sie also aus dem Netz und nicht irgendwo, wo sie ein Jahr alt sein kann. Wichtig ist hier, dass es eine gewöhnliche Transaktion ist und die Adresse danach ein Konto wie jedes andere.
Was es blockiert: die Wallet, die senden wird
Energie wird an ein Konto delegiert, und es gibt nichts zum Delegieren, wenn kein Konto existiert. Mehr ist die Abweisung nicht. Eine Bestellung in mode A oder mode C, die eine solche Wallet als from nennt, kommt als 422 invalid_address zurück, mit details.reason auf inactive_wallet sowie details.index — welcher Transfer des Stapels — und details.address. Es ist einer der vier Fehlschläge, die ein Auszahlungsteam immer wieder trifft, und einer der beiden, die eine Bestellung rundheraus ablehnt, statt sie zu bepreisen.
Drei Eigenschaften dieser Abweisung sind wichtig, bevor der Handler geschrieben wird.
Sie verbraucht den Idempotency-Key nicht. Keine der Abweisungen dieser Familie tut das: Die Anfrage ist wohlgeformt, und wir können sie mit diesen Adressen nur nicht annehmen. Sobald die Wallet existiert, ist derselbe Schlüssel mit Byte für Byte gleichem Body eine gültige Wiederholung und kein Konflikt, bei Ihnen muss also nichts neu abgeleitet werden.
Sie wird nicht aus einem Cache beantwortet. Adresszustände werden hier zwischengespeichert, aber die Aktivierung wird am Cache vorbei neu gelesen, bevor eine Bestellung deswegen abgewiesen wird — eine vor Sekunden aktivierte Wallet wird sofort angenommen und nicht erst, wenn irgendein Eintrag abläuft. Wiederholen Sie sofort; es gibt nichts abzuwarten.
In mode B gibt es sie nicht. Dort kommt die Transaktion bereits vom Eigentümer der Absenderadresse signiert an, das Konto ist also von Natur aus da, und die Prüfung würde eine Frage stellen, die sich selbst beantwortet hat.
Nicht aktiviert ist nicht fehlerhaft
Zwei Antworten tragen denselben Fehlernamen und bedeuten Gegenteiliges. 400 invalid_address, ganz ohne details.reason, betrifft die Form der Zeichenkette: Sie ist keine TRON-Adresse, und nichts, was auf der Kette geschieht, macht sie zu einer. 422 invalid_address mit einem details.reason betrifft den Zustand einer völlig einwandfreien Adresse, und eine einzige Transaktion behebt ihn. Eine Pipeline, die beide gleich behandelt, wiederholt die erste ewig und gibt die zweite auf — es lohnt sich also, über das Vorhandensein von details.reason zu verzweigen und nicht über den Fehlernamen, den sich die beiden teilen.
Was es kostet: die Adresse, die bezahlt wird
Auf der Empfängerseite wird nichts abgewiesen; ein nicht aktivierter Empfänger ist ein Preis. Ein Transfer an eine Adresse ohne USDT-Guthaben muss neben dem Bewegen der Token auch das Token-Konto des Empfängers eröffnen, und das braucht rund 131,000 Einheiten Energie gegenüber rund 65,000 für eine Adresse, die bereits USDT hält (warum sich die beiden unterscheiden). Zum Protokollsatz sind das 13.1 TRX Verbrennung statt 6.5 TRX, und in einem Auszahlungslauf an neue Kunden kann ein Großteil des Stapels gleichzeitig in diesem Zustand sein — was das Mieten dieser Energie kostet, bewegt sich mit dem Markt, die Verbrennung nicht.
Hier gehen die beiden Fragen auseinander, und die Namen laden zur Verwechslung ein, seien Sie also genau. activated fragt, ob das Netz ein Konto für die Adresse hat. holds_usdt fragt, ob ihr USDT-Guthaben über null liegt. Der Preis folgt der zweiten Frage: kind ist double, wann immer die Adresse kein USDT hält, aktiviert oder nicht. Die Warnung inactive_recipient folgt der ersten. Eine vor Jahren aktivierte Adresse, die schlicht nie in USDT bezahlt wurde, trägt also keine Warnung und wird trotzdem als double bepreist; und eine Adresse, die nie aktiviert wurde, kann durchaus USDT halten — ein TRC-20-Guthaben lebt im eigenen Speicher des Token-Vertrags, ein Eingang legt also ein Guthaben an und kein Konto —, was sie als single bepreist und zugleich mit inactive_recipient warnt. Die beiden sehen aus wie eine Frage, bis eine Adresse sie verschieden beantwortet.
Eine Adresse prüfen, und fünfhundert prüfen
Für eine einzelne Adresse beantwortet GET /v1/address-check beide Fragen und zwei weitere in einem Aufruf: activated, holds_usdt, blacklisted, is_contract und das expected_kind, das daraus folgt.
Für einen Stapel nimmt POST /v1/estimate bis zu 500 Transfers und weist nichts ab — alles, was ihm auffällt, kommt als warnings an der Position zurück, auch Befunde, die eine Bestellung stoppen würden. Empfänger werden immer geprüft. Der Absender wird nur geprüft, wenn Sie einen nennen: from ist an einer Schätzposition optional und ändert keinen Preis, und das Einzige, was es einbringt, ist die Auskunft. inactive_sender ist dort derselbe Befund, den eine Bestellung als 422 meldet, nur dass nichts auf dem Spiel steht.
POST /v1/estimate
{"transfers":[{"from":"TN3W…","to":"TMu1…"}]}
# warnings, die eine Position tragen kann: blacklisted, inactive_recipient,
# contract_recipient, inactive_sender, blacklisted_sender
Keiner der beiden Aufrufe reserviert oder belastet etwas, eine Liste lässt sich also so oft prüfen, wie die Rate-Limits es zulassen. Was keiner von beiden probt, ist die Bestellung selbst, die in jedem Modus echtes Geld ausgibt.
Der Ausweg
Schicken Sie der Adresse etwas TRX, lassen Sie diese Transaktion bestätigen, und wiederholen Sie die Bestellung mit demselben Schlüssel und denselben Bytes. Es gibt keinen Registrierungsschritt, keinen Antrag und keinen zweiten Aufruf bei uns. Die eine Reihenfolgeregel, die aufzuschreiben lohnt: Die Wallet muss vor der Bestellung existieren, nicht vor dem Transfer — Energie wird an ein Konto geliefert, das Konto muss also da sein, um sie zu empfangen.
Dasselbe gilt für eine Wallet, die aufgefüllt bleiben soll. Eine Auto-refill-Regel wird auf einer nicht aktivierten Adresse mit demselben Grundwort abgewiesen und auf einer Vertragsadresse mit contract_wallet — der Energieverbrauch eines Vertrags funktioniert anders, und die Regel hat nichts zu bemessen. Erst aktivieren, dann die Regel setzen.