• Suggestions

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

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

                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

                    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.

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

                            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)

                                  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.

                                      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

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

                                            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.

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

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

                                                            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.

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

                                                                    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.

                                                                        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.

                                                                            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.