Front running protection

[boolafish]

Description

As a trader, I want to prevent my trade to be frontrunned So that I can earn what I should earn and won't lose what I should not lose.

sub story of #53

Successful Criteria

• List out all possible design solutions we have
• Put the chosen solution in doc.

[boolafish]

[NOTE] we basically have a solution for this already. Need to doc it and list our alternatives and potentially ask for review with clear pool to ask some input.

[boolafish]

Listing the front-running research founding in: this doc here

[boolafish]

[Note] Assuming auction is settled in a single price for all market orders and all limit orders, then front-running might not be a concern at all (?) because the priority would be more price based instead of time based. There is really little space for front-running (like inserting an order in front of yours and put if after yours does not really matters)

Statement above sort of blocks this story. All approaches we have on protection are documented.

[boolafish]

[NOTE]

One solution would be to batch buy and sell orders so that there is no front running. instead, all buys and sells over a span of blocks are averaged out and distributed at the same price across the group. This is a repo outlining some code to do just that scenario.

From: https://github.com/okwme/batchedBondingCurves Seems like single price auction is by default without front-running issue.

Updated the frontrunning doc, asides from the previous idea, add another one: Moving "Ordering" Responsibility out of Venue.

My personal take is that it seems hard to prove frontrunning on root chain in general as it needs a replay of all orders (unless black magic like zk-snark comes in...). Even in child chain, do we want to add such burden to operator is quite debatable. But it might be good enough to make misbehavior of venue obvious as we are targeting regulated exchanges and they would lose their business whenever proven misbehaving.