Séparer l’interface du marché sous-jacent
Avant de commander un échange décentralisé, précisez ce que vous construisez : une interface pour des pools existants, un routage, de nouveaux pools ou des contrats spécifiques. Ces choix entraînent des responsabilités différentes. Un formulaire fonctionnel ne fournit pas de liquidité. Qui sélectionne les marchés, apporte la liquidité initiale et maintient l’intégration lorsque ses dépendances évoluent ? Inscrivez ces réponses dans le périmètre avant de comparer les démonstrations. Le devis doit distinguer le développement de l’application, l’exploitation du marché et l’examen indépendant des contrats éventuellement nécessaire.
Distinguer impact sur le prix et glissement
L’impact sur le prix décrit l’effet d’un échange sur son prix d’exécution à travers la liquidité disponible. Le glissement concerne une variation entre la cotation et l’exécution. Transformez ces notions en décisions compréhensibles plutôt qu’en une alerte unique. Pendant la revue, comparez une petite opération et une opération plus importante, puis discutez du message attendu. Augmenter largement la tolérance ne devrait pas devenir le remède habituel aux échecs. Définissez quand rafraîchir la cotation et quand une modification significative exige une nouvelle approbation du client.
Présenter la liquidité utile à la décision
Les positions de liquidité concentrée couvrent des plages de prix choisies. Fournir de la liquidité demande donc davantage que saisir deux soldes. Si le produit gère ces positions, expliquez comment le client voit leur plage et leur état actif. Pour l’échange, privilégiez les conséquences du parcours disponible sur l’ordre proposé plutôt qu’un gros chiffre de valeur totale. Demandez une démonstration avec un marché calme et un parcours peu liquide. L’interface doit rester compréhensible lorsqu’une paire connue ne permet pas une exécution raisonnable pour le montant demandé.
Faire de la cotation un accord vérifiable
Réunissez le parcours, le montant engagé, la sortie attendue, la limite d’exécution, le coût réseau estimé et les frais applicatifs. Signalez les estimations et ne remplacez pas silencieusement les conditions approuvées pendant que la confirmation du portefeuille est ouverte. L’autorisation d’utiliser un jeton constitue une décision distincte : son bénéficiaire et son montant doivent être identifiables. Lors de la réception, comparez l’écran lisible et la transaction préparée. Un évaluateur doit pouvoir expliquer comment le choix du client devient la demande envoyée au portefeuille, sans reconstruire plusieurs écrans.
Prévoir une suite pour chaque interruption
Énumérez les situations prises en charge : cotation expirée, solde insuffisant, refus dans le portefeuille, parcours absent, prestataire indisponible ou transaction toujours en attente. Déterminez quand demander une nouvelle cotation et quand vérifier d’abord une opération déjà envoyée. Conservez le parcours et la référence pour le support. Chaque erreur ne doit pas devenir une invitation à élargir la tolérance. Un message utile indique l’étape concernée et l’action encore possible, en conservant si pertinent la paire et le montant saisis par le client pour faciliter sa reprise.
Évaluer des conditions de marché réalistes
La réception doit couvrir plusieurs tailles d’ordre, une liquidité réduite, des réponses lentes, des jetons non disponibles et un changement de réseau en cours de parcours. Définissez explicitement les contrats et les environnements pris en charge. Documentez l’évaluation des nouvelles versions et la suspension d’un parcours au comportement incertain. Face à une comparaison de rapidité ou de prix, demandez la charge et les conditions de mesure. Un bon cahier des charges associe parcours cohérent, hypothèses de liquidité, états observables et maintenance au-delà de la démonstration initiale.