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

Michael-RealT

🇫🇷 Disponible en FR dans le deuxième post
🇺🇸

Summary:

This proposal aims to determine the distribution method for REGs resulting from RealTokens revaluations. Three options are presented:

A: The initial direct distribution system.
B: A vault system that stores the value in $ convertible to REG.
C: A vault system that stores the number of REGs created.

The vote on this proposal asks the DAO to validate option B, which offers a compromise between two investor philosophies. In case of rejection, a new vote will be launched to validate option C. If rejected, option A will be implemented for a minimum period of 6 months (new vote possible after 6 months).

Motivation:

It is crucial to choose a distribution system that is equitable, transparent, and efficient while considering the advantages and disadvantages of each approach for the Realtoken ecosystem.

Context:

After the SOON converter implementation, new house revaluations that have never been revalued are allocated a budget in newly created REG (see tokenomics), adding to the existing supply.
This REG inflation aims to reward property owners who have invested in tokenized assets, encouraging them to maintain their investments, and allow newcomers to access the DAO without having to invest.
This also allows for better distribution of voting power over time to limit power concentration within the DAO.

Description of options:

Option A: System initially planned and proposed by RealT
- Conversion of dollar amount to REG at market price at distribution time
- Direct distribution to beneficiaries' wallets at rent payment address
Option B: On-demand conversion system with automatic claim option
- Extension of SOON to REG conversion system for future distributions
- Storage of $ value convertible to REG in a vault
- Beneficiary's choice of conversion timing
- No time limit for conversion
- Use of merkle tree for conversion rights management
- Automatic claim option to be activated in vault Smart Contract (disabled by default)
- Conversion rate set by an oracle (with anti-price manipulation calculation system)
- Conversion triggers claim of all amounts due to beneficiary
- Possibility to activate fees for automatic claims (0% by default)
Option C: Vault system storing created REG amount
- Storage of created REG amount in a vault
- Beneficiary's choice of when to claim allocated REG amount
- No time limit for claiming
- Use of merkle tree for conversion rights management

Comparison of options:

Option A (Initial System):
Advantages:

Simple to implement and use
Transparency on inflation and distributions
Prevents price manipulation
Smooths REG value received over time (DCA)
Immediate voting power benefit from REGs upon snapshot power update

Disadvantages:

Systematic REG emission, even for inactive users

Option B (On-demand conversion system with automatic claim):
Advantages:

Potentially limits number of REGs issued
Allows beneficiaries to choose between manual or automatic claim
DCA possible for users who activate automatic claim
Ability to choose conversion timing for users who don't activate automatic claim

Disadvantages:

Market manipulation risks
Initial complexity for automatic system setup
Complexity for newcomers to understand
Difficulty quantifying inflation
No voting rights for unclaimed REGs
Potential fees needed for automatic claims (benefiting those who execute automatic claim transactions, gas fee compensation)

Option C (Vault system storing created REG amount):
Advantages:

No price manipulation
Automatic DCA for all beneficiaries
Easily calculable potential maximum supply

Disadvantages:

No choice of conversion rate for those who would have wanted it
No voting rights for unclaimed REGs
Inflation similar to option A, but reduced by unclaimed REGs
Must claim to benefit from voting power and REGs
System implementation complexity requiring 2 vaults (one for SOON, one for REG)

Important note:

If options B and C are rejected, option A will automatically be implemented for a minimum of 6 months, after which the DAO can vote again on a new proposal to modify the REG distribution method.

Implementation steps:

Community vote to validate or reject option B
If option B is rejected, vote will be launched to validate option C
If option C is rejected, option A will be implemented for minimum 6 months
Smart contract adjustment according to DAO's chosen option
Implementation of chosen system
Community communication about new system

Team:

RealT technical team for development and implementation

Budget:

Option A: $0
Option B: $5,000 to $10,000 (development, testing, automation implementation)
Option C: $7,000 to $12,000 (development, testing, automation implementation)

