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

EzSwim

Is the DAO happy with the current limits on the USDREG conversion oracle ?
minAnswer = 0.5 USD (lower limit of the bracket in the smart contract/ also refered to as "the threshold")
maxAnswer = 100 USD (upper limit of the bracket in the smart contract)

Theses values were initialized by RealT as they released the USDREG conversion vault on march 19. (it was discussed with experts over at Chainlink and based on the REG price at the time)

Theses limits can be modified and Michael encouraged the DAO on Telegram to discuss the relevance of the initial values.

This suggestion serves as a means for anyone to follow and participate in the debate:

How should the DAO manage the USDREG conversion Threshold ?

Context :

To put things into context, it's important to understand the impact of this threshold (currently at 0.5) for the USDREG oracle and why it was put in place.

On March 19 2025, a tool appeared to claim your REG. This tool allows you to convert your USDREG (the right to mint REG based on their value).

RealT has implemented a conversion threshold. Currently, it's therefore not possible to convert USDREG below 0.5 per 1 REG.

This threshold is not intended to control the price of REG, but rather to limit high inflation in case of a hack on the oracle.

For instance, if a hacker found a way to manipulate the oracle to return 1 REG = 0.0001 USDREG, it would then be very easy to create a lot of REG and thus have uncontrolled inflation. This threshold is therefore an essential protection mechanism for the security of REG and its supply. This mechanism could potentially be adjusted over time depending on the liquidity of REG and the level of risk we are willing to take.

~~We must maintain a balance between a conversion that reflects market reality and a conversion that does not endanger REG and its supply.~~ (do we really have to? Some DAO members have argued against)

Where does this threshold of 0.5 come from? This value, implemented by RealT, is based on Chainlink's recommendations. Chainlink, which is used to managing this type of oracle, recommended 0.5 to protect the REG supply as a minimum (at the time 1 REG was worth between $1.5 and $2). REG markets have especially very low liquidity. If liquidity were sufficient, this threshold would not necessarily be required

How the oracle algorithm works :

You can find the oracle smart-contract here.

Every 24h, the fulfillRegPrice(bytes32,uint256) function updates the price the oracle (🔴) returns to the USDREGConversionVault with an off-chain price (🔵). This price (🔵) is calculated from Chainlink's server (more insights on how this price is calculated in the wiki).

Below you can find the conditions (written in english) that acts as the protective measure against hackers:
If the price (🔵) is within the range [minAnswer; maxAnswer] and [regTwapPrice * (1 - diffFactor); regTwapPrice * (1 + diffFactor)] then update the oracle price (🔴).

On march 19:
minAnswer = 50000000 (= 0.5 since 8 decimals) => the lower limit of the bracket
maxAnswer = 10000000000 (= 100 since 8 decimals) => the upper limit of the bracket
regTwapPrice => The on-chain TWAPOracleREGUSD calculated price
diffFactor = 500 (= 5% since 10000 = 100%) => probably to check if the off-chain price (🔵) returned by chainlink's server is not widely off the regTwapPrice (since the REG pools are illiquid there can be high price variation in a split second)

The full fulfillRegPrice(bytes32,uint256 ) function:

function fulfillRegPrice(
        bytes32 requestId,
        uint256 price
    ) public recordChainlinkFulfillment(requestId) {
        uint256 regTwapPrice = getRegTwapPriceInUsd();
        uint256 diffFactorCache = _priceRangeDiffFactor; // cache to save gas
        uint256 minAnswerCache = _minAnswer; // cache to save gas
        uint256 maxAnswerCache = _maxAnswer; // cache to save gas

        // If the price is within the range (minAnswer, maxAnswer) and (regTwapPrice * (1 - diffFactor), regTwapPrice * (1 + diffFactor)) then update the price
        if (
            price >
            ((regTwapPrice * (PRICE_RANGE_FACTOR - diffFactorCache)) /
                PRICE_RANGE_FACTOR) &&
            price <
            ((regTwapPrice * (PRICE_RANGE_FACTOR + diffFactorCache)) /
                PRICE_RANGE_FACTOR) &&
            price > minAnswerCache &&
            price < maxAnswerCache
        ) {
            // Emit the callback function event
            emit RequestRegPriceFulfilled(requestId, price);

            _latestAnswer = int256(price);
            _latestRound += 1;
            _latestTimestamp = block.timestamp;
            _answers[_latestRound] = _latestAnswer;
            _timestamps[_latestRound] = block.timestamp;
            emit AnswerUpdated(int256(price), _latestRound, block.timestamp);
            emit NewRound(_latestRound, msg.sender, block.timestamp);
        } else {
            // Emit the off-chain price out of range event
            // Do not revert the transaction to prevent Chainlink automation from stopping
            emit OffChainPriceOutOfRange(
                price,
                regTwapPrice,
                diffFactorCache,
                minAnswerCache,
                maxAnswerCache,
                requestId
            );
        }
    }

