Evaluate Integration of Gamma's Deposit Check for Price Change Security

[langnavina97]

Background:

Gamma is a decentralized finance (DeFi) protocol designed to manage concentrated liquidity on automated market makers (AMMs) like Uniswap V3. It actively manages liquidity ranges to optimize capital efficiency, reduce impermanent loss, and maximize fee generation for liquidity providers. Gamma is known for its automated vaults that handle liquidity management tasks, such as rebalancing and compounding, while providing a more passive experience for liquidity providers. While Gamma does not serve as an oracle provider, it does integrate price-checking mechanisms to ensure secure operations and protect against price manipulation attacks during processes like deposits.

Gamma's deposit process includes a price check feature implemented via the clearDeposit function, which leverages oracle data to monitor price changes and avoid deposit exploits. This mechanism is a key part of their security architecture, designed to protect against front-running and other price manipulation tactics.

Relevant Contracts:

• Gamma Deposit Proxy Contract: 0xF75c017E3b023a593505e281b565ED35Cc120efa
• ClearingV2 Contract: 0x3943665751bd48263DAAeA7680D2852A7DfBE1db

Key Function:

The checkPriceChange function in ClearingV2.sol serves as the main security feature, ensuring that no significant price fluctuations occur during the deposit process. This function leverages oracles to compare prices and block deposits if the price change exceeds a predefined threshold, thereby preventing exploits.

Considerations:

Pool Address Mapping:

• The clearDeposit function requires a pool address to operate.
• Pool addresses need to be mapped from our token registry, and only pools supported by a reliable oracle should be whitelisted to avoid unsupported or manipulated pools.

Gamma's Approach:

• Gamma is not an oracle solution but wraps tokens into ERC20 tokens, similar to our approach.
• While we could integrate their price validation mechanism, some pools may not be supported by Gamma's oracle system.

Limitations:

• Gamma's lack of support for one-sided liquidity management could present challenges, as our system supports this feature.
• The limited pool support in Gamma’s oracle system could reduce the range of tokens and pools we can offer, potentially affecting the token universe available to us.

https://docs.gamma.xyz/gamma/learn/scans

[langnavina97]

Further findings:

Gamma’s Price Change Check:

• clearDeposit(...) and checkPriceChange are security mechanisms Gamma uses to prevent price manipulation during deposits.
• Limitations: These checks work within predefined price ranges, which are specific to Gamma’s managed positions. This means the mechanism is tailored to positions with a clear price range.

Gamma's Compatibility with Your Custom Price Ranges:

• Gamma's clearDeposit function is designed for their predefined liquidity positions. In our case, where you use customized price ranges and manage multiple positions, integrating this function directly could be challenging, as Gamma’s system wouldn’t account for the dynamic or multiple ranges you manage.

getDepositAmount Function:

• The function calculates the deposit amounts for a specific price range within Gamma’s predefined structure. Since you manage multiple positions with custom price ranges, this function would not be directly applicable to your system. You would need to extend or customize it to support your wider range of positions.

Oracle Usage:

• Gamma does not provide a dedicated oracle solution but rather uses oracles for validating price changes during deposits. You can potentially use this for security in supported pools, but unsupported pools would present limitations.

One-sided Liquidity Management:

• Gamma’s system does not support one-sided liquidity, which is a feature you manage. This further complicates direct integration, as it requires flexibility Gamma currently doesn’t provide.

[Havoc19]

To implement something like - clearDeposit similar to Gamma Stratergy, we anyway need priceOracle, in that case we can use uniswap Twap to expand no.of tokens, if we are going in that direction

I am not sure, how much insecure it will be if there is no priceOracle. Is there issue, like front-running, would like to know the reason

[langnavina97]

Only the fee amount is being affected as described here: https://github.com/Velvet-Capital/Velvet-v4/issues/9

[aj07]

Is there scenario of --> Manipulators might use flash loans to temporarily influence asset prices and exploit the system.

Also, I feel priceOracle is bit needed here

[langnavina97]

I think sandwich attack would also be a concern..

I agree, this would restrict the Thena positions to only Chainlink supported assets but our Core protocol would still support any ERC20 tokens independent on any oracle..