fix(DepositPool-v2): track off-contract staked principal in reward sync

[moscowchill]

The real fundValidator() path forwards 40k QRL to the beacon deposit
contract, dropping the pool balance by the stake. _syncRewards() compared
balance - withdrawalReserve against totalPooledQRL, so funding a validator
read as a 40k slashing event: the next (permissionless) syncRewards would
collapse the exchange rate, after which a dust deposit could mint a
near-unbounded share count and drain the pool when stake/rewards returned.

• add stakedQRL accumulator, incremented by fundValidator() when principal
  leaves for the beacon contract
• _syncRewards() now reconciles balance + stakedQRL - withdrawalReserve, so
  funding is balance-neutral (fundValidatorMVP keeps stakedQRL at zero)
• add owner-only recordValidatorExit(amount) to settle returned principal so
  it is not double-counted as rewards on the next sync
• emergencyWithdraw() recoverable calc excludes off-contract stakedQRL
• fix stale 0x01 -> 0x00 withdrawal-credentials doc comment
• 8 new regression tests (195 pass total); refresh docs + test counts

Note: live v2.2 pool carries the pre-fix bytecode and has already run a real
fundValidator() — do not call syncRewards() on it until redeployed as v2.3.

https://claude.ai/code/session_017KpTnYNbCJgqAffCktJ6Wc

[gemini-code-assist]

Code Review

This pull request introduces off-contract stake accounting via a new stakedQRL accumulator in DepositPoolV2 (both Solidity and Hyperion versions) to prevent phantom slashing events when funding validators. It also adds the recordValidatorExit function to settle returned principal and updates the test suite with new regression tests. Feedback highlights a critical security vulnerability where validator exit proceeds landing via EIP-4895 can be front-run before recordValidatorExit is called, leading to phantom reward arbitrage. Restricting or decoupling automatic reward syncing is recommended to mitigate this risk.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Critical Security Vulnerability: Front-Running / Phantom Reward Arbitrage during Validator Exits

The Issue

Validator exit proceeds (principal) arrive via EIP-4895 and land in address(this).balance automatically at the start of a block. However, the owner's transaction to call recordValidatorExit() can only be executed during the block execution phase. This creates an exploitable window where the contract balance has increased, but stakedQRL has not yet been decremented.

During this window, any call to _syncRewards() (which is triggered automatically on user actions like requestWithdrawal() and claimWithdrawal(), or permissionlessly via syncRewards()) will calculate:
currentBalance = address(this).balance + stakedQRL

Since address(this).balance is inflated by the returned principal (e.g., 40,000 QRL) and stakedQRL is still at its pre-exit value, currentBalance will be incorrectly inflated by 40,000 QRL. This will be registered as a massive phantom reward, immediately inflating the exchange rate of stQRL (e.g., from 1.0 to 1.8 QRL/share).

Exploit Scenario

1. A validator exits, and 40,000 QRL lands in the pool's balance via EIP-4895.
2. An arbitrageur or user front-runs the owner's recordValidatorExit transaction by calling requestWithdrawal() or claimWithdrawal().
3. The transaction triggers _syncRewards(), inflating the exchange rate.
4. The user's withdrawal is processed at the highly inflated exchange rate, allowing them to drain significantly more QRL from the pool than they are entitled to.
5. When the owner's recordValidatorExit transaction finally executes, stakedQRL is decremented, and the subsequent sync registers a massive phantom slashing, deflating the exchange rate back to normal and leaving the remaining pool participants with a permanent loss of funds.

Recommended Remediation

To completely eliminate this front-running window, you must prevent permissionless or automatic triggering of _syncRewards() during exits:

1. Restrict the external syncRewards() function to onlyOwner.
2. Remove the automatic _syncRewards() calls from requestWithdrawal() and claimWithdrawal().

This ensures that the exchange rate is only updated when the owner explicitly syncs rewards, allowing the owner to safely execute recordValidatorExit and syncRewards in a single transaction or block without any risk of user front-running.

[moscowchill]

Good catch — confirmed and fixed in f4c8d68.

The root cause is exactly as described: exit proceeds land in address(this).balance via EIP-4895 a block before the owner can call recordValidatorExit(), so during that window balance + stakedQRL double-counts the principal and an unrestricted sync books it as a phantom reward. Because requestWithdrawal() snapshots the QRL value at request time, a front-runner could lock the inflated rate in and drain the pool when it corrects.

Rather than make sync owner-only unconditionally (which would remove the trustless permissionless sync even on the MVP path where it's provably safe), the fix gates it precisely on where the ambiguity exists:

• New _permissionlessSyncAllowed() ⇒ stakedQRL == 0. While all principal is on-contract, balance − withdrawalReserve is exactly the pooled total, so sync stays trustless and permissionless (MVP/testnet path unchanged).
• Once principal is off-contract (stakedQRL > 0), syncRewards() reverts NotOwner for non-owner callers, and the implicit sync inside requestWithdrawal/claimWithdrawal is skipped. Both withdrawal functions already pay out the request-time snapshot, so their behavior is otherwise unchanged. The operator now sequences recordValidatorExit() + syncRewards() so settlement and reward recognition can't be front-run.

Added a PHANTOM-REWARD FRONT-RUN PROTECTION test block (5 tests) covering: permissionless-when-unstaked, owner-only-while-staked, front-run blocked during exit (the exploit path), permissionless resumes after settlement, and owner still recognizing genuine rewards while staked. Suite now 200.

One caveat: the contract compiles clean with solc 0.8.34, but forge binaries aren't reachable from the environment I ran in, so I wasn't able to execute the Foundry suite here — please confirm forge test is green locally before merge.

---

Generated by Claude Code