SOLUTIONS:

(En français sous le résumé Anglais)
🇺🇸

1 · Fixed $0.50 Threshold (status‑quo)

Effect when the price freezes

Situation	Spot price	Oracle price (frozen)	REG / USDREG	Relative inflation
Before crash	$0.60	$0.60	1.67	–
After crash < $0.50	$0.30	$0.50	2.00	+20 % REG per USDREG

As soon as the spot price drops below $0.50, the Chainlink feed stops updating and keeps the last answer.
Each coupon can mint no more than 2 REG, capping the potential impact to ≈ 0.32 % of total supply if the remaining 800 k USDREG are all converted.

Pros & Cons

✅ Pros	❌ Cons
Automatic protection – no governance action, no room for human error.	USDREG holders are penalised while spot < $0.50, receiving fewer REG than the real price would allow.
Limited arbitrage pressure – converters receive fewer REG, so fewer tokens hit the market.	When REG climbs back above $0.50, the oracle “catches up”, creating temporal inequality between early and late converters.

2 · Parameterised Periodic Floor‑Cut (variables X, Y, Y′, Z)

How it works

Every X days the Security Committee compares the current anti‑hack floor with the Z‑day TWAP:

Calculate the Time‑Weighted Average Price (TWAP) over Z days.
Measure the gap:

Gap = (CurrentFloor – TWAP) ÷ TWAP
If the gap is greater than or equal to Y′ percent, lower the floor by Y percent:

NewFloor = CurrentFloor × (CurrentFloor – Y percent)
The multisig calls setMinAnswer(). Once mined, the oracle either follows the live price (if spot ≥ NewFloor) or stays frozen at the new value.

When the spot price leaves the minAnswer / maxAnswer range, the Chainlink feed keeps returning the last valid answer.

DAO‑set variables

Symbol	Purpose	Current example	Main effect
X	Execution frequency	7 days	Shorter ⇒ more reactive, higher cost
Y	Cut applied to the floor	35 %	Higher ⇒ bigger one‑shot inflation
Y′	Trigger margin	10 %	Lower ⇒ cuts fire more often
Z	TWAP window	3 days	Shorter ⇒ more sensitive to spikes

Example

Parameters: X = 7, Y = 35 %, Y′ = 10 %, Z = 3

3-days TWAP : 0,3725 USD
Current Floor: 0,5 USD
Gap = (CurrentFloor – TWAP) ÷ TWAP = (0.5 - 0.3725) / 0.3725 = 34.28 % (above 10 %) → condition met
New floor = CurrentFloor × (CurrentFloor − Y %) = 0.5 - 0.5 × 0.35 = 0.325 USD

While the spot price stays below 0.325 USD, conversion uses the frozen rate (≈ 3.08 REG per USDREG). As soon as spot rises back above the floor, the oracle resumes live updates.

Pros & Cons

✅ Pros	❌ Cons
Clear parameters, adjustable by vote.	Manual executions: any delay opens an arbitrage window.
Gradually reduces USDREG discount without sacrificing the circuit breaker.	One‑off inflation peaks proportional to Y percent and the coupon volume converted right after the cut.
Guarantees no minting below the active floor (anti‑hack stays intact).	Hyper inflation risk

3 · Inflation‑Cap Threshold

Mechanics under freeze

minAnswer = USDREG_remaining / (REG_supply × InflCap).
If spot falls below this value, the price freezes at minAnswer.
Total REG minted can never exceed InflCap × REG_supply, regardless of how deep the crash is citeturn0search1.

Example

Inputs: 800 k USDREG left, 500 M REG supply, InflCap 0.25 % ⇒ minAnswer = $0.64.
If REG ↘ $0.30, oracle stays at $0.64 ⇒ 1 USDREG = 1.56 REG.
Maximum inflation = 0.25 % of supply even in total market collapse.

Pros & Cons

✅ Pros	❌ Cons
Automatic & predictable – no vote until “USDREG_remaining” or supply move beyond a threshold.	-
Security scales with future allocations: a large Merkle update immediately raises `minAnswer`.	-

Comparative snapshot

Criterion / Option	Fixed floor 0.50 USD	Parameterised periodic cut	Inflation‑Cap
Behaviour when REG < floor	Conversion at 2 REG / USDREG	Price frozen; once the Y′ % gap is met, floor is cut and conversion happens at a higher rate	Conversion at a capped rate (≤ InflCap)
Complexity	☆☆☆	★☆☆	★☆☆
Inflation risk	0.32 % of supply (current data)	Risk of hyper inflation	Chosen InflCap (e.g., 0.25 %)
Alignment with anti‑hack goal	🟢	🟢	🟢

Key Take‑aways for the DAO

The threshold never stops conversion; it only caps how many REG each USDREG can mint.
A low threshold restores USD parity but weakens protection; a high threshold shields supply but deepens coupon discount.
Inflation‑Cap offers the same anti‑hack guarantee as a fixed floor while tracking the real USDREG stock.
Whatever the model, keep a pauseVault() emergency switch in case the oracle is compromised above minAnswer.

