> 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-11-low-level-.call-.transfer-and-.send/examples.md).

# Examples

{% hint style="info" %}
[**Book an audit with Zokyo**](https://www.zokyo.io/)
{% endhint %}

{% hint style="info" %}
**Understanding the Examples:** In the "Examples" section, we will dive into practical instances of vulnerabilities related to the use of `.call`, `.transfer`, and `.send` methods, sourced from actual bug bounty reports, Code Arena analyses, and beyond. By examining these real-world cases, you'll attain a richer and more concrete comprehension of the nuances associated with these Ethereum functions and their potential ramifications. This hands-on insight will significantly augment your smart contract auditing prowess.
{% endhint %}

**Example 1: High vulnerabilty Code4rna bounty payout**

Description: 

In this example contract's operations, when utilizing a wrapped native token, employ the `payable.transfer()` method to manage complete user withdrawals. This approach introduces a risk due to the inherent limitations of the `transfer()` method. Specifically, `transfer()` has a hardcoded gas budget, which can cause the call to fail, especially when the recipient address is a smart contract. Consequently, any programmatic use of this contract becomes vulnerable.

Implications:

 If a user fails to implement the necessary payable fallback function, or if the total gas consumption for the sequence of functions invoked during a native token transfer surpasses the 2300 gas limit, there are notable issues:

* The native tokens won't be delivered successfully.
* The mechanism to return the undelivered funds to the user will continuously fail. Notably, the `closeTrade` function in OpenLevV1 is affected, resulting in potential scenarios where users' primary funds are frozen. This elevates the vulnerability to a high-severity level.

relevant code: 

```
    function doTransferOut(address to, IERC20 token, address weth, uint amount) external {
        if (address(token) == weth) {
            IWETH(weth).withdraw(amount);
            payable(to).transfer(amount);
        } else {
            token.safeTransfer(to, amount);
        }
    }
```

A safer approach would be to replace the `transfer()` function with the `call` method, which doesn't have the same restrictive gas limitations and offers more flexibility.

**Example 2: Low vulnerabilty Code4rna bounty payout**

Description: 

The code in question makes use of the `payable.transfer()` method, a practice that is widely discouraged due to potential risks. The primary concern is that `payable.transfer()` can result in funds becoming inaccessible or "locked". The `transfer()` method necessitates that the recipient has a payable fallback function and allocates only 2300 gas for its execution. This limited gas budget can cause the transfer to fail in various scenarios:

1. If the contract lacks a payable callback.
2. When the contract's payable callback exceeds the 2300 gas limit. This could happen even with a simple event emission, which requires more than 2300 gas.
3. If the contract is accessed through a proxy, and that proxy consumes the allotted 2300 gas

relevant code:

```
payable(msg.sender).transfer(amount);
```

Implications: 

The usage of `transfer()` in this context can lead to inadvertent fund lockups if the recipient contract doesn't adhere to the expectations set by the 2300 gas stipend. In worst-case scenarios, users or contracts could permanently lose access to their funds.

Recommendation: 

To ensure more reliable fund transfers and to avoid the mentioned pitfalls, it's advised to use the more flexible `address.call{value: x}()` pattern. This approach doesn't impose the same restrictive gas limitations as `transfer()` and offers better handling of different contract interactions.


---

# 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:

```
GET https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorial-11-low-level-.call-.transfer-and-.send/examples.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.