Brisk Pine Camel Vulnerability Analysis - Incorrect Swap Direction

Jul 26, 2025 by gitftunila 67 views

Brisk Pine Camel Vulnerability - Incorrect Swap Direction Analysis

Introduction

In the realm of decentralized finance (DeFi), the security and correctness of smart contracts are paramount. The Brisk Pine Camel vulnerability, identified during the Sherlock audit of the DeBank project on July 2025, highlights a critical flaw in the VelodromeExecutor contract. This vulnerability, categorized as high severity, stems from an incorrect swap direction determination due to a naive lexicographic comparison of token addresses. This article delves into the intricacies of this vulnerability, its root cause, potential impact, and proposed mitigation strategies. We will explore how this seemingly simple flaw can lead to significant consequences, including swap failures and unexpected output amounts, ultimately affecting the trust and reliability of the DeFi platform.

The Brisk Pine Camel vulnerability in the VelodromeExecutor contract arises from a fundamental misunderstanding of how swap direction should be determined in the context of Uniswap-style Automated Market Makers (AMMs). The contract attempts to determine the swap direction based on a simple lexicographical comparison of the token addresses involved in the swap. While this approach might seem intuitive at first glance, it overlooks the underlying complexities of AMM pool token ordering. Uniswap-style AMMs, such as Velodrome, maintain an internal order of tokens within their pools, designated as token0 and token1. This ordering is established lexicographically during pool creation and is crucial for the correct calculation of swap parameters, such as the price limit. The vulnerability lies in the fact that the lexicographical order of the input and output token addresses does not necessarily align with the token0 and token1 order within the pool. This misalignment can lead to the contract setting an incorrect swap direction, which in turn can have severe consequences for swap execution. To fully grasp the implications of this vulnerability, it's essential to understand the mechanics of swap direction determination in AMMs and the potential pitfalls of relying on a naive address comparison.

Understanding the importance of correct swap direction in AMMs requires delving into the mechanics of how these decentralized exchanges operate. In a typical AMM swap, a user provides one token (the fromToken) and receives another token (the toToken). The direction of the swap, often represented by a boolean flag (e.g., zeroForOne), dictates which token is being sold and which is being bought relative to the pool's internal token ordering (token0 and token1). This direction is crucial for calculating the correct price impact and setting the appropriate price limits to ensure the swap executes within acceptable parameters. If the swap direction is determined incorrectly, the price limit might be set in the wrong direction, potentially leading to slippage beyond acceptable levels or even swap failures. The sqrtPriceLimitX96 parameter, used in Uniswap-style AMMs, plays a critical role in setting this price limit. An incorrect swap direction can cause this parameter to be set towards the wrong boundary (either the minimum or maximum price), significantly impacting the swap outcome. Therefore, a robust and accurate method for determining swap direction is essential for the reliable functioning of any AMM-based exchange. The Brisk Pine Camel vulnerability underscores the potential dangers of overlooking this critical aspect of AMM design.

Summary

The VelodromeExecutor contract incorrectly determines the swap direction (zeroForOne) based on a lexicographic comparison of token addresses:

bool zeroForOne = fromToken < toToken;

This logic assumes that the address ordering of fromToken and toToken reflects the token ordering (token0 and token1) within the underlying Velodrome pool, which is not guaranteed. This can cause the contract to:

Set an incorrect sqrtPriceLimitX96
Fail to execute swaps as intended
Return an unexpected or lower output amount

Root Cause

The root cause of the Brisk Pine Camel vulnerability lies in the flawed logic used to determine the swap direction within the VelodromeExecutor contract. The contract uses a simple lexicographical comparison of the fromToken and toToken addresses to set the zeroForOne flag, which dictates the direction of the swap. This approach is fundamentally flawed because it fails to account for the actual token ordering within the Velodrome pool. Uniswap-style AMMs, including Velodrome, sort tokens lexicographically during pool creation and assign them as either token0 or token1. The swap direction must be determined relative to this internal pool ordering, not based on a simple address comparison. The vulnerability arises because the lexicographical order of token addresses does not necessarily correspond to the token0 and token1 ordering within the pool. This discrepancy can lead to the contract incorrectly determining the swap direction, which has cascading effects on subsequent swap calculations and execution. The contract's reliance on this naive address comparison highlights a critical oversight in the design and implementation of the swap direction logic, ultimately exposing the system to potential vulnerabilities. To fully understand the implications, let's examine the specific code reference and its role in the vulnerability.

