• Closed ProposalsFor
  • [RIP00009] - Choice of distribution method for REGs resulting from revaluations

JoeD It is not clear in the proposal that there is an option C. If there is an option C, can you amend the proposal to include a description of what the option C is about please?
If there is no option C available, can you remove the mentions about option C in the poll?

Between A and B, I like option B better as I am the one to choose when to convert SOON to REG and therefore will not be impacted by the price of REG.

If option A is the way to go, by the time I realize my SOON have been converted to REG, maybe the REG value will have drop off a lot and I will not be able to recover my loss. Option A will also be beneficial for people with automated solutions (bots) as they will be able to swap their tokens as soon as their REG tokens have landed on their wallet.

Option B is to me the fairest solution.

I currently lack the time to regularly update the proposals, and doing this work if there is no interest in this proposal C, would not bring much.

PhilP Un détail, dans cette dernière mouture, me semble passé inaperçu : il s'agit du "Claim automatique" dans l'option B !

Ainsi avec l'option B, nous avons tout les avantages de l'option A (en mode claim automatique) ainsi que ceux de l'option B (en mode claim manuel) et tout cela pour 5 à 10 K$, soit 3 semaines de revenu RMM !..
Ca me parait top comme approche.

juste le automatique c'est pour le destinataire, ça ne sera pas réélement automatique, un SC doit avoir une activation d'une fonction déclanché une action.
Cela signifie que soit RealT devra déclenché pour chaque utilisateur qui le veux cette fonction, soit ont met la fonction accessible a tous (pour effectué le claim) mais dans se cas c'est quoi qui vas motivé une personne a exécuté le claim pour un autre.

