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

EzSwim

Thank you for the additional information! That was very detailed and brought insights on how the minAnser and maxAnswer were initially chosen.

Saitama The lower bound (0.5 USD) sets a limit on this inflation.

Did you mean the threshold mechanism in itself sets a limit on the USREG conversion inflation or that 0.5 USD is a good enough number to limit this inflation ?

Saitama

EzSwim
I mean it's setting a limit for inflation. But it might not be a good value now since the value was chosen before launch.
Now it's up to the community to decide

which value it should be (0.5, 0.1, 0.01,...)
and which mechanism to use to adjust this value (through the security committee or each DAO vote for an update).

Michael-RealT

DRKTT Donc le comité de sécurité doit pouvoir

Changer le seuil en fonction du risque de hack
Mettre en pause le contrat d'échange en cas de hack.

Ni plus ni moins.

d'accord pour la mise en pause, par contre pour le changement d'un paramètre je pas aussi convaincu de cela.
a la base du comité de sécurité dans la mission initial (qui peux bien évidement évoluer) il est question de pouvoir uniquement mettre en pause des contrats, sans autres action possible.
cela permet de tester le comité, de le construire, de le former sans prendre de risque.

donné le pouvoir a un comité naissant de pouvoir modifier une valeur comme celle la peux etre un risque, sur tout au début quant nous ne somme pas sur du bon fonctionnement du comité, que les bonnes pratique ne sont pas en place.

ce seuil ne devrais pas etre modifier toutes les semaine, en tout cas dans le future il faut espérer avoir un seul qui entre en action rarement, si telle es le cas il es envisageable selon la politique d'utilisation du seuil et de mise a jours, que cette mise a jours soie uniquement effectuée par vote, cela prend 10j pour un vote se qui peux être acceptable ou non, dans tout les cas cela serais plus sur que de passer par un comité ou encore une entité de confiance

DRKTT

Michael-RealT

Vu qu'il s'agit d'un seuil de sécurité, je trouve complètement aberrant de devoir procéder à un vote à chaque modification.

Ce seuil de sécurité anti-hack est actuellement bien en dessus du cours actuel depuis déjà plusieurs jours.

C'est pas normal.

J'ai bien compris que tu ne souhaites pas quelque chose d'automatique qui dirait par exemple, fixer automatiquement le seuil à 20% en dessous de la moyenne des 3 derniers jours. Car l'automatisme peut présenter un risque. Il faut donc le faire manuellement. Mais passer par un vote à chaque fois c'est contre-productif, c'est le contraire de l'agilité et c'est surtout totalement absurde.

PhilP

Michael-RealT

dans la solution que je propose ( PhilP ) :

la DAO vote sur le taux d'inflation maximum admissible (le mode de calcul du seuil et de sa fréquence),
le comité ne fait qu'exécuter ce qui a été voté : actualisation du seuil à la fréquence prévue.

ainsi le comité ne porte qu'une responsabilité limité.

PhilP

DRKTT C'est pas normal.

cela me semble tout a fait normal, car comme le souligne @Saitama: est il juste de minter des REG dans un marché aussi illiquide ?

Il faut qu'un "garde fou" s'applique à RealT, dans sa capacité à créer des REG (via USDREG).
C'est à la DAO de fixer cette limite.
Hors situation de hack, c'est à dire le plus souvent, le seuil va être ce "garde fou" (par par choix, mais comme une conséquence : PhilP )

Le marché reste pour autant libre et si tous le monde vend dans cette période d'illiquidité, le cours tombera et le seuil n'y pourra rien et le convertisseur ne pourra être stoppé.
Le seuil évitera juste, qu'à cause d'un cours très bas, RealT se retrouve à distribuer trop de REG (et comme le dit @Saitama fasse encore plus chuter le prix !.. et engendre une spirale mortifère)

Saitama

DRKTT
Le contrat a été conçu d'une façon qu'une entité comme le DAO, qui détient le MODERATOR_ROLE, peut mettre à jours des paramètres pendant son usage si c'est nécessaire:

