Damn, same old tricks again, seen this a million times
---
1500x leverage? Direct minting operation, can't even be bothered
---
Permission checks are a minefield, so many projects have gotten rekt on this
---
Hit that transfer tax exploit before, got wrecked
---
Audit? Stop joking, small projects conducting audits my ass
---
Another unlimited minting scheme, can't even
---
That's why I always check permission settings first when reviewing contracts now
---
Fuck, just remembered getting rugged like that, exact same playbook
---
Liquidity provider balance bug, brutal
---
Good thing everyone's smarter now, reading the code before playing
最近発見された注意すべきパターンです。異常なデータ比較から、これは「初回鋳造攻撃」の一種の変種ではないかと疑われます。
まずデータの現象を見てみましょう:0.001 BNBを投入して1000枚のトークンを獲得(約$0.3)、しかし引き出すとなんと1500万枚のトークン(価値$450)を受け取る。1500倍の利益差は、通常のスリッページや数学的誤差の範囲をはるかに超えており、背後に何かしらの仕掛けがあることは明らかです。
最も可能性の高い攻撃手法は、直接mint関数を呼び出すことです。品質の低いトークンコントラクトの中には、設計時に権限チェックを行っていないものもあり、誰でも直接鋳造関数を呼び出せるようになっています:
function mint(address to, uint amount) public {
_mint(to, amount);
}
このような場合、攻撃者はまず少しだけトークンを購入(アドレス記録を残す)し、その後直接mintを呼び出して自分にコインを作り出し、最後にこれらの空から出現したトークンを使って流動性を追加または削除します。全体の流れは普通の操作とほとんど変わりません。
もう一つの可能性は、送金税のバグです。いくつかのトークンは非常に高い送金税(例えば20%)を設定しており、表面上はAがBに100トークン送ると、Bは80を受け取り、20は焼却される仕組みです。しかし、攻撃者が流動性提供者になった場合、プールが税金計算のバグにより追加のトークンを生成してしまう可能性があります。
さらに、残高同期攻撃も警戒すべきです。攻撃者は流動性を追加した後、他の場所でこっそりと自分のトークン残高を増やし、その後流動性を引き出すことで、より多くの価値を得ることができるのです。
これらはすべて、コントラクトのロジック自体を歪めて悪用するものであり、防御の鍵はトークンコントラクトの監査の質と権限管理が適切に行われているかどうかにかかっています。