• Closed ProposalsFor
  • [RIP00008] - Transfer RealToken Wrapper RMMv3 execution functions to the DAO

🇫🇷 Disponible dans le 2ème post
🇺🇸

Proposal Summary:

This proposal aims to approve modifications to the RealToken Wrapper on RMMv3 and transfer the responsibility for executing new functions to the Realtoken DAO. These changes will allow managing special cases related to RealTokens while ensuring decentralized control to prevent abuse and total transparency.
The vote on this proposal therefore aims to validate that the DAO will take control of the execution of the RealTokens recovery functions on the RMM Wrapper, the DAO will have a verifier/security role, but cannot refuse execution if it complies with the planned process.

Motivation:

  1. Address specific requirements of different types of RealTokens in RMMv3
  2. Ensure the restitution and recovery of RealTokens in special cases (regulatory requirements, etc.)
  3. Guarantee the proper functioning of processes related to the life of RealTokens
  4. Establish decentralized control to prevent manipulation and abuse
  5. Total transparency on processes related to RealTokens on RMMv3

Context:

RealT offers several types of RealTokens, each with specific requirements. In order to benefit from RMMv3 with a maximum of RealToken types and meet regulatory requirements, we must be able to safely extract RealTokens from RMMv3 in cases where the investor cannot do it by their own means.

For example, DEBT tokens will need to be partially or fully burned at some point. If they are on RMMv3, we cannot burn them without creating uncollateralized debt problems.

This is why the RealToken Wrapper needs to be updated with new functionalities that allow the DAO governance to repay a user's debt in the same transaction as withdrawing the concerned realtokens.

  1. Modifications to the RealToken Wrapper contract:

    • Removal of redundant _isRealTokenWhitelisted verification
    • Gas usage optimization with a cached user token array
    • Addition of new functions repayForRecover and recoverByGovernance
  2. Transfer of execution responsibility to the DAO:

    • The DAO will be responsible for executing new functions on RealT's proposal

    • These functions will be limited to addresses with the GOVERNANCE_ROLE

    • Applicable only to RealTokens, not to other RMMv3 assets (USDC and XDAI)

  3. Control process:

    • RealT will submit proposals to the DAO for executing these functions
    • The DAO will review and vote on these proposals to validate execution

Implementation Steps:

  1. Audit of modified code by an independent third party (already completed)
  2. DAO vote to approve modifications and transfer of responsibility
  3. Update of the RealToken Wrapper contract on RMMv3
  4. Configuration of governance roles for the DAO
  5. Comprehensive testing of new functionalities
  6. Training of DAO members on the review and execution process

Roadmap:

  • Code audit: 2-3 weeks (already completed)
  • Discussions on the governance forum: 7 days
  • DAO vote: 7 days
  • Queue: 2 day

Budget:

No additional costs for the DAO except for transaction fees.

Financial Implications:

  • Audit and development costs
  • Potential increase in gas fees for certain operations
  • No penalties or fees for investors who use these functionalities (possibility in the future to add fees with a new contract update)

Team:

  • RealT technical team for implementation
  • External auditors for code verification

Success Metrics:

  1. Successful implementation of contract modifications
  2. Absence of security issues after deployment
  3. Efficient and responsible execution of new functions by the DAO
  4. Successful resolution of special cases related to RealTokens

Alignment with Mission:

This proposal aligns with the Realtoken DAO's mission by ensuring efficient management of RealTokens while strengthening the decentralization and transparency of the ecosystem.
By controlling the execution of functions, governance demonstrates transparency and ensures that RMMv3 remains a secure and reliable ecosystem.

Key Terms:

  • RMMv3: Realtoken Money Market v3
  • RealToken Wrapper: Contract allowing interaction of RealTokens with RMMv3
  • GOVERNANCE_ROLE: Specific role assigned to addresses authorized to execute governance functions

Points to Discuss Before Creating the Final Proposal:

  • Detailed process for submission and review of proposals by RealT
  • Evaluation criteria for proposals by the DAO
  • Security mechanisms to prevent abuse in function execution
  • In-depth training of DAO members on the implications of new functions
  • Emergency procedure in case of need for rapid action
  • Frequency and method of reviewing this process
  • Process for communicating these changes to the community
  • Reporting and transparency mechanisms for the use of these functions

