So verarbeitet STONfi bouncebare und nicht-bouncebare Adressen in TON
TON-Adressen können unterschiedlich aussehen, während sie auf dasselbe On-Chain-Konto zeigen.
Ein gängiges Beispiel ist der Unterschied zwischen einer Adresse, die mit EQ… beginnt, und einer, die mit UQ… beginnt. Die erste ist die vertraute bouncebare benutzerfreundliche Darstellung, während die zweite die nicht-bouncebare Darstellung ist. Trotz der unterschiedlichen Präfixe können beide die gleiche zugrunde liegende TON-Account-Adresse identifizieren, weil das Konto selbst durch seinen Workchain- und den 256-Bit-Account-Bezeichner bestimmt wird. Die Unterscheidung zwischen bouncebar und nicht-bouncebar ist in den Metadaten der benutzerfreundlichen Darstellung codiert, statt ein anderes Konto zu erstellen.
Diese Unterscheidung wird besonders wichtig, wenn man mit DeFi-Protokollen wie STONfi interagiert—bei denen ein einzelner Swap mehrere TON-Adressen und mehrere Ebenen von Contract-Nachrichten beinhalten kann.
Wenn du verstehst, was das Adresspräfix tatsächlich bedeutet, wird es viel einfacher zu verstehen, warum STONfi mit unterschiedlichen Adressdarstellungen funktionieren kann, ohne sie als unterschiedliche Ziele zu behandeln.
Die erste wichtige Unterscheidung: Adressidentität vs. Nachrichtenverhalten
Der einfachste Weg, TON-Adressen zu verstehen, ist, zu trennen, wer das Ziel ist, von dem, wie sich eine Nachricht verhalten soll, wenn sie dorthin gesendet wird.
Eine benutzerfreundliche TON-Adresse enthält mehrere Informationen. Dazu gehören die Kennung der Workchain, die Konto-ID sowie Flags, die beschreiben, wie die Adresse beabsichtigt ist. Insbesondere codieren die Flags, ob eine Nachricht als bounceable oder non-bounceable gesendet werden soll.
Das bedeutet: Das sichtbare Präfix ist nicht einfach nur eine alternative Kontokennung.
Zum Beispiel:
EQ... → benutzerfreundliche bounceable Darstellung
UQ... → benutzerfreundliche non-bounceable Darstellung
Wenn Workchain und Konten-ID identisch sind, sind das zwei Darstellungen desselben Kontos.
Die eigenen TON-Adress-Utilities können eine Adresse in ihre rohen, bounceable und non-bounceable Formen umwandeln. Das ist eine weitere Möglichkeit zu zeigen, dass es sich um unterschiedliche Darstellungen desselben zugrunde liegenden Ziels handelt—nicht um separate Wallets.
Das ist eines der wichtigsten Konzepte für Entwickler, die auf TON aufbauen:
Vergleiche nicht das visuelle Präfix, wenn du herausfinden willst, ob zwei Adressen dieselbe Kontoidentität darstellen. Parisi die Adresse und vergleiche die zugrunde liegenden Adressbestandteile.
Was bedeutet „Bounceable“ eigentlich?
Bounceability betrifft grundlegend die Nachrichtenbehandlung.
TON-interne Nachrichten enthalten ein Bounce-Flag. Wenn eine bounceable Nachricht an ein Ziel zugestellt wird und die Verarbeitung unter den Bedingungen fehlschlägt, unter denen Bouncing unterstützt wird, kann der verbleibende Wert zum Absender zurückgegeben werden. TONs Richtlinien für Smart Contracts empfehlen bounceable Nachrichten für die meisten Interaktionen, weil sie Schutz gegen bestimmte Ziel- oder Ausführungsfehler bieten.
Der wichtige Punkt ist, dass ein Konto nicht dauerhaft zu einem „bounceable Konto“ oder einem „non-bounceable Konto“ wird.
Stattdessen enthält die benutzerfreundliche Adressdarstellung ein Flag, das Software beim Konstruieren der ausgehenden Nachricht verwenden kann.
TON dokumentiert die Mainnet-freundlichen Formate als:
E... für bounceable Adressen
U... für non-bounceable Adressen
Dasselbe Konto kann daher in beiden Formen dargestellt werden.
Wenn also jemand eine Adresse von EQ... nach UQ... ändert, hat er kein Geld verschoben, keine zweite Wallet erstellt oder das Konto selbst geändert.
Sie haben die benutzerfreundliche Darstellung und die zugehörige Bounce-Präferenz geändert.
Warum braucht TON non-bounceable Adressen?
Die Antwort wird klarer, wenn wir die Initialisierung des Kontos betrachten.
TON unterstützt Contract-Konten, deren Adressen bestimmt werden können, bevor der zugehörige Contract bereitgestellt wurde. Ein Wallet-Contract kann zum Beispiel eine deterministische Adresse haben, die aus seinen Initialisierungsparametern abgeleitet wird, selbst bevor das Konto on-chain aktiviert wurde. Die TON-Dokumentation beschreibt ausdrücklich Fälle, in denen eine Adresse als deterministischer Wert existiert, während das Konto selbst sich noch im „nicht existiert“-Zustand befindet.
Das erzeugt ein wichtiges Finanzierungsproblem.
Angenommen, du möchtest TON an eine Wallet senden, deren Adresse bekannt ist, deren Konto aber noch nicht initialisiert wurde. Eine non-bounceable Nachricht kann verwendet werden, um dieses Ziel zu finanzieren, ohne dass der Wert zurückgeprallt wird—einfach weil das Konto noch nicht initialisiert ist.
Deshalb werden non-bounceable Darstellungen besonders mit dem Finanzierten oder Initialisieren von Wallets in Verbindung gebracht.
TONs Dokumentation empfiehlt non-bounceable Adressen für Wallet-Contracts in Situationen, in denen das Ziel möglicherweise noch nicht initialisiert ist. Bounceable Nachrichten sind allgemein bevorzugt für Smart-Contract-Interaktionen, bei denen ein fehlgeschlagenes Ausführen dazu führen soll, dass der Wert zurückgegeben wird.
Wallets auf TON sind Smart Contracts
Ein weiteres Konzept, das manchmal Verwirrung stiftet, ist das Wort „Wallet“.
Auf TON ist eine Wallet nicht nur ein Konto-Label im gleichen Sinne wie ein Konto auf einer traditionellen zentralisierten Börse. Wallet-Implementierungen sind Smart Contracts, und ihre Adresse kann schon vor dem Deployment abgeleitet werden.
Deshalb ist es möglich zu wissen, wo eine Wallet existieren wird, bevor der Wallet-Contract tatsächlich on-chain initialisiert wurde.
TONs Adress-Workflow spiegelt diese Unterscheidung wider. Wenn eine Wallet-Anwendung eine Übertragung vorbereitet, kann sie den Kontostatus des Ziels prüfen. Die TON-Dokumentation weist darauf hin, dass Wallet-Software, wenn ein Ziel noch nicht initialisiert ist, das Bounce-Feld der ausgehenden Nachricht auf false setzen kann—und damit effektiv non-bounceable Lieferung für Initialisierungsszenarien bevorzugt. Für bereits initialisierte Ziele kann die Wallet die Bounce-Präferenz verwenden, die in der Adresse dargestellt ist.
Damit ist das praktische Verhalten anspruchsvoller als nur zu sagen:
„EQ bounce’t immer.“
oder
„UQ bounce’t nie.“
Das Präfix liefert eine Vorgabe für die Nachrichtenbehandlung, während auch die Wallet-App und der Zielzustand beeinflussen können, wie die Transaktion aufgebaut wird.
Wo STONfi in dieses Modell passt
Ein STONfi-Swap ist nicht einfach nur eine einzelne Übertragung von einer Wallet zur anderen.
Ein typischer Swap kann mehrere Adressen und mehrere Nachrichten umfassen:
Deine Wallet → STONfi-Contract/Router → Token-Contracts oder Pools → Empfänger-/Refund-/Überschussziele
Je nach Operation kann die Transaktion Adressen für Folgendes umfassen:
Dein verbundene Wallet
Jetton-Master-Contracts
Jetton-Wallet-Contracts
STONfi-Router
Pool-Contracts
Empfängeradressen
Refund-Adressen
Ziele für überschüssige Werte
Jede Adresse kann auf einer anderen Ebene der Transaktion auftauchen.
Das ist wichtig, weil das als anfängliches Transaktionsziel verwendete Ziel nicht notwendigerweise dasselbe ist wie jede Adresse, die in der Contract-Payload mitgeführt wird.
Wenn eine Wallet beispielsweise eine TON-Connect-Transaktion sendet, hat die Nachricht selbst eine Zieladresse und kann eine beliebige Payload enthalten. Contract-Interaktion kann dann zusätzliche MsgAddress-Werte in diese Payload kodieren. Die eigenen TON-Beispiele zeigen dieses Muster für Token- und NFT-Interaktionen: Dabei kann eine Contract-Nachricht Adressen wie einen neuen Besitzer oder ein Ziel für Überschuss enthalten.
Das ist die Architektur, die die Adressbehandlung in einem STONfi-Swap interessanter macht als eine einfache „Sende von A nach B“-Übertragung.
Das anfängliche Ziel ist nur ein Teil der Transaktion
Betrachte den Anfang eines Swaps.
Deine Wallet erstellt eine ausgehende Nachricht, deren anfängliches Ziel der STONfi-Contract ist, der die Anfrage empfangen und verarbeiten soll.
Die Wallet benötigt daher eine gültige Zieladresse für diesen Contract.
Innerhalb der Request-Payload muss das Protokoll jedoch möglicherweise auch wissen, wohin die resultierenden Assets geliefert werden sollen, wo überschüssiger Wert zurückgegeben werden sollte, oder wohin eine Refund gehen soll, falls eine bestimmte Operation dies erfordert.
Diese Adressen werden im Contract-Datenbereich als normale TON-Adresswerte dargestellt.
Sie werden nicht notwendigerweise anhand des visuellen Präfixes interpretiert, das ein Mensch in einer Wallet-Oberfläche gerade sieht.
Auf Protokollebene sind die wichtigen Informationen die geparste TON-Adresse selbst sowie die Nachrichtensemantik, die damit verbunden ist, wie diese Adresse verwendet wird.
Warum STONfi EQ... und UQ... als dasselbe Ziel behandeln kann
Stell dir das folgende vereinfachte Szenario vor:
EQxxxxxxxx... und UQxxxxxxxx...
können wie zwei verschiedene Strings aussehen.
Eine naive Anwendung könnte sie als Rohtext vergleichen und daraus schließen, dass sie verschiedene Wallets darstellen.
Eine TON-aware Anwendung sollte sie stattdessen in ihre zugrunde liegende Adressstruktur parsen.
Sobald geparst, kann die Anwendung die gemeinsame Workchain und die Kontenkennung identifizieren.
Darum ist das richtige mentale Modell:
Andere freundliche Darstellung ≠ anderes Konto.
Dieses Prinzip ist besonders wichtig für STONfi, weil eine DeFi-Anwendung Adressen von verschiedenen Wallets, SDKs, Exchanges, Explorern oder Entwicklern empfangen kann. Unterschiedliche Tools können dasselbe Konto mithilfe unterschiedlicher benutzerfreundlicher Darstellungen anzeigen.
TON stellt sogar offizielle Utilities bereit, um diese Formen zu erkennen und in ihre zugrunde liegenden Komponenten zu zerlegen.
Was passiert mit STONfi-„to“-Parametern?
Gemäß dem in STONfi SDK beschriebenen Verhalten ab v0.5.0, verwenden generierte „to“-Parameter bounceable Darstellungen, weil diese Protokoll-Ziele erwartete initialisierte Contracts sind, die Logik empfangen und ausführen sollen.
Dieses Design passt zu TONs allgemeiner Smart-Contract-Beratungslogik.
TON empfiehlt bounceable Nachrichten für Smart-Contract-Interaktionen, weil—wenn es passend ist—eine fehlgeschlagene Contract-Interaktion dazu führen kann, dass der verbleibende Nachrichtenwert zurückgegeben wird, statt einfach in ein unbrauchbares Ziel zu verschwinden.
Das bedeutet nicht, dass jede Adresse, die an einer STONfi-Transaktion beteiligt ist, visuell immer mit EQ beginnen muss.
Das bedeutet, dass Nachricht und Contract-Interaktion das passende Bounce-Verhalten für die Rolle verwenden sollen, die diese Adresse spielt.
Diese Unterscheidung ist entscheidend.
Ein protokollseitiger Contract, der eine Operation empfängt, ist etwas anderes als ein Wallet-Konto, das zum ersten Mal initialisiert wird.
Empfänger-, Refund- und Überschussadressen
Einer der leichtesten Fehler für Entwickler ist anzunehmen, dass jede Adresse in einer Swap-Transaktion denselben Typ von Ziel hat.
Nein.
Ein Swap kann unterschiedliche Rollen von Adressen mit unterschiedlichen Zwecken umfassen.
Empfänger
Der Empfänger identifiziert, wohin das resultierende Asset letztlich geliefert werden soll.
Refund
Eine Refund-Adresse kann verwendet werden, wenn bei einer Operation der Wert an den ursprünglichen Nutzer oder an ein anderes festgelegtes Ziel zurückgegeben werden muss.
Überschuss
Ein Überschussziel wird für den Wert verwendet, der übrig bleibt, nachdem die erforderlichen Ausführungskosten oder -Beträge abgewickelt wurden.
Diese Adressen können als TON MsgAddress-Werte durch das Protokoll reisen, die in Payloads eingebettet sind.
Deshalb reicht es nicht, nur die erste Adresse in einer Wallet-Transaktion anzusehen, um zu wissen, was im Swap tatsächlich passiert.
Warum Builder Adressen parsen sollten statt Strings zu vergleichen
Für Entwickler ist das möglicherweise die praktischste Erkenntnis von allen.
Baue keine Logik wie:
wenn (addressA === addressB)
wenn diese Werte unterschiedliche benutzerfreundliche Darstellungen sein können.
Stattdessen: Parisi beide Werte in echte TON-Address-Objekte und vergleiche ihre zugrunde liegende Identität.
Bibliotheken im TON-Ökosystem sind dafür ausgelegt, zwischen rohen und benutzerfreundlichen Darstellungen zu konvertieren. Die TON-Dokumentation beschreibt ausdrücklich die Konvertierung zwischen rohen, bounceable und non-bounceable Formen, während die Sicherheitsrichtlinie Entwickler davor warnt, mit Tonns mehreren Adressdarstellungen korrekt umzugehen.
Die Anwendung sollte sich darum kümmern:
Workchain + Kontenkennung
statt:
EQ vs. UQ
als Textpräfix.
Das ist besonders wichtig für Indexierung, Caching, Datenbankspeicherung, Portfolio-Tracking, Empfängervalidierung, Analytik und Protokoll-Integrationen.
Ein nützliches mentales Modell
Der einfachste Weg, sich das gesamte System zu merken, ist: Stell dir eine TON-Adresse als zwei Schichten vor.
Layer 1: Das Konto
Dies ist die zugrunde liegende Identität:
Workchain + 256-Bit-Konto-ID
Das identifiziert das Zielkonto.
Layer 2: Die benutzerfreundliche Darstellung
So wird dieses Konto für Menschen und Software codiert:
Raw / Bounceable / Non-bounceable / Testnet-Varianten
Die freundliche Darstellung ergänzt Metadaten, darunter Bounceability und Testnet-Informationen, plus eine Prüfsumme.
Daher können zwei „freundliche“ Strings dieselbe zugrunde liegende Kontoidentität beschreiben.
Genau deshalb sollten eine EQ...-Darstellung und eine UQ...-Darstellung nicht automatisch als zwei verschiedene Wallets behandelt werden.
Was Nutzer vor einem STONfi-Swap tun sollten
Für STONfi-Nutzer im Alltag ist der sicherste Ansatz überraschend einfach.
Verwende die von deiner Wallet bereitgestellte oder von vertrauenswürdigen TON-Tools verwendete Adresse, statt Präfixe manuell zu bearbeiten.
Ändere EQ nicht in UQ oder UQ nicht in EQ, nur weil eine andere Anwendung die Adresse anders darstellt.
Noch wichtiger: Überprüfe immer das tatsächliche Ziel, das Netzwerk, den Betrag und die Transaktionsdetails, bevor du unterschreibst.
TON-Wallets und TON-Connect-Anwendungen verstehen bereits benutzerfreundliche Adressen und das dazugehörige Verhalten. Die TON-Connect-Dokumentation erwartet zum Beispiel benutzerfreundliche Adressen für Transaktionsnachrichten und stellt Utilities bereit, um die verbundene Wallet-Adresse darzustellen.
Mit anderen Worten: Nutzer müssen bei einer korrekt integrierten Wallet und Protokoll-Schnittstelle Bounce-Flags normalerweise nicht manuell verwalten.
Was Builder mitnehmen sollten
Für Entwickler, die STONfi integrieren oder TON-Anwendungen bauen, sollte die Adressnormalisierung als grundlegender Bestandteil der Integration behandelt werden—nicht als Randfall.
Eine robuste Implementierung sollte:
Parsie Adressen, bevor du sie vergleichst.
Gehe niemals davon aus, dass zwei unterschiedliche Strings zwei verschiedene Konten bedeuten.
Arbeitsketten-Informationen (Workchain) beibehalten.
Die Kontenkennung muss zusammen mit der korrekten Workchain interpretiert werden. TONs Sicherheitsrichtlinie empfiehlt ausdrücklich, beim Verarbeiten von Adressen die Adresskette zu validieren.
Verstehe den Unterschied zwischen einem Konto und einer Nachricht.
Bounceability beschreibt, wie sich eine Nachricht verhalten soll; es ist keine permanente Eigenschaft, die ein zweites Konto erzeugt.
Verwende bounceable Nachrichten für passende Contract-Interaktionen.
Smart-Contract-Operationen profitieren generell von bounceable Lieferung, wenn beim fehlgeschlagenen Ausführen der verbleibende Wert zurückgegeben werden soll.
Verwende non-bounceable Lieferung, wenn Initialisierung oder Finanzierung dies erfordert.
Neue oder noch nicht initialisierte Wallet-Contracts sind der klassische Fall.
Überlass vertrauenswürdigen SDKs die Details der Darstellung.
Der Zweck eines SDK ist nicht nur, Contract-Aufrufe einfacher zu machen, sondern auch die Anzahl von fehleranfälligen Low-Level-Adressbehandlungen zu reduzieren, die Entwickler machen können.
Der größere Kontext für STONfi
Während TON DeFi immer ausgefeilter wird, beinhalten Transaktionen zunehmend mehrere Contracts statt einer einfachen Übertragung von Wallet zu Wallet.
STONfi-Swaps sind ein gutes Beispiel.
Ein Nutzer sieht möglicherweise nur:
„Token A gegen Token B tauschen.“
Hinter dieser einfachen Schnittstelle kann die Blockchain Wallet-Nachrichten, Router, Jetton-Wallets, Pool-Contracts, Empfängerziele und Mechanismen für die Rückgabe von Werten koordinieren.
Die korrekte Adressbehandlung wird dadurch Teil der Zuverlässigkeit des Protokolls.
Der Unterschied zwischen EQ... und UQ... mag für einen Nutzer kosmetisch wirken, stellt auf Protokollebene jedoch eine bedeutungsvolle Unterscheidung in der Nachrichtenkonstruktion dar.
Gleichzeitig sollte diese Unterscheidung niemals die zugrunde liegende Wahrheit verschleiern:
Das Präfix bedeutet nicht automatisch, dass es zwei verschiedene Konten gibt.
Dasselbe TON-Konto kann unterschiedliche benutzerfreundliche Darstellungen haben, während die an dieses Konto gesendete Nachricht je nach Kodierung der Adresse und Aufbau der Transaktion unterschiedliches Bounce-Verhalten tragen kann.
Finale Schlussfolgerung
Das Adresssystem von TON ist genau deshalb mächtig, weil es die Kontoidentität von der nutzerseitigen Darstellung trennt.
Eine EQ...-Adresse und eine UQ...-Adresse können auf dasselbe zugrunde liegende Konto zeigen. Die entscheidende Identität ist Workchain plus Kontenkennung; das freundliche Präfix ergänzt dabei Informationen zur Handhabung wie Bounceability.
Für STONfi-Nutzer heißt das: Du solltest dir keine Sorgen machen, wenn eine vertrauenswürdige Wallet oder App deine Adresse in einer anderen gültigen Form anzeigt.
Für Builder ist die Erkenntnis sogar noch wichtiger:
Parsi TON-Adressen. Normalisiere sie. Vergleiche die zugrunde liegende Identität. Und wähle das Bounce-Verhalten entsprechend der Rolle des Ziels und dem Zweck der Nachricht.
Sobald dieses Modell klar ist, wird die Adressbehandlung von STONfi viel leichter zu verstehen.
Beim nächsten Mal, wenn du eine EQ...- und eine UQ...-Adresse siehst, denke nicht sofort „zwei Wallets“.
Denk daran:
gleiches mögliches Ziel, andere Darstellung, andere Präferenz für die Nachrichtenbehandlung.
Diese Unterscheidung ist auf der Benutzerschnittstelle klein, aber grundlegend, wenn man zuverlässige Anwendungen auf TON baut.
Erfahre mehr über STON.FI in app.ston.fi
Mehr über STONfi erfährst du hier BLOG.STON.FI