Une solutions sera d'ajouter un fee paramétrable, qui serais par exemple de 0.1% soit 10ct par 100$, se qui inciterais les bot a exécuté la fonction de claim pour les utilisateurs qui ont choisi d'activé le claim auto.
l'avantage c'est que ça décentraliser le processus et évite de trop compter sur RealT pour effectuer des actions.

    Sylvain Leroux En fait tu peux organiser les choses de manière plus équitable si tu as 2n propositions: tu organise n votes, chaque vote réduisant de moitié le nombre de possibilités. De cette manière, quelle que soit la proposition, cela reclamera le même nombre d'actions.

    Ex:
    vote 1 voulez vous (ab) ou (cd).
    Vote 2, choix entre un des deux finalistes.

    Je vais voir comment on peut faire si on a pas 2n options.

    je comprend se que tu veux fais mais je me demande a quelle point c'est plus équitable, et plus simple a comprendre.
    ça vas donc demander 2n * 10 jours pour arrivé a un résultat.
    je veux bien faire les chose, mais la ça commence a devenir un vrais sac de noeux, aucune option ne semble se démarquer, et mon calandrer commence a ce limité en place pour animer et creuser ses proposals.

      Michael-RealT la ça commence a devenir un vrais sac de noeux, aucune option ne semble se démarquer, et mon calandrer commence a ce limité en place pour animer et creuser ses proposals

      Je comprends.

      En prenant un peu de recul, voici quelques pistes qui pourraient être utiles :

      1. Peut-être qu'une pause sur cette proposition permettrait de digérer toutes les informations, de concilier les exigences contradictoires, et de permettre aux esprits de se calmer
      2. Il pourrait être judicieux de rediriger cette énergie sur d'autres priorités ou propositions. Parfois, les choses ou les gens ne sont tout simplement pas encore prêts pour un sujet donné. 
      3. Concernant ce cas particulier, l'option suggérée par Draazzzz, qui consiste à retirer cette proposition pour l'instant, implanter la solution de RealT (option A) et revenir sur le sujet dans 6 mois, semble être une approche pragmatique

      Michael-RealT

      L'exécution du "claim automatique" par RealT, sera j'imagine pas faite à la main, mais codée. Le développement de cet automate (bot) me semble faire parti des coûts de dev. de l'option B, automate qui sera à terme géré par la DAO. Il serait effectivement judicieux que, dès le dev initial, soit prévu des fees pour ce service, que la DAO décidera ou non d'activer (comme pour YAM).

      Là où la solution resterait dépendante de RealT, c'est pour l'enregistrement du souhait de "claim auto". Ce qui me choque pas outre mesure, puisque le versement de REG fait parti des conditions commerciales propres à RealT.

        Michael-RealT

        Le "sac de noeud" s'est pour moi fortement simplifié, depuis que tu as ajouté le "claim automatique" dans l'option B.

        Ainsi en votant pour l'option B (ce qui n'était pas mon souhait à l'origine), on aura :

        • l'option A si on active le "claim automatique",
        • l'option B si on n'active pas le "claim automatique".

        Cette solution de convergence me parait la meilleur, même si elle coute un peu plus cher (3 semaines de revenu RMM).

        Pour les raisons que tu as mentionnées précédemment (Michael-RealT ) , cette décision ne doit pas être décalée. Je serai donc partisan qu'on passe rapidement au vote pour tourner la page et passer à l'exécution.

        L'option de "convergence" étant la B, je propose qu'on commence par voter pour ou contre celle-ci sur Tally (quitte à avoir d'autres votes, si le contre l'emporte).

        Je ne vois pas de convergence dans la solution B, juste la demande d'un petit nombre de pouvoir avoir davantage de possibilités d'optimisation. J'étais plutôt favorable à la C pour éviter de distribuer des Reg qui ne servent à rien, mais si c'est une condition commerciale de RealT et qu'il faut les distribuer sans pouvoir mettre une limitation de durée sur le Claim, autant rester sur la A.

          pompom

          Je qualifie l'option B de convergente, car si comme tu le conclues tu veux l'option A : il te suffira si la B est votée de demander un "claim automatique". Ainsi, comme dans la solution A : tes REG te seront versés automatiquement lors de la réévaluation et libre à ceux qui veulent spéculer de le faire. A moins que ce que tu souhaites, c'est d'empêcher cette spéculation ;-) !..

          Indeed, option B with an automatic claim allows it to work like option A, with REG being distributed directly at revaluation, leaving everyone free to speculate. However, if option B includes automatic claim by default, it still does not solve the issue of inflation...

          I believe that, in the current state of things, and given that the community is somewhat divided on this topic, to move forward calmly and clearly, as Draazzzz suggested on Telegram, it would be wise to amend the proposal so that this vote is effective for a duration of 6 months, rather than a minimum duration of 6 months. This means we would hold another vote in 6 months. This approach would limit the impact of this important proposal while giving members time to understand, reflect, and observe. By then, we would have better visibility on revaluations as well as SOON/REG exchanges (with metrics such as the number of people who have converted their SOON to REG, etc.).

            Sylvain Leroux

            Quand tu as un nombre impair d'options, comme dans notre cas, il suffirait :

            • d'un premier vote : pour ou contre l'option B (par ex ;-)),
            • puis d'un éventuel second vote (si l'option B a été contrée) : pour ou contre l'option C, sachant qu'en cas de contre de l'option C ce sera l'option A qui sera retenue.

            Il n'y a pas besoin d'un troisième vote : pour ou contre l'option A, car comme écrit dans la proposition en cas de rejet de la proposition ce sera l'option A qui sera appliquée.

              PhilP Là où la solution resterait dépendante de RealT, c'est pour l'enregistrement du souhait de "claim auto". Ce qui me choque pas outre mesure, puisque le versement de REG fait parti des conditions commerciales propres à RealT.

              non ce sera a l'utilisateur de faire une tx pour enregistrer l'activation du claim auto dans le contrat

                Yohann76 if option B includes automatic claim by default

                no it will not be by default, this will allow to record a value $ in the contract, and for the people who will understand later not to lose on the value $ which is due to them in the case where the REG would have decreased in values.
                in the case of an increase in values ​​they do not lose value in $ and do not gain either

                Yohann76 it would be wise to amend the proposal so that this vote is effective for a duration of 6 months, rather than a minimum duration of 6 months.

                Setting a minimum allows for 2 options after 6 months:

                1. the system is not suitable, the DAO votes for a new distribution approach
                2. the system is suitable, we are not required to vote to keep the system

                If we say that a vote is needed in 6 months, we must do it even if we want to keep the system A, B, C voted here

                PhilP Quand tu as un nombre impair d'options, comme dans notre cas, il suffirait :
                d'un premier vote : pour ou contre l'option B (par ex ;-)),
                puis d'un éventuel second vote (si l'option B a été contrée) : pour ou contre l'option C, sachant qu'en cas de contre de l'option C ce sera l'option A qui sera retenue.

                Il n'y a pas besoin d'un troisième vote : pour ou contre l'option A, car comme écrit dans la proposition en cas de rejet de la proposition ce sera l'option A qui sera appliquée.

                Oui je pense que c'est la bonne approche à adopté.
                L'option B semble être celle qui peux contenté le plus de personnes et donc permettre d'avancé sur le sujet

                Michael-RealT

                Ca me semble différent ce qui est dans la proposition ( Michael-RealT ) :

                • Option de claim automatique disponible dans le compte RealT
                • Conversion automatique en REG par l'administrateur après mise à jour du vault pour les utilisateurs ayant activé l'option

                Auriez vous progressé depuis, sur la façon de faire ?

                  PhilP d'un premier vote : pour ou contre l'option B (par ex ;-)),

                  Oui, vous avez sans doute raison. Au moins on pourra passer à autre chose.

                  PhilP Ca me semble différent ce qui est dans la proposition ( Michael-RealT ) :
                  Option de claim automatique disponible dans le compte RealT
                  Conversion automatique en REG par l'administrateur après mise à jour du vault pour les utilisateurs ayant activé l'option

                  Auriez vous progressé depuis, sur la façon de faire ?

                  oui plus ont "tard a valider" plus il y as des idées et du temps pour préparer de nouvelle chose.

                  Bonjour à tous,

                  Je me suis aidé de GPT et du document rédigé par PhilP pour essayer de synthétiser et comprendre globalement les enjeux autour de chacune des options, mais certains points me paraissent encore flou, déjà si j'ai bien compris :

                  Option A = Conservation du fonctionnement actuel, c'est à dire qu'il y aurait transmission de SOON convertibles en REG lors des réévaluations et cette option ne nécessite pas de coût supplémentaire au niveau de la DAO. Mais elle aurait un gros impact sur le nombre de REG mintés, et donc sur la valeur du REG.

                  Option B = Mode de conversion intermédiaire, avec choix laissé aux holders du timing de conversion, afin de maximiser la quantité de REG récupérés en fonction de sa parité avec le $ + Option de versement et conversion automatique possible encore mais suppose un coût important pour la DAO.

                  Option C = Pas de conversion automatique possible de $ en REG, et se basant uniquement sur un claim manuel, avec un système d'enregistrement au moment des réévaluations. Cela permettrait de limiter l'inflation de REG, tout en offrant aux holders la possibilité de les claim lorsque la parité leur paraitra favorable. Cette option nécessiterait aussi un coût (plus important visiblement ?)

                  En cas de rejet, le fonctionnement actuel serait encore en vigueur pendant 6 mois (option A finalement)

                  À partir de ces informations, voici mes questions/floues :

                  1) J'ai un peu de mal à voir de grande différence entre l'option B et C, si ce n'est simplement l'absence totale de distribution automatique possible avec l'option C, est-ce que quelque chose m'échappe ? Qu'est-ce qui change fondamentalement, est-ce uniquement cette question d'impossibilité de mint/conversion automatique ?

                  2) L'option C semble être la plus "complexe" à mettre en œuvre, qu'est-ce qui explique sa surcomplexification par rapport à l'option B, sachant qu'au final, il y aurait au contraire, une option en moins à dev (celle de la conversion auto présente en option dans l'option B)

                  3) En quoi l'inflation du REG serait-elle un problème pour sa valeur ? Si j'ai bien compris, le prix du REG est surtout défini en fonction de la quantité de REG disponible dans les pools de liquidité non via des swap ? Donc, un grand nombre de REG mintés ne signifieraient pas forcément que tous les REG soient déposés en pool de liquidité si ?

                  Au final, J'ai l'impression qu'il y a surtout 2 grandes problématiques à mon sens liée à cette proposition : celle du coût et celle de l'impact sur le prix du REG via une vente massive des REG obtenus contre des $ ?

                  Je suis curieux de connaitre les arguments allant dans le sens d'une limitation de l'inflation du REG, en l'état de mon point de vue, cela ne me parait pas si problématique que cela, mais certaines choses m'échappent sans doute.

                  En l'état, la proposition B me paraît être le compromis le plus pertinent entre une conversion auto totale et un contrôle total des holders, puisqu'il offre à chacun finalement la solution qui lui convient. Mais j'ai dû mal à évaluer l'impact en matière de coût, est-ce qu'un budget de 5/10k pour la DAO parait "énorme", ou bien est-ce quelque chose qu'elle peut se permettre ?

                  Merci à tous pour vos éclaircissements !

                    Cogatos

                    1/ la différence entre B et C est le moment de conversion (et donc de la parité) : C au moment de la réévaluation, B (sans claim auto) au moment choisi par le holder.
                    2/ l'option C nécessite un nouveau vault (en nombre de REG),
                    3/ Toute émission de REG dilue sa valeur (comme pour les actions). La quantité de REG dans les pools, influe sur slipage (glissement entre la parité affichée et exécutée).
                    Les options B et C, limite la quantité de REG mintée par le fait qu'il faut claimer et que certains pourraient ne pas le faire.
                    Le coût de l'option B représente 4 à 5 semaines des revenus de la DAO issus du RMM (1,8 k / semaine actuellement).

                      Cogatos En l'état, la proposition B me paraît être le compromis le plus pertinent entre une conversion auto totale et un contrôle total des holders, puisqu'il offre à chacun finalement la solution qui lui convient. Mais j'ai dû mal à évaluer l'impact en matière de coût, est-ce qu'un budget de 5/10k pour la DAO parait "énorme", ou bien est-ce quelque chose qu'elle peut se permettre ?

                      En complément a la réponse de PhilP, j'ajouterais pour cette partie:
                      que B dans la version initial étais désavantageuse pour une partie des personnes qui sont désireuse de DCA du REG et jouir dès que possible du pouvoir de vote qui en découle, avec l'ajout du claim auto, cela rééquilibre et donc semble bine etre la solution la plus universel, qui sera probablement mise au vote.
                      Concernant le cout, la DAO fais environs 1000 à 2000$ semaine de rentrée d'argent sur le RMM actuellement, vas avoir des rentrée d'argent avec la proposition de ventre de REG au travers de MtPelerin si accepter, et possiblement avec la liquidité sur Sushiswap.
                      il y as un peux plus de 23k dans la trésorier de la DAO + 12k sur la trésorier du RMM (20% pour AAVE et 80% pour la DAO), donc 5/10k représente un petit budget actuellement mais il pourrais être possible de payé RealT intégralement ou partiellement en REG

                      Merci à tous les deux pour vos éclaircissements.

                      PhilP 3/ Toute émission de REG dilue sa valeur (comme pour les actions). La quantité de REG dans les pools, influe sur slipage (glissement entre la parité affichée et exécutée).

                      Justement, à l'inverse de l'émission d'actions classiques, je crois comprendre que dans le cas du REG, et de la DEFI, cela n'est pas automatique, puisque les REG ne sont pas automatiquement émis dans les pools, mais supposerait une action de la part des holders souhaitant s'en séparer (tous les REG en dehors des pools n'influant pas sur le prix du REG par définition, puisque n'étant pas dans le système de pool). On prend à chaque fois l'hypothèse selon laquelle l'ensemble des REG émis seraient de facto injectés dans les pools, ce qui ferait diminuer mécaniquement son prix mais à mon sens cette hypothèse n'est pas certaine ou évidente pour tout possesseur de REG.

                      Quoi qu'il en soit, ces précisions me confortent en tout cas dans l'idée que l'option B me parait effectivement être la solution la plus viable pour tout le monde.