Mystic Finance Liquid Staking Security Review — December 2025

Description

In the auto-distribution path of _depositEther, the contract decides whether a validator can be used by calling getNextValidator(remainingAmount, validatorId) with the full remainingAmount: while (remainingAmount > 0 && index < numVals) { uint256 depositSize = remainingAmount; _validatorId = uint16(validators[index].validatorId); (uint256 validatorId, uint256 capacity) = getNextValidator(remainingAmount, _validatorId); if (capacity > 0 && capacity >= minStakeAmount) { if (capacity < depositSize) { depositSize = capacity; } if (depositSize < minStakeAmount) { currentWithheldETH += remainingAmount; return depositedAmount; } plumeStaking.stake{value: depositSize}(uint16(validatorId)); remainingAmount -= depositSize; depositedAmount += depositSize; emit DepositSent(uint16(validatorId)); } index++; }

Inside getNextValidator, the validator’s new percentage is computed using depositAmount equal to that full remainingAmount: function getNextValidator(uint256 depositAmount, uint16 validatorId) internal view returns (uint256 validatorId_, uint256 capacity_) { (bool active, , uint256 stakedAmount, ) = plumeStaking.getValidatorStats( validatorId); uint256 totalStaked = plumeStaking.totalAmountStaked(); if (!active) return (validatorId, 0); (, capacity_) = _getValidatorInfo(validatorId); uint256 percentage = ((stakedAmount + depositAmount) * RATIO_PRECISION) / (totalStaked + depositAmount); if (maxValidatorPercentage[validatorId] > 0 && percentage > maxValidatorPercentage[validatorId]) { return (validatorId, 0); // validator is skipped entirely } if (capacity_ > 0) { return (validatorId, capacity_); } return (validatorId, 0); } The critical line is: if (maxValidatorPercentage[validatorId] > 0 && percentage > maxValidatorPercentage[ validatorId]) { return (validatorId, 0); } If sending the entire remainingAmount would push a validator above its maxValidatorPercentage, getNextValidator returns a capacity of 0, and _depositEther skips that validator completely. However, _depositEther later caps depositSize to capacity only if capacity > 0, so this partial capping never happens for validators that are rejected at the percentage check. This means that if a validator still has some allowed headroom under both capacity and maxpercentage, but not enough to take the full remainingAmount, the contract refuses to use it at all. It does not attempt a partial deposit that would keep the validator within limits. For example, a validator with max capacity 10 ETH and current stake 8 ETH still has 2 ETH of safe room. IfremainingAmount is5ETH,thepercentageiscalculatedasif5ETHweregoingtothisvalidator. Ifthat hypothetical 5 ETH would violate the max percentage, the validator is excluded, even though putting just 2 ETH there would be perfectly valid. As a result, those 2 ETH are never used for this validator; the loop just moves to the next one with the full 5 ETH still in remainingAmount. Validators that still have valid headroom (for example, 1–2 ETH) can be skipped entirely if the full remainingAmount would break the percentage limit.

This leads to under-utilization of individual validator capacities and reduces how evenly stake is spread, since the allocator refuses to use small remaining slots on validators that are close to their limit. In practice, more ETH may end up routed to fewer validators.

Description

The restake() function can reuse funds that users have already unstaked and are waitingtowithdraw. Whenuserscallunstake(), theirETHenterscooling/parkedstateunderthecontract, but restake() does not check whether those funds are already committed to pending withdrawal requests. It simply calls: plumeStaking.restake(validatorId, amount); and consumes whatever cooling balance exists. This allows the rebalancer to restake ETH that users are expecting to withdraw after their cooldown period. If this happens, users may reach the end of their cooldown and find that their withdrawal cannot be fulfilled because their cooled funds were re-staked before they could withdraw them. This can lead to temporary withdrawal delays or failed withdrawals until the protocol unstake cycle produces new cooled funds again.

Resolution

Acknowledged 4.3 Informational