Kevin Lallement

🔄 J'ai réalisé une refonte complète du module de swap de @MiddleStaking et pour le déployer simultanément sur @TheDinoVox, j'en ai fait un package réutilisable.

Voilà ce qui change.

---

⚙️ Comment ça marche ?

Un backend référence les pools de @xExchangeApp et @TheDinoVox, surveille l'activité de chaque paire activée, et calcule la meilleure route possible — jusqu'à 3 swaps agrégés dans une seule transaction.

Pas de multi-step manuel. Une tx, le meilleur prix disponible.

---

📦 Ce qui est déjà en ligne

~80 tokens répartis sur une centaine de paires sont déjà activés.

Le référencement des nouvelles paires n'est pas encore automatique — volontairement, pour tester le back tranquillement. Mais si votre token est listé sur @xExchangeApp et qu'il n'apparaît pas dans la liste, envoyez-moi un message, je l'ajoute au cas par cas.

---

🔁 Ce que reçoit le front en réponse

Quand un utilisateur sélectionne ses tokens, son montant et son slippage, le module interroge le back qui retourne la route optimale — avec le détail de chaque hop, le price impact, et directement les datas de la tx à signer.

```json
{
"tokenIn": "EGLD",
"tokenOut": "MID-ecb7bf",
"amountIn": "1000000000000000000",
"amountOut": "1016635251539218381621",
"priceImpact": "0.016000",
"hops": 2,
"route": [
{
"pair": "erd1...q",
"tokenIn": "WEGLD-bd4d79",
"tokenOut": "USDC-c76f1f",
"amountIn": "1000000000000000000",
"amountOut": "4236142",
"dexType": "XExchange",
"priceImpact": "0.003000"
},
{
"pair": "erd1...l",
"tokenIn": "USDC-c76f1f",
"tokenOut": "MID-ecb7bf",
"amountIn": "4236142",
"amountOut": "1019694334542846922388",
"dexType": "XExchange",
"priceImpact": "0.013000"
}
],
"tx": {
"scAddress": "erd1...k",
"txData": "multiPairSwap@...",
"gasLimit": 52000000,
"egldValue": "1000000000000000000"
}
}
```

Le front n'a plus qu'à faire signer. Toute la logique de routing reste côté back.

---

🛡️ Sécurité utilisateur

La tx signée passe par un smart contract qui tente d'exécuter les opérations avec les paramètres de l'utilisateur. Si le montant final est insuffisant (slippage dépassé ou autre), l'ensemble est annulé et les fonds sont retournés automatiquement.

---

💧 Nouveauté : création de pools de liquidité

Cette version introduit aussi la possibilité de créer une paire de liquidité au sein de l'écosystème MID/DinoVox. Dans un premier temps avec $MID en tokenA uniquement — extensible à d'autres tokens plus tard. Chaque pool déployée génère son propre contrat et émet son LP token dédié.

---

🧱 Pour les devs

Le module est packagé pour être intégré côté front ou back. La réponse JSON est pensée pour minimiser la logique à embarquer côté client : route, price impact, txData, gasLimit — tout est là.

Si vous buildez sur @MultiversX et que ça vous intéresse, DM ouvert.

---

Cette version est une grosse amélioration par rapport à ce que j'avais mis en place il y a 3 ans. Elle n'est pas finale — elle évoluera en fonction des retours et des perfs observées.

Comme toujours. 🙂

$XMPH utilise le tout nouveau carnet d'ordres limit du dex @TheDinoVox

L'agrégateur vous propose la route la plus efficiente en en traversant plusieurs DEX.

Je vous détail tout ca prochainement.
app.dinovox.com/swap

Depuis une semaine, on observe un acteur malveillant qui passe en revue les Smart Contracts du réseau MultiversX.

Un par un, de manière méthodique, il cherche à extraire la moindre valeur mal protégée.

Le rythme et la méthodologie de chaque exploit constaté semblent indiquer un processus automatisé : un agent récupère le code de chaque contrat, liste les fonctions existantes, vérifie les autorisations liées à chaque fonction (only owner vs public), puis cherche un vecteur d’attaque en simulant le résultat de la transaction.

Si l’agent trouve quelque chose, il exécute l’attaque en soumettant des transactions pour mettre en œuvre le scénario découvert.

Les failles que j’ai analysées parmi les dizaines de Smart Contracts touchés présentent deux principaux vecteurs d’attaque.

Le premier est l’utilisation de fonctions qui auraient dû être réservées à l’owner du Smart Contract, mais qui sont restées publiques.

L’oubli de la macro #[only_owner] sur un endpoint permet à tout le monde d’exécuter une fonction qui aurait dû être réservée au propriétaire du contrat.

L’attaquant a exploité cette faille pour modifier des paramètres sensibles, comme une adresse ou un token utilisé dans la logique du contrat, lui permettant ainsi d’extraire ou de rediriger des fonds vers son wallet.

Le second est plus technique. Il consiste à appeler des fonctions publiques en leur envoyant des paramètres que le développeur n’avait pas pensé à vérifier.

Quelques exemples :

Payer le bon montant, mais avec un autre token.
Payer avec le bon token, mais avec un montant incorrect.
Exploiter une fonction qui accepte deux identifiants identiques alors qu’ils auraient dû être différents.

Une grande partie de ces contrats ont été développés avant l’avènement de l’IA telle qu’on la connaît aujourd’hui.

Si vous avez écrit des contrats par le passé, faites-les passer à la moulinette pour détecter d’éventuels oublis.

Si vous développez des Smart Contracts aujourd’hui, avec ou sans IA, challengez votre agent pour qu’il recherche des scénarios d’exploitation liés à ce type d’oubli.

Faites également relire et auditer votre code par des sources externes.

Ce n’est pas parce que votre code fonctionne qu’il ne peut pas être détourné pour un usage que vous n’aviez pas anticipé.

Pour finir sur une note positive, la majeure partie des fonds extraits par l’attaquant ont été bloqués au niveau du bridge.

🦁 Nouveau validateur sur le liquid staking !

Dans l'objectif de soutenir la décentralisation, ROAR Community Validator a été ajouté au set de validateurs sélectionnés pour participer à la composition des intérêts du token liquide $VOXEGLD 🦖.

Dès à présent, vous pouvez déposer à partir de 1 EGLD sur Graou Protocol et choisir vous-même où ils sont stakés : onglet Déposer → mode Direct → ROAR Community Validator, le staking provider de @ROARHighSpeX 👇

app.dinovox.com/providers

Do you Kwak it ?