- satisfying multiple hard requirements,
- yields low rewards, and
- can be easily and quickly mitigated by project owners.
Full answer:
---
What you describe is actually not possible for a number of reasons.
In order for an attack on a Merge to earn project to have success, an attacker needs to obtain:
- Access as owner / maintainer to the Github repo, and
- The private keys of the wallets of enough safe owners to autonomously execute transactions. The general rule for multisigs is, the higher the quorum, the higher the safety.
In absence of both conditions, project maintainers have plenty of time to get control of the situation, and the attacker couldn't do anything. In fact, even if a Github account is compromised and fake PRs are merged to give themselves fat rewards, nothing happens until multisig owners actually execute the malicious transactions.
But, even though extremely improbable, let's assume an attacker manages to do that and the worst possible scenario happens. What then?
Due to how slicers are designed, the attacker wouldn't be able to get money received until that point out of the slicer, but only what has been received after he gained control. The Slice protocol has been designed to safeguard against these kind of attacks and malicious usage.
On the contrary, to mitigate an attack, project owners just need to reinitialize MTE for their repo with a new slicer and multisig, distribute ownership to contributors as it was before the attack, and redirect any new income and donations to the new slicer. This is technically trivial and can be done in minutes.