# Wrapped Rocket Pool ETH (wrETH) Exploit Post Mortem
**Explanation and Effect on the Prize WRETH Vault (przWRETH)**

## Summary

- The **ONLY** affected PoolTogether vault was the Rocket Pool Prize wrETH vault.
- The exploit occurred in the underlying wrETH asset and was **NOT** due to a fault in the PoolTogether code base or security.
- Steps have been taken to mitigate exposure by preventing new deposits to the affected vault in Cabana and PoolTime interfaces.

## Affected Contracts

- [Wrapped Rocket Pool ETH (wrETH): `0x67CdE7AF920682A29fcfea1A179ef0f30F48Df3e`](https://optimistic.etherscan.io/address/0x67CdE7AF920682A29fcfea1A179ef0f30F48Df3e)
- [RETHERC4626: `0xA73ec45Fe405B5BFCdC0bF4cbc9014Bb32a01cd2`](https://optimistic.etherscan.io/address/0x67CdE7AF920682A29fcfea1A179ef0f30F48Df3e)
- [Prize WRETH - Rocket Pool (przWRETH): `0x8C2F27b7819Eb1Bb7E3b5C407C5e1839186D5aBA`](https://optimistic.etherscan.io/token/0x8c2f27b7819eb1bb7e3b5c407c5e1839186d5aba)

## Description of Exploit

Rocket Pool recently deployed a [Wrapped Rocket Pool ETH (wrETH)](https://optimistic.etherscan.io/address/0x67CdE7AF920682A29fcfea1A179ef0f30F48Df3e) token on Optimism for the purpose of providing a rebasing version of the [`rETH`](https://optimistic.etherscan.io/address/0x9Bcef72be871e61ED4fBbc7630889beE758eb81D) token by keeping `rETH` as collateral and minting rebasing `wrETH` tokens to depositors which could be redeemed at any point for `rETH` at the current exchange rate.

Immediately after it's deployment and first deposit, an exploiter found a bug in the `burnTokens` and `burn` functions that allowed them to withdraw the entire `rETH` collateral without needing to burn any `wrETH` tokens at all. The exploiter(s) proceeded to drain the contract of any new deposits over the next five days.

> The drain txs and order of events can be seen on the [wrETH contract token transfer page](https://optimistic.etherscan.io/address/0x67CdE7AF920682A29fcfea1A179ef0f30F48Df3e#tokentxns). The drain txs have been highlighted in red:

The first two multicall draining transactions were initiated by `0x0000000009AE004a920069B8e1A189B82403a130`, which is associated with the ENS name: [fuzz-tea.eth](https://app.ens.domains/fuzz-tea.eth). The following message is posted on it's ENS profile:

> "I am an automated generalized MEV bot. I will return the funds in case of accidental execution of a transaction that can be considered a hack. Please use onchain messages and social media channels to clearly communicate where to return the funds and give it some time."

`fuzz-tea.eth` still holds the ~0.0164 `rETH` on Optimism.

---

The next drain tx was sent by `0x8b5aAbaA42FaeF0992708926f7f39C0dfF3FFf6d`, who promptly swapped the ~1.895 `rETH` and bridged the funds to another chain.

---

The last two drain txs were sent by `0x86f6D2D6740018262CF71020992150200cF6c4d9`, who promptly swapped the ~2.997 `rETH` to `WETH` and continues to hold it on Optimism.

---

The cause of the exploit was a bug in the `burnTokens` function where the token balance of the caller was reduced using ["unchecked" arithmetic](https://docs.soliditylang.org/en/v0.8.24/control-structures.html#checked-or-unchecked-arithmetic) which, in the case of subtraction, does not revert the call when the balance goes below zero. This allowed the drainers to be able to call this function with zero token balance and still receive `rETH` in return.


> Note: A similar bug exists in the `burn` function as well.

## Response

At 2024-07-29 14:23 UTC, a depositor notified the PoolTime team that they were unable to withdraw from the `przWRETH` vault. PoolTime immediately acted and passed this info on to G9 Software, who found the cause of the issue and initiated communication with the Rocket Pool team and PoolTogether community members. Both PoolTime and Cabana immediately pushed updates to the user interfaces to prevent further deposits to the `przWRETH` vault on PoolTogether and initiated communications to affected depositors.

A total of 4.9079 `rETH` (or 5.4576 `wrETH` which is worth about $18k USD at the time of writing) was stolen from the `wrETH` contract. The majority of these funds were from the nine `przWRETH` depositors.

> Note: The exploit was not due to a bug in the PoolTogether code base and was **solely** due to the insecure burning of `wrETH` tokens, which was the deposit token for the `przWRETH` vault. Depositors can currently withdraw their `wrETH` tokens from the `przWRETH` vault, but will be unable to redeem these tokens for `rETH` via Rocket Pool's contract.

## Plan of Action

G9 Software is continuing to discuss the next steps with Rocket Pool.