Possible front running of `flag()`
The `target` might call `unstake()/forceUnstake()` before a flagger calls `flag()` to avoid a possible fund loss. Also, there would be no slash during the unstaking for `target` when it meets the `penaltyPeriodSeconds` requirement.\\n```\\nFile: contracts\\OperatorTokenomics\\SponsorshipPolicies\\VoteKickPolicy.sol\\n    function onFlag(address target, address flagger) external {\\n        require(flagger != target, "error_cannotFlagSelf");\\n        require(voteStartTimestamp[target] == 0 && block.timestamp > protectionEndTimestamp[target], "error_cannotFlagAgain"); // solhint-disable-line not-rely-on-time\\n        require(stakedWei[flagger] >= minimumStakeOf(flagger), "error_notEnoughStake");\\n        require(stakedWei[target] > 0, "error_flagTargetNotStaked"); //@audit possible front run\\n```\\n
There is no straightforward mitigation but we could implement a kind of `delayed unstaking` logic for some percent of staking funds.
A malicious target would bypass the kick policy by front running.
```\\nFile: contracts\\OperatorTokenomics\\SponsorshipPolicies\\VoteKickPolicy.sol\\n    function onFlag(address target, address flagger) external {\\n        require(flagger != target, "error_cannotFlagSelf");\\n        require(voteStartTimestamp[target] == 0 && block.timestamp > protectionEndTimestamp[target], "error_cannotFlagAgain"); // solhint-disable-line not-rely-on-time\\n        require(stakedWei[flagger] >= minimumStakeOf(flagger), "error_notEnoughStake");\\n        require(stakedWei[target] > 0, "error_flagTargetNotStaked"); //@audit possible front run\\n```\\n