Evolution of the Oracle protection threshold (USDREG Conversion)" ?

Seb

Ne pas l’admettre, c’est comme ne pas admettre une maladie, impossible d’administrer le bon traitement…

EzSwim

Les 3 Solutions viables discutées sur le forum on été détaillées ce matin dans le 1er message (je t'invites à y jeter un oeil), laisse moi le temps de réécrire plus proprement la 2ème par rapport à la discussion que j'ai eu avec @DRKTT et je fais le sondage après.

Seb mais la situation actuelle n’est pas tenable

Ça ne sert à rien de répéter que le temps presse, etc... Tous ceux qui ont porté attention à ce sujet le savent. Malheureusement, je ne suis pas payé par la DAO pour délaisser mes autres responsabilités à ce jour. Donc ça prendra le temps que ça prendra. Maintenant, si tu n'es pas satifait des délais, je t'invite à ouvrir des suggestions à l'avenir où tu auras le contrôl sur l'avancé des sujets abordés 🙂

PhilP

EzSwim
Super travail, sur un sujet pas simple !
Mes remarques :

c'est quoi "l'inflation relative" de 20% ?

avec 800K USDREG et un supply de 500 million de REG : le seuil de 0,5 correspond à une inflation de 0,32% (pas 0,4),

c'est quoi une "inégalité temporelle entre convertisseurs", alors que la conversion est par construction fonction de l'oracle ?

c'est quoi " la fenêtre d'opportunité", puisqu'avant le vote tout le monde a intérêt à attendre la baisse : où est l'opportunité ?

concernant le "point fort" : "permet d'accompagner la baisse progressive du REG", en quoi est un point fort, puisque ce mode d'action de créer (et pas accompagner) la baisse ?

que signifie "chaque retard accroît l'arbitrage potentiel" ?

que signifie "si plusieurs baisses rapides sont votées" puisque cette solution est appliquée tous les x jours (sans autre vote)?

dans le tableau finale, dans le risque de sur-inflation, pour le scénarion "baisse périodique" le chiffre inscrit est très sous évalué au vu des simulations faites par @Saitama

que signifie (seuil jamais inférieur à l'anti-hack)

EzSwim

PhilP c'est quoi "l'inflation relative" de 20% ?

Dans le tableau, cette colonne compare la quantité de REG frappés après le gel à celle frappée avant.
• Avant le krach : 1 USDREG → 1,67 REG (prix 0,60 USD)
• Après le gel (0,50 USD) : 1 USDREG → 2 REG.
Le nombre de REG créés par coupon augmente donc de (2 − 1,67)/1,67 ≈ 20 %.

PhilP avec 800K USDREG et un supply de 500 million de REG : le seuil de 0,5 correspond à une inflation de 0,32% (pas 0,4),

Oui c'est fixé

PhilP c'est quoi " la fenêtre d'opportunité", puisqu'avant le vote tout le monde a intérêt à attendre la baisse : où est l'opportunité ?

J'ai pas retrouvé

PhilP concernant le "point fort" : "permet d'accompagner la baisse progressive du REG", en quoi est un point fort, puisque ce mode d'action de créer (et pas accompagner) la baisse ?

Pas retrouver (je sais pas si c'est pas sur l'ancienne version).

PhilP dans le tableau finale, dans le risque de sur-inflation, pour le scénarion "baisse périodique" le chiffre inscrit est très sous évalué au vu des simulations faites par @Saitama

En fait j'ai éditée parce qu'après reflexion, je sais pas trop les conséquence inflationiste que ça peut avoir avec les boucles.

PhilP que signifie (seuil jamais inférieur à l'anti-hack)

J'ai reformulé => je voulais indiquer que l’algorithme ne descend jamais en dessous du niveau calculé, donc ne compromet pas la fonction coupe‑circuit

Pour les trucs que j'ai pas trouver, est-ce que tu peux me les "citer" stp pour pas que j'ai à les chercher

DRKTT

EzSwim

Attention, suite à la remarque de PhilP sur TG j'ai revu mes paramètres et corrigé l'erreur (on part pas de 0.53 mais de 0.50)

Voir le détail ici : https://forum.realtoken.community/d/48-evolution-of-the-oracle-protection-threshold-usdreg-conversion-/97

PhilP

EzSwim ??? mais contrôlable selon X, Y, Y′ et le timing

Absolument pas contrôlable, une fois les 4 paramètres fixés par vote.

Je ne comprends pas pourquoi le risque majeur (de spirale mortelle) pour la solution 2 apparait nul par dans ta synthèse??.

PhilP

EzSwim Calcul et monitoring plus complexes (lecture racine Merkle + supply on‑chain).

Le supply des REG est extrêmement simple à trouver, sur un explorateur.
Le nombre d'USDREG restant a claimer, est un peu plus complexe à trouver, mais @DRKTT nous a déjà donné des valeurs.

PhilP

EzSwim Conversion figée puis, après déclenchement (écart Y′ %), abaissement du seuil et conversion à un taux plus élevé

La conversion n'est pas figée, puisque dès que le REG sera a nouveau inférieur au seuil (de 10% dans la dernière version sur TG) le seuil sera à nouveau réduit (de 35% dans la dernière version) : d'ou la spirale..

MattDev

Serait-il simple de changer le contrat pour que lorsque le prix est sous le seuil alors le seuil est utilisé au lieu d'abandonner, et donc, de conserver l'ancien prix ? Je pense que ça serait plus clair et intuitif, par exemple actuellement le claim serait à 0.5 au lieu de 0.53.

Sans cela, il est possible qu'une baisse du seuil n'aboutisse pas à un changement de prix, ce qui est contre-intuitif et empêche des stratégies de baisse progressives en restant au dessus du cours. Par exemple baisse du seuil actuel à 0.4, le claim resterait quand même bloqué à 0.53.

Cela serait plus cohérent avec la volonté, qui semble se dégager chez plusieurs intervenants, d'utiliser ce seuil pour fixer une limite basse afin de limiter l'inflation, alors qu'il a manifestement été conçu (dans son implémentation) comme un système de coupure d'urgence en cas de hack.

Pour moi le mécanisme actuel du seuil ne correspond plus à ce que plusieurs souhaitent en faire.
Par exemple, avec seuil à 0.5, claim et prix à 1$, puis chute très rapide à 0.1 $ :
-> logique actuelle anti-hack : le prix reste à 1$
-> logique limite d'inflation : le prix descend à 0.5 $

PhilP

MattDev Pour moi le mécanisme actuel du seuil ne correspond plus à ce que plusieurs souhaitent en faire.
Par exemple, avec seuil à 0.5, claim et prix à 1$, puis chute très rapide à 0.1 $ :
-> logique actuelle anti-hack : le prix reste à 1$
-> logique limite d'inflation : le prix descend à 0.5 $

Le seul objet de la présente proposition est de trouver une façon d'actualiser la valeur du seuil.
Aucune modification dans le fonctionnement : de l'oracle et de la conversion.
Dans ton exemple :
-> "logique actuelle anti-hack" : l'oracle décroit (à la moyenne de la veille) jusqu'à ce que la moyenne passe sous le seuil,
-> "logique de limite d'inflation" : le comportement de l'oracle est identique, cette "logique" est juste une façon d'actualiser la valeur du seuil.

MattDev

Pour mon exemple, on ne s'est pas compris, je parlais d'une hypothèse ou le prix chute brutalement en cas de hack de 1 à 0.1, donc aucune mise à jour car le prix passe sous le seuil. C'était juste pour illustrer les deux manière possibles d'utiliser ce seuil si on pouvait changer le contrat.

Je ne savais pas que les propositions étaient aussi rigides.

On est donc très limité dans les valeurs possibles car tout nouveau seuil au dessus du prix sera ignoré et ne servira donc à rien, à part en cas de remonté au dessus . Ce mécanisme empêche de faire des baisses plus progressives (par ex 0.4) puisque le prix de claim ne bougera pas tant qu'on ne va pas au moins un peu en dessous du prix actuel.

Le mécanisme actuel du fonctionnement du seuil n'est pas bien adapté à ce que vous voulez en faire...

PhilP

MattDev Je ne savais pas que les propositions étaient aussi rigides.

On peut proposer tout ce qu'on veut, le problème est d'être compris par ceux qui vote, et qui ont un temps limité a y consacrer.
Rester sur la question d'origine (comment actualiser le seuil), "simplifie" le débat et aide à converger.
D'autre suggestions , comme celle de la modification du contrat, pouvant voir le jour séparément.

MattDev si on pouvait changer le contrat.

OK, si ton exemple, sert a démontrer l'intérêt d'un changement du contrat, il pourrait être tourné comme suit :
En cas de baisse brutale (1 à 0,1), conduisant la moyenne à passer sous le seuil :

avec le contrat actuel : l'oracle reste à 1,
avec te contrat modifié l'oracle passerait à la valeur de seuil.

MattDev On est donc très limité dans les valeurs possibles car tout nouveau seuil au dessus du prix sera ignoré et ne servira donc à rien,

Pour mémoire, le seuil sert juste de protection en cas de hack de l'oracle. Il n'est donc pas grave qu'un nouveau seuil ne change rien en temps normal. Cette baisse ne servant pas à rien, puisqu'elle modifiera l'impact en cas de hack.

« Previous Page