Code Reference

The critical code snippet responsible for the vulnerability is found within the VelodromeExecutor contract, specifically in the function that handles swaps using the Velodrome v2 protocol. Let's examine the code reference provided:

bool zeroForOne = fromToken < toToken;

IVelodromeRouter(arg.router).exactInputSingle(
 IVelodromeRouter.ExactInputSingleParams({
 tokenIn: fromToken,
 tokenOut: toToken,
 tickSpacing: arg.tickSpacing,
 recipient: address(this),
 deadline: block.timestamp,
 amountIn: fromTokenAmount,
 amountOutMinimum: 0,
 sqrtPriceLimitX96: arg.sqrtX96 == 0
 ? (zeroForOne ? UniswapV3Lib.MIN_SQRT_RATIO + 1 : UniswapV3Lib.MAX_SQRT_RATIO - 1)
 : arg.sqrtX96
 })
 );

This code snippet demonstrates the core issue: the zeroForOne flag, which determines the swap direction, is set based on the result of a simple less-than comparison between the fromToken and toToken addresses. This boolean value directly influences the sqrtPriceLimitX96 parameter, which is crucial for setting the price boundaries of the swap. If zeroForOne is true (i.e., fromToken address is less than toToken address), the sqrtPriceLimitX96 is set to UniswapV3Lib.MIN_SQRT_RATIO + 1, representing the minimum price limit. Conversely, if zeroForOne is false, it's set to UniswapV3Lib.MAX_SQRT_RATIO - 1, representing the maximum price limit. This direct dependency between the naive address comparison and the price limit setting is the crux of the vulnerability. If the zeroForOne flag is incorrectly determined, the sqrtPriceLimitX96 will be set towards the wrong boundary, potentially leading to swap failures or unexpected price execution. This code reference clearly illustrates the flawed logic at the heart of the Brisk Pine Camel vulnerability.

The Uniswap-style AMMs sort token0 and token1 lexicographically inside the pool contract. However, swap direction must be determined based on which token is being sold, relative to the actual pool token order — not based on a naive address comparison.

Internal & External Pre-conditions

There are no specific internal or external preconditions that directly trigger this vulnerability. The vulnerability is inherent in the logic of the contract itself and can be exploited under various conditions where swaps are executed through the VelodromeExecutor. This means that the vulnerability is always present and poses a risk whenever the contract is used for swapping tokens. The lack of specific preconditions makes the vulnerability even more insidious, as it can be triggered by any swap transaction involving tokens where the address ordering does not align with the pool's token0 and token1 ordering. This highlights the importance of addressing the root cause of the vulnerability to ensure the overall security and reliability of the system.

Attack Path

While a specific step-by-step attack path wasn't detailed in the initial report, the vulnerability's nature suggests a scenario where an attacker could exploit the incorrect swap direction determination to their advantage. Imagine a situation where the lexicographical order of the token addresses is opposite to the actual token0 and token1 order within the Velodrome pool. In such a case, the contract would set an incorrect sqrtPriceLimitX96, potentially allowing an attacker to manipulate the price execution. For instance, if the price limit is set towards the maximum when it should be set towards the minimum, the attacker could execute a swap that results in a significantly lower output amount for the user. This type of manipulation could lead to financial losses for users interacting with the contract. While a precise attack path would depend on the specific market conditions and pool parameters, the underlying vulnerability creates an opportunity for malicious actors to exploit the flawed swap direction logic. This underscores the need for a robust mitigation strategy to prevent potential attacks and ensure the integrity of the DeFi platform.