🇫🇷

1 · Seuil fixe 0,50 USD (statu quo)

Effet avec gel du prix

Situation	Prix spot	Prix oracle (gelé)	REG/ USDREG	Inflation relative
Avant krach	0,60	0,60	1 ,67	–
Après krach <0,50	0,30	0,50	2 ,00	+20 % REG / USDREG

Le gel maintient une inflation bornée : tant que le marché reste sous 0,50, chaque coupon ne peut émettre plus de 2 REG, ce qui limite l’impact à 0,32 % du supply si les 800 k USDREG restants sont tous convertis.

Avantages & Limites

✅ Avantages	❌ Limites
Protection automatique : aucun update ⇒ aucune erreur de gouvernance.	Les détenteurs d’USDREG sont pénalisés quand le prix spot < 0,50, car ils frappent moins de REG qu’au prix réel.
Décote maîtrisée pour le REG : la demande d’arbitrage (revendre REG) est moindre car les convertisseurs reçoivent moins de REG que si le prix suivait le marché.	S’il remonte > 0,50, l’oracle rattrape le marché et réduit encore le nombre de REG/ USDREG, créant une différence de ratio entre convertisseurs précoces et tardifs.

2 · Révision manuelle périodique paramétrée (variables X, Y, Y′, Z)

Principe

Tous les X jours, le Comité de sécurité compare le seuil anti‑hack actuel au TWAP calculé sur Z jours :

Calculer le Time‑Weighted Average Price (TWAP) sur Z jours.
Mesurer l’écart :

Écart = (SeuilActuel – TWAP) ÷ TWAP
Si l’écart est supérieur ou égal à Y′ %, baisser le seuil de Y % :

NouveauSeuil = SeuilActuel × (SeuilActuel − Y %)
Le multisig exécute setMinAnswer(). Une fois la transaction minée, l’oracle continue soit au nouveau prix (si le spot est ≥ NouveauSeuil), soit reste figé sur cette valeur.

Quand le spot sort de la plage minAnswer / maxAnswer, le feed Chainlink conserve la dernière valeur valide.

Variables fixées par la DAO

Symbole	Rôle	Exemple actuel	Effet principal
X	Fréquence d’exécution	7 jours	Plus court ⇒ réactivité accrue, frais plus fréquents
Y	Pourcentage de réduction	35 %	Plus élevé ⇒ inflation ponctuelle plus forte
Y′	Écart déclencheur	10 %	Plus bas ⇒ coupes plus régulières
Z	Fenêtre TWAP	3 jours	Plus courte ⇒ plus sensible aux pics

Exemple

Paramètres : X = 7, Y = 35 %, Y′ = 10 %, Z = 3

TWAP (3 jours) : 0,3725 USD
Seuil actuel: 0,5 USD
Écart : (SeuilActuel – TWAP) ÷ TWAP = (0.5 - 0.3725) / 0.3725 = 34,28 % (supérieur à 10 %) → condition remplie
Nouveau seuil : SeuilActuel × (SeuilActuel − Y %) = 0.5 - 0.5 × 0.35 = 0,325 USD

Tant que le spot reste inférieur à 0,325 USD, la conversion se fait au taux figé (≈ 3,08 REG par USDREG). Dès que le spot repasse au‑dessus, l’oracle se remet à jour.

Avantages & Limites

✅ Avantages	❌ Limites
Paramètres clairs, ajustables par vote.	Exécutions manuelles : tout retard ouvre un décalage avant mise à jour.
Réduit progressivement la décote des USDREG sans sacrifier le « circuit‑breaker ».	Pics d’inflation ponctuels proportionnels à Y % et au volume converti juste après la coupe.
Garantit qu’aucun mint ne se fait sous le seuil actif (protection anti‑hack intacte).	Risque d'hyper inflation

3 · Seuil Inflation‑Cap

Mécanique sous freeze

minAnswer = USDREG_dispo / (REG_supply × InflCap). Si le cours spot tombe sous cette valeur, l’oracle gèle à minAnswer. Le nombre de REG frappés ne peut pas dépasser InflCap × REG_supply, quelle que soit la profondeur du krach.

Exemple

Données : 800 k USDREG restants, supply 500 M, InflCap 0,25 % ⇒ minAnswer = 0,64 USD.
Si REG ↘ 0,30 USD, l’oracle reste à 0,64 ⇒ 1 USDREG = 1,56 REG.
Inflation maximale théorique : 0,25 % du supply, atteinte même si le marché se délite totalement.

Avantages & Limites

✅ Avantages	❌ Limites
Automatique et prévisible : aucun vote tant que les variables “USDREG_dispo” et “supply” n’ont pas bougé au‑delà d’un seuil.	-
Aligne la sécurité sur le risque d’allocation future : une grosse mise à jour du Merkle tree augmente immédiatement `minAnswer`.	-

