> 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-38-eigen-layer/denial-of-service-in-nodedelegator-due-to-eigenlayers-maxperdeposit-check.md).

# Denial of Service in NodeDelegator Due to EigenLayer's maxPerDeposit Check

**Overview of the Vulnerability**

The vulnerability in the **NodeDelegator** contract's `depositAssetIntoStrategy` function introduces a potential **Denial of Service (DoS)** issue, arising from the interaction with **EigenLayer's `maxPerDeposit` limit**. When the NodeDelegator attempts to deposit assets into a strategy managed by EigenLayer, it triggers a check in EigenLayer’s `StrategyBaseTVLLimits` contract to ensure that the deposited amount does not exceed the maximum allowed per deposit (`maxPerDeposit`). If the deposit exceeds this limit, the transaction is reverted, leaving the tokens in the NodeDelegator contract without being deposited.

This can cause a DoS condition for the NodeDelegator contract because subsequent attempts to deposit assets will fail unless manual intervention is taken to resolve the issue. While the assets are not directly lost, the contract's normal operations and financial management may be disrupted, leading to stuck tokens and blocked transactions.

***

#### How the Vulnerability Occurs

1. **Asset Deposit Request**: The process begins when the **NodeDelegator** contract’s `depositAssetIntoStrategy` function is called to deposit tokens into a strategy managed by EigenLayer. The contract calculates the token balance and attempts to deposit the entire amount.
2. **Triggering the `maxPerDeposit` Check**: When the deposit request reaches the strategy, EigenLayer’s **StrategyBaseTVLLimits** contract performs a check to ensure that the deposit amount does not exceed the configured `maxPerDeposit` value. This limit is designed to cap the maximum allowable deposit per transaction, protecting the strategy from receiving excessively large deposits.
3. **Transaction Reversion**: If the balance of tokens in the NodeDelegator contract exceeds the `maxPerDeposit` limit, the transaction is reverted by EigenLayer’s `deposit` function, preventing the tokens from being deposited.
4. **Tokens Stuck in the NodeDelegator**: As a result of the reversion, the tokens remain stuck in the NodeDelegator contract without being successfully deposited into the strategy. Further attempts to deposit will continue to fail unless manual steps are taken to resolve the issue.

***

#### Example Flow

* **Step 1**: The NodeDelegator contract attempts to deposit 1,000 tokens into an EigenLayer strategy by calling the `depositAssetIntoStrategy` function.
* **Step 2**: The EigenLayer strategy checks the `maxPerDeposit` limit, which is set at 500 tokens.
* **Step 3**: Since the NodeDelegator's balance (1,000 tokens) exceeds the 500-token limit, the transaction is reverted, and the tokens remain in the NodeDelegator contract.
* **Step 4**: The tokens are not deposited, and further attempts to deposit them will fail until the balance is manually adjusted or split.

***

#### Impact of the Vulnerability

* **Denial of Service (DoS)**: The inability to deposit assets effectively creates a DoS condition for the NodeDelegator contract. Any assets that exceed the `maxPerDeposit` limit remain stuck, and subsequent deposit attempts will also fail until the issue is resolved.
* **Operational Disruption**: The NodeDelegator contract’s normal operations are disrupted, potentially preventing important financial transactions, asset management, or other protocol functions.
* **Blocked Transactions**: If the protocol relies on regular deposits into EigenLayer strategies, the blocked deposits can lead to delays, reduced efficiency, and missed opportunities for staking rewards or yield generation.


---

# 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-38-eigen-layer/denial-of-service-in-nodedelegator-due-to-eigenlayers-maxperdeposit-check.md?ask=<question>&goal=<endgoal>
```

`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.