Impact

The impact of the Brisk Pine Camel vulnerability can be significant, potentially leading to financial losses for users and eroding trust in the platform. The VelodromeExecutor contract's role in handling swaps via Velodrome v2 makes it a critical component of the DeFi ecosystem. The incorrect calculation of the zeroForOne flag, due to the naive lexicographical comparison of token addresses, can have several adverse consequences. First and foremost, it can lead to an incorrect price limit. The sqrtPriceLimitX96 value, which determines the acceptable price range for the swap, may be set towards the wrong boundary (either the minimum or maximum). This misdirection can cause the swap to either revert, meaning the transaction fails entirely, or execute far outside the expected price range, resulting in significant slippage and financial losses for the user. Secondly, the vulnerability can cause swap failures. If the incorrectly set price limit is incompatible with the current market price, the swap will fail, reverting the transaction and preventing the intended token exchange. This can disrupt user activity and create a negative experience. Finally, the vulnerability can result in an unexpected or lower output amount. Even if the swap doesn't fail entirely, executing with an incorrect price limit can lead to users receiving less of the desired token than they anticipated, effectively costing them money. The combined impact of these potential consequences highlights the severity of the Brisk Pine Camel vulnerability and the importance of implementing effective mitigation measures.

PoC

No specific Proof of Concept (PoC) was provided in the initial report. However, the nature of the vulnerability allows for the creation of a PoC that demonstrates the potential for incorrect swap execution and financial loss. A PoC could involve setting up a scenario where the token address ordering is deliberately mismatched with the pool's token0 and token1 ordering. By executing swaps under these conditions, it would be possible to demonstrate how the incorrect zeroForOne flag leads to an incorrect sqrtPriceLimitX96, resulting in either swap failures or significantly unfavorable price execution. Such a PoC would further emphasize the practical implications of the vulnerability and the urgency of implementing a fix.

Mitigation

The proposed mitigation for the Brisk Pine Camel vulnerability is straightforward and effective. It involves fetching the token0 address from the pool contract and using a direct comparison to determine the swap direction. Instead of relying on the naive lexicographical comparison of token addresses, the corrected logic would compare the fromToken address to the pool's token0 address. This ensures that the swap direction is determined relative to the actual token ordering within the pool, as intended. The recommended code snippet is as follows:

address token0 = IUniswapV3Pool(pool).token0();
bool zeroForOne = (fromToken == token0);

This approach eliminates the ambiguity and potential for error introduced by the address comparison method. By directly comparing the fromToken to the token0 address, the contract can accurately determine the swap direction, ensuring that the sqrtPriceLimitX96 is set correctly and swaps are executed within the expected price range. This mitigation strategy is simple to implement and effectively addresses the root cause of the vulnerability, significantly improving the security and reliability of the VelodromeExecutor contract. Implementing this mitigation is crucial for preventing potential exploits and maintaining user trust in the DeFi platform.

Conclusion

The Brisk Pine Camel vulnerability serves as a crucial reminder of the importance of careful design and implementation in smart contract development, especially within the complex landscape of DeFi. The seemingly simple mistake of using a naive lexicographical comparison for swap direction determination highlights how subtle flaws can have significant consequences. The potential impact of this vulnerability, ranging from swap failures to financial losses for users, underscores the need for rigorous auditing and testing of smart contracts. The proposed mitigation, which involves directly comparing the fromToken address to the pool's token0 address, provides a clear and effective solution to the problem. By implementing this fix, the VelodromeExecutor contract can ensure accurate swap direction determination, preventing potential exploits and enhancing the overall security and reliability of the DeFi platform. This vulnerability serves as a valuable lesson for developers in the DeFi space, emphasizing the critical role of understanding the intricacies of underlying protocols and implementing robust logic to prevent unexpected behavior. Continuous vigilance and proactive security measures are essential for building a trustworthy and resilient decentralized financial ecosystem.