## Global Limit on Maximum TW

### Problem Statement

With the planned support for EIP-7002 and triggerable withdrawals in Lido, validators will be able to exit via the Execution layer in a more flexible and permissionless way. According to the proposed support architecture, this functionality introduces new risk vectors that require assessing potential losses and defining safe global TW limits for the protocol.

An attacker (or even a profit-seeking actor) could:

- Exit a large number of validators in one transaction while TW fees are low
- Wait for the fee to drop again and repeat the process
- Fill up the TW queue, slowing down access for valid actors
- **Cause direct APR losses** by forcing Lido to reactivate large amounts of validators, delaying their return to staking

As a **permissionless middleware**, Lido needs clearly defined TW caps and recovery speeds to protect against these risks without harming protocol efficiency.

### Threat Models

We consider two main types of attacks:

1. **DDoS Attack**
The attacker consumes TW capacity without significantly impacting APR but disables the TW mechanism by exhausting the limit.

2. **Protocol Exploit**
The attacker finds and exploits a vulnerability in the TW logic to manipulate APR at a minimal cost.

[Reference: Risk Analysis Spreadsheet](https://docs.google.com/spreadsheets/d/1g8nzq9gbF36lqZaGdaXRjvAMI9JqNF6jMZT_GS7sCCY/edit?usp=sharing)

---

### Assumptions

1. **Why a Higher Limit Might Be Needed**
Higher global TW limits allow for better utilization and scalability under normal operating conditions.

2. **Exit Scenario**
One possible stress scenario: a large-scale exit of Curated NO due to governance changes or security issues.

3. **Response Timeframe**
The time needed to react and adjust TW limits:

- **1 day** — Emergency Committee intervention
- **9 days** — Fast DAO vote
- **14 days** — Standard DAO process

4. **Attacker Model**
Given the exponential increase in TW fee pricing, we assume the attacker will wait for the TW contract fee to recover (i.e., decrease to a low point) before executing an attack.

As a result, the effective TW throughput during an attack is likely to be limited to `≤ 2` per unit time. A higher limit (`≥ 2`) would cause the TW fee to rise sharply, making sustained attacks economically infeasible.

We acknowledge that the **likelihood of an exploit in the Lido TW logic is assumed to be extremely low**. However, in the interest of **protocol-level safety**, we must also consider a conservative scenario where such a vulnerability exists. In that case, an attacker could potentially bypass cost mechanics and gain **unfair or repeated access to TW capacity**, increasing potential harm.

> Even though this is a **low-probability event**, its impact could be severe. Therefore, TW limits and recovery speeds should be treated as **defensive parameters** that remain valid under both normal and degraded assumptions.

Per TW price(in ETH) depends on count of validators in TW contract queue

---

### Real-World Reference: P2P Validator Stats

As a practical benchmark, we reference current usage by one of the largest node operators (P2P):

- **Used validators**: 10,848
- **Active validators**: 7,466
- **Submitted validators**: 13,000

## Attack Impact and TW Limit Considerations

### Annual APR Losses from Single Attack

This table shows the potential impact of a single attack depending on the validator cap. Each row reflects how much APR (%) and ETH could be lost, how much the attack costs the attacker, and how long the attack would take.

| **Cap** | **APR Loss (%)** | **ETH Loss** | **Attacker Cost (ETH)** | **Attack Duration (days)** |
|--------|------------------|--------------|--------------------------|----------------------------|
| 10,000 | 0.1141% | 351.10 | 1.6210 | 0.69 |
| 13,000 | 0.1585% | 487.77 | 2.1073 | 0.90 |
| 25,000 | 0.3841% | 1,179.11 | 4.0524 | 1.74 |
| 38,200 | 0.7213% | 2,206.91 | 6.1920 | 2.65 |
| 63,400 | 1.6314% | 4,946.76 | 10.2768 | 4.40 |
| 113,800 | 4.5774% | 13,488.56 | 18.4464 | 7.90 |
| 133,960 | 6.2211% | 18,048.47 | 21.7142 | 9.30 |
| 214,600 | 16.1377% | 42,820.62 | 34.7855 | 14.90 |

**Example**:
A cap of **25,000** means that a single attack executed over **1.74 days** would lead to a **0.3841% loss** in annual APR, equivalent to **1,179.11 ETH**.
If such an attack were real, and we responded via DAO vote (14-day window), the reactivation time for validators would be **14.39 days**.

---

### Suggested TW Limit Parameters

To manage TW security, we need to define two key parameters:

1. **Validator Cap** — maximum allowed validators via TW
2. **Recovery Speed** — how quickly validators can be restored (validators/day)

Assuming:
- Initial validator cap: **13,000**
- DAO-based reaction time: **14 days**

We get the following mapping of recovery speeds to TW validators cap for 14 days:

| **Recovery Speed (validators/block)** | **Max TW Validator Count** |
|-------------------------------------|-----------------------------|
| 0.1 | 23,080 |
| 0.15 | 28,120 |
| 0.25 | 38,200 |
| 0.3 | 43,240 |
| 0.5 | 63,400 |
| 1.0 | 113,800 |
| 2.0 | 214,600 |

**Example**:
If we choose a recovery speed of **0.25 validators/day**, then during a 14-day DAO vote window, the **maximum TW validator usage** would be **38,200**.
This corresponds to a **0.7213% loss** from annual APR if fully exploited.

### Final Considerations and Recommended TW Cap

To conclude, we aim to define a cumulative TW limit that:

- Can be used multiple times throughout the year
- Has a minimal impact on annual APR even under attack
- Aligns with protocol recovery mechanics and DAO reaction capabilities

Based on all the assumptions and metrics above, we propose the following configuration:

- **TW Cap**: 11,200 validators
- **Recovery Speed**: 0.25 validators per block

This setup implies the following:

- In the event of a **DDoS attack**, we can **fully restore TW functionality within 14 days**.
This would involve **temporarily increasing the recovery speed to 13,000 at block `X`**, then **reducing it immediately after (from block `X+1`)** to maintain stability.

- The **minimum cost to the attacker** for such an extended attack (lasting **14.9 days**) would be **3.5721 ETH**.

- In the case of a **protocol vulnerability exploit**, the **potential APR loss over 14.9 days** is estimated to be **0.7213%**, or **2,206.91 ETH** (i.e., ~0.02380% APR loss per day).

Additionally, this configuration aligns with Ethereum's systemic validator exit rate. For example:

- The **0x01 exit queue** in Ethereum supports **~1,800 exits per day**
- Our chosen recovery rate of `0.25 validators per block` = `7200 blocks/day × 0.25 = 1,800 validators/day`
- This is exactly **2x faster than the DAO's standard 14-day reaction window**, providing a solid operational safety margin

In accordance with the likely usage pattern of triggerable withdrawals—specifically, submitting a large number of validators in a single transaction followed by waiting for the TW contract queue to shrink—the global limit should be adjusted to account for a conservative baseline recovery buffer. Given that up to 1,800 validators/day can exit, and the total cap is 13,000, the effective TW usage cap should be set to 13,000 - 1,800 = 11,200 validators.

Therefore, a validator cap of **11,200** with a **recovery speed of 0.25 validators per block** offers a balanced trade-off between usability, attack resistance, and system alignment. This configuration reflects the architecture of the TW system, which separates access between **CSM actors** (interacting directly with the TW contract) and others accessing through the **VEB contract**, while oracles operate under a dedicated throughput limit of **1,800 validators per day**. Applying the same cap and recovery rate across both TW and VEB contracts ensures consistency and safety under the proposed design.