📍 CHECK-LIST: ( 🔲 : under discussion / ✅ : finalized / ❎: not applicable )
✅ Proposal Summary
✅ Motivation
✅ Context
✅ Implementation steps
✅ Team
✅ Budget / Allocation
✅ Roadmap
✅ Objectives
✅ Key terms

What is your feeling about the proposal?

You can choose an option to indicate your state with respect to the proposal, this allows us to measure the general feeling, this will help to know when progress has been made If your feeling changes, for example you had questions and now the proposal is correct, you can edit your selection this allows us to visualize the progress

It's ok for me
I still have questions
I am totally against it
This poll has ended.

    Résumé de proposition:

    Cette proposition vise à approuver les modifications du Wrapper RealToken sur le RMMv3 et à transférer la responsabilité de l'exécution des nouvelles fonctions à la DAO Realtoken. Ces changements permettront de gérer les cas particuliers liés aux RealTokens tout en assurant un contrôle décentralisé pour éviter les abus et une transparence totale.
    Le vote sur cette propositions vise donc a valider que la DAO prendra le contrôle de l’exécution des fonctions de récupération des RealTokens sur le Wrapper du RMM, la DAO aura un rôle de vérificateur/sécurité, mais ne peux pas refuser l’exécution si conforme au processus prévu

    Motivation:

    1. Répondre aux exigences spécifiques des différents types de RealTokens dans le RMMv3
    2. Assurer la restitution et la récupération des RealTokens dans des cas particuliers (exigences réglementaires, etc...)
    3. Garantir le bon fonctionnement des processus liés à la vie des RealTokens
    4. Établir un contrôle décentralisé pour prévenir les manipulations et les abus
    5. Transparence totale sur les processus liés aux RealTokens sur le RMMv3

    Contexte:

    RealT propose plusieurs types de RealTokens, chacun avec des exigences spécifiques, afin de pouvoir bénéficier du RMMv3 avec un maximum de types de RealTokens et répondre aux exigences réglementaires. Nous devons être en capacité d'extraire des RealTokens du RMMv3 en toutes sécurités dans le cas ou l'investisseur ne pourrait le réaliser par ses propres moyens.

    Par exemple : les tokens de DETTE devront à un moment être burn partiellement ou intégralement, si ils sont sur le RMMv3, nous ne pouvons pas les burns, sans créer des problèmes de dettes non collatéralisées.

    C'est pourquoi le Wrapper RealToken doit être mis a jour avec de nouvelles fonctionnalités qui permettent à la gouvernance de la DAO, de rembourser la dette d'un utilisateur, dans la même transaction que le retrait des Realtokens concernés.

    1. Modifications du contrat Wrapper RealToken :

      • Suppression de la vérification redondante _isRealTokenWhitelisted
      • Optimisation de l'utilisation du gaz avec un tableau de jetons utilisateur en cache
      • Ajout des nouvelles fonctions repayForRecover et recoverByGovernance
    2. Transfert de la responsabilité d'exécution à la DAO :

      • La DAO sera chargée d'exécuter les nouvelles fonctions sur proposition de RealT

      • Ces fonctions seront limitées aux adresses ayant le rôle GOVERNANCE_ROLE

      • Applicable uniquement aux RealTokens, pas aux autres actifs du RMMv3 (USDC et XDAI)

    3. Processus de contrôle :

      • RealT soumettra des propositions à la DAO pour l'exécution ces fonctions
      • La DAO examinera et votera sur ces propositions pour valider l'exécution

    Étapes d'implémentation:

    1. Audit du code modifié par une tierce partie indépendante (déjà réaliser)
    2. Vote de la DAO pour approuver les modifications et le transfert de responsabilité
    3. Mise à jour du contrat Wrapper RealToken sur le RMMv3
    4. Configuration des rôles de gouvernance pour la DAO
    5. Test complet des nouvelles fonctionnalités
    6. Formation des membres de la DAO sur le processus d'examen et d'exécution

    Feuille de route:

    • Audit du code : 2-3 semaines (déjà réaliser)
    • Discussions sur le forum de gouvernance : 7 jours
    • Vote de la DAO : 7 jours
    • Queue : 2 jour

    Budget:

    Pas de frais supplémentaires pour la DAO hormis les frais de transaction.

    Implications financières:

    • Coûts d'audit et de développement
    • Potentielle augmentation des frais de gaz pour certaines opérations
    • Aucune pénalité ou frais pour les investisseurs qui font recours à ces fonctionnalités (possibilité dans le future d'ajouter des frais avec une nouvelle mise a jour du contrat)

    Équipe:

    • Équipe technique de RealT pour la mise en œuvre
    • Auditeurs externes pour la vérification du code

    Métriques de succès:

    1. Mise en œuvre réussie des modifications du contrat
    2. Absence de problèmes de sécurité après le déploiement
    3. Exécution efficace et responsable des nouvelles fonctions par la DAO
    4. Résolution réussie des cas particuliers liés aux RealTokens

    Alignement avec la mission:

    Cette proposition s'aligne avec la mission de la DAO Realtoken en assurant la gestion efficace des RealTokens tout en renforçant la décentralisation et la transparence de l'écosystème.
    En contrôlant l’exécution des fonctions, la gouvernance fais preuve de transparence et s'assure que le RMMv3 reste un écosystème sécurisé et fiable.

    Termes clés:

    • RMMv3 : Realtoken Money Market v3
    • Wrapper RealToken : Contrat permettant l'interaction des RealTokens avec le RMMv3
    • GOVERNANCE_ROLE : Rôle spécifique attribué aux adresses autorisées à exécuter les fonctions de gouvernance

    Points à discuter avant la création de la proposition finale :

    • Processus détaillé pour la soumission et l'examen des propositions par RealT
    • Critères d'évaluation des propositions par la DAO
    • Mécanismes de sécurité pour prévenir les abus dans l'exécution des fonctions
    • Formation approfondie des membres de la DAO sur les implications des nouvelles fonctions
    • Procédure d'urgence en cas de besoin d'action rapide
    • Fréquence et méthode de révision de ce processus
    • Processus de communication avec la communauté sur ces changements
    • Mécanismes de reporting et de transparence pour l'utilisation de ces fonctions

    J'ai encore un peu de mal à comprendre certaines choses vis à vis de cette proposal :

    Actuellement, le RMM a vocation à être donné par Realt à la DAO c'est bien cela ? Si oui, n'est-ce pas un peu trop tôt pour envisager l'octroi de certaines fonctionnalités du RMM au profit de la DAO avant même que le RMM n'ait été légué lui-même ?

      Cogatos J'ai encore un peu de mal à comprendre certaines choses vis à vis de cette proposal :

      Actuellement, le RMM a vocation à être donné par Realt à la DAO c'est bien cela ? Si oui, n'est-ce pas un peu trop tôt pour envisager l'octroi de certaines fonctionnalités du RMM au profit de la DAO avant même que le RMM n'ait été légué lui-même ?

      Donné pas forcément mais vendu probablement, RealT n'a jamais pris 1$ pour sont compte sur le RMMv2 ou v3, nous avons toujours dis et utiliser les fonds générer pour les audites des contrat du RMM.
      Non je pense pas tu peux avoir la propriété qui est détenu par x et y qui exploite, ici la DAO serais simplement le garent d'action sensible sur le RMM, c'est un premier pas vers d'autre transfère de responsabilité

      Hello everyone,

      Thanks to everyone involved with the DAO for the great work.

      A few questions on this proposal:

      1. If I understand it correctly, this implies touching the RMM smart contracts. Can you confirm or confirm?
      2. The code is audited. By whom?
      3. Concretely for the end user (and for a newbie like me), which current use cases of the RMM will be impacted and how?

        Sylvain Leroux If I understand it correctly, this implies touching the RMM smart contracts. Can you confirm or confirm?

        not RMM directly but Wrapper which allows to have thousands of RealTokens in the RMM normally limited to 128.
        This update is mandatory that the control is at the DAO or RealT we must do it to be able to put the LOAN tokens on the RMM, and resolve cases like the death of the owner of the tokens, the loss of control of the address of the owner of the address, the sale of detokenization.
        All these procedures imply that if we do not do this update the tokens are blocked in the RMM and poses compliance problems

          Sylvain Leroux Concretely for the end user (and for a newbie like me), which current use cases of the RMM will be impacted and how?

          This does not change much in normal operation, it is only in special cases mentioned in the previous message.
          The proposal aims to strengthen transparency and security, by entrusting control to the DAO, each member of the DAO can consult the requests and verify and approve them without there being any start from a particular person.

          RealT has the duty to follow legal processes for this type of request, to strictly verify the information, then submit the transaction to the DAO.
          If the proposal is refused, RealT will still have to proceed with the update and will keep control of its new features to be able to meet the compliance requirements

          🇫🇷
          J'ai une hésitation sur le transfert de responsabilité.

          RealT (et ses RealTokens) est pour pas mal d'investisseurs un point d'entrée dans le monde de la crypto. Ces personnes là pourraient être refroidies à l'idée que s'ils venaient à collatéraliser leur investissement, la DAO (une communauté envers ils pourraient n'avoir aucune confiance comparé à une entreprise auprès de laquelle ils acceptent de confier leur argent) pourrait avoir un moyen de contrôle sur leur investissement.

          Les personnes présentes ici pourraient bien ne pas représenter par leur vote ces investisseurs un peu éloignés du web 3.0.

          Ne craignez-vous pas une fracture entre ces deux mondes (qui pourrait certes s'apaiser avec le temps si le système fait ses preuves) et donc une plus forte hésitation de la part de certains investisseurs à dynamiser le RMM ?

          De plus, n'y a-t-il pas un risque d'allongement des procédures en cas de hack d'un portefeuille ou de n'importe quel incident si RealT ne peut plus agir directement (début d'effet millefeuille) ?

          __
          🇺🇸
          I have some hesitation about the transfer of responsibility.

          For many investors, RealT (and its RealTokens) is an entry point into the world of crypto. These people might be deterred by the idea that if they were to collateralize their investment, the DAO (a community in which they might have no trust compared to a company where they feel secure entrusting their money) could have some degree of control over their investment.

          The individuals here may not truly represent, through their votes, these investors who are somewhat distant from the Web 3.0 ecosystem.

          Aren't you concerned about a possible divide between these two worlds (which could, of course, ease over time if the system proves itself), potentially leading to increased hesitation among certain investors to energize the RMM?

          Furthermore, isn't there a risk of extended procedures in the event of a wallet hack or any other incident if RealT can no longer act directly (leading to a 'layered' effect)?

            While I understand the motivation, I also share concerns about the process of recovering RealTokens and struggle to see how it would work out in practice.

            Currently, once the smart contracts are updated and the responsibility of execution is transferred, each recovery will require a vote as per the proposal:

            Michael-RealT

            1. Control process:
              • RealT will submit proposals to the DAO for executing these functions
              • The DAO will review and vote on these proposals to validate execution

            Let's now consider different scenarios where recovery is needed:

            1. "the sale of detokenization"
              Holders of RealToken X have approved its detokenization, now all deposited RealToken X must be removed from the RMM to be burned. The DAO must not have the ability to intervene in that process. What happens to the detokenization if the vote is rejected?
            2. "to be able to put the LOAN tokens on the RMM"
              Similarly, at the maturity of the loan, LOAN tokens must be removed from the RMM to be burned. Why should the DAO need to be consulted if the only possible outcome is the burn of these tokens? Again, what happens to the wind down of the loan if the vote is rejected?
            3. "resolve cases like the death of the owner of the tokens, the loss of control of the address of the owner of the address"
              As already highlighted before me, there can be a sense of urgency, in the case of an hack for example, that would introduce additional processes to circumvent the slow DAO processes. For non-urgent cases, there remains a need to recover the tokens, and in some instances, there may even be a legal obligation to do so. Yet, by asking the DAO to cast a vote on this matter, a NO result becomes a possibility.

            So, in which situations would the DAO vote on a recovery be legitimate?

            Suggestion

            Instead of seeing the execution responsibility being transferred to the DAO, I think it should remain in the hands of RealT, or the future actors in the ecosystem.

            RealT and the DAO could be assigned a new role (e.g. RECOVERY_EXECUTOR) different from GOVERNANCE_ROLE, that would restrict the execution of the new functions.

            While the DAO would not be required to approve each request individually, its role would be to enforce a posteriori reporting for each action taken by the executors, assessing whether the actions were justified and aligned with the DAO standards, and if not, considering consequences for them.

              Michael-RealT All these procedures imply that if we do not do this update the tokens are blocked in the RMM and poses compliance problems

              Just for the sake of clarity, does that mean the same SC updates will happen regardless of the approval or rejection of the current proposal?

                Kel Jln De plus, n'y a-t-il pas un risque d'allongement des procédures en cas de hack d'un portefeuille ou de n'importe quel incident si RealT ne peut plus agir directement (début d'effet millefeuille) ?

                Ici la fonction n'es pas la pour les questions de hack, pour cela ça reste RealT qui peux agir vial le gèle de l'adresse.
                En revanche oui le processus pour les autres action deviendrais plus lent que si RealT a tout les droit, il faut passer par le processus de vote qui prend 2 semaines, pourrais dans ce cas particulier etre raccourci a 10j
                Un processus plus lent pour les cas qui sont prévu pour l'usage de ses fonction n'es pas un problème.

                Kel Jln RealT (et ses RealTokens) est pour pas mal d'investisseurs un point d'entrée dans le monde de la crypto. Ces personnes là pourraient être refroidies à l'idée que s'ils venaient à collatéraliser leur investissement, la DAO (une communauté envers ils pourraient n'avoir aucune confiance comparé à une entreprise auprès de laquelle ils acceptent de confier leur argent) pourrait avoir un moyen de contrôle sur leur investissement.

                Les personnes présentes ici pourraient bien ne pas représenter par leur vote ces investisseurs un peu éloignés du web 3.0.

                Ne craignez-vous pas une fracture entre ces deux mondes (qui pourrait certes s'apaiser avec le temps si le système fait ses preuves) et donc une plus forte hésitation de la part de certains investisseurs à dynamiser le RMM ?

                Je ne pense pas que cela pose problème, car la DAO n'a pas le contrôle des actif (REALTOKENS), la DAO a le contrôle du Wrapper avec cette proposal, et donc peux éjecter des RealToken du RMM, mais pas prendre le contrôle des REALTOKENS.
                de plus la DAO n'a pas intérêt a mal utiliser ses fonction car cela lui porterais préjudices, sachant que le RMM est pour le moment la principal source de revenu, ce serai comme coupé la branche sur la quelle nous sommes assis.
                Par contre laisser le contrôle à RealT laisse ouvert la porte a un employer malveillant qui pourrais vouloir utiliser pour sont profit, nuisent a RealT et la DAO.
                Une DAO bien au fait de se qui se passent et comment cela fonctionne permet une bien plus grande sécurité qu'un acteur centraliser, meme si en interne de RealT il y as des processus de sécurité et du multi signature sur les actions sensible, il est plus simple de manipuler une poignée de personnes que ensemble d'une DAO

                Madricas "the sale of detokenization"
                Holders of RealToken X have approved its detokenization, now all deposited RealToken X must be removed from the RMM to be burned. The DAO must not have the ability to intervene in that process. What happens to the detokenization if the vote is rejected?

                It is simply not possible from a legal, accounting point of view to have tokens still active on the blockchain at the end of the detokenization process.
                First of all, it is the responsibility of the token holders to remove their token from the RMM to allow these actions to be carried out, however, as we see with RMMv2, while the buyer rate is > 30%, there are deposits that have been inactive for months.
                This creates an impossible compliance situation for RealT, which must be accountable to the authorities and respect their requests.

                So in any case, this update of the contracts will be carried out, if the proposal is accepted then the DAO will have control of the functions, otherwise it is RealT, it is mandatory to be able to put assets such as loans, and for all the cases mentioned.

                Madricas "to be able to put the LOAN tokens on the RMM"
                Similarly, at the maturity of the loan, LOAN tokens must be removed from the RMM to be burned. Why should the DAO need to be consulted if the only possible outcome is the burn of these tokens? Again, what happens to the wind down of the loan if the vote is rejected?

                just like the previous case with the addition of the case of partial repayment of the loan, this implies having to burn a proportional part of the tokens at the time of payment

                Madricas "resolve cases like the death of the owner of the tokens, the loss of control of the address of the owner of the address"
                As already highlighted before me, there can be a sense of urgency, in the case of an hack for example, that would introduce additional processes to circumvent the slow DAO processes. For non-urgent cases, there remains a need to recover the tokens, and in some instances, there may even be a legal obligation to do so. Yet, by asking the DAO to cast a vote on this matter, a NO result becomes a possibility.

                So, in which situations would the DAO vote on a recovery be legitimate?

                Address hacking does not use its features, it is the freezing of the address that will be the most effective, moreover most often when the users realize the hacking, it is already too late to be able to act.

                The role of the DAO in these cases is not to say whether it agrees or not with the detokenization, the LOAN bunr process, the recovery in the event of loss of access to the address or in the context of successes, it is the responsibility of RealT, however the DAO is responsible for the proper functioning of the RMM and other applications of the ecosystem, and therefore what is executed on its contract even if it cannot refuse to do so, it must ensure that what is executed is consistent with what should be executed.

                The purpose of giving control of these functions to the DAO is to be able to guarantee the proper functioning of the RMM, that there will be no end, to give more transparency on this delicate process, this will also give more confidence because imagine a malicious employee who has access to this functionality, he could withdraw user funds from the RMM (even if it is limited in terms of possibility), he could still withdraw to put an address close to liquidation. So it could execute this function at any time, whereas if it goes through a vote of the DAO, the holder of the DAO could say, no there is no announcement of detokenization, or the tokens impacted in the request are not the right ones, for the death or loss of access I admit it is a little more complicated, because there is no announcement, but we can imagine finding verifiable information onChain like the creation of the address, the WL which would have just been carried out by RealT, etc...

                For hacks the solution is the Realtoken Wallet, as there is no more seed, this removes many problematic cases of hack, and if unfortunately the control of the address is lost, then there are still the recovery functions which allow to remove the control to a social login to give it to a new one.

                In any case the security of the Wallets should be a priority of the users with a significant crypto heritage. Having a hardware wallet or better a gnosis safe should be a priority above all that for a few months it is possible to have a safe directly in Rabby as if it were a classic address

                Sylvain Leroux Just for the sake of clarity, does that mean the same SC updates will happen regardless of the approval or rejection of the current proposal?

                yes to be able to be in compliance and meet the requirements of the regulator we must eliminate all the tokens and have distributed the funds to the investors.
                So either RealT has control of the function or it is the DAO but in any case we must update the Wrapper to be able to carry out its operations, otherwise we would have to seize the tokens which would break the RMM contract and put the borrowing positions on the RMM without collateral

                  7 days later

                  “allow the DAO governance to repay a user's debt in the same transaction as withdrawing“ je comprends l’utilité et le principe mais pas les finances et la temporalité.
                  C’est la trésorerie de la DAO qui avance les fonds pour rembourser la dette et qui en échange devient propriétaire du token?
                  La trésorerie serait donc remboursée lorsque le capital sera restitué au propriétaire du token après le burn.

                    NicoCrypto je comprends l’utilité et le principe mais pas les finances et la temporalité.
                    C’est la trésorerie de la DAO qui avance les fonds pour rembourser la dette et qui en échange devient propriétaire du token?
                    La trésorerie serait donc remboursée lorsque le capital sera restitué au propriétaire du token après le burn.

                    non le demandeur doit fournir les fonds nécessaire a la DAO avant l’exécution de la transaction, si c'est un burn de LOAN alors RealT devrais envoyé l'argent a la DAO pour pouvoir exécute la transaction.
                    La DAO fais office de tiers de confiance pour l’exécutions de la fonction.

                      Michael-RealT merci pour ta réponse. Maintenant je comprends mieux pourquoi la proposition ne parlait pas financé.

                      11 days later

                      🇺🇸
                      This proposal seems to have arrived ready for the OnChain vote.
                      I added a clarification in the summary of the proposal to better indicate what will be voted
                      If you have any questions or comments, this is the right time to do so, within 24 hours it should go to the OnChain submission
                      🇫🇷
                      Cette proposition semple arrivé prêt pour le vote OnChain.
                      j'ai ajouté une précision dans le résumé de la proposition pour mieux indiquer se qui sera voté
                      Si vous avez des questions ou remarque c'est le bon moment pour le faire, d'ici 24h elle devrais passer a la soumission OnChain