Rebase sandwich attack protection

[mz7mz7mz7]

As documented in point 1 of other rebase token, with similar design to ours: https://forum.ampleforth.org/t/technical-implementation-of-the-rebase-operation/578#h-1-a-user-initiates-the-rebase-operation-3 Shall we do the same restriction on who can trigger rebase? @Tunji17 , @haidarally

[haidarally]

@mz7mz7mz7

I think we are already covered As the executeRebase method, requires the signature of the params to match ours, so we control the data and therefore, it doesnot matter if someone is spamming the method with wrongly signed encoded values

However we can consider adding the restriction as well for extra security

[mz7mz7mz7]

I don't think this is what the sandwich attack is about ( https://medium.com/coinmonks/defi-sandwich-attack-explain-776f6f43b2fd ). Wrongly signed data would be clearly rejected, so that's not the issue. I suspect there might be some issue with miners reordering our rebase transaction and sandwiching/wrapping it with their own two transactions, before and after the rebase. Let's pause and think if we can find there some issues.

[haidarally]

My initial understanding is that

• Nothing much we can do to protect endusers from the front running. It's out of our control
• For our protocol, By making use of the Orchestrator, we already have some sort of MEV protection whenever we rebase and do rebase related operations.