~$1.6M Lost: Moke Token, LpdFi Exploits

During the past week (2026/08/03 - 2026/08/09), the following 2 notable security incidents are featured, involving approximately $1.6M in total losses.

Date	Incident	Type	Estimated Loss
2026/08/03	LpdFi	Price Manipulation	~$697K
2026/08/03	Moke Token	Price Manipulation & Accounting Error	~$906K

LpdFi was selected because it illustrates the systemic risk of using manipulable AMM reserves for both position valuation and interest redemption. The attacker first inflated the recorded principal through spot price manipulation, then altered the pool reserves through a direct donation and sync() to make the oversized interest claim executable. It highlights the importance of validating solvency across the complete position lifecycle rather than treating deposit valuation, interest calculation, and redemption as independent operations.
Moke Token was selected because it demonstrates how vulnerabilities across separate accounting mechanisms can be combined into a single profitable attack. The attacker manipulated a spot price to inflate the amount of claimable MOKE, duplicated LP reward records by synchronizing the same LP tokens across multiple addresses, and converted the resulting tokens into extractable BNB through the dividend system. It highlights the importance of using manipulation-resistant price sources and keeping reward accounting synchronized with actual token ownership.

Weekly Highlight: LpdFi Protocol

This incident is highlighted because the same manipulable AMM state governed both liability creation and asset redemption. It shows why a protocol must validate solvency across the full position lifecycle, not treat deposit valuation, interest accrual, and redemption as independent steps.

On August 3, 2026, the LpdFi protocol on BNB Chain was exploited for approximately $697K, drained from the LPD/USDC PancakeSwap pair. LpdFi derived both a position's recorded value and its later interest payout from the same live PancakeSwap pair, so manipulating that pair distorted both. The attacker opened a position valued far above its real worth, waited for interest to accrue, then shifted the pair's reserves so the oversized interest claim could be paid out, draining almost all liquidity the protocol held.

Background

LpdFi is a yield protocol built around the LPD token. A user creates a position by depositing LPD. At deposit time the protocol values the deposit using the current LPD/USDC PancakeSwap spot price and stores the result as uAmount, a USD-denominated principal for the order. The order accrues interest by issue, where each issue is one daily accounting period, and the protocol caps each order's total interest against the recorded principal.

When a user claims interest, the protocol converts the accounting interest into USDC by removing liquidity from the LPD/USDC pair using LP tokens held by LpdFi. The redeemed USDC is then split between the claimant and the fee address. Both ends of the position lifecycle, valuation at deposit and payout at redemption, therefore read from the same live PancakeSwap pair.

Vulnerability Analysis

The buggy contracts are 0xce6a...f295e and 0x3876...273604.

The root cause is that LpdFi used the live LPD/USDC spot price and reserves as the source of truth for both order accounting and interest redemption. Neither value is safe to trust: both are derived from pair reserves that a caller with enough temporary liquidity can move within a single transaction.

At deposit, buy() computes the token amount from token.price():

LPD.price() reads the LPD/USDC reserves directly through getReserves(), so the recorded principal moves with the spot price:

At redemption, claimInterest() pays out the accrued interest by calling removeLp():

removeLp() computes how many LP tokens to burn from the live reserve r1 (or r0):

Two invariants break as a result. First, because the recorded principal is derived from the spot price, a principal can be recorded that is far larger than the deposit's real value, which raises the interest cap. Second, because removeLp() sizes the LP burn from the live reserve, the number of LP tokens the protocol must burn to satisfy a given USDC payout depends on a reserve value that is not fixed at claim time.

Attack Analysis

The following analysis is based on the transactions 0xbb5b85...41c3588 and 0x70bbe0...b3315d6.

Step 1: In block 113613923, the attacker used flash-loaned funds to perform a large USDC-to-LPD swap in the LPD/USDC pair. This reduced the pool's LPD reserve and raised the spot price returned by LPD.price().
Step 2: While the price was inflated, the attacker called buy() to open an oversized order. Valued at the manipulated spot price, the deposit was recorded with a USD principal of 140,324,732.

Step 3: In the next block, 113613924, the attacker crossed the protocol's issue boundary. Although only one block passed, the protocol treats each issue change as a daily accounting period, so one period of interest on the inflated principal became claimable.
Step 4: In the claim transaction, the attacker borrowed 730,607.755349 USDC through PoolManager, transferred 3,440.992868 USDC directly to the LPD/USDC pair, and called sync(). Under the original reserve state, the inflated interest would have required more LP tokens than LpdFi held, so the redemption would revert. By raising the pair's recorded USDC reserve from 718,619.888284 to 722,060.881152, the attacker reduced the LP amount that removeLp() needed to burn, bringing it within the protocol's actual LP balance.