*Note: Option B development costs are related to necessary adaptations for functionality and automatic claim at smart contract and user interface level.
Option C costs are related to implementation/development of 2 vaults, their operation, and interface that must abstract this complexity for users.

*Note 2: Smart contract audit if necessary will be performed by third party, cost is approximately $30 per line of code, internal audit is included in options B and C cost.

Financial implications:

Development and smart contract audit costs
Potential impact on inflation and REG value depending on chosen option

Roadmap:

Forum discussion: 7 days minimum
Proposal publication: 1 day
DAO vote: 7 days
Queue: 2 days
Development and audit: 2-3 weeks
Launch: Date to be determined based on next revaluation

Success metrics:

Vote participation rate
Community satisfaction with chosen system
Efficiency and transparency of future distributions
Impact on REG price stability

Mission alignment:

This proposal aligns with Realtoken DAO's mission by seeking to optimize REG distribution and strengthen participatory governance of the ecosystem.
As REG belongs to the DAO, giving choice on distribution method is an important point for DAO governance.

Key terms:

REG: Realtoken DAO governance token
SOON: Temporary token representing $1 value, this token will be destroyed when converter vault is implemented
Merkle tree: Data structure used for efficient rights verification
---

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

Vicfer

Michael-RealT

Bonjour Michael,

J’espère que tout va bien. En réfléchissant à la proposition concernant les options A et B pour la distribution des REG, je me dis que l’option B, avec son système de conversion étendu, pourrait être vraiment intéressante, surtout pour sa flexibilité et sa capacité à limiter l’inflation.

Cela m’a amené à une idée : est-ce qu’on pourrait envisager d’ajouter de petits frais de conversion dans l’option B ?

Ces frais, même modestes (par exemple entre 0,1 % et 1 % du montant converti), pourraient servir à :
• Générer des revenus réguliers pour la DAO, permettant de financer des projets stratégiques ;
• Construire ou acquérir des outils pour renforcer l’écosystème, comme des solutions techniques ou des initiatives communautaires ;
• Réduire l’inflation : Une partie des frais pourrait être utilisée pour brûler des REG, augmentant leur rareté et leur valeur.

Je pense que, de façon générale, tous les outils que la DAO pourrait développer ou acquérir seraient des atouts importants pour la croissance et la pérennité de l’écosystème. Ce genre de mécanisme de financement pourrait contribuer directement à ce renforcement.

Après, il me manque sans doute beaucoup d'éléments pour comprendre tous les enjeux.

Je reprends ma formation :-)

Sylvain Leroux

Michael-RealT Malheureusement ont ne peux pas totu expliquer dans chaque proposal, il faudrait dans se cas expliquer comment fonctionne un blockchain, un SC, un Wallet, ect, [...]

Tu tournes toujours en dérision mes demandes pour clarifier les Proposal et faire en sorte que kes votants puissent faire un choix éclairé

Michael-RealT Je ne suis pas de cette avis, car l'option B est une extension direct du SOON convertor (nom qui devra etre changer si c'est B qui est choisi)
Il es donc importante pour la transparence de parler des SOON vu que l'option A permettra la mise en service comme initialement prévu du Soon convertor et si c'est B ou meme C alors le Sonn convertor sera étend

Est-ce qu'on a besoin de connaître les détails d'implémentation pour faire un choix?

Michael-RealT Option A: Initial direct distribution system (proposed by RealT)

Conversion of the dollar amount to REG at market price
Direct distribution to beneficiaries' wallets at the rent payment address

Option B: Extended conversion system (proposed by community members)
Extension of the SOON to REG conversion system to future distributions
Use of a merkle tree for managing conversion rights

Sérieusement, n'as tu pas l'impression qu'une de ces deux proposition est plus claire et compréhensible par le plus grand nombre, et que l'autre s'adresse à un public plus averti?

Je dis encore partialime et manque d'équité.