Synthèse comparative

Critère / Piste	Seuil fixe 0,50 USD	Baisse périodique paramétrée	Inflation‑Cap
Comportement si REG < seuil	Conversion à 2 REG / USDREG	Après déclenchement (écart Y′ %), abaissement du seuil et conversion à un taux plus élevé	Conversion à un taux plafonné (≤ InflCap)
Complexité	☆☆☆	★☆☆	★☆☆
Risque d'inflation	0,32 % du supply (données actuelles)	Risque d'hyper inflation	InflCap choisi (ex. 0,25 %)
Alignement avec l’objectif anti‑hack	🟢	🟢	🟢

Points clefs pour la DAO

Comprendre que le seuil n’arrête jamais la conversion, il borne seulement la quantité de REG que chaque USDREG peut créer.
Un seuil trop bas protège moins mais rétablit la parité USD ; un seuil trop haut protège mieux mais creuse la décote des coupons.
L’option Inflation‑Cap apporte la même garantie anti‑hack qu’un seuil fixe, tout en suivant la croissance du stock d’USDREG.
Quel que soit le modèle retenu, prévoir une pauseVault() de secours si l’oracle est compromis au‑dessus de minAnswer.

Michael-RealT

EzSwim Theses values were imposed by RealT as they developed the USDREG conversion vault.

Avec se genre de remarque, il pourrais que RealT ne développe plus rien, REALT n'as pas imposer, et c'est meme Realt qui as demander a la DAO de décider de la politique lier a ses valeurs, RealT n'as que mis ds paramétré par rapporta un moment de déploiement, Valeur qui ne sont pas en dure et donc modifiable se qui as été demander a la DAO de décidé

se commentaire est d'une total mauvaise fois

Michael-RealT

EzSwim Indeed, with a price manipulation where a REG would be worth 0.01, it would then be very easy to create a lot of REG and thus have uncontrolled inflation. This threshold is therefore an essential protection mechanism for the security of REG and its supply. This mechanism could potentially be adjusted over time depending on the liquidity of REG and the level of risk we are willing to take.

il y as une erreur ici c'est pas contre une manipulation du prix sur le marché, la protection contre cela c'est la logique de fonctionnement de l'oracle qui le calcule, baser sur les conseilles de la team Chainlink.
le prix si c'est le prix que la communauté décide en vendant sans racheter sera le prix.

le Seuil dans le contrat a pour objectif de protéger les failles dans la valeur de l'oracle, si un hacker trouve une solution pour forcé une valeur comme 0.0001 alors que le REG n'a pas cette valeur sur le marché.
Le seuil a donc pour objectif de limité la casse en cas de hack de l'oracle.

Michael-RealT

EzSwim Where does this threshold of 0.5 come from? This value, implemented by RealT, is based on Chainlink's recommendations. Chainlink, which is used to managing this type of oracle, recommended 0.5 to protect the REG supply as a minimum, especially in a very low liquidity market. If liquidity were sufficient, this threshold would not necessarily be necessary

oui ce'st baser sur les discussion dans un contexte donné, un REG qui étais entre 1.5 et 2$
Le contexte a changer et RealT a demander de prendre ses responsabilité en fixant une politique de mise a jours de ses valeurs.
au lieu de réfléchir efficacement sur le sujet, la communauté fais des affirmation hors de propos et totalement incorrect, des proposition absurde, espérons que la réflexion sera meilleur ici

Saitama

EzSwim
I think this can bring some context to the situation:

First, if we have to summarize the REG market in one word, it is: ILLIQUID.

It has only 10 liquidity pools, only 2 of which have somewhat meaningful liquidity (REG/USDC Sushiswap V3: 300K REG and 6K USDC, REG/sDAI on Balancer v2: 17 K REG and 6 K sDAI). In total, these pools hold less than $20,000 USD in stablecoins (at peak, there were around $50,000 USD). They have less than 500k REG (0.1% of the total supply 500M REG)
The average monthly volumes since launch is around 100k USD (or an average 3k USD daily volume)
That means there is very low-liquidity, low-amount of REG in the market, low-volume trading. This creates a perfect environment for market manipulation in either direction (up or down), so using the market spot price is a big NO.

Second, after considering all these conditions, we decided to use TWAP for REG oracle for protection against short-time manipulation with the tradeoff of disadvantages (lagging price and market coverage). When the price is on increasing trends, then TWAP report lower than spot price. When the price is on decreasing trends, then TWAP report higher than spot price.

