RDPX price manipulation benefit for attacker via a Flashloan attack

[code423n4]

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/core/RdpxV2Core.sol#L657

Vulnerability details

Impact

As the RdpxV2Core contract burns RDPX tokens, a malicious attacker can benefit from a price manipulation attack using a flashloan attack

Proof of Concept

The function bond() in the RdpxV2Core contract is a primary function to enter the protocol and bond DpxETH. This function accepts a rdpxBondId which if this parameter is equal to zero, then the _transfer() function switches the calculations from RdpxDecayingBonds token to RDPX ERC20 token. This function explicitly checks all the required criteria and it works well. However, this type of transfer for corresponding zero bondId is somehow similar to a fee-on-transfer mechanism. It burns a small portion of RDPX token and makes the RdpxV2 core contract makes the RDPX token inflation-proof. This burning mechanism can affect the RDPX token price if great DpxETH bonding amounts are passed to the bond() function. Consider an attacker gets a large amount of WETH and swaps some portion of these tokens to RDPX tokens via the Uniswap v2 routers. Now the attacker has large WETH and RDPX balances. Then the attacker decides to call the bond() functions with proper amount of DpxETH bonding amounts. This will make the core contract burn some large amounts of RDPX. As a result, the price of RDPX skyrockets. Then the attacker can swap the RDPXs into WETH and pay back the initial flashloan. This process can be iterative and may lead for attacker to benefit from such price manipulation scenario.

Due to the complexity of testing such a POC using Forge (both using assume or forking the chain), it requires more time to work on. This report simply describes a possible strong attack which happens daily and consequently the attacker benefits from flashloan attack.

Tools Used

Manual Review Forge Invariant Test

Recommended Mitigation Steps

Consider putting a max cap for amounts to prevent these flash loan attacks.

Assessed type

Token-Transfer

[c4-pre-sort]

bytes032 marked the issue as low quality report

[bytes032]

• Over inflated
• No POC
• Doesn't show an vulnerability

[c4-judge]

GalloDaSballo marked the issue as unsatisfactory: Insufficient proof

[GalloDaSballo]

Due to the complexity of testing such a POC using Forge (both using assume or forking the chain), it requires more time to work on. This report simply describes a possible strong attack which happens daily and consequently the attacker benefits from flashloan attack.

Due to the complexity of the finding, I'm closing due to lack of proof