🔗 POURQUOI l’ENCHAÎNEMENT DES MESSAGES TON CHANGE L’EXPÉRIENCE DU STONfi SWAP
Un swap STONfi peut sembler être une seule action : connecter, confirmer, attendre. En réalité, TON fonctionne différemment d’une simple transaction en une seule étape. La requête passe par des smart contracts, et cette architecture influence l’exécution.
🧠 UN SWAP, PLUSIEURS MESSAGES
TON utilise une exécution asynchrone et sharded. Un swap passe donc par des messages plutôt que par un simple appel de fonction synchrone.
- Wallet → Router
- Router → liquidity Pool
- Pool → réponse
- Réponse → état final du wallet
Chaque message a sa propre phase de traitement. Un swap sur un seul pool a une chaîne plus courte. Une route multi-hop ajoute des étapes, donc attendre plus longtemps ne signifie pas automatiquement un échec.
⏱ POURQUOI STONfi A BESOIN D’UN ÉTAT « PENDING »
Cette architecture rend la différence entre soumis et complété importante.
Le premier message ne veut pas dire que l’ensemble du swap est déjà réglé. L’interface doit communiquer l’avancement.
Trois règles sont importantes :
- Ne renvoyez pas la requête juste parce que l’interface est en cours de traitement.
- Vérifiez le statut de la transaction avant de supposer que la première tentative a échoué.
- Traitez « pending », « failed » et « completed » comme des états d’exécution différents.
Le délai peut simplement refléter la chaîne.
🌉 LE CROSS-CHAIN ALLONGE LA CHAÎNE
Omniston ajoute une couche supplémentaire lorsque la destination se trouve sur une blockchain différente. Le flux côté TON doit se coordonner avec le règlement HTLC sur un réseau indépendant, qui a ses propres blocs et règles de confirmation.
C’est pourquoi un swap STONfi cross-chain peut prendre plus de temps qu’un swap TON-to-TON. La latence supplémentaire reflète la coordination entre deux systèmes distincts.
Le « pending » n’est pas nécessairement un problème — parfois, c’est simplement l’architecture qui montre son travail.
Ce n’est pas un conseil en investissement : faites vos propres recherches ! 🚀
$SOL
Un swap STONfi peut sembler être une seule action : connecter, confirmer, attendre. En réalité, TON fonctionne différemment d’une simple transaction en une seule étape. La requête passe par des smart contracts, et cette architecture influence l’exécution.
🧠 UN SWAP, PLUSIEURS MESSAGES
TON utilise une exécution asynchrone et sharded. Un swap passe donc par des messages plutôt que par un simple appel de fonction synchrone.
- Wallet → Router
- Router → liquidity Pool
- Pool → réponse
- Réponse → état final du wallet
Chaque message a sa propre phase de traitement. Un swap sur un seul pool a une chaîne plus courte. Une route multi-hop ajoute des étapes, donc attendre plus longtemps ne signifie pas automatiquement un échec.
⏱ POURQUOI STONfi A BESOIN D’UN ÉTAT « PENDING »
Cette architecture rend la différence entre soumis et complété importante.
Le premier message ne veut pas dire que l’ensemble du swap est déjà réglé. L’interface doit communiquer l’avancement.
Trois règles sont importantes :
- Ne renvoyez pas la requête juste parce que l’interface est en cours de traitement.
- Vérifiez le statut de la transaction avant de supposer que la première tentative a échoué.
- Traitez « pending », « failed » et « completed » comme des états d’exécution différents.
Le délai peut simplement refléter la chaîne.
🌉 LE CROSS-CHAIN ALLONGE LA CHAÎNE
Omniston ajoute une couche supplémentaire lorsque la destination se trouve sur une blockchain différente. Le flux côté TON doit se coordonner avec le règlement HTLC sur un réseau indépendant, qui a ses propres blocs et règles de confirmation.
C’est pourquoi un swap STONfi cross-chain peut prendre plus de temps qu’un swap TON-to-TON. La latence supplémentaire reflète la coordination entre deux systèmes distincts.
Le « pending » n’est pas nécessairement un problème — parfois, c’est simplement l’architecture qui montre son travail.
Ce n’est pas un conseil en investissement : faites vos propres recherches ! 🚀
$SOL
