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

PhilP

EzSwim
Donnes moi le titre que tu souhaites mettre et je vais faire la modification.

EzSwim

PhilP
Un titre comme: "🫷😬🫸Pushing the limits: Evolution of the Oracle protection threshold (USDREG Conversion)" ?

Cogatos

PhilP On voit donc que les variables à prendre en comptes, pour fixer le seuil, sont :
le % max d'inflation accepté lors d'un hack (paramètre qui serait fixé par la DAO)
le nombre de REG déjà mintés (paramètre mesurable lors de l'actualisation du seuil),
le nombre d'USDREG disponible (paramètre mesurable lors de l'actualisation du seuil)
(en gardant l'hypothèse extrême, que tous les USDREG disponibles pourraient être mintés lors du hack).

la variable du nombre de REG déjà mintés est considérée dans l'optique où tous les possesseurs de REG ou une grande majorité vendraient également leur REG suite au hack ou pour une autre raison ?

Si l'on part du principe qu'en cas de hack, une vente massive de REG mintés aurait lieu, une variable supplémentaire à considérer pour la définition du seuil pourrait être le niveau de liquidité disponible à un cours donné. En réalisant des simulations, il faudrait par exemple pouvoir s'assurer qu'en cas d'un tel événement, le cours du REG ne s'effondre pas, ou s'accorder sur un prix à maintenir, si l'on considère sa valeur comme étant un facteur susceptible de favoriser son adoption. Et dans ce cas, peut être faudrait-il ne pas forcément bouger les seuils tant que cette condition ne serait pas satisfaite ?

Concrètement, si demain il y avait un hack, avec un seuil à 0,2$, et une vente de 5 M de REG, portant sa valeur à $0.00204743 selon 1inch actuellement à l'instant t, est-ce que cela serait souhaitable pour la DAO ? Perso je ne pense pas.

DRKTT

Cogatos Concrètement, si demain il y avait un hack, avec un seuil à 0,2$, et une vente de 5 M de REG, portant sa valeur à $0.00204743 selon 1inch actuellement à l'instant t, est-ce que cela serait souhaitable pour la DAO ? Perso je ne pense pas.

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.

Un seuil de 0.2 protège le taux de conversion afin qu'il n'aille pas plus bas en cas de hack de l'oracle.
S'il un hack de l'oracle avait lieu et qu'il n'y avait pas de seuil de sécurité, le taux de conversion pourrait passer à 0.0001 et là avec 1000 USD REG chacun pourrait minter 10 millions de REG.

Comme indiqué plus haut, le seul devrait être abaissé périodiquement en fonction du marché et ça sera le rôle à mon avis du comité de sécurité de s'en charger.

PhilP

Cogatos

Cogatos la variable du nombre de REG déjà mintés est considérée dans l'optique où tous les possesseurs de REG ou une grande majorité vendraient également leur REG suite au hack ou pour une autre raison ?

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

Cogatos Concrètement, si demain il y avait un hack, avec un seuil à 0,2$, et une vente de 5 M de REG, portant sa valeur à $0.00204743 selon 1inch actuellement à l'instant t, est-ce que cela serait souhaitable pour la DAO ? Perso je ne pense pas.

Si tu souhaites maintenant intégrer l'impact de la vente des REG hackés sur le marché, il faudrait comme tu l'envisages fixer un maximum de décroissance admissible du cours du REG.
Imaginons que nous fixions un impact maximum admissible lors d'un hack de : 90% de réduction du cours (ou division du cours par 10 !)
Dans les conditions actuelles de liquidité, il faudrait vendre environ 300 K REG pour baisser le cours à ce point.
Pour que les 1 million d'USDREG disponibles, ne génère pas plus de 300 K REG il faudrait que le seuil de l'oracle soit ... à 3,3$ !
Pour les raisons expliqués précédemment, il n'est évidement pas possible de mettre le seuil minimum de l'oracle à ce niveau.

La simulation 1inch à 0,002$ a par ailleurs ses limites, car à partir d'un moment les détenteurs de REG s'arrêteront de vendre car ils toucheraient une sommes trop dérisoire.

PhilP

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

Hélas, quand le seuil sera atteint (a cause d'un hack ou des cours) tous les possesseurs d'USDREG (1 millions actuellement) pourront convertir et vendre leur REG, sans que le comité de sécurité n'y puisse rien !..

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.

PhilP

DRKTT
Je pense qu'on se comprend pas, reprenons :
@Cogatos : s'inquiète d'un seuil à 0,2$, qui pourrait engendrer une vente de 5 M de REG, portant sa valeur à $0.00204743
Ce à quoi tu réponds "Avant d'avoir une vente il va falloir minter 5M REG.. avant que le comité de sécurité n'intervienne".

Je confirme que lorsqu'on sera au seuil, le comité de sécurité n'aura aucun droit d'intervenir.
C'est une situation "normale" (sans bug, sans hack, qui justifierait l'intervention du comité de sécurité), nous seront juste dans une situation critique pour le REG si tout le monde vend en même temps !
Le paramètre de seuil de l'oracle, ne peut être une protection contre cette situation (cf PhilP )

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

MarkoeZ

I understand that there must be guardrails. That said, the 0.5 made sense when launching, but it should not stand in the way of a fair market going forward.
IMO, the minimum value should be revalued periodically to about 1/3rd of the current value at that time (as was the initial suggestion from Chainlink from what i gathered). Optimally with some weighted average like is currently the case with the daily valuations.

PhilP

MarkoeZ il ne devrait pas faire obstacle à un marché équitable à l'avenir.

Le seuil ne fait pas obstacle au marché équitable, il a deux fonctions :

protéger contre un hack de l'oracle,
et, limiter l'attribution de nouveaux REG par RealT : PhilP

MarkoeZ environ un tiers de sa valeur actuelle

Le cours du REG ne doit pas être un paramètre d'actualisation du seuil.
Il pourrait l'être au titre de sa première fonction (protection d'un hack de l'oracle), mais pas au titre de sa seconde fonction (limitation de l'attribution de REG par RealT).