Et tu me repondras "t'as qu'à chercher sur Perplexity si tu comprends pas". Est-il vraiment impossible d'écrire les deux proposals avec le même degré de lisibilité et d'uniformiser la charge cognitive linguistique des deux propositions?

Michael-RealT

🇫🇷

Résumé:

Cette proposition vise à déterminer le mode de distribution des REG issus des réévaluations des RealTokens. Trois options sont présentées :

A : le système initial de distribution directe.
B : un système de vault qui stocke la valeur en $ convertible en REG.
C : un système de vault qui stocke le nombre de REG créés.

Le vote sur cette proposition demande à la DAO de valider la proposition B qui offre un compromis entre deux philosophies d'investisseurs. En cas de refus, un nouveau vote sera lancé pour valider l'option C. Si celle-ci est rejetée, l'option A sera mise en place pour une durée minimum de 6 mois (nouveau vote possible après 6 mois).

Motivation:

Il est crucial de choisir un système de distribution qui soit à la fois équitable, transparent et efficace, tout en prenant en compte les avantages et inconvénients de chaque approche pour l'écosystème Realtoken.

Contexte:

Après la mise en service du SOON convertor, les nouvelles réévaluations des maisons qui n'ont jamais été réévaluées se voient attribuer un budget en REG nouvellement créés (voir tokenomics), s'ajoutant à la supply déjà existante.
Cette inflation de REG vise à récompenser les propriétaires qui ont fait des investissements dans des actifs tokenisés, les encourageant à conserver leurs investissements, et permettre aux nouveaux arrivants de bénéficier d'un accès à la DAO sans devoir investir.
Cela permet également de mieux répartir le pouvoir de vote dans le temps afin de limiter la concentration du pouvoir au sein de la DAO.

Description des options:

Option A : Système initialement prévu et proposé par RealT
- Conversion du montant en dollars en REG au prix du marché au moment de la distribution
- Distribution directe dans les wallets des bénéficiaires sur l'adresse de paiement des loyers
Option B : Système de conversion à la demande avec option de claim automatique
- Extension du système de conversion des SOON en REG aux distributions futures
- Stockage de la valeur en $ convertible en REG dans un vault
- Choix du bénéficiaire du moment de la conversion
- Pas de limite dans le temps pour la conversion
- Utilisation d'un merkle tree pour la gestion des droits de conversion
- Option de claim automatique a activé dans le Smart Contract du vault ( par defaut desactivé).
- Taux de conversion fixé par un oracle (avec système de calcul anti-manipulation de prix)
- La conversion déclenche un claim de tout ce qui est dû au bénéficiaire
- Possibilité d'activer des frais pour les claims automatiques (par défaut 0%)
Option C : Système de vault qui stock le nombre de REG créés
- Stockage du nombre de REG créés dans un vault
- Choix du bénéficiaire du moment de claim du nombre de REG attribué
- Pas de limite dans le temps pour le claim
- Utilisation d'un merkle tree pour la gestion des droits de conversion

Comparaison des options:

Option A (Système initial):
Avantages:

Simplicité de mise en place et d'utilisation
Transparence sur l'inflation et les distributions
Évite les manipulations de prix
Lisse la valeur des REG reçus dans le temps (DCA)
Bénéfice du pouvoir de vote des REG directement dès la mise a jour snapshot du pouvoir de vote

Inconvénients:

Émission systématique de REG, même pour les utilisateurs inactifs

Option B (Système de conversion à la demande avec claim automatique):
Avantages:

Limite potentiellement le nombre de REG émis
Permet aux bénéficiaires de choisir entre claim manuel ou automatique
DCA possible pour les utilisateurs qui activent le claim automatique
Possibilité de choisir le moment de convertions en REG pour les utilisateurs qui n'activent pas le claim automatique

Inconvénients:

Risques liés aux manipulations de marché
Complexité initiale pour la mise en place du système automatique
Complexité à comprendre l'option pour les nouveaux arrivants
Difficulté à quantifier l'inflation
Pas de droit de vote pour les REG non claimés
Frais potentiellement nécessaires pour les claims automatiques (bénéficiant aux personnes qui exécutent les transactions de claim automatique, dédommagement des frais de gas)

Option C (Système de vault qui stocke le nombre de REG créés):
Avantages:

Pas de manipulation de prix
DCA automatique pour tous les bénéficiaires
Maximum supply potentiel facilement calculable

Inconvénients:

Pas de choix du taux de conversion pour ceux qui l'auraient voulu
Pas de droit de vote pour les REG non claimés
Inflation similaire à l'option A, mais diminuée du nombre de REG non claimés
Obligation de claim pour bénéficier du pouvoir de vote et des REG
Complexité de mise en œuvre du système demandant 2 vaults pour fonctionner

Note importante:

En cas de rejet de l'option B et C, l'option A sera automatiquement mise en place pour une durée minimum de 6 mois, après cette durée, la DAO pourra à nouveau voter pour une nouvelle proposition de modification du mode de distribution des REG.

Étapes d'implémentation:

Vote de la communauté pour valider ou non l'option B
Si l'option B est rejetée, le vote sera lancé pour valider l'option C
Si l'option C est rejetée, l'option A sera mise en place pour une durée minimum de 6 mois
Ajustement des smart contracts selon l'option choisie par la DAO
Mise en place du système choisi
Communication à la communauté sur le nouveau système

Équipe:

Équipe technique de RealT pour le développement et la mise en œuvre

Budget:

Option A : 0$
Option B : 5000 à 10000$ (développement, tests, mise en service de l'automatisation)
Option C : 7000 à 12000$ (développement, tests, mise en service de l'automatisation)

*Note : les coûts de développement de l'option B sont liés aux adaptations nécessaires pour le fonctionnement de l'option et du claim automatique au niveau du smart contract et interface utilisateur.
Les coûts de l'option C sont liés à la mise en place/développement de 2 vaults, leur fonctionnement et l'interface qui doit abstraire cette complexité pour les utilisateurs.

*Note 2 : l'audit des smart contracts si nécessaire sera réalisé par un prestataire tiers, le coût est d'environ 30$ la ligne de code, un audit interne est compris dans le coût des options B et C.

Implications financières:

Coûts de développement et d'audit des smart contracts
Impact potentiel sur l'inflation et la valeur des REG selon l'option choisie

Feuille de route:

Discussion sur le forum : 7 jours minimum
Publication de la proposition : 1 jour
Vote de la DAO : 7 jours
Queue : 2 jours
Développement et audit : 2-3 semaines
Lancement : Date à déterminer en fonction de la prochaine réévaluation

Métriques de succès:

Taux de participation au vote
Satisfaction de la communauté avec le système choisi
Efficacité et transparence des distributions futures
Impact sur la stabilité du prix du REG

Alignement avec la mission:

Cette proposition s'aligne avec la mission de la DAO Realtoken en cherchant à optimiser la distribution des REG et à renforcer la gouvernance participative de l'écosystème.
Le REG appartenant a la DAO, donné le choix sur le mode de distribution, est un point important pour la gouvernance de la DAO.

Termes clés:

REG : Token de gouvernance de la DAO Realtoken
SOON : Token temporaire représentant 1$ de valeur, ce token sera détruit au moment de la mise en service du convertor vault
Merkle tree : Structure de données utilisée pour la vérification efficace des droits

Madricas

Michael-RealT l'option B, enregistrera un montant en $ claimable de REG, tout comme le soon représente 1$, ce n'ais donc pas lié a la valeur de la réévaluation, mais au moment de la réévaluation qui déclenche le calcule d'attribution.
en revanche le Claim lui vas déterminer le nombre de REG par rapport a ça valeur en $

Est-ce qu'on ne pourrait pas envisager une option intermédiaire qui utilise la méthode de distribution B mais à un prix fixe comme pour l'option A ?

Avec l'option A, le prix est fixé par la distribution qui intervient à un instant t.
Si dans l'option B on considère le déploiement de la distribution comme l'instant t, et qu'au lieu d'enregistrer un montant en $ c'est le montant en REG au prix de l'instant t qui est enregistré, alors l'inflation maximale de l'option B est identique à l'inflation de l'option A et on n'aurait pas les 3 situations décrites, surtout celle où le prix baisserait.

Cela faciliterait aussi la fonction de claim, puisqu'il ne serait plus question de devoir convertir au moment du claim et donc recourir à un oracle.

Michael-RealT
Inconvénients:

Risques liés aux manipulations de marché

Complexité pour les utilisateurs moins expérimentés (obligé de claimer les REG)

Difficulté à quantifier l'inflation

Complexité pour appliquer un droit de vote aux REG non créés

Des quatres inconvénients initiaux, cela permettrait donc de réduire les risques liés au marché et les incertitudes sur l'inflation.

Complexité pour les utilisateurs moins expérimentés (obligé de claimer les REG)

Il s'agit d'un effort de documentation et d'explication que la communauté devra faire.

Complexité pour appliquer un droit de vote aux REG non créés

À mon avis, tant qu'un REG n'entre pas dans l'écosystème (par un mint ou une distribution) il ne devrait tout simplement pas avoir de droit de vote associé.

CyberSapyen

Hello,
Max Total Supply = 69,099,793.9 REG.
Est il envisagé ou pas des mécanismes de Burn des REG et par qui ?
Thanks

PhilP

CyberSapyen C'est à la décision de la DAO cf : https://medium.com/realtfrench/token-economy-ce7a2455dead

-RP-

CyberSapyen I believe the Total Supply is 500,000,000 REG (as per the whitepaper: https://medium.com/realtplatform/token-economy-f0b935fe2777), not 69,099,793.9 REG
Also, I believe burn mechanisms is something that can be included in proposals if needed.

Michael-RealT

-RP- I believe the Total Supply is 500,000,000 REG (as per the whitepaper: https://medium.com/realtplatform/token-economy-f0b935fe2777), not 69,099,793.9 REG
Also, I believe burn mechanisms is something that can be included in proposals if needed.

69,099,793.9 is the current mint supply on Gnosis, you still need to add Polygon and Eth to have the current total mint supply. the total of tokens distributed for free is indeed 500,000,000, to this you must add the Soon converted (unknown amount) and the future distribution of the REG, as the model provides there is no maximum, the possession of RealToken tokens gives the right to an amount in REG after the first sale of the RealToken (currently at the revaluation of the houses but this will evolve to work with any tokenized asset)

500 Million REG is potentially very little to be able to function well in the planned system, there will be a lot of REG blocked in contracts to obtain discounts, unlock features, obtain yield, deposit as collateral by service providers, etc.

But indeed if the DAO decides at one point it can set up Burn mechanics, adjust the REG creation mechanics to match the mass of REG to the DAO strategy

Defer

Bonjour puis-je avoir le lien pour allez voté ? MErci bcq 🙂

Bda

Defer pour l'instant c'est au stade de discussion, le vote On chain n'est pas ouvert.

-RP-

Defer This proposal is not active yet (which means it is currently being discussed and not yet "active" and ready to be voted). Feel free to check on https://forum.realtoken.community/d/2-realtoken-dao-official-guidelines to understand the process

volkill

L'option A permet un presque prédictibilité de l'inflation du token ( comparer à l'option B ), et offre une liquidité croissante au fil des distributions qui peut aider à stabiliser sont prix, mais exerçant une tendance baissière sur le token à long terme.
Cette tendance est compenser en parti, pars le nombre de token qui seras immobiliser pour la gouvernance de la DAO.

spK

L'option B me plait sur le "papier" avec un côté actif de l'utilisateur pour récupérer ses REG issus de réévaluation. Elle évite ainsi que des REG dorment sur des wallets de holders non sensibles à la DAO (option A).
L'inflation sera mécaniquement plus faible du fait d'une forte probabilité que nombres de REG ne seront pas réclamés à l'instar de l'airdrop Genesis ; en proportion j'entends, car la croissance RealT est basée sur l'augmentation constante des RealTokens Holders.
De ce que je comprends également sur la future distribution des REG, contrairement aux SOON qui étaient jusqu'alors émis en 1 pour 1 (1 SOON = 1$), là le nombre de REG distribué dépendra de la réévaluation du RealToken mais en plus maintenant du cours du REG sur les marchés au moment de la réclamation (indispensable car on peut imaginer que le cours fasse des sauts ponctuels selon les annonces DAO, et serait défavorable au Token Holder selon le timing de la ré-évaluation) ; à ce propos quelle sera la source 'officielle' du cours du REG pour établir cette conversion en temps réel ? Est-ce là qu'on peut y voir une manipulation de marché énoncée par @Michael-RealT dans les inconvénients listés ?

Une inflation certes non anticipable, mais est-ce vraiment gênant ? Pour moi elle peut rester prédictive selon différents scénarios basés sur les REG claimed. Après, on parle de réguler l'inflation par 'burn' de REG, ne serait-ce pas également possible d'envisager une période maximale pour claim son dû (limitée à X epochs depuis la date de réévaluation) et ainsi limiter l'incertitude d'inflation long-terme si un Holder se réveillait X années après ?

Un point technique annoncé par @Michael-RealT et nécessisite des éclaircissements :

"Utilisation d'un merkle tree pour la gestion des droits de conversion"

J'ai lu un peu de théorie sur le concept, mais ça donnerait quoi appliqué au modèle RealT actuel ?

Michael-RealT

spK De ce que je comprends également sur la future distribution des REG, contrairement aux SOON qui étaient jusqu'alors émis en 1 pour 1 (1 SOON = 1$), là le nombre de REG distribué dépendra de la réévaluation du RealToken mais en plus maintenant du cours du REG

Pas tout a fais, l'option B, enregistrera un montant en $ claimable de REG, tout comme le soon représente 1$, ce n'ais donc pas lié a la valeur de la réévaluation, mais au moment de la réévaluation qui déclenche le calcule d'attribution.
en revanche le Claim lui vas déterminer le nombre de REG par rapport a ça valeur en $, donc il y as 3 scénario opposant A et B
A est distribuer a un prix x,

en mode B si tu claime alors que le prix du REG a monté entre temps, alors tu as moins de REG
en mode B si tu claime alors que le prix du REG a baisser entre temps, alors tu as plus de REG
en mode B si tu claime alors que le prix du REG n'a pas changer, alors tu as le même nombre de REG de REG

Michael-RealT

spK à ce propos quelle sera la source 'officielle' du cours du REG pour établir cette conversion en temps réel ?

Cela sera surement aussi un sujet de vote, car il peux y en avoir plusieurs avec des risque et avantage

Michael-RealT

spK Est-ce là qu'on peut y voir une manipulation de marché énoncée par @Michael-RealT dans les inconvénients listés ?

Dans le cas de B effectivement si tu as une liquidité faible et un prix de conversion sans sécurité, que tu trouve un moyen de faire chuté le prix (fake news, vente massive de REG, ect....) tu pourrais claim beaucoup plus de REG.
donc dans le cas de l'option B nous devons mettre en place des système pour évité cela.

Michael-RealT

spK Une inflation certes non anticipable, mais est-ce vraiment gênant ? Pour moi elle peut rester prédictive selon différents scénarios basés sur les REG claimed. Après, on parle de réguler l'inflation par 'burn' de REG, ne serait-ce pas également possible d'envisager une période maximale pour claim son dû (limitée à X epochs depuis la date de réévaluation) et ainsi limiter l'incertitude d'inflation long-terme si un Holder se réveillait X années après ?

Juridiquement c'est un peux plus compliquer comme ce claim et lier a l'achat d'un investissement, concrètement c'est de l'argent du a un client, ça ne pourrais pas être simplement annuler contrairement au GENESIS qui étais un cadeau.
Le problème avec l'anticipation de B, c'est que tout a cous nous pourrions voir arrivé une quantité importante de REG sur le marché si des personnes en ont accumulé en droit de claim, et pourrais créer une chute de prix ponctuel, c'est pas un problème en soit mais les effets de bord peuvent être plus problématique et par souci de clarté il faut poser le sujet sur la table

Yohann76

I am inclined to choose option B, mainly for two reasons:

Inflation control: Option B would better manage the inflation of REG by only issuing tokens when beneficiaries convert them, thereby limiting the creation of inactive REG. This would protect the value of existing REG by aligning supply with real demand, and ensure that REG are actively used rather than sitting unused in inactive wallets.

Individual responsibility: Option B prevents placing the responsibility on RealT in the event of delays in revaluations, as the timing of conversion would be at the discretion of the holders, thus reinforcing their individual responsibility.

Stouban

Yohann76 Individual responsibility: Option B prevents placing the responsibility on RealT in the event of delays in revaluations, as the timing of conversion would be at the discretion of the holders, thus reinforcing their individual responsibility.

🇫🇷
L’option A doit être écartée car elle donne une responsabilité à RealT sur la date de conversion en REG, comme le souligne Yohann76.

L’option B est très sexy mais elle est complexe à expliquer, difficile à comprendre, et difficile à mettre en place…

Je ne sais pas si l’équipe de RealT a déjà étudié cette option :
le nombre de REG par Realtoken est défini en fonction de la valeur du REG au jour de la mise en vente du Realtoken.

Concrètement :
Imaginons que le 24/10/2024, il y a une vente d’un Realtoken à 50$ et que le REG est à 1,3$, il est défini que lors de la réévaluation (date à la discrétion de RealT), 3,8461538462 REG seront distribués par Realtoken de cette propriété.

Prix du Realtoken x 10% de RealT / Prix du REG à la date de mise en vente du Realtoken
50$ x 10% / 1,3$ = 3,8461538462 REG par realtoken

Les propriétés vendues avant le REG peuvent rester sur la logique du SOON.

Cette option est simple à expliquer, à comprendre et à mettre en place.
Les conséquences, par contre, ne sont pas du tout les mêmes (je développerai cette option uniquement si elle présente un intérêt).

🇺🇸
Option A must be ruled out because it gives RealT the responsibility for the conversion date into REG, as pointed out by Yohann76.

Option B is very appealing, but it is complex to explain, difficult to understand, and hard to implement…

I don’t know if the RealT team has already considered this option:
the number of REG per Realtoken is defined based on the value of REG on the day of the sale.

Specifically:
Let’s imagine that on 10/24/2024, there is a token sale at $50 and the REG is valued at $1.3. It is defined that during the revaluation (at RealT’s discretion), 3.8461538462 REG will be distributed per Realtoken of this property.

Realtoken price x 10% of RealT / REG price at the token sale date
$50 x 10% / $1.3 = 3.8461538462 REG

Properties sold before the REG can remain under the SOON logic.

This option is simple to explain, understand, and implement.
However, the consequences are not the same at all (I will only elaborate on this option if it seems worthwhile).

durand

I think I will vote in favor of option A. It will be a security vote to prioritize inflation control and prevent risks related to market manipulation. The goal is to reduce slippage.

If the only disadvantage of this option is inactive tokens, which do not participate in the DAO, then we can limit the risk with a decrease in the distribution for these portfolios:

we protect tokens that are not used
we protect ourselves from too much speculation

davidg

Hello,
J'espère ne pas être totalement à côté du sujet.
Si je comprends bien, lorsqu'une réévaluation d'un bien est réalisée, des tokens REG pourraient être émis pour matérialiser la hausse de la valeur. Quid d'une réévaluation à la baisse, comment est-ce que cela se matérialise ?

Michael-RealT

davidg J'espère ne pas être totalement à côté du sujet.
Si je comprends bien, lorsqu'une réévaluation d'un bien est réalisée, des tokens REG pourraient être émis pour matérialiser la hausse de la valeur. Quid d'une réévaluation à la baisse, comment est-ce que cela se matérialise ?

non c'est pas tout a fais cela.
le système actuelle qui vas devoir changer pour fonctionner avec d'autre actif tokeniser, fonctionne actuellement comme cela.
a l’achat tu as des frais REALT de 10% dans le prix du token, a la réévaluation de la maison (peux importe que la maison vaut plus ou moins) les 10% sont retirer du prix du token pour des questions comptable, de bouclement de compte car si on les laisser RealT ne peux jamais les comptabilisés vu que nous rachetons au prix affiché moins les frais de traitement.
Donc les 10% sont converti en REG, actuellement en soon qui vaut 1$, une fois le soon covertor en service c'est des REG qui doivent etre distribuer pour le montant en $ des 10% de fee RealT (mécanique prévu dans la token économic), et la soit option A RealT distribue directement les REG aux cours du moment sur les Wallet, soit le montant en $ est enregistrer dans le contrat pour une conversions au moment choisis par le bénéficiaire aux cours de la source de prix

Yohann76

Michael-RealT

Dans le cas de B effectivement si tu as une liquidité faible et un prix de conversion sans sécurité, que tu trouve un moyen de faire chuté le prix (fake news, vente massive de REG, ect....) tu pourrais claim beaucoup plus de REG.
donc dans le cas de l'option B nous devons mettre en place des système pour évité cela.

A-t-on déjà des idées de systèmes pour éviter cela ?

Cela pourrait être par exemple(?) :

Une limite de conversion par période
Des pénalités pour manipulation
Avoir un certain niveau de liquidité minimum

Michael-RealT

spK Un point technique annoncé par @Michael-RealT et nécessisite des éclaircissements :
"Utilisation d'un merkle tree pour la gestion des droits de conversion"

J'ai lu un peu de théorie sur le concept, mais ça donnerait quoi appliqué au modèle RealT actuel ?

si tu comprend pas le merkle tree c'est pas grave, vulgarisation c'est une structure de données qui permet de ne pas enregistre toutes les infos dans un SC mais qui permet au contrat de vérifier que se que tu lui demande de faire, de te donné tu as bien le droit de le faire.
la majorité des airdop et distribution par claim utilise cette technique

davidg

Michael-RealT excellent merci c'est très clair !

Lolca

Michael-RealT

Bonjour,

Je suis d'avance désolé, mais j'ai du mal à comprendre cette notion de création de REG lors des réévaluations.
Pourquoi est-ce que Realt ne prélève pas dès le départ ses 10% et que le prix du token baisse immédiatement ?
D'autant que je croyais que Realt et la DAO étaient ou avaient pour but d'être 2 entités différentes. Donc comment est-ce que Realt peut décidé de créer des REG au détriment de la DAO ?
Certainement que des informations m'ont échappées car je n'ai pas encore rattrapé les nombreuses années d'existance de Realt, donc désolé pour mes questionnements ?

Sinon si tout est clair et normal pour les autres, ne peut-on pas envisager que Realt récupère ses 10% en REG pour pouvoir contrôler la libération des token ? (Peut être pas gérable d'un point de vue comptable)
Ou encore partir sur l'option A, mais avec une libération progressive sur les wallets du genre 1, 2 ou 3% par jour ? Ca éviterait une vente massive dès le versement des REG.