Paramètres lié directement au Chainlink: LINK token, Chainlink oracle, JobID, Fee, Multifactor (transformer le prix en 8 decimals comme le norme de Chainlink).
Paramètres des sources de prix offchain/onchain: api url, api path, twap oracle, twap interval (intervalle pour calculer TWAP).
D'autres paramètres du contrat de sécurité: minAnswer, maxAnswer, twap range diff factor (difference tolerance between TWAP onchain/offchain).
Fonctions custom: setPriceByAdmin (manuellement exécuté, vérifié toujours avec TWAP onchain et min/max range) et cancelChainlinkRequest (en cas si le request d'update a eu un problème).

Le changement de ces paramètres ne peut pas être pris à la légère. A mon avis, le DAO sera la seule entité dans le futur qui peut éxecuter le changement de ces paramètres (même s'il s'agit un seuil de sécurité). Ce sera aussi le cas pour les paramètres de RMM, YAM, DEX,...
Un update des paramètres = vote DAO comme Aave, Uniswap,...

La comité de sécurité est effectivement plus adapté pour agir rapidement, par example mettre en pause le contrat en cas d'exploit détecté.

Michael-RealT

DRKTT Vu qu'il s'agit d'un seuil de sécurité, je trouve complètement aberrant de devoir procéder à un vote à chaque modification

j'ai jamais dis qu'il fallait un vote a chaque fois, mais voter sur une politique de modification c'est très différant

DRKTT

PhilP cela me semble tout a fait normal, (...) est il juste de minter des REG dans un marché aussi illiquide ?

Non ce n'est pas normal car rien a été décidé ni voté sur le sujet.

Je me demande comment tout cela se serait déroulé si les REG avaient été directement envoyés sur les wallets (la fameuse solution A tant plébiscitée à l'époque).

PhilP

EzSwim Yup saw at the time I wrote the "How the oracle algorithm works". But I won't be updating it everytime it chages that's why I specified the dates (at the time of the vault release).

Je ne pense pas que cette valeur soit modifiée souvent, cf @Saitama : "The initial tolerance difference was 5% and now at 10% (after the USDREGConversionVault launch)."

EzSwim Yes the oracle returns a USD value. 1 USDREG = 1 USD

Certes 1 USDREG = 1 USD, les valeurs sont identiques mais ce n'est pas du tout la même chose et ça pourrait créer de la confusion :

l'USDREG est un droit à convertir, uniquement en REG et non transférable,
l'USD est est une monnaie, utilisable pour n'importe quoi et facilement transférable.

EzSwim

PhilP Ce qui serait décidé par la DAO, serait un % d'inflation maximum acceptable lors d'un hack (de l'oracle). Un % d'inflation, s'établi à partir de la quantité total de REG existants (mintés).

I don't understand why @PhilP's idea revolving around the USDREG supply and the amount of hacked inflation we are okay with, was so easily dismissed. If we give Pausable rights to the security committee (as a last resort) as well it seems to be a solid solution where it'll be hard to cheat and we don't have to manually change the threshold

PhilP

Saitama

Merci pour ces détails.
J'ai fait de mon coté un document, à destination du wiki, pour expliquer en détail "Comment ça Marche" : https://docs.google.com/document/d/1ffzpBoCnFEIWVEDlnx2tlCWs9YG-RQzpMoy7AMyQ9nQ/edit?usp=sharing

Pourrais tu le relire, corriger, voir proposer des compléments (je peux, si besoin, te le partager en mode éditeur).
D'autres relecteurs, peuvent aussi me faire leur propositions.
Le document sera traduit en anglais par la suite.

DRKTT

Saitama

Saitama Le changement de ces paramètres ne peut pas être pris à la légère

Est-ce quelqu'un a prétendu le contraire ?

A mon avis, le DAO sera la seule entité dans le futur qui peut éxecuter le changement de ces paramètres (même s'il s'agit un seuil de sécurité).

Je ne suis pas de cet avis. Dans le cas précis, la DAO peut très bien définir et voter une stratégie anti-hack (par exemple de rabaisser périodiquement le seuil anti-hack à 20% en dessous du seuil actuel si ce dernier est à plus 20% au dessus du prix moyen sur les dernières 24 heures) et que cela serait au comité de sécurité d'être en charge de l'exécution de cette stratégie anti-hack.

EzSwim

DRKTT Je me demande comment tout cela se serait déroulé si les REG avaient été directement envoyés sur les wallets (la fameuse solution A tant plébiscitée à l'époque).

Easy to answer, there would have been no need for the thresholds since the conversion would have been done according to the market price of the REG at the time. No hack possible, no hyperinflation either. No issue to debate about.

Solution B was voted because DAO members wanted to be able to swap for REG when they felt like it = when prices were low (it gives them the possibility to accumulate REG for less $$$). Therefore, not lowering the threshold at this point is for one not normal as you said, but I would go further and say it goes against what the DAO voted in the RIP-9.

Now that's been said, This PhilP is best option by far. Instead of voting each time we could vote on what the DAO thinks is the right inflation in case of a hack and the security committee updates it weekly or monthly manually (after the calculations are done) and see how that goes. When that is done and we see it works fine, we could always iterate and automate the calculation on-chain or whatever so that the security committee only has the manage the pausable option.

TL;DR
I am against an arbitrary number like let's lower the threshold by 20% and I am for the threshold to follow along the circulation supply of REGUSD. I am against making the DAO vote each time when the threshold needs to be changed and I am for delegating this task to the security committee.

PhilP

DRKTT

Là encore, c'est normal que "rien a été décidé ni voté sur le sujet." :
L'écosystème se construit, avec une première solution créée par RealT.
Ainsi, les membres de la DAO peuvent comprendre comment ca marche et APRES, se poser les bonnes questions sur les paramètres à revoir compte tenu de l'usage de la solution.
Il est donc normal qu'on se pose la question du seuil, que maintenant.

PhilP

DRKTT rabaisser périodiquement le seuil anti-hack à 20% en dessous du seuil actuel si ce dernier est à plus 20% au dessus du prix moyen sur les dernières 24 heures

Je suis contre une telle solution, qui engendrerait la spirale de la mort évoquée par Saitama
Plus le cours baisse => plus on baisse le seuil => plus de REG sont convertis => plus sont vendue => plus le prix baisse ...

DRKTT

PhilP Je suis contre une telle solution, qui engendrerait la spirale de la mort évoquée par Saitama
Plus le cours baisse => plus on baisse le seuil => plus de REG sont convertis => plus sont vendue => plus le prix baisse ...

Peux-tu me dire la relation entre la spirale de la mort et un hack ?

Là on ne parle plus de hack mais de protection du prix contre le marché lui-même. On ne peut pas soutenir d'un côté que l'inflation du à la distribution (indirecte) de REG lors des réévaluations n'a qu'une incidence marginale et de l'autre côté avoir peur de ses conséquences. A partir d'un moment donné, il faut être cohérent et il faut que marché se fasse. Autrement dit, il faut assumer les token economics.

Je ne vais apprendre à personne (enfin j'ose l'espérer) que la plupart des investisseurs de RealT sont là pour l'argent et pas la tech ni la DAO. Donc le réflexe naturel de cette majorité sera de vendre leurs REG. C'est pour lutter contre ce fait que j'avais émis cette proposition directement à RealT de limiter et à terme supprimer cette distribution (indirecte) de REG :

https://www.youtube.com/live/nn7eKY2tJiQ?t=1154s

Donc soit on va dans cette direction soit (et on peut faire les deux) il faut donner plus d'utilités au REG qu'un simple droit de vote dont la majorité des investisseurs RealT s'en carre le coquillage. Il parait que des choses vont arriver en juin sans plus de détails.

Là où je veux en venir c'est qu'il faut s'attaquer aux causes et non aux conséquences.

Bref, l'argument ne reposant pas sur une logique de hack mais sur une logique de protection du prix contre le marché, on rentre dans d'autres considérations et là il faudra voter sur ce sujet spécifique.

En attendant des personnes qui souhaiteraient échanger leurs USDC-REG au prix moyen du marché pour les vendre (et c'est leur droit) sont dans l'incapacité de le faire. Certains d'entre eux auraient peut-être même contribué à apporter de la liquidité. Et ça c'est pas normal.

Le courage augmente en osant et la peur en hésitant.

Proverbe romain.

PhilP

DRKTT Peux-tu me dire la relation entre la spirale de la mort et un hack ?

La relation est que, sous prétexte de se protéger d'un hack on mettrait en place une solution qui conduirait à la spirale de la mort.
Cf ton propos : "la DAO peut très bien définir et voter une stratégie anti-hack (par exemple de rabaisser périodiquement le seuil anti-hack à 20% en dessous du seuil actuel si ce dernier est à plus 20% au dessus du prix moyen sur les dernières 24 heures)"

L'objet de la présente proposition est de décider comment actualiser la valeur de seuil.
Ce seuil n'étant pas une "protection du prix contre le marché lui-même", le marché reste libre.

Le seuil ne doit pas être actualisé en fonction du prix du REG, mais de l'inflation maximum admissible.

Ce qui au passage à comme conséquence, d'aller dans le sens de ta proposition ("j'avais émis cette proposition directement à RealT de limiter et à terme supprimer cette distribution (indirecte) de REG") puisque comme je l'ai expliqué ce seuil limitera AUSSI la distribution de REG faite par RealT.

Cogatos

DRKTT Attention, on parle d'un hack de l'oracle qui est utilisé pour la conversion REG USD => REG.

Avant d'avoir une vente il va falloir minter 5M REG (dont pour 1 million de REG usd) et dans ton exemple il faudrait que le tout ceux qui ont pas échangé leur REG USD contre les REG le fasse à ce moment précis, avant que le comité de sécurité n'intervienne.

La personne qui détient le plus de REG USD non réclamé en a 33379 (dont mint max = 166895 REG à 1 seuil de 0.2. Si c'est l'attaquant oui il peut tout vendre mais ça serait pas très malin, RealT a son KYC.

Bien sûr, mais j'essayais de réfléchir à un exemple extrême pour éprouver la logique, même si la probabilité de survenance reste très faible.

J'ai pris connaissance de l'ensemble des discussions, et globalement je reste partisan du fait de ne considérer le seuil que comme protection contre un éventuel hack de l'oracle, ou comme l'indiquait Saitaman, à moins de considérer l'ensemble de l'écosystème dans la balance pour motiver un changement de façon réfléchie, au-delà de la seule question de la fluctuation du cours de conversion USDREG/REG par rapport au cours du REG actuel.

La proposition de PhilP reposant sur une fixation du seuil en fonction notamment d'un pourcentage d'inflation de REG induit me paraît aller dans le bon sens dans l'immédiat.

DRKTT En attendant des personnes qui souhaiteraient échanger leurs USDC-REG au prix moyen du marché pour les vendre (et c'est leur droit) sont dans l'incapacité de le faire. Certains d'entre eux auraient peut-être même contribué à apporter de la liquidité. Et ça c'est pas normal.

Dans le cadre du lancement, il fallait bien définir un seuil, rien n'empêche selon moi, les personnes qui attendent de pouvoir convertir, d'attendre un premier vote de la DAO venant modifier le seuil pour se positionner ensuite et revendre ultérieurement.

DRKTT

PhilP La relation est que, sous prétexte de se protéger d'un hack on mettrait en place une solution qui conduirait à la spirale de la mort.

Donc la solution A pour la distribution de REG était elle aussi une spirale de la mort

PhilP L'objet de la présente proposition est de décider comment actualiser la valeur de seuil.
Ce seuil n'étant pas une "protection du prix contre le marché lui-même", le marché reste libre.

Avant de voter comment on doit actualiser ce seuil il faut d'abord qu'on soit tous d'accord sur ce qu'est ce seuil et à quoi il doit servir. Et pour cela il faut apparemment voter également.

PhilP

DRKTT Donc la solution A pour la distribution de REG était elle aussi une spirale de la mort

Oui peut être mais ce débat est dépassé.

DRKTT il faut d'abord qu'on soit tous d'accord sur ce qu'est ce seuil et à quoi il doit servir. Et pour cela il faut apparemment voter également.

Le seuil est une fonction standard de la solution d'oracle Chainlink : il n'y a donc pas de vote à faire pour "qu'on soit tous d'accord sur ce qu'est ce seuil et à quoi il doit servir".
La seule décision que la DAO doit prendre c'est comment cette valeur doit être actualisée (vs sa valeur initiale au lancement de la solution).

« Previous Page Next Page »