Recentemente, foi identificado um padrão que merece atenção. Através da comparação de dados anormais, suspeita-se que seja uma variação de um tipo de "ataque de cunhagem inicial".

Primeiro, observe o fenômeno nos dados: após investir 0.001 BNB para comprar, recebe-se 1000 tokens (equivalente a $0.3), mas ao retirar, na verdade, obtém-se 15.000.000 de tokens (valor de $450). Essa diferença de rendimento de 1500 vezes já ultrapassa qualquer desvio normal de slippage ou erro matemático, indicando que há algo mais por trás.

A técnica de ataque mais provável é a chamada direta à função mint. Alguns contratos de tokens de baixa qualidade não implementam verificações de permissão na sua concepção, permitindo que qualquer pessoa chame diretamente a função de cunhagem:

```solidity
function mint(address to, uint amount) public {
_mint(to, amount);
}
```

Assim, o atacante só precisa comprar um pouco de tokens (deixando o endereço registrado), e depois chamar diretamente a função de cunhagem para criar tokens para si mesmo. Por fim, pode usar esses tokens criados do nada para adicionar ou remover liquidez, tudo isso parecendo uma operação normal.

Outra possibilidade é uma vulnerabilidade na taxa de transferência. Alguns tokens aplicam uma taxa de transferência elevada (por exemplo, 20%), onde, na prática, ao transferir 100 tokens de A para B, B recebe 80, e 20 são destruídos. Mas, se o atacante se tornar um provedor de liquidez, o pool pode gerar tokens extras devido a bugs no cálculo da taxa, ao transferir para ele.

Além disso, é preciso ficar atento a ataques de sincronização de saldo. O atacante, após adicionar liquidez, pode secretamente aumentar seu saldo de tokens em outro lugar, e ao remover a liquidez, consegue retirar mais valor do que realmente possui.

Todos esses métodos envolvem distorcer a lógica do contrato para agir de má-fé. A prevenção fundamental depende da qualidade da auditoria do contrato de tokens e de uma implementação adequada do controle de permissões.