iamlequanghuong

Ooooo

874Seguindo

846seguidores

Feed

iamlequanghuong repostou

Uma análise detalhada do SATO da ETH A boa notícia é que não temos esse problema Olhei o contrato de gancho SATO e o problema não é uma simples taxa de manuseio, nem ele retira diretamente o ETH como é comum em clipes ou festas de projeto. Análise detalhada O problema central é que o Hook mantém dois estados de curva internamente que deveriam estar sincronizados: ethCum totalMintedFair Em teoria, eles devem satisfazer: totalMintedFair = Curve.totalMinted(ethCum) Ou: ethCum = Curve.ethAt(totalMintedFair) Mas no contrato propriamente dito, comprar e vender usam coordenadas diferentes. Caminho de compra: Curve.mintFor(ethCum, ethToCurve) Ou seja, a compra é precificada na posição da curva onde o ethCum está localizado. Caminho de Venda: Curve.burnFor(totalMintedFair, satoFairIn) Ou seja, vender ETH na posição que foi invertida. Assim que ethCum > Curve.ethAt(totalMintedFair), o seguinte aparecerá a seguir: Compre em uma curva mais cara, Venda em uma curva mais barata. Não é uma taxa normal de 0,3% + 0,3%. Um bloco que avaliei 25.041.403: Saldo de ganchos ≈ 1774,9398 ETH taxas acumuladas ≈ 91,1172 ETH reserva de curva ≈ 1683,8226 ETH No entanto, as responsabilidades totais no reverso do lado da venda lançado pela totalMintedFair são: ≈ 1626.8557 ETH Ou seja, já existiam, naquela época: ≈ 56,9669 ETH permanece no Hook, mas a função de venda não o trata como valor resgatável pelo detentor. Esta parte pode ser definida como: gap = ethCum - Curve.ethAt(totalMintedFair) O dinheiro não desapareceu, nem foi para um endereço de clipe ou carteira do projeto. Ainda está no contrato da Hook. No entanto, como o caminho de venda reconhece apenas o totalMintedFair e não reconhece o gap excedente criado pelo ethCum, essa parte do ETH se torna uma reserva excedente que não pode ser alcançada pelo caminho atual da transação. As consequências são: Compras subsequentes continuarão a impulsionar o ethCum para cima, O preço de compra está caindo cada vez mais, No entanto, a venda e o resgate ainda são calculados de acordo com a curva inferior do totalMintedFair. Quanto maior a diferença, maior a perda entre compra e venda. Isso diluirá continuamente o valor real resgatável do SATO e, em casos extremos, mesmo que ainda haja muito ETH no gancho, o detentor não pode vendê-lo de volta integralmente com esses saldos de ETH. Vejo que o próprio token não encontra permissões como proprietário / pausa / lista negra / imposto / upgrade; Minter está preso ao Gancho. Então, isso é mais como um bug de design/implementação contábil em curva de gancho, não um backdoor tradicional de proprietário. No entanto, o problema é sério: o gancho implantado não vê a entrada de upgrade/reparo administrativo, nem percebe que retirada/resgate pode migrar essa parte do gap normalmente. Se a parte do projeto quiser estancar o sangramento, no mínimo: 1. Pausar ou forçar compras front-end 2. Exibir o preço de compra e o valor imediato de venda 3. Preços de curva única não são mais exibidos 4. Fazer uma solução de migração/compensação/novo gancho Frase central: O problema com o SATO não é que o ETH é roubado, mas sim que o ETH fica preso em um gancho, transformando-se em uma reserva excedente que a curva de venda não reconhece. A versão curta pode ser enviada assim: O problema com SATO Hook não é um clipe típico, nem retira diretamente o ETH como o projeto party. O núcleo é que as duas curvas do ethCum e totalMintedFair no contrato estão fora de sincronia. As compras são cotadas em ethCum e as vendas são resgatadas no totalMintedFair. Quando ethCum > Curve.ethAt(totalMintedFair), os usuários estão "comprando na curva alta, vendendo na curva baixa". A diferença no ETH ainda está no contrato Hook, mas o caminho de venda não reconhece esse valor, criando uma diferença irredimível. Quando revisei o bloco 25.041.403, a diferença ≈ 56,97 ETH. Não é uma taxa comum, mas sim um desalinhamento contábil de curva.