Wie STONfi Bounceable- und Non-Bounceable-Adressen auf TON verarbeitet
TON-Adressen können unterschiedlich aussehen, obwohl sie dasselbe On-Chain-Konto identifizieren. EQ… ist die bounceable Form, während UQ… nicht-bounceable ist. Wenn Workchain und Kontenkennung identisch sind, können beide dieselbe Adresse darstellen.
Was Bounceable bedeutet
Bounceability beschreibt das Nachrichtenverhalten, nicht eine dauerhafte Kontoeigenschaft. Eine TON benutzerfreundliche Adresse enthält Flags, die der Software helfen zu bestimmen, wie eine Nachricht verarbeitet wird.
Bei bouncebarer Zustellung kann der verbleibende Wert bei fehlgeschlagener Verarbeitung unter den jeweiligen Bedingungen zum Absender zurückkehren. Daher eignen sich bouncebare Nachrichten für Smart-Contract-Interaktionen.
Nicht-bouncebare Zustellung ist nützlich, wenn ein Konto finanziert wird, das noch nicht initialisiert wurde. In TON sind Wallets Smart Contracts, und ihre Adressen können bereits vor dem Deployment bekannt sein. Ungeeignetes Bounce-Verhalten für ein nicht initialisiertes Ziel kann dazu führen, dass die Übertragung fehlschlägt, statt das Konto zu finanzieren.
Wie STONfi Adressen verwendet
Ein STONfi-Swap kann die verbundene Wallet, Jetton Masters, Router, Pools, Empfänger, Refund- und Excess-Adressen umfassen.
Das anfängliche Transaktionsziel ist der Contract, der die Wallet-Nachricht empfängt. Andere Adressen können innerhalb des Payloads als TON-Adresswerte mitreisen.
Seit STONfi SDK v0.5.0 verwenden generierte zu-Parameter bounceable Adressen, weil davon ausgegangen wird, dass Protokoll-Contracts existieren und die Logik ausführen. Das entspricht der TON-Praxis für etablierte Contract-Interaktionen.
Warum Entwickler Adressen parsen sollten
Ein häufiger Fehler ist, EQ… und UQ… als reine Strings zu vergleichen und anzunehmen, dass es sich um unterschiedliche Wallets handelt. Stattdessen sollte man sie in korrekte TON Address-Objekte parsen und die zugrunde liegende Workchain und Kontenkennung vergleichen.
Das ist wichtig für Integrationen, Validierung und die Erstellung von Transaktionen. Entwickler sollten die Workchain beibehalten und sich auf vertrauenswürdige TON-Tools zur Adresskodierung verlassen.
$STON $RAY
#BTC Preis-Analyse#
TON-Adressen können unterschiedlich aussehen, obwohl sie dasselbe On-Chain-Konto identifizieren. EQ… ist die bounceable Form, während UQ… nicht-bounceable ist. Wenn Workchain und Kontenkennung identisch sind, können beide dieselbe Adresse darstellen.
Was Bounceable bedeutet
Bounceability beschreibt das Nachrichtenverhalten, nicht eine dauerhafte Kontoeigenschaft. Eine TON benutzerfreundliche Adresse enthält Flags, die der Software helfen zu bestimmen, wie eine Nachricht verarbeitet wird.
Bei bouncebarer Zustellung kann der verbleibende Wert bei fehlgeschlagener Verarbeitung unter den jeweiligen Bedingungen zum Absender zurückkehren. Daher eignen sich bouncebare Nachrichten für Smart-Contract-Interaktionen.
Nicht-bouncebare Zustellung ist nützlich, wenn ein Konto finanziert wird, das noch nicht initialisiert wurde. In TON sind Wallets Smart Contracts, und ihre Adressen können bereits vor dem Deployment bekannt sein. Ungeeignetes Bounce-Verhalten für ein nicht initialisiertes Ziel kann dazu führen, dass die Übertragung fehlschlägt, statt das Konto zu finanzieren.
Wie STONfi Adressen verwendet
Ein STONfi-Swap kann die verbundene Wallet, Jetton Masters, Router, Pools, Empfänger, Refund- und Excess-Adressen umfassen.
Das anfängliche Transaktionsziel ist der Contract, der die Wallet-Nachricht empfängt. Andere Adressen können innerhalb des Payloads als TON-Adresswerte mitreisen.
Seit STONfi SDK v0.5.0 verwenden generierte zu-Parameter bounceable Adressen, weil davon ausgegangen wird, dass Protokoll-Contracts existieren und die Logik ausführen. Das entspricht der TON-Praxis für etablierte Contract-Interaktionen.
Warum Entwickler Adressen parsen sollten
Ein häufiger Fehler ist, EQ… und UQ… als reine Strings zu vergleichen und anzunehmen, dass es sich um unterschiedliche Wallets handelt. Stattdessen sollte man sie in korrekte TON Address-Objekte parsen und die zugrunde liegende Workchain und Kontenkennung vergleichen.
Das ist wichtig für Integrationen, Validierung und die Erstellung von Transaktionen. Entwickler sollten die Workchain beibehalten und sich auf vertrauenswürdige TON-Tools zur Adresskodierung verlassen.
$STON $RAY
#BTC Preis-Analyse#
