Après avoir lu les informations de mise en ligne de la V2 pour le @TermMax , je suis d’abord allé voir le bilan de la V1. Les soucis des contrats à taux fixe ne viennent peut-être pas du fait qu’il n’y a pas de cotation, mais plutôt de l’argent réparti entre différents ordres, marchés et pages de la chaîne : voir un taux ne veut pas dire que le montant intégral peut être exécuté à ce taux.
Dans la V1, les ordres à fourchette du gérant de curation (range order) et les ordres à cours limité des utilisateurs sont affichés séparément. Pour emprunter un peu plus de fonds, il faut comparer les ordres un par un, puis accepter les variations de prix induites par chaque niveau de profondeur. Le taux peut être qualifié de « fixe », mais le coût d’entrée n’est pas forcément clair du premier coup.
La V2 corrige précisément cette couche. Les ordres unifiés lisent les ordres à fourchette du gérant et les ordres à cours limité personnels, puis les combinent en un seul chemin d’exécution ; l’utilisateur consulte une cotation, signe une fois, et le système exécute la combinaison au sein de la liquidité du même marché. Les ordres à cours limité sont aussi ouverts à chaque marché : le prêteur place le taux minimal acceptable, l’emprunteur place le taux maximal qu’il est prêt à payer, sans avoir à « manger » le prix affiché en profondeur insuffisante.
Ce n’est pas rendre le taux plus fixe, c’est déplier la friction du carnet d’ordres. C’est comme si au comptoir on écrit un prix : l’essentiel n’est pas seulement le prix indiqué, mais si la quantité que tu veux peut être obtenue à un prix proche. La V2 assemble les ordres, puis transmet un chemin exécutable.
Mais il y a une limite qu’on ne peut pas effacer d’un coup de main. Officiellement, il est question d’afficher, filtrer et comparer le marché inter-chaînes et le coffre (vault) sur une même interface ; rien ne dit que les fonds de différentes chaînes sont physiquement fusionnés en une seule piscine. La profondeur sur Ethereum ne va pas « traverser » automatiquement vers Base juste parce qu’on peut la voir sur sa page et exécuter la transaction à ta place. La liquidité on-chain, le Gas, le temps d’attente des ordres à cours limité et le volume réellement exécutable sont toujours comptés séparément.
Un autre point d’observation concerne la performance des grosses transactions. Un chemin plus fluide ne signifie pas que n’importe quel volume peut être obtenu au taux affiché en première page. Ce qu’il faut surveiller, ce sont les différences de cotations entre montants, les temps d’attente des ordres à cours limité, et le nombre de sources que combine une transaction ; ces éléments disent davantage sur la qualité d’exécution que « le nombre de chaînes supportées ».
Ainsi, la valeur de la V2 de #TermMax n’est pas simplement que la page devient plus concise, mais qu’elle sépare « le caractère déterminé du taux » et « le caractère déterminé de l’exécution ». Le premier est défini par le FT et la date d’échéance ; le second doit toujours être prouvé par la profondeur. L’interface peut dessiner le chemin, mais pour savoir s’il y a assez de « voitures » sur la route, il faut encore voir la transaction réellement exécutée. $BOME $BTC
Dans la V1, les ordres à fourchette du gérant de curation (range order) et les ordres à cours limité des utilisateurs sont affichés séparément. Pour emprunter un peu plus de fonds, il faut comparer les ordres un par un, puis accepter les variations de prix induites par chaque niveau de profondeur. Le taux peut être qualifié de « fixe », mais le coût d’entrée n’est pas forcément clair du premier coup.
La V2 corrige précisément cette couche. Les ordres unifiés lisent les ordres à fourchette du gérant et les ordres à cours limité personnels, puis les combinent en un seul chemin d’exécution ; l’utilisateur consulte une cotation, signe une fois, et le système exécute la combinaison au sein de la liquidité du même marché. Les ordres à cours limité sont aussi ouverts à chaque marché : le prêteur place le taux minimal acceptable, l’emprunteur place le taux maximal qu’il est prêt à payer, sans avoir à « manger » le prix affiché en profondeur insuffisante.
Ce n’est pas rendre le taux plus fixe, c’est déplier la friction du carnet d’ordres. C’est comme si au comptoir on écrit un prix : l’essentiel n’est pas seulement le prix indiqué, mais si la quantité que tu veux peut être obtenue à un prix proche. La V2 assemble les ordres, puis transmet un chemin exécutable.
Mais il y a une limite qu’on ne peut pas effacer d’un coup de main. Officiellement, il est question d’afficher, filtrer et comparer le marché inter-chaînes et le coffre (vault) sur une même interface ; rien ne dit que les fonds de différentes chaînes sont physiquement fusionnés en une seule piscine. La profondeur sur Ethereum ne va pas « traverser » automatiquement vers Base juste parce qu’on peut la voir sur sa page et exécuter la transaction à ta place. La liquidité on-chain, le Gas, le temps d’attente des ordres à cours limité et le volume réellement exécutable sont toujours comptés séparément.
Un autre point d’observation concerne la performance des grosses transactions. Un chemin plus fluide ne signifie pas que n’importe quel volume peut être obtenu au taux affiché en première page. Ce qu’il faut surveiller, ce sont les différences de cotations entre montants, les temps d’attente des ordres à cours limité, et le nombre de sources que combine une transaction ; ces éléments disent davantage sur la qualité d’exécution que « le nombre de chaînes supportées ».
Ainsi, la valeur de la V2 de #TermMax n’est pas simplement que la page devient plus concise, mais qu’elle sépare « le caractère déterminé du taux » et « le caractère déterminé de l’exécution ». Le premier est défini par le FT et la date d’échéance ; le second doit toujours être prouvé par la profondeur. L’interface peut dessiner le chemin, mais pour savoir s’il y a assez de « voitures » sur la route, il faut encore voir la transaction réellement exécutée. $BOME $BTC
