alt: alternative payValidatorWithdraw to account for slashing

[sandybradley]

Raising this PR as an alternative process for payValidatorWithdraw as a result of kebabsec audit. The issue at hand is accounting for slashing in the best way. Our current options are:

• Account for slashing by reducing rewards payouts correspondingly. Advantage of this is that accounting for validator exits is simplified and there are less attack and mistake vectors. The risk is that in the event net slashing exceeds net rewards, accounting for slashing is impossible unless rewards come back above slashing or the slashing is subsidized. This is the current setup. To leave as is (by closing this PR).
• Account for slashing in payValidatorWithdraw directly (this PR). Advantage of this is that it can handle above scenario but requires sandwich protection and requires operator does not call invalid amounts by mistake

@sambacha @ControlCplusControlV @mevpig @mevr2 @aldoborrero Votes / thoughts appreciated

[sambacha]

The way the infrastructure is implemented, we should never have a slashing event: we would go offline first.

We should use this as a chance to specify how FOLD can be used to protect in this case via a per-rata charge against a FOLD single asset staking vault. We can cover the losses, and this incentive aligns Manifold with running the validator set safely in exchange for 20bps (as an example rate) for this 'insurance'[^1]

[^1]: Legally, this is NOT insurance. It is in a sense a risk-free rate of return if the statement about 'never having a slashing event' holds true.

[sandybradley]

@sambacha this is your call at the end of the day. I'm not familiar enough with the operational risks associated with slashing but aren't validators slashed a little for going offline too?

If you are happy this event should not occur or that it can be mitigated, this PR can be safely closed without merging.

[ControlCplusControlV]

Given my understanding of slashing, and the above comments by @sambacha,

Raising this PR as an alternative process for payValidatorWithdraw as a result of kebabsec audit. The issue at hand is accounting for slashing in the best way. Our current options are:

Account for slashing by reducing rewards payouts correspondingly. Advantage of this is that accounting for validator exits is simplified and there are less attack and mistake vectors. The risk is that in the event net slashing exceeds net rewards, accounting for slashing is impossible unless rewards come back above slashing or the slashing is subsidized. This is the current setup. To leave as is (by closing this PR). Account for slashing in payValidatorWithdraw directly (this PR). Advantage of this is that it can handle above scenario but requires sandwich protection and requires operator does not call invalid amounts by mistake

Account for slashing by reducing rewards payouts correspondingly seems to be the best option, as we will incur an activity leak yes, but the idea that it would be greater than all rewards gets less likely by the day, so assuming a smooth launch all is well. I am more concerned about the operation risks of an incorrect value by an operator, and failing sandwich protection, than I am in our the chance that we get slashed for than we can reasonably compensate and offset with income, and in that latter case something catastrophic has already happened