New Gold Protocol is a decentralized finance protocol built on Binance Chain, launched on September 18, 2025, with the stated goal of becoming a "next-generation DeFi 3.0" platform. It aimed to create an inclusive, transparent, and automated staking environment using smart contracts, promoting its native token as deflationary through token burns and promising real-yield distributions instead of speculative incentives. The protocol was designed to achieve transparency, fairness, and sustainability through AI optimization, setting a new benchmark for staking protocols. However, the protocol was exploited just hours after its launch, resulting in the theft of approximately $2 million in assets from its liquidity pool.
The attack exploited critical compounded vulnerabilities in NGP's core smart contract logic primarily because of price oracle manipulation.
Price Oracle Manipulation is a critical vulnerability in smart contracts that rely on oracles to fetch price and provide real-world data to smart contracts. However, attackers can exploit oracles by manipulating the data they supply, leading to devastating consequences such as unauthorized withdrawals, excessive leverage, or even draining liquidity pools.
getTokenPrice.
IUniswapV2Pair pair = IUniswapV2Pair(mainPair);
(uint reserve0, uint reserve1, ) = pair.getReserves();
price = (usdtReserve * 1e18) / tokenReserve;
DEAD address:
address constant DEAD = 0x000000000000000000000000000000000000dEaD
whitelisted addresses:
mapping(address => bool) public whitelisted
DEAD was listed as whitelisted address along with protocol and mintAddress:
whitelisted[address(this)] = true;
whitelisted[address(DEAD)] = true;
whitelisted[mintAddress] = true;
DEAD address enabled the attacker of bypassing key restrictions and limitations set by contract logic including but not limited to:
maxBuyAmountInUsdt which is 10_000.maxBuyPerDay which is 3 per day.transferCooldown which is 30 mins.from or to are whitelisted addresses:
if (whitelisted[from] || whitelisted[to])
DEAD address as a bypass
gateway to initially route huge volumes of tokens to skip fee deductions, buy/sell caps, and cooldowns.
getPrice was used in _update
function to enforce limitation on the maximum purchase amounts maxBuyAmountInUsdt
require(((value * getPrice()) / 1e18) <= maxBuyAmountInUsdt, "Exceeds max buy amount");
getPrice function to report misleading low or high prices
which can allow the attacker to bypass the purchase limits that were supposedly to be enforced by contract logic.
Selling NGP triggered the contract logic to deduct set of fees as follows:
sync() function then transfer seller's tokens as detailed below:
lpBurnEnabled is false, then burning is disabled.
lpBurnEnabled is true, then it calculates how many tokens are left in circulation:
surplusAmount = totalSupply - burnedSupply; if the remaining supply is below 10 million
tokens, it returns true and stop burning, otherwise it returns false and keep burning.
_update()function when someone sells, it calculates the burn fee:
burnAmount = (value * burnFeeRate) / RATIO_PRECISION
from to the DEAD address to be burned
isLpStopBurn() == false
from and rerouted to the marketAddress
isLpStopBurn() == true
marketFee = (value * marketFeeRate) / RATIO_PRECISION
super._update(from, marketAddress, marketFee)
from and sent to the protocol’s marketAddress.
marketAddress always receives at least marketFee,
and sometimes also the burnAmount if burning is disabled.
burnPoolAmount = treasuryAmount + rewardAmount;
treasuryAmount and rewardAmount
that the protocol mistakenly deducted from the pool reserves directly instead of deducting it from the seller address from.
The protocol checks if pool has enough balance to cover sum of treasuryAmount and rewardAmount and if it does:
treasuryAmount from pool's balance directly
super._update(mainPair, treasuryAddress, treasuryAmount);
rewardAmount from pool's balance directly
super._update(mainPair, rewardPoolAddress, rewardAmount);
Attacker combined all above vulnerabilities in a single atomic transaction of manipulating the price via flash loan, bypassing buy limits through the whitelist, and exploiting premature fee and sync logic to sell at an inflated price.
Following the exploit, the New Gold Protocol team acknowledged the incident publicly on September 20, 2025, stating their intent to continue the project and relaunch. However, no concrete remediation steps were provided: no contract upgrades, audits, or restitution plans were announced. Communication was limited to a few posts on X about tracking the attacker’s funds and “resuming activities soon,” leaving users without clear guidance and liquidity severely impacted.
| Severity | Likelihood | Status | Impact | Vulnerability | Description |
|---|---|---|---|---|---|
| Critical | High | Exploited | High | Flash Loan Oracle Manipulation pair.getReserves() |
Relied on a single DEX pool’s spot reserves, allowing attacker to distort NGP-USDT price via flash loans and sell at inflated valuations. |
| Critical | High | Exploited | High | Fee Deduction from LP Reserves Directly Treasury Fees & Reward Fees |
Treasury/reward fees deducted from liquidity pool reserves instead of seller balances, breaking AMM invariant and directly draining pool. |
| High | High | Exploited | High | Whitelisted DEAD Address Whitelisted `from` & `to` |
Enabled bypass of buy caps, cooldowns, and fee checks, allowing attacker to execute unrestricted swaps via DEAD address. |
| High | High | Exploited | High | Simplistic Price Calculation L 346 |
Used a raw reserve ratio without TWAP/guards, making price trivial to manipulate during reserve imbalance. |
| Medium | Medium | Contributed | Medium | Burn Logic Misuse isLpStopBurn() |
Redirected intended burns to market wallet, undermining supply deflation and compounding supply centralization during attack. |
| Medium | Medium | Contributed | Medium | Abuse of sync() sync() |
Locked manipulated reserves as valid pool state, inflating false price and amplifying profitability of attacker’s swaps. |
| Info rmational |
Low | Design Risk | Low | Misleading Naming of Tokens Redistributions burnPoolAmount |
Misnamed variable suggests burning, but actually redistributes tokens, confusing devs and auditors. |
A hands-on smart contract security education platform designed to help developers, auditors, and protocol teams master adversarial thinking through challenges, tutorials, and real-world exploit case studies.
Start Learning