In normal circumstances, consecutive slash amounts will be rolled over. For example, Alice is slashed in round 1. If Alice is slashed again in round 2, the slash amount from round 1 will be rolled over in round 2. See this doc.
However, the above behavior cannot be guaranteed due to a possible permissionless lockAndBurn() racing.
When slash() on round 2 is settled before lockAndBurn(). The doc-described behavior is preserved:
https://github.com/code-423n4/2024-03-gitcoin/blob/6529b351cd72a858541f60c52f0e5ad0fb6f1b16/id-staking-v2/contracts/IdentityStaking.sol#L448
But if lockAndBurn() settles first, the staked amount of sStake.slashedInRound from round 1 will be burned, and the slash amount from round 2 will be counted in round 3 even though the slash() is submitted in round 2.
https://github.com/code-423n4/2024-03-gitcoin/blob/6529b351cd72a858541f60c52f0e5ad0fb6f1b16/id-staking-v2/contracts/IdentityStaking.sol#L455
As seen above, slash() submitted close to the end of a round(90 days burnRoundMinimumDuration), might be counted either at the next round or current round due to potential lockAndBurn racing.  When slash() settles at the next round, the users previous round slash amount will not be rolled over, and the slash amount will be directly burned instead of being preserved for the next round.
Consider having lockAndBurn() access controlled by the protocol to ensure slash() and lockAndBurn() settle in the correct order.