We use both offchain/onchain for price reporting to double check that both values are the same (for a give time interval with a difference tolerance).
Offchain TWAP price allows to have more market coverage, and onchain TWAP price allows to double-checking the offchain price.
The time interval is set at 24h. It could have been set at 72h, but we consider that 24h provides more fresh price data and enough for monitoring.
The initial tolerance difference was 5% and now at 10% (after the USDREGConversionVault launch). For reference, most Chainlink oracle price feeds are operating with deviation threshold around 0.5%-2%. Low-liquidity pairs can have 5% of deviation threshold. Even these pairs have 5-10 millions USD daily volume, comparing to 3k-5k daily volume of REG.
We use a circuit-breaker mechanism (presented in Chainlink price feeds) to limit the price lower/upper bounds (0.5-100 USD). If the price fell out of these range, the price will not be updated. When these values were set, the REG was trading in range 1.5-2 USD. We thought a limit at 70-80% lower might be enough, but apparently it is not.

Third, The problem is we have 1.4M USDREG-equivalent to be "converted" into REG (600k of which is already converted), while there were less than 20k USD in pools. We already know this kind of situation will create a death spiral: mint REG from USDREG => dump and lower REG price => mint more REG => dump and lower REG price => mint more REG...
There were already incidents in the past for this kind of exploit: Terra luna, Iron finance
Here is an example with 80k USDREG initially, someone can mint 26 billions REG in 4 steps.
Even with TWAP in place, this can happen in slow motion. The lower bound (0.5 USD) sets a limit on this inflation.

Benoist-Not-for-sale

Totally agree although it is currently the opposite:
min REG price is 0.5 USD / REG, minimum thresold is 1 USDREG = 2 REG.
So it makes sense to set min answer to 24 instead of 42

EzSwim

Benoist-Not-for-sale

What are you agreeing with and how is 24 any better than 42 I don't understand the logic behind.

For the record, 42 was @DRKTT 's absurd answer to my absurd suggestion on Telegram where I said something along the lines of "Let's ramp up the lower limit to 10" (meaning way above the REG market price) because people kept telling me the lower limit is JUST a preventive measure against hyperinflation.
If that were TRUE, everyone should be ok with 42.

I now have explained in great details how the oracle works and what was the intended purpose of theses limits.
If readers still have troubles understanding the topic please tell me what is keeping you from participating and I will update the suggestion accordingly as well as try my best to provide you with answers.

PhilP

Je trouve surprenant que la question soit posée ainsi, surtout par quelqu'un qui fait de supers videos de vulgarisation !
Seuls les personnes qui ont lu les dizaines de messages sur le TG DAO d'hier, peuvent comprendre de quoi il en retourne.
Le sujet à traiter par la DAO https://t.me/realtokendao_official/3/9649 me semble mériter mieux, pour que chacun s'approprie la problématique et puisse avoir un avis.

EzSwim

PhilP
This is to move the debate to the forum. I don't think the topic is easy to follow for non-french speakers on Telegram. I deliberately phrased it in a provocative way so that interested people would take part in the discussion and explain their point of view and their understanding of the threshold mechanism.

Why is 0.5 better than 42?

If the oracle's price really aims to prevent hyperinflation, why not choose a stupidly high number as the threshold?

If people instinctively reject a minAnswer (lower limit) above the market price, why?

Why a bracket and not a fixed random number?

Maybe we should keep the default 0.5-100 forever ? Maybe not, if so, why and how should we decide on the next limits?

Yohann76

To clarify and put things into context, it's important to understand the impact of this threshold (currently at 0.5) for the USDREG oracle and why it was put in place.

A few days ago, a tool appeared to claim your REG. This tool allows you to convert your USDREG (the right to mint REG based on their value).

RealT has implemented a conversion threshold. Currently, it's therefore not possible to convert USDREG below 0.5 per 1 REG.

This threshold is not intended to control the price of REG, but rather to limit high inflation in case of REG price manipulation.

Indeed, with a price manipulation where a REG would be worth 0.01, it would then be very easy to create a lot of REG and thus have uncontrolled inflation. This threshold is therefore an essential protection mechanism for the security of REG and its supply. This mechanism could potentially be adjusted over time depending on the liquidity of REG and the level of risk we are willing to take.

We must maintain a balance between a conversion that reflects market reality and a conversion that does not endanger REG and its supply.

Where does this threshold of 0.5 come from? This value, implemented by RealT, is based on Chainlink's recommendations. Chainlink, which is used to managing this type of oracle, recommended 0.5 to protect the REG supply as a minimum, especially in a very low liquidity market. If liquidity were sufficient, this threshold would not necessarily be necessary.

EzSwim

Michael-RealT

As I clearly suggested to change the threshold, It seemed obvious to me that there was no need to specify that the limits CAN be changed if needed. I have now added a sentence mentioning that just in case.

I also added that it was RealT that invited the DAO to discuss the limits as I agree that It was missing from the context.

After some digging, it seems that the word “impose” doesn't mean what I thought it meant. I thought it meant more "without taking someone's opinion into account" / “regardless of what someone thinks” than “against someone's will”.
Anyway, I was trying to get across that the DAO had no say in the values (0,5 and 100) during the development of the safe. So it must have something to say now that the safe has been delivered. Whether it agrees with the initial values or want to change it. Therefore I switched "impose" to "initialized".

