Orbit Labs a publié la proposition d'implémentation technique pour un système de staking USTC natif sur Terra Classic il y a seulement 2 heures.
La proposition suit le passage réussi de la Proposition de Gouvernance #12219, qui a signalé le soutien de la communauté pour un système de $USTC staking dans un cadre sans minting. Le nouveau document technique explique comment le staking de l'USTC pourrait fonctionner au Layer 1, comment les récompenses seraient calculées, comment les validateurs participeraient, et quelles conditions doivent être remplies avant l'activation. [1]
La proposition donne aux détenteurs d'USTC une image plus claire du système. Elle place également la question économique la plus importante directement devant la communauté :
D'où viendront les USTC utilisés pour les récompenses de staking ?
Un Système de Staking Séparé pour USTC
Orbit Labs propose un nouveau module Cosmos SDK appelé x/ustcstaking.
Un module est une partie dédiée de la blockchain Terra Classic qui gère une fonction spécifique. Dans ce cas, le module gérerait l'activité de staking USTC, y compris :
Déléguer des USTC à des validateurs
Déléguer des USTC
Redéléguer des USTC entre validateurs
Calculer les récompenses de staking
Réclamer des récompenses de staking
Payer la commission des validateurs
Le module de staking USTC fonctionnerait séparément du système de staking existant $LUNC . Il lirait les informations des validateurs à partir du module x/staking existant tout en gardant ses propres enregistrements pour les délégations USTC, les récompenses, les redélégations et les activités de désengagement. [1]
LUNC resterait l'actif de staking utilisé pour la sécurité de consensus, la sélection des validateurs, le pouvoir de vote, et le vote de gouvernance.
La délégation USTC donnerait aux détenteurs accès aux récompenses de staking et à l'utilité de verrouillage de l'offre. Elle ne donnerait aucun pouvoir de consensus supplémentaire aux validateurs.
Risque principal et de validateur USTC
Le staking USTC n'aurait aucun risque de slashing sous le design proposé.
Le slashing est une pénalité utilisée dans les systèmes de staking de consensus lorsque les validateurs commettent des fautes graves, telles que des temps d'arrêt prolongés ou des doubles signatures. Les délégateurs LUNC peuvent être affectés par ces pénalités car le staking LUNC soutient directement la sécurité du réseau.
Le staking USTC n'a pas de rôle de consensus, donc le principal USTC resterait sûr pendant les fautes des validateurs. Le statut du validateur affecterait toujours l'accumulation de récompenses et la disponibilité des délégations. [1]
La politique de cycle de vie proposée comprend :
Un validateur lié peut recevoir de nouvelles délégations d'USTC et générer des récompenses
Un validateur emprisonné cesse de générer des récompenses USTC jusqu'à ce qu'il soit déverrouillé
Un validateur tombstoné cesse de générer des récompenses et les délégations USTC existantes sont forcées de se désengager
Un validateur qui se désengage volontairement cesse de recevoir de nouvelles délégations d'USTC
Le principal USTC reste retiré par le processus normal de désengagement
Les récompenses mises en pause resteraient à l'intérieur du pool de récompenses.
D'où viennent les récompenses de staking USTC ?
Les récompenses de staking USTC proviendraient d'un pool de récompenses préfinancé détenu à l'intérieur du compte du module x/ustcstaking.
La proposition n'utilise pas l'inflation de bloc ou les frais de transaction comme source initiale de récompense. Le module distribuerait les USTC qui ont déjà été déposés dans le pool de récompenses. [1]
Les paramètres de départ proposés sont :
Pool de récompenses initial : 30 000 000 USTC
Durée minimale de récompense : 2 ans
Budget annuel de récompenses de départ : 15 000 000 USTC par an
Le pool de récompenses pourrait recevoir des USTC supplémentaires grâce à un message de financement sans permission appelé MsgFundUSTCRewardPool.
Le financement sans permission signifie que n'importe quelle adresse pourrait contribuer des USTC au pool. Les contributeurs possibles incluent :
Une trésorerie
Membres de la communauté
Sponsors externes
Revenus futurs du protocole
Revenus futurs de MM2
Autres sources de revenus approuvées par la communauté
Les recharges seraient limitées à USTC.
La proposition utilise l'APR, pas l'APY
Les estimations de récompenses dans la proposition sont des chiffres APR.
L'APR mesure le taux de récompense annuel avant la capitalisation. L'APY inclut l'effet de la réinvestissement répétée des récompenses.
Le budget de récompenses proposé crée la courbe APR estimée suivante :
Total des USTC stakés actifs Estimation de l'APR effectif 150 millions d'USTC Environ 10% 300 millions d'USTC Environ 5% 600 millions d'USTC Environ 2,5%
L'APR change parce que tous les stakers actifs partagent le même budget de récompenses.
Une plus petite quantité d'USTC stakée donne à chaque staker une plus grande part du pool. Une plus grande quantité d'USTC stakée répartit le budget de récompense sur plus de participants. [1]
La proposition vise un verrouillage volontaire d'environ 5% à 10% de l'offre circulante d'USTC. Avec environ 6 milliards d'USTC en circulation, cet objectif représente entre 300 millions et 600 millions d'USTC verrouillés dans le staking. [1]
Comment chaque paiement de récompense est calculé
Chaque période de récompense calculerait trois limites différentes :
Budget de base
Plafond maximum d'APR
Taux de libération sécurisé du pool
Une époque est une période de calcul de récompenses programmée. La proposition utilise une époque quotidienne dans son exemple.
Le module libérerait la plus petite valeur produite par les trois calculs. [1]
Le budget de base contrôle le taux de dépense de récompense prévu.
Le plafond maximum d'APR empêche des taux de récompense extrêmement élevés lorsque très peu d'USTC est staké.
Le taux de libération sécurisé du pool réduit les émissions de récompenses à mesure que le pool de récompenses devient plus petit.
Ce système donne au pool de récompenses une courbe de déclin progressive. À mesure que le solde du pool diminue, le montant libéré par époque diminue également. Le pool s'approche progressivement de zéro, et l'APR devient plus bas avec le temps.
Si le pool de récompenses atteint un solde bas défini par la gouvernance, le module émettrait un événement USTCRewardPoolLow et réduirait les récompenses à un minimum sûr jusqu'à ce que plus d'USTC soit déposé. Le principal de l'utilisateur resterait disponible pour retrait indépendamment du solde du pool de récompenses. [1]
Le Système de Staking USTC est-il durable ?
Le système proposé a une durée de démarrage contrôlée.
Le pool de récompenses initial de 30 millions USTC peut soutenir le budget annuel prévu de 15 millions USTC pendant environ deux ans selon les hypothèses de départ.
La durabilité à long terme dépend du financement récurrent en USTC.
Un pool de récompenses financé une seule fois va progressivement diminuer. Les émissions de récompenses deviendront plus petites, et l'APR effectif chutera. Des récompenses continues nécessitent que de nouveaux USTC entrent dans le pool par le biais de revenus de protocole, de revenus MM2, de financement de trésorerie, de sponsors, de contributions de la communauté, ou d'une autre source approuvée. [1]
La conception technique protège le pool d'une déplétion soudaine. La durabilité économique dépend toujours d'un financement réel.
Cette distinction est importante pour les détenteurs d'USTC. Une formule d'émission bien conçue peut gérer un pool de récompenses limité de manière responsable. Un système de staking durable nécessite des revenus qui peuvent continuer à reconstituer le pool.
La frappe est le principal drapeau rouge économique
La Proposition de Gouvernance #12219 a été présentée comme un système de staking USTC dans le cadre d'un cadre sans frappe. [2]
La proposition technique liste la source initiale du pool de récompenses comme TBD. Elle mentionne un dépense de pool communautaire, la trésorerie, ou un sponsor externe comme sources possibles. [1]
La communauté devrait exiger un plan de financement clair avant l'activation.
La question clé est :
« Le pool de récompenses n'utilisera-t-il que des USTC existants ? »
Utiliser les USTC existants peut encourager le verrouillage volontaire de l'offre.
Frappant de nouveaux USTC pour financer les récompenses de staking augmenterait l'offre et affaiblirait l'objectif de verrouillage de l'offre. Cela entrerait également en conflit avec la direction sans frappe signalée par la Proposition #12219.
Un engagement clair à ne pas frapper de nouveaux tokens devrait rester partie intégrante du processus de révision de la communauté.
Commission de Validateur
Les validateurs seraient en mesure de définir un taux de commission USTC séparé appelé ustc_commission.
Cette commission serait indépendante de la commission de staking LUNC existante de chaque validateur.
Lorsque les récompenses USTC sont distribuées, le validateur recevrait sa commission en USTC. La récompense restante serait distribuée aux délégateurs d'USTC selon leur part de la délégation totale d'USTC du validateur. [1]
La proposition inclut également des paramètres contrôlés par la gouvernance pour les plafonds de commission et la fréquence des mises à jour.
Pause d'urgence et Retraits des utilisateurs
Le module inclurait une fonction de pause d'urgence contrôlée par la gouvernance.
Lors d'une pause d'urgence, le système bloquerait :
Nouvelles délégations
Redélégations
Modifications de la commission des validateurs
Le système continuerait à autoriser :
Délégations non effectuées
Retraits de récompenses
Achèvement des entrées de désengagement existantes
La proposition stipule que les voies de retrait doivent rester ouvertes pendant une pause d'urgence. [1]
Processus d'activation
Le module x/ustcstaking serait expédié à travers une mise à niveau logicielle de Terra Classic avec le staking désactivé par défaut.
Une proposition de gouvernance séparée serait nécessaire pour activer le système après que plusieurs conditions soient remplies :
Le pool de récompenses initial est financé
Les paramètres sont examinés et définis
La validation du testnet est terminée
La révision par les validateurs et la communauté est terminée
Cette structure d'activation donne à la communauté une autre opportunité d'examiner la source des récompenses, les paramètres, les résultats des tests, et la préparation opérationnelle. [1]
Budget et Calendrier
Orbit Labs demande un budget total de mise en œuvre de 34 000 $.
Le budget est divisé en deux phases :
Phase 1 : Mise en œuvre et Validation du Testnet
Budget : 25 000 $
Cette phase comprend le développement de module, la distribution des récompenses, les hooks du cycle de vie des validateurs, les fonctions de pause d'urgence, les paramètres de gouvernance, le déploiement du testnet, les tests de scénarios, un calculateur de récompenses et une documentation préliminaire.
Phase 2 : Exécution de la mainnet et Support post-mise à niveau
Budget : 9 000 $
Cette phase comprend la préparation de la proposition de mise à niveau de la mainnet, la coordination des validateurs, l'exécution de la mise à niveau, la surveillance immédiate et la documentation finale. 1
Le calendrier de développement proposé est de 12 semaines :
Semaines 1 à 2 : Finaliser la conception, les paramètres, le comportement des validateurs et les calculs de récompenses
Semaines 3 à 6 : Construire la délégation, le désengagement, la redélégation et l'accumulation de récompenses
Semaines 7 à 8 : Ajouter des hooks de cycle de vie des validateurs, commission, pause d'urgence, et contrôles de gouvernance
Semaines 9 à 10 : Déployer sur le testnet, exécuter des scénarios, et corriger des bugs
Semaine 11 : Publier la documentation et commencer la révision par les validateurs et la communauté
Semaine 12 : Soumettre la proposition de gouvernance et préparer une mise à niveau de la mainnet
L'intégration de l'interface utilisateur du portefeuille, un audit de sécurité externe, des supports marketing, et un support prolongé après le lancement sont en dehors du budget proposé. [1]
Ce que la communauté devrait examiner ensuite
La proposition de staking USTC crée une utilité pratique de couche 1 pour les détenteurs d'USTC.
L'architecture garde le staking USTC séparé du consensus, protège le principal USTC contre le slashing des validateurs, et fournit un cadre clair pour la distribution des récompenses.
La prochaine étape nécessite un examen approfondi de la conception économique.
La communauté devrait se concentrer sur :
La source initiale du pool de récompenses
Un engagement clair à ne pas frapper de nouveaux tokens
Revenus récurrents à long terme
Précision des récompenses du testnet
Comportement du cycle de vie des validateurs
Sécurité des retraits d'urgence
L'absence d'un audit de sécurité externe dans le budget actuel
Le staking USTC peut devenir une infrastructure utile pour Terra Classic.
Sa valeur à long terme dépendra de la qualité de l'implémentation, de la discipline du modèle de récompense et de la capacité à financer les récompenses via les USTC existants et les revenus réels de l'écosystème.
Sources
[1] Orbit Labs, Proposition de Mise en Œuvre Technique du Système de Staking USTC de Terra Classic. (Terra Classic)
https://discourse.luncgoblins.com/t/terra-classic-ustc-staking-system-technical-implementation-proposal/492
[2] Résultat de vote de la Proposition de Gouvernance #12219 de Terra Classic et titre de cadre sans frappe. (Info Validateur)
https://validator.info/terra-classic/governance/12219
[3] Tweet officiel d'Orbit Labs
https://x.com/orbit__labs/status/2062537234860192202