DIP Exploit Drains $111K After Router Transfer Executes Twice

DIP was hit by an estimated $111,000 exploit after a flaw in its customized transfer logic allowed the same router-linked token movement to execute twice. The attacker combined the duplicated settlement with the accounting behavior of the AIC/DIP liquidity pair, drained its real DIP reserve and converted the extracted value through a related AIC/USDT pool.

The BNB Chain transaction shows a coordinated sequence involving balance preparation, a call to skim(router), reserve synchronization and reverse settlement through the compromised market.

Double Transfer Broke The Pool’s Accounting

The vulnerable path appears around nexus_dip.sol:1702. When either the sender or recipient matched the router address, DIP first executed super._transfer inside the router-specific branch. The function then continued to another unconditional transfer at the end of the same execution path.

One request could therefore settle the same amount twice. The first transfer completed the movement expected by the router, while the second removed an equal quantity without a separate economic action supporting it. That behavior broke a basic assumption used by automated market maker pairs, where one requested token transfer should create one corresponding balance change.

Attacker Set The DIP Balance To Twice The Reserve

The attacker first shaped the AIC/DIP pair until its live DIP balance equaled exactly twice its recorded reserve. If the stored reserve was represented as R, the pair held a balance of 2R, leaving an apparent surplus of R.

Calling skim(router) should have transferred only that surplus to the router. The first DIP transfer reduced the pair balance from 2R to R, which would normally leave the genuine reserve intact. DIP’s second transfer then removed the remaining R, emptying the real DIP reserve through the same call.

The attacker followed with sync(), updating the pair’s stored reserves to match the manipulated balances. This locked the distorted state into the pool’s accounting and created the conditions needed to extract value from the other side of the market.

AIC/USDT Pool Provided The Exit Liquidity

After the DIP reserve was drained and the pool was synchronized, the attacker completed reverse settlement through the AIC/DIP pair and received AIC from the compromised liquidity position. The AIC was then sold through the sibling AIC/USDT pool, turning the token-accounting failure into stablecoin-denominated proceeds.

The exploit did not depend on a flaw in skim() or sync() themselves. Both functions behaved according to normal pair accounting, while DIP’s non-standard transfer path produced two balance movements from one request. A similar market-structure risk appeared when a custom token mechanism distorted a PancakeSwap pool, allowing token-side behavior to become the route for extracting the paired asset.

Removing the second unconditional transfer is the central contract fix, but restoring safe trading also requires verifying the patched router path, rebuilding the affected liquidity and confirming that no other transfer branch can duplicate settlements. Until those steps are completed, the AIC/DIP pair remains exposed to the accounting failure that enabled the estimated $111,000 drain.

The post DIP Exploit Drains $111K After Router Transfer Executes Twice appeared first on Crypto Adventure.