Preventing frontrunning and protecting users from MEV

There’s a concept in DeFi called “Miner Extractable Value” aka MEV. This is where miners are able to see transactions while they are still unconfirmed in the mempool and then frontrun those transactions to realize their value potential. I’d like to open a discussion about how we can prevent this issue on the rollup that Sovryn will be migrating to.

There’s a technique called threshold encryption that can be used to protect users from MEV so long as the rollup has multiple independent operators producing rollup blocks. You can learn about this threshold encryption technique here:


Hey @light

In our rollup, we would be implementing a timestamp based transaction batching to be executed. Thus avoiding the front running problem.

In layman’s term, it will be sequential execution of transaction, rather than one based on the gas provided.

And we will have our own node(s) to validate these transactions.

More detailed content could be given by David who is currently working on this.

Thanks for the info! Couldn’t the rollup validator still frontrun the user, for example by replacing their transaction with another transaction with the same sequence number, and then forcing the user to re-submit their transaction with a higher sequence number?

the way that it works in sovryn-rollup is aggregation is permissionless and anyone can run an aggregator. Indeed the only benefit of posting your transaction through an aggregator rather than sending it to the L1 yourself is to amortize the fixed costs (e.g. Ethereum has a 21,000 base gas cost per transaction but rolup transactions are generally in the 2,000 gas range, so by batching you can reduce the overhead).

The sovryn sequencer is a privileged aggregator that can guarantee the ordering of its transactions and thus has the ability to put them ahead in line (in a short time window) of other aggregators’ transactions. So it can slow things down but not censor as anyone can post a transaction on chain that will be included.
Fair ordering protocols come in very useful for distributing the sequencer and making sure the sequencer cannot frontrun/reorder/extract MEV.
The initial sequencer will be run by us. So there won’t be frontrunning since we won’t do that but fair-ordering BFT gives you that guarantee without having to trust us at all.

We don’t love the idea that the sequencer can reorder transactions and extract MEV and we will therefore distribute the sequencer and use a fair-ordering BFT to ensure that the Sequencer does not re-order transactions.

Thanks for the info David! Would love to learn more about fair-ordering BFT once you have more info to share :slight_smile:

Sovryn rollup can support two different modes

a) Privileged sequencer
b) Fully decentralized transaction ordering

There are significant tradeoffs between these two modes. With the sequencer mode instant confirmations allow for rapid user interfaces and oracle updates which make a large number of new use cases possible, but a central party exists that can frontrun and delay transactions. In the fully decentralized model, transactions are simply ordered by the L1

As of now ,we don’t have sequencer enabled in the chain .It mean aggregator will not be front run user tx because now it gonna execute transaction sequentially .
Here you can read about fair-ordering BFT Sequncer Fair Sequencing Services: Enabling a Provably Fair DeFi Ecosystem and this paper

1 Like