Mystic Finance Liquid Staking Security Review — May 2026

Description

Commit 75fe19a adds an active gate to the batch-unstake path in order to avoid calling plumeStaking.unstake() for slashed validators. However, the same change also blocks queued withdrawal processing for validators that are merely inactive but not slashed. This matters because the upstream Plume staking layer distinguishes inactive from slashed: • slashed validators are blocked for unstake operations • validators that are only inactive are not slashed, and their stake remains recoverable As a result, if users already have queued withdrawals on a validator and that validator is later deactivated, the queue can stop progressing even though the underlying Plume layer would still permit unstaking.

Root cause The PR uses getValidatorStats(...).active as a proxy for “safe to process queued exits”. That proxy is too strict. For queued withdrawal liveness, the important condition is whether the validator is slashed, not whether it is currently active.

Relevant code The regression is centered in two places inside src/stPlumeMinter.sol. First, processBatchUnstake() now skips any validator whose active flag is false: function processBatchUnstake () external { uint numVals = numValidators (); uint256 index = 0; while (index < numVals) { uint16 validatorId = uint16(validators[index ]. validatorId); (bool active ,,,) = plumeStaking. getValidatorStats (validatorId); if (active && ( totalQueuedWithdrawalsPerValidator [validatorId] >= withdrawalQueueThreshold || block.timestamp >= nextBatchUnstakeTimePerValidator [validatorId ])) { _processBatchUnstake (validatorId); } index ++; } } Second, unstakeGov() uses the same active dependency, so governance cannot use it to flush the stuck queue while the validator remains inactive: function unstakeGov(uint16 validatorId , uint256 amount) external nonReentrant onlyByOwnGov returns (uint256 amountRestaked) { _rebalance (); (bool active , ,uint256 stakedAmount ,) = plumeStaking. getValidatorStats (uint16( validatorId)); uint256 queued = totalQueuedWithdrawalsPerValidator [validatorId ]; uint256 total = amount + queued;

if (active && stakedAmount > 0 && stakedAmount >= total) { amountRestaked = plumeStaking.unstake(uint16(validatorId), total); totalQueuedWithdrawalsPerValidator [validatorId] = 0; nextBatchUnstakeTimePerValidator [validatorId] = block.timestamp + batchUnstakeInterval ; } }

Attack / failure scenario 1. Users queue standard withdrawals against validator V. 2. Before the queued amount is processed, governance deactivates V without slashing it. 3. totalQueuedWithdrawalsPerValidator[V] remains non-zero. 4. processBatchUnstake() skips V because active == false. 5. unstakeGov() also cannot flush the queue because it is gated on the same active condition. 6. Pending withdrawals remain stuck until governance re-activates V.

Impact

This is a withdrawal liveness issue. Affected users can be left waiting indefinitely for governance intervention even though the stake is not slashed and should still be recoverable.

Description

When a user unstake request triggers processBatchUnstake, the contract updates nextBatchUnstakeTimePerValidator[validatorId] to block.timestamp + batchUnstakeInte before computing the user’s cooldown timestamp. unstake then derives request.timestamp from this updated “next batch schedule” value instead of the actual unstake initiation time. This introduces an unintended extra delay of batchUnstakeInterval to user withdrawals.

Root cause The cooldown timestamp is derived from nextBatchUnstakeTimePerValidator after processBatchUnstake mutates it for scheduling future batches. Expected source for user cooldown: actual unstake initiation time (current transaction execution time). Actual source used: next scheduled batch time.

Technical details In unstake (single-validator branch): • Queue is increased. • If threshold/time condition is met, processBatchUnstake is called. • processBatchUnstake sets nextBatchUnstakeTimePerValidator = block.timestamp + batchUnstakeInterval. • cooldownTimestamp is set to plumeStaking.getCooldownInterval() + nextBatchUnstake

Result cooldown becomes now + batchUnstakeInterval + externalCooldown. In unstake (multi-validator branch): The same pattern is repeated per validator, and cooldownTimestamp takes the maximum end time, where each end time uses the already-forwarded nextBatchUnstakeTimePerValidat

Result same unintended extra delay across all affected validators.

Why this is incorrect nextBatchUnstakeTimePerValidator is a scheduling variable for future batch execution, not a record of when unstake was actually executed. Using it as the basis for withdrawal cooldown conflates “next batch slot scheduling” with “actual unstake execution time”.

POC Assume cooldownInterval = C and batchUnstakeInterval = B. At time T: • User submits unstake and triggers processBatchUnstake. • External cooldown should end at T + C. • Contract stores request.timestamp = C + (T + B) = T + B + C. • withdraw() enforces block.timestamp >= request.timestamp.

Result user is forced to wait an additional B time.

Impact

Users whose unstake requests trigger batch execution must wait approximately batchUnstakeInter longer than intended by the underlying staking cooldown. With defaults (batchUnstakeInterval = 21 days + 1 hour), this becomes a material lockup extension that significantly delays withdrawals and degrades protocol UX and trust.

Recommendation

Do not derive request cooldown from nextBatchUnstakeTimePerValidator. Instead, derive cooldown from actual batch unstake execution time (e.g. block.timestamp at processBatchUnstake) or maintain a separate lastBatchUnstakeTimePerValidator updated only on execution. Keep nextBatchUnstakeTimePerValidator strictly for scheduling logic.