> For the complete documentation index, see [llms.txt](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorial-55-assetin-assetout-fromtoken-totoken/vulnerability-missing-fromtoken-totoken-check.md). # Vulnerability: Missing fromToken != toToken Check **Introduction** In token swap protocols, especially those handling complex operations like cross-chain swaps or margin trading, ensuring proper validation of input parameters is critical to maintaining the integrity and security of the system. One of the key checks often overlooked is confirming that the **input token (fromToken)** and **output token (toToken)** are different. Without this validation, attackers can manipulate the swap process by specifying the same token for both `fromToken` and `toToken`, leading to potential exploits where they withdraw funds or circumvent important security mechanisms such as time-locks or cooling periods. This type of vulnerability is particularly dangerous because it can drain liquidity or enable an attacker to withdraw funds they should not have access to, ultimately compromising the financial security of the protocol. *** #### Vulnerability: Missing `fromToken != toToken` Check **How the Exploit Works** When the contract responsible for token swapping (or any similar operation) does not check whether the **input token** and **output token** are the same, it allows attackers to manipulate the process. Typically, during a swap, the `fromToken` should be exchanged for a different `toToken`. If this check is missing, however, the attacker can specify the same token for both, causing the swap logic to misbehave and enabling them to withdraw funds without undergoing the proper swap process. **Attack Flow** 1. **No Input Validation**: The swap function does not verify that `fromToken` and `toToken` are different. 2. **Fake Pair Setup**: The attacker calls the function with a crafted pair, where the same token is used for both input and output. 3. **Fake Swap Process**: The swap proceeds with fake reserves, allowing the attacker to bypass proper fund transfers or security checks, such as time-locks. 4. **Circumventing Security Mechanisms**: The attacker can bypass conditions like cooling-off periods or other time-based restrictions on withdrawals by exploiting the faulty logic. 5. **Fund Withdrawal**: The attacker eventually ends up withdrawing the funds or circumventing security restrictions, leaving the system vulnerable. #### Tutorial: Vulnerability Arising from Missing `fromToken != toToken` Check **Introduction** In token swap protocols, especially those handling complex operations like cross-chain swaps or margin trading, ensuring proper validation of input parameters is critical to maintaining the integrity and security of the system. One of the key checks often overlooked is confirming that the **input token (fromToken)** and **output token (toToken)** are different. Without this validation, attackers can manipulate the swap process by specifying the same token for both `fromToken` and `toToken`, leading to potential exploits where they withdraw funds or circumvent important security mechanisms such as time-locks or cooling periods. This type of vulnerability is particularly dangerous because it can drain liquidity or enable an attacker to withdraw funds they should not have access to, ultimately compromising the financial security of the protocol. *** #### Vulnerability: Missing `fromToken != toToken` Check **How the Exploit Works** When the contract responsible for token swapping (or any similar operation) does not check whether the **input token** and **output token** are the same, it allows attackers to manipulate the process. Typically, during a swap, the `fromToken` should be exchanged for a different `toToken`. If this check is missing, however, the attacker can specify the same token for both, causing the swap logic to misbehave and enabling them to withdraw funds without undergoing the proper swap process. **Attack Flow** 1. **No Input Validation**: The swap function does not verify that `fromToken` and `toToken` are different. 2. **Fake Pair Setup**: The attacker calls the function with a crafted pair, where the same token is used for both input and output. 3. **Fake Swap Process**: The swap proceeds with fake reserves, allowing the attacker to bypass proper fund transfers or security checks, such as time-locks. 4. **Circumventing Security Mechanisms**: The attacker can bypass conditions like cooling-off periods or other time-based restrictions on withdrawals by exploiting the faulty logic. 5. **Fund Withdrawal**: The attacker eventually ends up withdrawing the funds or circumventing security restrictions, leaving the system vulnerable. *** #### Example: Faulty Swap Logic Let’s consider a simplified version of the vulnerable swap logic. Below, the `swapTokens` function does not check whether `fromToken` is the same as `toToken`: ``` function swapTokens( address fromToken, address toToken, uint256 amountIn, address recipient ) external { // Vulnerability: No check to ensure fromToken != toToken uint256 amountOut = calculateAmountOut(fromToken, toToken, amountIn); // Transfer the input tokens from the user to the contract IERC20(fromToken).transferFrom(msg.sender, address(this), amountIn); // Transfer the output tokens from the contract to the user IERC20(toToken).transfer(recipient, amountOut); } function calculateAmountOut( address fromToken, address toToken, uint256 amountIn ) internal view returns (uint256) { // Calculation logic (vulnerable when fromToken == toToken) return amountIn * getExchangeRate(fromToken, toToken); } ``` In this case: * The contract fails to check whether the `fromToken` and `toToken` are the same. * An attacker could call this function with the same token for both `fromToken` and `toToken`. * If the swap logic allows, the attacker can manipulate the reserves, making it appear as if a valid trade occurred, when in reality, no actual token exchange took place. This allows the attacker to bypass the intended security mechanisms, such as cooling-off periods for withdrawals, or to trick the contract into performing fake swaps. *** #### Potential Impact Failing to validate that the `fromToken` and `toToken` are different can have severe consequences, including: 1. **Liquidity Drain**: The attacker could repeatedly use this technique to drain liquidity from the pools, causing significant financial loss for liquidity providers and the protocol. 2. **Bypassing Security Mechanisms**: This exploit can be used to bypass important security features, such as time-locks or cooldown periods that are meant to protect user funds and the protocol’s stability. 3. **Economic Loss**: Even if liquidity is not fully drained, this exploit can disrupt the economic balance of the protocol, leading to price slippage or other market manipulation strategies that could harm regular users. #### Mitigation Strategies To prevent this type of vulnerability, it is essential to include a check that ensures the `fromToken` and `toToken` are not the same #### Conclusion The absence of a `fromToken != toToken` check introduces a critical vulnerability in swap-based protocols. Attackers can use this oversight to drain liquidity, bypass security measures, or manipulate the economic functions of the protocol. Developers and auditors must always include proper input validation to ensure that protocols function as intended, safeguarding against exploits and preserving user trust. By implementing straightforward checks, like ensuring the `fromToken` and `toToken` are different, DeFi protocols can protect themselves from these types of exploits and prevent significant financial loss. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorial-55-assetin-assetout-fromtoken-totoken/vulnerability-missing-fromtoken-totoken-check.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.