Step 5: The attacker called claimInterest(0). The inflated principal produced 701,623.66 USDC of claimable interest for one issue. After the reserve manipulation, removeLp() needed to burn only 1,678,049.359669 LP tokens, almost exactly the full LP balance held by LpdFi. The protocol burned about 97% of the total LP supply, transferred 693,529.790711 USDC to the attacker, and the attacker repaid the flash loan and moved out the profit.

Conclusion

This incident stemmed from using manipulable AMM spot reserves as the source of truth for both order accounting and redemption. Valuation and redemption were treated as independent operations reading the same live pool, so a principal recorded at a manipulated price was never reconciled against the pool's actual backing.

The protocol should not use live AMM reserves as the source of truth for order principal or withdrawal accounting. Safer designs value each deposit through a manipulation-resistant price source, such as a time-weighted average price with freshness and deviation checks, rather than a spot valuation, and enforce a solvency check before redemption so a claim can never burn more backing than the position genuinely contributed.

More Incidents This Week

Moke Token

On August 3, 2026, Moke Token on BNB Chain was exploited for approximately $906K through spot-price reliance combined with duplicated LP accounting. The attacker manipulated a spot price to inflate the amount of claimable MOKE, transferred it into the LP dividend contract, triggered the dividend process to sell the MOKE for BNB, and then collected that BNB through duplicated LP records.

Background

Moke Token is a BNB Chain ecosystem built around user participation, delayed MOKE release, LP rewards, and referral incentives. Users participate with USDT and AC. Instead of receiving MOKE immediately, each participation grants a future MOKE release managed by MokeRelease, which becomes claimable over time.

When a user claims, the contract converts the released USDT value into MOKE using the settled MOKE/USDT price, then transfers the corresponding MOKE from the reserve pool to the user. These released tokens are restricted by default and can only be transferred to authorized handler addresses, such as contracts used to add liquidity. Users holding LP tokens then receive BNB distributions from the protocol's tax and dividend pools based on their LP share.

Vulnerability Analysis

The buggy contracts are 0x684d...b302a7 and 0x5ae5...eba377.

The first root cause is spot-price reliance. getMokeUsdtPrice() derives the MOKE/USDT price from the WBNB/USDT and WBNB/MOKE pairs, with no manipulation-resistant price source:

The second root cause is duplicated LP accounting. _syncUserLP() records a user's LP balance by reading lpToken.balanceOf(user) into userLPRecord[user]. Because the update is triggered manually and keyed only on the current balance, the same LP tokens can be moved across multiple addresses and synced at each one, inflating the total recorded LP balance and the dividend rewards it earns:

Attack Analysis

The following analysis is based on the transactions 0xc0f1df...e26154 and 0x077604...756a8f.

Step 1: About 10 days before the exploit, the attacker prepared release quota by depositing USDT through the participate function in MokeVault, obtaining 45,000 USDT worth of MOKE release quota that unlocked at 5.5% per day.

Step 2: The attacker minted MOKE/WBNB LP tokens and called syncUserLP in MokeLPDividend to record the LP balance, then transferred the same LP tokens to another address and repeated the sync, creating duplicated LP records for one set of tokens.

Step 3: The attacker used flash loans to borrow a large amount of BNB and swapped it for USDT in the WBNB/USDT pair, pushing up the spot price of USDT. The attacker then updated the MOKE price in MokeRelease, and the settled MOKE price dropped sharply.

Step 4: With the manipulated MOKE price in place, the attacker called claim in MokeRelease and redeemed 24,766 USDT worth of quota for MOKE tokens, receiving far more MOKE than the quota's real value.

Step 5: The attacker transferred the released MOKE into the whitelisted MokeLPDividend contract and called distributeDividend, which sold the MOKE for BNB. The attacker then used the addresses that had recorded duplicated LP balances to call claimDividend and collect the distributed BNB, receiving a total of 1,546 BNB.

Conclusion

Moke Token combined two independent flaws: a spot price that could be moved with a flash loan, and dividend accounting that counted the same LP tokens more than once. Neither alone would have been as damaging as the two together.

Protocols should avoid instantaneous spot prices for security-sensitive calculations and use a manipulation-resistant source instead. Any accounting keyed on token balances must be updated together with the balance changes themselves, so the same tokens cannot be counted across multiple addresses.

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.