Prenons un exemple, pour mieux comprendre :

RealT a évalué qu'il devrait attribuer 10 millions d'USDREG, au titre de ses ventes depuis 5 ans,
soit une moyenne de 2 millions d'USDREG par an,
si le cours du REG était significativement en dessous du seuil actuel : imaginons à 0,06 $,
si le seuil était actualisé à 1/3 du cours, nous aurions un seuil à 0,02$,
la conversion des 2 millions d'USDREG attribués chaque année par RealT, générerait 100 millions de REG,
soit une inflation du REG de 20% par an ! ...(rapporté au 500 million existants),
sachant que le rythme de vente de RealT s'accélère avec le temps ...

L'actualisation du seuil doit donc se faire, sur la base de l'inflation et non du cours du REG.

Ce seuil n'est pas une entrave au marché du REG, mais juste une limite au nombre de REG donné en cadeau par RealT à ses clients (vs sa seconde fonction).

DRKTT

PhilP

Le comité de sécurité doit pouvoir mettre en pause le contrat d'échange ou changer le prix d'échange manuellement. Si ce n'est pas le cas, il va falloir faire en sorte que cela soit possible.

MarkoeZ

PhilP
Well for years it was mentioned that 1 SOON token would be 1 dollar of REG. That is currently not the case. I understand the reasoning for the limits, but IMO the limit could have been more clear up front, but that is hindsight of course.
maybe it could be honored for the original SOON tokens, and then voted on for future releases.

And the numbers i mentioned were just an example. I understand it going to 0.02 would be detrimental. But sticking to 0.5 seems a bit arbitrary.

p.s. edit: I honestly think the REG token is strong enough to carry itself, and that it will survive the initial drop. Just in favor of letting it play out naturally.

PhilP

MarkoeZ

RealT's commitment of 1 Soon = $1 of REG is fully respected, since each Soon has been converted into 1 USDREG.
Since REG has a variable parity, everyone uses their USDREG entitlement whenever they see fit.
RealT has never committed to a quantity of REG.

At no time does the oracle's threshold parameter manipulate the REG price.
This threshold has only one effect: limiting the mint of REG.
In two cases:

due to a hack by the oracle (basic function),
due to a price that is too low, leading USDREG to generate too much REG (inflation-limiting function).

With this threshold, RealT respects its commitment, the market remains free, and the DAO protects itself.

DRKTT

PhilP

PhilP Je pense qu'on se comprend pas, reprenons (...)

🇫🇷

Je vois les choses autrement. Et cela part du simple bon sens. :

Le comité de sécurité est responsable de l'aspect sécurité de la DAO.
Le seuil minimal est un seuil de sécurité contre les hacks. Rien d'autre.

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.

Ce n'est pas à la DAO de gérer la sécurité mais au comité ad-hoc élu par la communauté.

En attendant que le comité de sécurité soit opérationnel, il faut que @Michael-RealT puisse assurer l’intérim.

🇺🇸

I see things differently. And it all comes down to simple common sense:

The security committee is responsible for the security aspect of the DAO.
The minimum threshold is a security threshold against hacks. Nothing more.

Therefore, the security committee must be able to:

Change the threshold based on the risk of a hack
Pause the exchange contract in case of a hack

No more, no less.

It’s not up to the DAO to handle security, but to the ad-hoc committee elected by the community.

While the security committee is not yet operational, @Michael-RealT must be able to act as interim.

MarkoeZ

PhilP

I was not saying that anything was not respected, just what the current situation is.
And IMO we should try to stick as close to the original conversion as is possible without compromising the REG/DAO itself.

Just sharing my thoughts 🙂

DRKTT

PhilP

PhilP Ce seuil n'a qu'un seul effet : limiter la production de REG.
Dans deux cas :
en raison d'un piratage de l'oracle (fonction de base),
en raison d'un prix trop bas, ce qui conduit l'USDREG à générer trop de REG (fonction de limitation de l'inflation).

Avec ce seuil, RealT respecte son engagement, le marché reste libre et la DAO se protège.

🇫🇷

Le premier cas est officiel.

Le deuxième cas est le souhait d'une partie d'une communauté mais qui n'est pas officiel. Rien a été voté sur le sujet. Et je me permet de rappeler :

Que si les REG avaient été distribués directement et que chacun avait commencé à vendre, le prix aurait baissé tout autant si ce n'est plus, ça fait pas un pli.
Que lorsque les NFT vont arriver ou quand le budget communautaire va être distribué, nous aurons également droit à une forte pression vendeuse venant de ceux qui voudront tout vendre.

Donc dans l'attente d'une réelle volonté de la communauté de travestir ce seuil anti-hack en un seuil de protection du prix malgré les deux points mentionnés ci-dessus et donc qu'une votation soit organisée sur ce point précis, j'aimerai que ce seuil soit abaissé ATQP au niveau qu'il devrait être. Il en va de la crédibilité de la DAO.

🇺🇸

The first case is the official one.

The second case reflects the wishes of part of the community, but it is not official. Nothing has been voted on regarding this matter. And allow me to remind everyone:

If the REGs had been distributed directly and everyone had started selling, the price would have dropped just as much, if not more. That’s a given.
When the NFTs arrive or when the community budget is distributed, we will also face strong selling pressure from those who want to liquidate everything.

So, unless there is a clear will from the community to turn this anti-hack threshold into a price protection mechanism—despite the two points mentioned above, and unless a vote is held specifically on this matter, I would like the threshold to be lowered ASAP to the level it should be. It’s a matter of the DAO’s credibility.

PhilP

DRKTT

Ce que la DAO doit voter , c'est la méthode d'actualisation de seuil.
Après, qui lancera l'actualisation, ca peut effectivement être le Comité de sécurité.

Ca n'en retire pas moins, ce que je confirmais : quand nous seront au seuil et que tout le monde convertira et vendra, : en aucun cas, ce peut être le comité qui met en pause le contrat de conversion (sous prétexte que le cours s'écroule) : car il n'y a dans ce cas ni hack ni bug, juste un "bank run" !.

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

PhilP

DRKTT

Concernant ce seuil, il n'y a pas un cas "officiel" et un cas "souhaité".
Il y une raison "officielle" (pour laquelle ce seuil existe : protection contre un hack) et une conséquence (lié au contexte dans lequel le seuil est utilisé : limiter la quantité de REG converti).

Pour statuer sur la méthode d'actualisation du seuil (objectif de la présente proposition), il faut tenir compte des deux : la raison originelle et la(les) conséquence(s).

Pour décider sur le mode de calcul du seuil, nous avons vu précédemment (PhilP ), qu'il faut statuer sur le taux d'inflation maximum admissible.
Dans les conditions actuelles "d'émission" (500 millions de REG et 1 million d'USDREG restant) :

1 % d'inflation maximum admissible, conduit à un seuil de 0,2$,
0,4% d'inflation maximum admissible, conduit à un seuil de 0,5$ (valeur actuelle du seuil).

Une fois le taux d'inflation admissible voté par la DAO, le seuil sera recalculé régulièrement pour tenir compte des variations des "émissions".

L'effet de ce seuil, sera bien de limiter l'inflation contre un hack, mais aussi hors hack de limiter la conversion d'USDREG en REG.

Concernant ton rappel, nous sommes bien d'accord que quelque soit la méthode de distribution de REG (direct, via conversion d'USDREG, via NFT), leur abondance et la faible liquidité actuelle crée hélas une chute du cours.

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)

PhilP

