Benoist-Not-for-sale Je ne comprends pas la "fixation" sur bot "centralisé".
Je comprends ton point de vue, et évidemment qu’aucun système (y compris les oracles) n’est fiable à 100%. Mais c’est justement pour cette raison qu’on doit concevoir un système capable de résister même à des cas extrêmes.
Ce n’est pas une question de paranoïa, c’est une question de responsabilité :
-> On ne parle pas d’un petit bot pour trader des NFTs de poche. On parle d’un système automatique qui pourrait mobiliser des pools de plusieurs millions de dollars appartenant à des utilisateurs tiers.
Benoist-Not-for-sale Si on part du principe que l'api va renvoyer des données fausses autant arrêter de suite.
Quand tu dis “si l’API est fausse, autant arrêter tout de suite” : non, justement.
Il faut se dire “que faire si elle est fausse ?”
Car un attaquant malin ne va pas tenter de la fausser tout le temps. Il va attendre le bon moment, une opportunité juteuse, et injecter une donnée modifiée pour déclencher une transaction malicieuse. Et si derrière, il n’y a aucune vérification on-chain, aucun oracle, aucun garde-fou, la transaction passera.
Sur la question du bot “centralisé” : oui, je sais qu’un smart contract a besoin d’un trigger externe. Mais la vraie inquiétude vient du fait que le bot soit une autorité de validation en soi, et qu’il concentre toute la logique de décision.
S’il est compromis ou mal codé (ou même juste mal configuré), il met potentiellement toute la pool en danger.
Donc l’idée n’est pas de diaboliser le bot ou l’API, mais de réfléchir dès maintenant à ce qu’il se passe si une pièce de la chaîne est attaquée.
Parce que dans la vraie vie, ça arrive. Et plus il y a d’argent, plus les incentives pour attaquer augmentent.
J'ai fait un schéma rapidement pour illustrer l'architecture de la solution de base (et désolé d'avance si j'ai pu me tromper quelque part) :
Imaginons un scénario d'attaque possible.
- Un acteur malveillant liste un token RealT sur le YAM à un prix largement au-dessus de sa valeur réelle.
- En parallèle, il falsifie temporairement les données de l'API communautaire consultée par le bot (ou exploite une faille connue).
- Le bot, pensant détecter une opportunité d'achat conforme aux critères (car il lit des données erronées), déclenche un achat automatique.
- La pool se retrouve à acheter un token surévalué.
Note : Même si l'attaquant est KYC, le dommage est fait. Et si plusieurs tokens sont concernés, ça peut chiffrer très vite.
Une solution à ce genre de problème : Oracle + Vérification On-chain
Pour éviter ce genre de scénario, la seule manière de sécuriser le système de façon sérieuse est la mise en place :
- D’un oracle fiable pour fournir des données de marché précises, résistant à la manipulation (ex. Chainlink, mais il n’existe pas encore pour RealT).
- D’une vérification on-chain par le smart contract, qui s’assure que chaque achat respecte réellement les critères des utilisateurs avant d’exécuter quoi que ce soit.
Mais cette solution pose deux problèmes majeurs :
- Temps de traitement : une vérification on-chain ralentira inévitablement l’achat, ce qui rendra inutile l'avantage supposé d’un bot “rapide”.
- Complexité : créer un oracle spécifique à RealT est une étape supplémentaire, coûteuse et technique. On n’en est clairement pas là aujourd’hui.
Et la priorisation des utilisateurs dans la pool ? Un autre challenge : Comment répartir équitablement les opportunités entre les utilisateurs de la pool ?
- Priorité aux premiers arrivés ? Compliqué, car certains vont "squatter" la pool sans réelle intention d’achat.
- Priorité au montant de REG staké ? Peut créer un déséquilibre : un seul gros détenteur pourrait rafler toutes les opportunités.
- Priorité au prorata du montant bloqué ? Encore faut-il que les conditions soient identiques...
Une alternative : modèle en carnet d’ordre inversé
Je continue à penser qu’un modèle plus simple et plus sécurisé serait un carnet d’ordre directement intégré dans le YAM.
Fonctionnement :
- Chaque investisseur place des ordres d’achat avec ses propres critères (prix max, score, rendement, etc.)
- Un vendeur peut instantanément matcher un ou plusieurs ordres en vendant son token
- Le smart contract gère les matching et les transferts, sans intermédiaire
Avantages :
✅ Pas besoin d’oracle : toute la logique est contenue on-chain, donc pas de dépendance à une source externe potentiellement manipulable
✅ Transparence & auditabilité : toutes les règles sont dans le smart contract, donc lisibles, prévisibles, et vérifiables
✅ Réduction des risques : pas d’attaque possible via une API falsifiée ou un bot compromis
✅ Pas de problème de priorité : le vendeur choisit directement parmi les ordres disponibles
C'est beaucoup plus décentralisé, transparent et sécurisé.
Et au final, j'imagine qu'une personne qui voudra vendre un token qui sera une "opportunité valide" pour les utilisateurs de la pool, choisira plutôt vente rapide (car l'ordre sera automatique déclenché) plutôt qu'une vente classique (dans le cas des bots) -> puisqu'il pourra effectuer sa vente instantanément, ça rajoute donc de la liquidité.
Et l'important surtout, c'est d'en discuter. Donc merci car tu relève aussi certaine choses importante comme le fait que la création d'un carnet d'ordre pourrait amener de la complexité au YAM, alors que cela devrait rester simple.
J'ai donc estimé que faire une comparaison des deux solutions serait un bonne idée. Peut-être que l'auteur de la suggestion pourrait créer un tableau avec les différentes propositions et leurs avantages/défauts ?
PS : En y réfléchissant, pour que l'argent des utilisateurs génère du revenu en attendant un swap, il faudrait donc utiliser le RMM -> mais est-ce que les stablecoins prêté dans le RMM peuvent être sortis à n'importe quel moment en cas de swap ? Je crois que non, et dans certain cas partiellement ?