EzSwim

Michael-RealT le Seuil dans le contrat a pour objectif de protéger les failles dans la valeur de l'oracle, si un hacker trouve une solution pour forcé une valeur

Good point, I've applied the changes accordingly.

PhilP

A l'aide des contributions de chacun, cette proposition prend une meilleur tournure : moins provocatrice et plus constructive.
Reste encore :

le titre, qui pourrait par exemple être du type : "Evolution du seuil de protection de l'Oracle",
et la question principale, qui n'a pas trop de sens ..
La valeur minimal de l'oracle ne peut être significativement au dessus des cours, sous peine de pénaliser toutes les personnes qui claimeraient (exemple : avec un cours du REG à 1$, un utilisateur avec 100 USDREG aurait : 100 REG si le seuil était inférieur à 1 et 2,4 REG si le seuil était à 42 !).
Par contre, la question pourrait être : comment ajuster la valeur de cette protection, en fonction de l'évolution du cours du REG...

Cogatos

PhilP La valeur minimal de l'oracle ne peut être significativement au dessus des cours, sous peine de pénaliser toutes les personnes qui claimeraient (exemple : avec un cours du REG à 1$, un utilisateur avec 100 USDREG aurait : 100 REG si le seuil était inférieur à 1 et 2,4 REG si le seuil était à 42 !).

Je te remercie pour ce complément d'information qui donne un argument technique et clair du pourquoi la valeur du minAnswer ne peut être complètement arbitraire. Si je comprends bien, cela signifie qu'en cas de présence de cours du REG en dessous de la limite basse du seuil, c'est bien la valeur basse du seuil qui restera pertinente à considérer afin d'éviter un mint trop important de REG, et ce faisant, n'aura plus aucun sens à une telle valeur.

Idéalement, il faudrait après discussion, ajouter un sondage pour jauger les avis.

Cela dit, les vraies questions pour cette proposition selon moi, seraient :

1) L'intérêt de conserver les niveaux de seuils actuels ou non et pourquoi, en fonction d'intérêts clairement identifiés pour la DAO.

--> D'un côté, si l'on envisage le paramétrage des seuils uniquement d'un point de vue de sécurité en limitant le minting de nouveaux REG en cas de hack, les conserver en l'état aurait du sens, au moins pour une période fixe donné.

--> De l'autre, au travers des diverses discussions sur TG, il avait été question d'éventuellement pouvoir modifier le minAnswer, afin de "gérer" différemment certains événements courts/moyens termes ayant un impact pour la DAO, comme l'arrivée prochaine de nombreuses réévaluations en retard, impliquant une grande quantité de REG susceptibles d'être mintés et vendus, il faudrait que les explicitations en faveur de ces modifications soient claires.

2) Réfléchir aux modalités de modification ultérieures de ces seuils : Doivent-ils être fixés pour une durée déterminé ? Quelles sont les types d'imprévus éventuels à considérer et pouvant nécessiter des modifications d'urgence ? Quels impacts potentiels pour quels seuils bas donnés ?

--> À ce propos, il y avait il me semble des enjeux d'apport de liquidité, qui en fonction du volume apporté, pourrait permettre de motiver un abaissement du seuil vers le bas, afin de permettre l'acquisition davantage de REG max pour ceux croyant au projet et à ses usages futurs, sauf erreur de ma part.

Personnellement, concernant la gestion des seuils, je suis en faveur d'un maintien des seuils actuels pour une durée à déterminée, en ne considérant que l'aspect sécurité de la fonctionnalité pour le moment.

Il m'apparaît important dans un premier temps, de commencer par une phase de pédagogie et d'éducation des utilisateurs autour de l'intérêt de ces mécanismes de seuil, avant de chercher à les manipuler immédiatement sans raison pertinente.

DRKTT

42 était un joke sur telegram et les jokes sur telegram ne devraient être repris ici sur ce forum, ce n'est clairement pas le lieu.

Pour en revenir au débat, il y a eu deux aspects sur ce seuil minimum qui n'est là que dans le cas où l'Oracle serait compromis.

La nécessité d'abaisser le seuil de par exemple de 10%, 25 % ou 50% régulièrement par rapport au prix actuel. Pour cela il semble qu'un vote doit être organisé pour que ce travail (qui doit être manuel) soit fait périodiquement. Je suis pour aller qu'on puisse voter rapidement sur le sujet afin que les personnes qui ont choisi la conversion automatique des USD REG en REG ne soient pas lesés dans les prochaines semaines.
Un certain nombre de personnes souhaitent détourner le but de ce seuil afin de "protéger" le prix du REG. Il faudrait pour cela un autre vote. Je suis contre car cela amènerait plus de problèmes que cela en résoudrait et ceux qui ont choisi la conversion automatique se retrouveraient vraiment comme les dindons de la farce.

