QuantAMM

Summary

A potential vulnerability has been identified in the original UpliftOnlyExample contract, related to high gas consumption and the possibility of a partial DoS when multiple deposits and NFT transfers are performed. Specifically, the logic of storing deposits in an array and manually reordering it during each transfer can trigger costly iterations, increasing the likelihood of gas-related reverts (especially in congested scenarios or with high block.gaslimit).

Vulnerability Details

1. Location and Behavior

• The vulnerability primarily appears in the onAfterRemoveLiquidity and afterUpdate functions, where the contract manually reorders a user’s FeeData[] array.

• onAfterRemoveLiquidity iterates backward over the array to update and remove deposits, applying fees and computing amounts. This reverse loop can trigger substantial gas usage if many deposits exist.

• UpliftOnlyExample.sol - onAfterRemoveLiquidity

• afterUpdate (NFT transfers) searches for the tokenID in the array, then shifts elements in storage to maintain FILO order, causing multiple writes when the array holds numerous entries.

• More generally, each deposit is “pushed” to the array on deposit, while withdrawals and transfers require multiple storage touches (deletion, rewriting, copying) that become expensive as the array grows (up to 100 entries per user).

• UpliftOnlyExample.sol - afterUpdate

1. Potential Partial DoS

   • In a high gas cost environment or with a low block.gaslimit, these loops might exceed the available gas, causing the transaction to revert.

   • This situation blocks withdrawals or transfers for users holding many deposits, resulting in a partial DoS: user funds remain secure, but certain operations are effectively inaccessible during periods of elevated gas usage.

Impact

The vulnerability impacts the usability and efficiency of the contract:

1. Partial Denial of Service:

   • Users with a large number of deposits (close to 100) may experience failed transfers or withdrawals during periods of high gas prices or network congestion.

2. Excessive Gas Costs:

   • Regular operations (e.g., NFT transfers) become prohibitively expensive, discouraging participation and reducing the system's scalability.

3. Risk of DoS Exploitation:

   • A malicious actor could intentionally bloat arrays to degrade system performance, affecting other users indirectly.

Proof of Concept

Test

• Add the following test to pkg/pool-hooks/test/foundry/UpliftExample.t.sol:

Test Result

1. Test Explanation

   • We run testExcessiveGasWhenTransferringAfter100Deposits() (shown below) to create 100 deposits for Bob, then transfer the NFT #100 to Alice. The test logs reveal significant gas usage for both:

     1. Creating 100 deposits.

     2. Transferring the NFT and triggering array reordering.

2. Logs

   • The logs show Gas used for 100 deposits: 26331593 and Gas used for NFT transfer & array reorder: 210236.

   • This high gas usage affirms the vulnerability, as the array reordering calls multiple storage writes that can revert transactions under congested conditions.

Tools Used

• Foundry: Used to develop and run tests to validate the vulnerability.

• Manual Code Review: Confirms the array reordering logic exists in the contract and triggers repeated storage writes.

Recommendations

1. Use a Mapping Instead of Arrays

   • Map deposit IDs to structs (e.g., mapping(uint256 => FeeData)) and store only references to relevant data. This design avoids shifting array elements on transfer or removal.

2. Lower the Maximum Deposit Count

   • Reduce the hard limit from 100 to a smaller number (e.g., 30) to limit the iteration and partially mitigate gas usage if array logic is retained.

3. Aggregate Deposits

   • Consolidate multiple deposits into a single record when feasible. This drastically reduces the overall deposit count per user.

4. Off-Chain Indexing

   • Outsource complex ordering or deposit history to an off-chain index (like The Graph), thereby removing heavy on-chain loops.

5. User Warnings

   • Document or notify users that high deposit counts may yield significant gas costs and potential transaction failures in congested conditions.