Fix Review

The Solidity Unlocked event indexes sender and recipient, but the JavaScript builder ABI declares both parameters as non-indexed. As a result, the ABI does not match the emitted log format and Ethers cannot decode included refund events. Claim generation then fails when the builder processes the undecoded event.

Update the JavaScript Unlocked event ABI to mark sender and recipient as indexed, matching the Solidity event definition.

refundLockedFunds, burn, and recoverFunds are restricted by both onlyOwner and whenNotPaused. If the locker is paused during an emergency, the trusted owner must first unpause it before performing these recovery operations. This unnecessarily reopens the public lock and lockWithPermit entrypoints until the owner pauses the contract again, weakening the pause mechanism as an emergency containment tool and requiring additional transactions.

Consider removing the whenNotPaused modifier from the onlyOwner recovery functions while retaining it on the user-facing locking functions.

refundsEnabled is configured only during initialization and cannot be changed afterward. Consequently, the trusted owner cannot enable or disable the refund path in response to changing operational requirements or an emergency without upgrading or replacing the locker implementation.

Consider adding a setRefundsEnabled(bool) function.

The locker permits the owner to refund a balance from a historical epoch by passing an explicit _epoch to refundLockedFunds. However, once that epoch is closed, getEpochWindow restricts the builder query to epochStartBlock(epoch + 1) - 1. Any later Unlocked event referring to the closed epoch is therefore omitted.

Consider to either prohibit refunds from closed epochs or support them consistently in the builder.

Anyone can transfer PUSH directly to a migration locker without calling lock(). This increases the locker balance without emitting a Locked event. The claim builder requires exact equality between Locked - Unlocked events and the raw balance delta, so even one base unit causes it to abort without generating claims.

A malicious actor can therefore delay claims.

Consider to not treat unexplained surplus PUSH as a fatal reconciliation error. Or to not allow users to freely transfer PUSH tokens into the contract.