MattDev
vs les suggestions proposées :
-1 "Arrêt du claim" : me parait difficilement envisageable, car "le remède serait pire que le mal" ! donc pas voté
-2 "Baisser le seuil en fonction du prix" :
Comme expliqué précédemment :

l'actualisation ne doit pas se faire en fonction du prix du REG, sous peine d'engendrer la spirale de la mort Saitama (cf troisième point du message).
l'actualisation devrait plutôt être faite en fonction de l'inflation maximum admissible PhilP PhilP
-3 "Seuil fixe" : suggestion "temporaire" qui me semble préférable à la première.

PhilP

@EzSwim :
Juste deux petits points de détail :

concernant la partie "How the oracle algorithm works", peut être mettre le DiffFactor à 1000, puisque c'est sa valeur depuis le 20 mars : https://gnosis.blockscout.com/tx/0x8da4a6277381ec99df30ed7f7f5fb6049b5ef5cbf3f2fb2f5b90bc44d740acb6?tab=logs
l'oracle donne une valeur du REG en USD. Les unité min et max sont à modifier ainsi qu'un endroit dans le context.

EzSwim

PhilP concernant la partie "How the oracle algorithm works", peut être mettre le DiffFactor à 1000, puisque c'est sa valeur depuis le 20 mars :

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

PhilP l'oracle donne une valeur du REG en USD. Les unité min et max sont à modifier ainsi qu'un endroit dans le context.

Yes the oracle returns a USD value. 1 USDREG = 1 USD. I made the choice to put only one of the 2 in the explanation as to not add more complexity for the reader. I can replace everything by USD if you'd prefer

Saitama

EzSwim
I think this can bring some context to the situation:

First, if we have to summarize the REG market in one word, it is: ILLIQUID.

It has only 10 liquidity pools, only 2 of which have somewhat meaningful liquidity (REG/USDC Sushiswap V3: 300K REG and 6K USDC, REG/sDAI on Balancer v2: 17 K REG and 6 K sDAI). In total, these pools hold less than $20,000 USD in stablecoins (at peak, there were around $50,000 USD). They have less than 500k REG (0.1% of the total supply 500M REG)
The average monthly volumes since launch is around 100k USD (or an average 3k USD daily volume)
That means there is very low-liquidity, low-amount of REG in the market, low-volume trading. This creates a perfect environment for market manipulation in either direction (up or down), so using the market spot price is a big NO.

Second, after considering all these conditions, we decided to use TWAP for REG oracle for protection against short-time manipulation with the tradeoff of disadvantages (lagging price and market coverage). When the price is on increasing trends, then TWAP report lower than spot price. When the price is on decreasing trends, then TWAP report higher than spot price.

We use both offchain/onchain for price reporting to double check that both values are the same (for a give time interval with a difference tolerance).
Offchain TWAP price allows to have more market coverage, and onchain TWAP price allows to double-checking the offchain price.
The time interval is set at 24h. It could have been set at 72h, but we consider that 24h provides more fresh price data and enough for monitoring.
The initial tolerance difference was 5% and now at 10% (after the USDREGConversionVault launch). For reference, most Chainlink oracle price feeds are operating with deviation threshold around 0.5%-2%. Low-liquidity pairs can have 5% of deviation threshold. Even these pairs have 5-10 millions USD daily volume, comparing to 3k-5k daily volume of REG.
We use a circuit-breaker mechanism (presented in Chainlink price feeds) to limit the price lower/upper bounds (0.5-100 USD). If the price fell out of these range, the price will not be updated. When these values were set, the REG was trading in range 1.5-2 USD. We thought a limit at 70-80% lower might be enough, but apparently it is not.

Third, The problem is we have 1.4M USDREG-equivalent to be "converted" into REG (600k of which is already converted), while there were less than 20k USD in pools. We already know this kind of situation will create a death spiral: mint REG from USDREG => dump and lower REG price => mint more REG => dump and lower REG price => mint more REG...
There were already incidents in the past for this kind of exploit: Terra luna, Iron finance
Here is an example with 80k USDREG initially, someone can mint 26 billions REG in 4 steps.
Even with TWAP in place, this can happen in slow motion. The lower bound (0.5 USD) sets a limit on this inflation.

EzSwim

Saitama

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 ?

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

EzSwim

Seb

The oracle price is an average price of the past 24 hours as @Saitama explained here (he said it could have been 72h, idk if any more than that would have made sense for an oracle) :

Saitama we decided to use TWAP for REG oracle

As a reminder, the point of this debate is to discuss how the DAO should managed the threshold (the threshold that is currently preventing the update of the oracle price).

« Previous Page Next Page »