A estratégia de recompra e queima do pons não é bem igual à do stonk; isso pode gerar alguns mal-entendidos. Vamos esclarecer aqui onde estão as diferenças entre as duas.
Como todos sabem, @ponsdotfamily usa 80% da receita do protocolo para recomprar e queimar, enquanto @LaunchOnSF usa 60% da receita do protocolo para recompra e queima.
Mas note isto: a queima do stonk fica basicamente todo dia em torno de 60% da receita do protocolo, enquanto a do pons às vezes é claramente maior do que 80% da receita do protocolo; às vezes fica quase igual, e nos últimos dias ficou bem menor do que 80%. Onde está o problema?
A carteira operacional do stonk executa automaticamente e em sequência o claim das taxas de transação, quase sem acumular; além disso, com uma cadência de muitos pequenos pedidos frequentes, a cada minuto saem cerca de uma dúzia de ordens pequenas de recompra, e a cada poucos minutos elas são agrupadas e enviadas para o endereço de queima. Por isso, quase não existem “janelas vazias”: entra mais munição, sai mais; entra menos, sai menos.
No pons, as taxas de transação geradas precisam de multi-assinatura e também são feitas manualmente para o claim; os fundos destinados à recompra frequentemente ficam retidos na conta de custódia. Quando a custódia não faz o claim a tempo e não transfere os fundos para o recomprador (recompra alocador/dispensador), a queima por TWAP a cada 15 minutos — o $PONS — fica menor. Assim, quando entra mais munição, dispara-se mais; quando entra menos, dispara-se menos.
Mas olhando para um horizonte de tempo mais longo, as duas acabam chegando ao mesmo resultado: atingir, no fim, a proporção de recompra e destruição de acordo com a receita do protocolo previamente definida.
Vale notar que, tanto no pons quanto no stonk, esta etapa de claim das taxas não foi feita de forma descentralizada; o stonk apenas implementou o claim de forma altamente automatizada.
#pons
$PONS
Como todos sabem, @ponsdotfamily usa 80% da receita do protocolo para recomprar e queimar, enquanto @LaunchOnSF usa 60% da receita do protocolo para recompra e queima.
Mas note isto: a queima do stonk fica basicamente todo dia em torno de 60% da receita do protocolo, enquanto a do pons às vezes é claramente maior do que 80% da receita do protocolo; às vezes fica quase igual, e nos últimos dias ficou bem menor do que 80%. Onde está o problema?
A carteira operacional do stonk executa automaticamente e em sequência o claim das taxas de transação, quase sem acumular; além disso, com uma cadência de muitos pequenos pedidos frequentes, a cada minuto saem cerca de uma dúzia de ordens pequenas de recompra, e a cada poucos minutos elas são agrupadas e enviadas para o endereço de queima. Por isso, quase não existem “janelas vazias”: entra mais munição, sai mais; entra menos, sai menos.
No pons, as taxas de transação geradas precisam de multi-assinatura e também são feitas manualmente para o claim; os fundos destinados à recompra frequentemente ficam retidos na conta de custódia. Quando a custódia não faz o claim a tempo e não transfere os fundos para o recomprador (recompra alocador/dispensador), a queima por TWAP a cada 15 minutos — o $PONS — fica menor. Assim, quando entra mais munição, dispara-se mais; quando entra menos, dispara-se menos.
Mas olhando para um horizonte de tempo mais longo, as duas acabam chegando ao mesmo resultado: atingir, no fim, a proporção de recompra e destruição de acordo com a receita do protocolo previamente definida.
Vale notar que, tanto no pons quanto no stonk, esta etapa de claim das taxas não foi feita de forma descentralizada; o stonk apenas implementou o claim de forma altamente automatizada.
#pons
$PONS
