Je regarde le contrat de promesse (claim) de TermMax depuis bien trop longtemps, et quelque chose me tracasse.
Personne chez TermMax n’a publié le chiffre réel derrière le seuil d’acquisition. Ni formule, ni fourchette, rien. On penserait qu’un mécanisme de claim qui décide de la partie de tes TMX qui est bloquée s’accompagnerait au moins d’une note de bas de page expliquant comment cette ligne a été tracée. Ce n’est pas le cas.
Ce qui m’a sauté aux yeux, c’est le problème de calendrier sous cet espace. La gouvernance TMX n’existe pas encore et ne se mettra en marche qu’au TGE. Donc quel que soit le seuil inclus dans le contrat de claim actuellement, il a été défini par une équipe ou un multisig, point final. Aucun vote n’a eu lieu, aucun vote n’aurait pu avoir lieu. Qualifier cela de décentralisé me semble prématuré quand le paramètre le plus déterminant de tout l’airdrop a été un choix unilatéral.
Ce qui a réellement changé ma façon de penser, c’est le chemin par défaut. Si tu manques la date limite de claim, tu ne tombes pas dans un endroit neutre : tu es automatiquement basculé vers une acquisition sur 6 mois plus un staking sur 6 mois, la combinaison la plus illiquide disponible. Ce n’est pas une simple erreur d’arrondi : c’est un choix de conception, qui punit discrètement toute personne qui est simplement lente ou distraite plutôt que quelqu’un qui cherche à contourner le système.
Je peux me tromper, mais je ne vois non plus de voie de recours : pas de pause côté admin, pas de fenêtre de correction si un wallet est compromis au milieu d’un claim. Une fois que c’est confirmé, c’est confirmé.
Rien de tout cela ne veut dire que le mécanisme est cassé. Ça signifie juste que la logique réelle vit dans le code du contrat, pas dans la documentation. Tu ferais un claim avant de lire le bytecode ?
#termmax @TermMax
Personne chez TermMax n’a publié le chiffre réel derrière le seuil d’acquisition. Ni formule, ni fourchette, rien. On penserait qu’un mécanisme de claim qui décide de la partie de tes TMX qui est bloquée s’accompagnerait au moins d’une note de bas de page expliquant comment cette ligne a été tracée. Ce n’est pas le cas.
Ce qui m’a sauté aux yeux, c’est le problème de calendrier sous cet espace. La gouvernance TMX n’existe pas encore et ne se mettra en marche qu’au TGE. Donc quel que soit le seuil inclus dans le contrat de claim actuellement, il a été défini par une équipe ou un multisig, point final. Aucun vote n’a eu lieu, aucun vote n’aurait pu avoir lieu. Qualifier cela de décentralisé me semble prématuré quand le paramètre le plus déterminant de tout l’airdrop a été un choix unilatéral.
Ce qui a réellement changé ma façon de penser, c’est le chemin par défaut. Si tu manques la date limite de claim, tu ne tombes pas dans un endroit neutre : tu es automatiquement basculé vers une acquisition sur 6 mois plus un staking sur 6 mois, la combinaison la plus illiquide disponible. Ce n’est pas une simple erreur d’arrondi : c’est un choix de conception, qui punit discrètement toute personne qui est simplement lente ou distraite plutôt que quelqu’un qui cherche à contourner le système.
Je peux me tromper, mais je ne vois non plus de voie de recours : pas de pause côté admin, pas de fenêtre de correction si un wallet est compromis au milieu d’un claim. Une fois que c’est confirmé, c’est confirmé.
Rien de tout cela ne veut dire que le mécanisme est cassé. Ça signifie juste que la logique réelle vit dans le code du contrat, pas dans la documentation. Tu ferais un claim avant de lire le bytecode ?
#termmax @TermMax