📢 Exclusive on Gate Square — #PROVE Creative Contest# is Now Live!
CandyDrop × Succinct (PROVE) — Trade to share 200,000 PROVE 👉 https://www.gate.com/announcements/article/46469
Futures Lucky Draw Challenge: Guaranteed 1 PROVE Airdrop per User 👉 https://www.gate.com/announcements/article/46491
🎁 Endless creativity · Rewards keep coming — Post to share 300 PROVE!
📅 Event PeriodAugust 12, 2025, 04:00 – August 17, 2025, 16:00 UTC
📌 How to Participate
1.Publish original content on Gate Square related to PROVE or the above activities (minimum 100 words; any format: analysis, tutorial, creativ
Poolz suffers from an arithmetic overflow attack, resulting in a loss of $665,000.
Poolz suffers from arithmetic overflow attack, losing approximately $665,000
Recently, the Poolz platform was attacked on the Ethereum, Binance Smart Chain, and Polygon networks, resulting in the theft of a large number of tokens, with a total value of approximately $665,000. The attack occurred on March 15, 2023, at 3:16 AM (UTC).
According to on-chain data monitoring, this attack involves multiple tokens, including MEE, ESNC, DON, ASW, KMON, POOLZ, etc. The attacker has exchanged some of the stolen tokens for BNB, but the funds have not yet been transferred.
The attacker exploited an arithmetic overflow vulnerability in the Poolz contract. Specifically, the issue lies in the getArraySum function within the CreateMassPools function. This function causes an overflow when calculating the token amount because the accumulated result exceeds the maximum value of the uint256 type, ultimately resulting in a return value of 1.
The attack process is as follows:
The attacker first exchanged some MNZ tokens through a certain DEX.
Subsequently, call the CreateMassPools function, exploiting the vulnerability of the getArraySum function. The _StartAmount array provided by the attacker contains extremely large values, resulting in an overflow during the addition.
Since the CreatePool function uses _StartAmount to record pool attributes, the attacker actually only transfers 1 token, but the system records it as a huge value.
Finally, the attacker calls the withdraw function to extract the tokens, completing the attack.
To prevent such issues from occurring again, it is recommended that developers use a newer version of Solidity for compilation, as the new version will automatically perform overflow checks. For projects using older versions of Solidity, it may be worth considering the use of OpenZeppelin's SafeMath library to address integer overflow issues.
This incident reminds us once again that we must be particularly cautious when handling mathematical operations in smart contract development, especially when it involves large numerical calculations. At the same time, regular code audits and security checks are also important measures to ensure project safety.