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

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.

    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.

      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.

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

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

            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.

              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.

                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 )

                  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.

                    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 🙂

                    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.

                      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.

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

                          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.

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

                              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.

                              1. 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).
                              2. Offchain TWAP price allows to have more market coverage, and onchain TWAP price allows to double-checking the offchain price.
                              3. 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.
                              4. 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.
                              5. 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.

                              https://imgur.com/a/VotpBdD

                                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

                                  Now the question everyone is asking: How do we know which threshold should be set?
                                  If the value is too low, then it could create a large inflation which might not be fair to users holding REG already.
                                  If the value is higher than spot market, the users with right to mint will feel it is unfair for them to mint REG higher than TWAP market price.
                                  We could adjust the threshold like DRKTT proposes, but how low do we go?

                                  To answer this, I think we should come back to the original situation and ask the question: Is it fair to mint REG PURELY based on an ILLIQUID market (less than 0.1% of total REG)?
                                  While 99.9% other REG are sitting aside in idle mode.

                                  One of the solutions is evaluating the REG ecosystem in its current state and its full potential (RMM, YAM, future DEX, NFTs,...).

                                  • On the base layer, we have 120M+ real estate tokenization, which brings renter yield every week. But this is not contributing directly to the DAO, so it should not be counted in DAO valuation.
                                  • Lending activity (RMM): currently it has 14M stablecoins (11M borrowed) + 30M RealTokens, at 8% borrow APY, it brings 800k USD revenue (90% to LP, 8% to DAO, 2% to Aave). At full potential today, if the DAO can do marketing and bring more liquidity, with 120M RealToken in total, with 60% LTV, it can generate 5-6M USD revenue.
                                  • Trading activities (YAM + future DEX): YAM has less than 20M trading volume, it could have generated 20-50k USD to the DAO with 0.1-0.3% fees. For comparison, Uniswap has less than 4B TVL, and 2B daily volume, with around 700M annualized fees. Of course, real estate tokens will have a lot less trading activity than exotic tokens on Uniswap, but we could expect 200-600M annual trading volume. This can bring 1.8M USD revenue from RealToken YAM/DEX.
                                  • Other activities with NFTs (collector selling + fees on marketplace): no number for now.

                                  These are projections and not certain, but they give an overall picture of the ecosystem. The total value of RealTokens will mostly increase over time with more properties. There are also a lot of other types of RWA assets that the DAO can explore.

                                  Once the REG ecosystem is somewhat evaluated, the DAO can say, hey this is the range for fair valuation, and the minting limit should be at least >= this value.
                                  I think this gives a bigger picture than purely basing on an illiquid market (with 0.1% of REG, of course, the market can overvalue/undervalue the ecosystem).

                                  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 ?

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