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

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

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é.

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.

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).

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