PhilP

Pour établir un mode de calcul du seuil de protection, prenons d'abord un exemple pour comprendre quelles sont les variables à prendre en compte :
Soit :

500 millions, le nombre de REG déjà mintés,
1 million, le nombre total d'USDREG disponibles (attribués et non encore convertis),
faisons l'hypothèse extrême, que tous les USSDREG disponibles sont convertis lors du hack.

Donc, si nous souhaitons qu'un hack ne produise pas plus de 1% d'augmentation des REG mintés, la valeur minimum de l'oracle devrait être de 0,2$ par REG.
Explications : 1% x 500 millions = 5 millions REG. 1 millions d'USDREG / 5 millions de REG = 0,2$.

Pour mémoire, le seuil est actuellement à 0,5$
(ce qui, dans l'exemple ci-dessus, générerait lors d'un hack : 2 millions de REG, soit 0,4% d'augmentation des 500 millions mintés)

On voit donc que les variables à prendre en comptes, pour fixer le seuil, sont :

le % max d'inflation accepté lors d'un hack (paramètre qui serait fixé par la DAO)
le nombre de REG déjà mintés (paramètre mesurable lors de l'actualisation du seuil),
le nombre d'USDREG disponible (paramètre mesurable lors de l'actualisation du seuil)
(en gardant l'hypothèse extrême, que tous les USDREG disponibles pourraient être mintés lors du hack).

La DAO devrait en plus décider : la fréquence d'actualisation du seuil.

soit périodiquement (par ex 1 fois par trimestre),
soit conjoncturellement (si le nombre d'USDREG disponible augmentait brutalement, par ex à l'occasion d'un changement de règle de d'attribution des USDREG...)
ou les deux ..

En espérant avoir contribué à l'éclaircissement du débat (dont il serait souhaitable que le titre change ;-) )

EzSwim

PhilP le nombre de REG déjà mintés (paramètre mesurable lors de l'actualisation du seuil),

So the threshold would follow the total "circulating supply" of USDREG (USDREG can be considered "burnt" after the REG conversion) in relation to how much inflation we are comfortable with in case of a hack ? Or did you mean ALL the USDREG that has ever been "distributed" to RealToken holders since the beginning. In which case the threshold can only decrease and never increase (I might come back to that later, I don't know yet if that can cause an issue).

EzSwim

PhilP dont il serait souhaitable que le titre change ;-)

BTW I can't change the title (or haven't found how). I can only edit the first message

Cogatos

PhilP On voit donc que les variables à prendre en comptes, pour fixer le seuil, sont :
le % max d'inflation accepté lors d'un hack (paramètre qui serait fixé par la DAO)
le nombre de REG déjà mintés (paramètre mesurable lors de l'actualisation du seuil),
le nombre d'USDREG disponible (paramètre mesurable lors de l'actualisation du seuil)
(en gardant l'hypothèse extrême, que tous les USDREG disponibles pourraient être mintés lors du hack).

la variable du nombre de REG déjà mintés est considérée dans l'optique où tous les possesseurs de REG ou une grande majorité vendraient également leur REG suite au hack ou pour une autre raison ?

Si l'on part du principe qu'en cas de hack, une vente massive de REG mintés aurait lieu, une variable supplémentaire à considérer pour la définition du seuil pourrait être le niveau de liquidité disponible à un cours donné. En réalisant des simulations, il faudrait par exemple pouvoir s'assurer qu'en cas d'un tel événement, le cours du REG ne s'effondre pas, ou s'accorder sur un prix à maintenir, si l'on considère sa valeur comme étant un facteur susceptible de favoriser son adoption. Et dans ce cas, peut être faudrait-il ne pas forcément bouger les seuils tant que cette condition ne serait pas satisfaite ?

Concrètement, si demain il y avait un hack, avec un seuil à 0,2$, et une vente de 5 M de REG, portant sa valeur à $0.00204743 selon 1inch actuellement à l'instant t, est-ce que cela serait souhaitable pour la DAO ? Perso je ne pense pas.

PhilP

DRKTT

Concernant ce seuil, il n'y a pas un cas "officiel" et un cas "souhaité".
Il y une raison "officielle" (pour laquelle ce seuil existe : protection contre un hack) et une conséquence (lié au contexte dans lequel le seuil est utilisé : limiter la quantité de REG converti).

Pour statuer sur la méthode d'actualisation du seuil (objectif de la présente proposition), il faut tenir compte des deux : la raison originelle et la(les) conséquence(s).

Pour décider sur le mode de calcul du seuil, nous avons vu précédemment (PhilP ), qu'il faut statuer sur le taux d'inflation maximum admissible.
Dans les conditions actuelles "d'émission" (500 millions de REG et 1 million d'USDREG restant) :

1 % d'inflation maximum admissible, conduit à un seuil de 0,2$,
0,4% d'inflation maximum admissible, conduit à un seuil de 0,5$ (valeur actuelle du seuil).

Une fois le taux d'inflation admissible voté par la DAO, le seuil sera recalculé régulièrement pour tenir compte des variations des "émissions".

L'effet de ce seuil, sera bien de limiter l'inflation contre un hack, mais aussi hors hack de limiter la conversion d'USDREG en REG.

Concernant ton rappel, nous sommes bien d'accord que quelque soit la méthode de distribution de REG (direct, via conversion d'USDREG, via NFT), leur abondance et la faible liquidité actuelle crée hélas une chute du cours.

PhilP

Je vous propose de regarder ce seuil sous un autre angle, qui va vous montrer qu'il peut avoir une autre fonction que celle de la protection contre un hack de l'oracle.

= > RealT dispose d'un droit de création de REG (via les USDREG), que ce seuil va aussi permettre de limiter.

Revenons déjà sur une confusion, comme quoi "les REG données par RealT, servent à compenser les frais de sourcing (10% en général)".
Cette confusion vient du fait que le montant en REG (USDREG) donnée par RealT, correspond aux frais sourcing, mais ce n'est pas pour autant en compensation !
Par cette distribution, l'objectif de RealT est en fait de permettre aux investisseurs en Realtoken, d'avoir gratuitement des REG pour s'intéresser à ce qu'est la DAO.

Prenons maintenant un cas de figure : Le REG tombe de façon durable à 0,01$ .. 😱
Si il n'y avait pas de seuil sur l'oracle, les attributions d'USDREG générerait des quantités astronomiques de REG (1 million d'USDREG génèreraient 100 millions de REG, soit 20 % du supply).
Dans ce cas, RealT irait à l'encontre de son objectif : il détruirait le DAO en voulant la faire connaitre !

On voit donc qu'avec ce seuil, par ex à 0,5$, l'effet de l'attribution d'USDREG par RealT sera limité à la création de 0,4% du supply (cf mon msg précédent).

Le seuil limite donc l'effet d'un hack sur l'oracle ainsi que l'effet des attributions (gratuites) faite par RealT.

Rappelons que dans cas, il n'y a pas "manipulation de marché" mais juste une limitation des cadeaux faits par RealT

PhilP

MarkoeZ il ne devrait pas faire obstacle à un marché équitable à l'avenir.

Le seuil ne fait pas obstacle au marché équitable, il a deux fonctions :

protéger contre un hack de l'oracle,
et, limiter l'attribution de nouveaux REG par RealT : PhilP

MarkoeZ environ un tiers de sa valeur actuelle

Le cours du REG ne doit pas être un paramètre d'actualisation du seuil.
Il pourrait l'être au titre de sa première fonction (protection d'un hack de l'oracle), mais pas au titre de sa seconde fonction (limitation de l'attribution de REG par RealT).

Prenons un exemple, pour mieux comprendre :

RealT a évalué qu'il devrait attribuer 10 millions d'USDREG, au titre de ses ventes depuis 5 ans,
soit une moyenne de 2 millions d'USDREG par an,
si le cours du REG était significativement en dessous du seuil actuel : imaginons à 0,06 $,
si le seuil était actualisé à 1/3 du cours, nous aurions un seuil à 0,02$,
la conversion des 2 millions d'USDREG attribués chaque année par RealT, générerait 100 millions de REG,
soit une inflation du REG de 20% par an ! ...(rapporté au 500 million existants),
sachant que le rythme de vente de RealT s'accélère avec le temps ...

L'actualisation du seuil doit donc se faire, sur la base de l'inflation et non du cours du REG.

Ce seuil n'est pas une entrave au marché du REG, mais juste une limite au nombre de REG donné en cadeau par RealT à ses clients (vs sa seconde fonction).

Michael-RealT

A small addition for medium- to long-term consideration.

RealT has already planned how we could technically transfer control of the REG mint from USDREG, once the DAO is more established with roader processes, and probably with Governance v2, which will allow more flexibility in voting.
We will be able to activate this transition; the main difficulty currently would be the 10-day delay if we were to use Governance v1.

The imagined process would be as follows:

Anyone could propose an update to the rights in USDREG
The data generated in Merkle Tree is verified by the DAO
A vote is held to change the root in the contract to validate that the DAO agrees with the data linked to this root
Once the vote is accepted, the rights are active

PhilP

Michael-RealT
Il faudra alors rajouter dans les clauses de ventes des RealTokens, que les USDREG attribués ne le seront vraiment qu’à la suite d’un vote de la DAO…

PhilP

EzSwim
Il s’agit du nombre d’USDREG « disponibles », c’est à dire : tout ceux attribués et moins ceux qui ont déjà donné lieux à conversion.
Ils ne sont pas vraiment brûlés, car l’USDREG n’est pas un token mais un droit à conversion, historisé dans un Merkel tree.

PhilP

EzSwim
Donnes moi le titre que tu souhaites mettre et je vais faire la modification.