La stratégie de rachat-« burn » de Pons n’est pas tout à fait la même que celle de Stonk. Elle peut donc entraîner quelques malentendus ; clarifions ici en quoi les deux diffèrent.
Comme tout le monde le sait, @ponsdotfamily utilise 80 % des revenus de protocole pour racheter et brûler, tandis que @LaunchOnSF utilise 60 %.
Mais observez : chez Stonk, le niveau de burn reste quasiment tous les jours autour de 60 % des revenus de protocole, tandis que chez Pons, le burn est parfois nettement supérieur à 80 % des revenus, parfois presque identique, et ces derniers jours il est clairement inférieur à 80 %. D’où vient le problème ?
Le wallet opérationnel de Stonk exécute en continu et de manière automatisée le claim des frais ; il n’y a presque jamais d’accumulation. Ensuite, grâce à un rythme de petits ordres très fréquents, on effectue, chaque minute, une dizaine de petits ordres de rachat, et toutes les quelques minutes on les regroupe pour les envoyer à l’adresse de burn. Ainsi, il n’y a presque pas de fenêtre vide : on envoie autant d’« munitions » qu’elles entrent ;
Chez Pons, les frais générés nécessitent un claim manuel avec multi-signature. Les fonds destinés au rachat restent souvent en attente sur le compte de custody (dépôt/stockage). Tant que ces fonds ne sont pas claim à temps puis transférés vers le répartiteur de rachat, le $PONS que TWAP rachète et brûle toutes les 15 minutes sera inférieur. Donc : quand les « munitions » entrent en quantité, on envoie plus ; quand elles entrent en moins, on envoie moins ;
Mais si on élargit la période d’analyse, les deux stratégies reviennent au même : elles finissent toutes par atteindre la proportion de rachat-destruction (burn) prédéfinie par rapport aux revenus de protocole.
À noter : que ce soit Pons ou Stonk, l’étape du claim des frais n’est pas réalisée de manière décentralisée. Stonk ne fait que rendre le claim automatisé et à haute fréquence.
#pons
$PONS
Comme tout le monde le sait, @ponsdotfamily utilise 80 % des revenus de protocole pour racheter et brûler, tandis que @LaunchOnSF utilise 60 %.
Mais observez : chez Stonk, le niveau de burn reste quasiment tous les jours autour de 60 % des revenus de protocole, tandis que chez Pons, le burn est parfois nettement supérieur à 80 % des revenus, parfois presque identique, et ces derniers jours il est clairement inférieur à 80 %. D’où vient le problème ?
Le wallet opérationnel de Stonk exécute en continu et de manière automatisée le claim des frais ; il n’y a presque jamais d’accumulation. Ensuite, grâce à un rythme de petits ordres très fréquents, on effectue, chaque minute, une dizaine de petits ordres de rachat, et toutes les quelques minutes on les regroupe pour les envoyer à l’adresse de burn. Ainsi, il n’y a presque pas de fenêtre vide : on envoie autant d’« munitions » qu’elles entrent ;
Chez Pons, les frais générés nécessitent un claim manuel avec multi-signature. Les fonds destinés au rachat restent souvent en attente sur le compte de custody (dépôt/stockage). Tant que ces fonds ne sont pas claim à temps puis transférés vers le répartiteur de rachat, le $PONS que TWAP rachète et brûle toutes les 15 minutes sera inférieur. Donc : quand les « munitions » entrent en quantité, on envoie plus ; quand elles entrent en moins, on envoie moins ;
Mais si on élargit la période d’analyse, les deux stratégies reviennent au même : elles finissent toutes par atteindre la proportion de rachat-destruction (burn) prédéfinie par rapport aux revenus de protocole.
À noter : que ce soit Pons ou Stonk, l’étape du claim des frais n’est pas réalisée de manière décentralisée. Stonk ne fait que rendre le claim automatisé et à haute fréquence.
#pons
$PONS
