The Current State and Future of MEV on Sui

MEV (Maximum Extractable Value) has become an important topic in the blockchain industry due to its implications for transaction ordering and arbitrage opportunities. To ensure transparency, protect transactions, maintain network health, and reward participants, we have been implementing targeted Sui Improvement Proposals (SIPs) and other mechanisms to guide MEV on Sui.

In addition to existing mechanisms, we plan to establish further mechanisms to ensure our core principles guide the evolution of MEV on Sui.

Design Principles and Considerations

Every transaction on Sui introduces new information and potential profit opportunities. The MEV ecosystem on Sui is shaped through several mechanisms:

• Mechanisms for submitting MEV transactions

• Mechanisms for publishing MEV opportunities

• Mechanisms for distributing MEV revenue

• Mechanisms for protecting user transactions

Our overall priorities are as follows:

• User transaction protection is more important than the amount of value extracted. Prioritize smaller slippage over larger extracted value. Avoid off-protocol auctions that increase latency and offer no exit options.

• Network transparency is preferred over off-chain transactions with validators or relayers.

• Promote competition through priority gas auctions (PGA) to discourage spamming behaviors that lead to system inefficiency: Our ideal outcome is for searchers' dominant strategy to be sending a single transaction whose priority fee is determined by the value extracted.

• Encourage reward distribution to participants aligned with the ecosystem: validators, stakers, applications, and users.

Transaction Submission

Since transactions modifying the same object execute sequentially, clients compete to improve their execution order. From a system perspective, PGA is an efficient resource allocation method that prevents spam while redistributing gas fees among participants.

The key driver behind priority gas auctions is quantification of execution:

• Transactions ordered by consensus are processed within blocks. Traders compete via gas auctions for priority, both within internal competition and across different submissions.

• This differs from CEX market makers, where execution priority is entirely speed-dependent, achieved through low-latency networks and algorithms.

• Higher consensus submission rates reduce quantification effects, making DEX execution more efficient but also narrowing the PGA window.

• Currently, PGA matters most for the fastest searchers on non-congested objects. At Sui's rate of 15 submissions per second, a 70-millisecond advantage in transaction submission speed could determine whether a transaction settles.

• Congested objects may delay transaction execution, further amplifying the importance of PGA, as the competitive window for transactions could be up to 10 times longer than regular consensus submission intervals.

Two mechanisms can direct transactions toward specific upcoming Sui submissions:

1 Submitting a bundle of transactions via soft bundling: SIP-19

🌟 SIP-19: https://github.com/sui-foundation/sips/blob/main/sips/sip-19.md

• Transactions submitted via soft bundling have a high probability of being included in the same consensus submission together with a valid bundle. Bundle validity requires all transactions to have the same gas price.

• In practice, this mechanism enables off-chain auctions for original and follow-up transactions, such as those operated by Shio (https://www.getshio.com/explorer).

2 Amplifying priority transactions through consensus: SIP-45

🌟 SIP-45: https://github.com/sui-foundation/sips/blob/main/sips/sip-45.md

• SIP-45 addresses potential jitter issues in consensus submissions, preventing lower gas-priced transactions submitted at the same time from being ranked after higher gas-priced ones.

• Two natural sources of jitter in consensus submissions: (1) The submitting validator lags behind by several consensus rounds: transactions submitted by another validator might be ordered first. (2) The leader of a consensus round has an advantage over other validators in submission timing.

• SIP-45 enhances consensus submission by amplifying gas prices above k x RGP (k is a system parameter currently set to 5, RGP is the reference gas price). A transaction with a gas price of n x RGP will be amplified by a factor of n.

• Widespread adoption of SIP-45 will create a more efficient and fair competitive system. Note that SIP-45 does not change the fundamental properties of the system from the client’s perspective: it suppresses spam by providing a more efficient alternative.

Selecting the Appropriate Transaction Gas Price

Clients should consider the following key factors when determining the gas price for submitting transactions:

1 Priority Gas Auction

Within a consensus submission, transactions modifying the same object are ordered by gas price, offering searchers a fair chance to compete.

2 Consensus Submission Amplification

As described above, transactions with gas prices exceeding 5 x RGP are amplified through n validators’ submission into consensus. Any gas price above the amplification threshold reduces inefficient submission jitter. In practice, an amplification factor of 5 is sufficient to eliminate jitter, while a gas price of 100 x RGP will highly likely unlock the next round’s leader submission.

3 Avoiding Congestion Delays and Cancellations

Sui limits wall-clock time for checkpoint execution by controlling the rate of transactions modifying the same shared object. Transactions modifying congested objects are ordered by gas price; lower-priced transactions are delayed and eventually canceled to limit the maximum sequential execution chain per checkpoint—a mechanism known as object-based local fee markets. (Note: While gas prices may spike when shared objects present high arbitrage opportunities, other parts of the system remain unaffected.)

Full nodes track the gas prices of executed and canceled transactions, especially those involving modifications to congested objects. By analyzing transaction dry-run results, clients can obtain the gas prices of the lowest-priced executed transaction and the highest-priced canceled transaction. Using this information, clients can determine the required gas price to highly avoid transaction delays. (Note: This feature is currently only partially implemented and is expected to be released as part of the SDK within the next two months.)

Disseminating Transaction Information

Every transaction on Sui introduces potential profit opportunities. Consider the lifecycle of a shared object transaction, from client submission to third-party observation of its effects.

1. Client submits transaction: The client submits the transaction to an RPC full node (typically selected by the application).

2. RPC node broadcasts transaction: The RPC node broadcasts the transaction to validators, who validate its correctness and sign it. The RPC node assembles the transaction certificate from collective validator signatures.

3. RPC node broadcasts transaction certificate: The RPC node broadcasts the transaction certificate to validators.

4. Validator submits transaction: A deterministically selected validator submits the transaction to consensus. Mysticeti consensus broadcasts blocks among validators, and within 3 consensus rounds, the block containing the transaction will be committed. Transaction execution: The transaction is executed on each validator.

5. Execution effect certificate sent back to RPC node and client: The certificate of post-execution effects is returned to the RPC node and client.

6. Checkpoint generation: Within 1 to 3 consensus rounds, each validator forms and signs a checkpoint (a batch of multiple consensus submissions).

7. Checkpoint signature broadcast: Checkpoint signatures are broadcast among validators, and each validator forms a checkpoint certificate.

8. State synchronization protocol propagates checkpoints: The state synchronization protocol is responsible for disseminating authenticated checkpoints via peer-to-peer connections. Typically, each validator has a direct peer node that does not provide RPC services—a state sync full node—that receives checkpoints from the validator.

9. Third-party nodes download checkpoints: Third-party full nodes connected to state sync full nodes receive checkpoints and download their contents. At this point, we assume third parties directly connected to full nodes can post-process transaction effects and respond accordingly.

Transaction Information Dissemination Before Submission

As mentioned earlier, Sui has off-chain auction systems for submitting soft bundles under SIP-19. These auctions intercept transaction submissions through off-chain agreements between applications and auction systems (e.g., Shio).

This information dissemination assumes the auction system behaves well and protects user transactions from potential frontrunning attacks. Shio is incentivized to protect user transactions to sustain its business and thus employs certain auction techniques (decoy transactions, random delays) to weaken the financial gains of potential sandwich bots.

Clearly, this information flow occurs outside Sui (between applications and auctions), represents a voluntary choice by applications and users, provides only speculative information, and cannot guarantee the success of the original user transaction.

Consensus Block Streaming

To enable low-latency access to user transactions, we are designing a system to directly stream consensus blocks. In general, full nodes will be able to directly subscribe to consensus blocks.

Through this method, full nodes can speculatively notify transactions that are highly likely to be committed. The network topology uses a standard open state sync peer discovery protocol.

This speculative notification could significantly reduce transaction propagation latency to approximately 160 milliseconds (2 consensus rounds), right after validator submission.

The consensus block streaming project is currently in the design phase and is expected to release a SIP within the next 1–2 months.

Protecting User Transactions

User transactions need protection against frontrunning, sandwiching, and involuntary submission delays.

External Membership Driving

Sui transaction submission requires external membership driving, typically performed by full nodes.

If a validator receives a request to submit transaction t and wishes to initiate a new transaction t', it will lag behind the original membership driver during certificate assembly. Unless the submitting full node has poor connectivity with Sui members, the validator will fall behind t in the certificate assembly process for t'.

Moreover, since t’s consensus submission is decentralized, once t’s certificate reaches consensus, it cannot be reliably delayed. Therefore, if t’s certificate reaches Sui consensus before t’, t will settle with high probability before t’.

Thus, external membership driving provides natural frontrun protection, assuming trust in the full node responsible for transaction submission (since frontrun attacks can be easily detected on-chain, such attacks would be logged by clients and damage the RPC operator’s reputation).

Mysticeti Fast Path

We are currently working on a project to change transaction submission to the fast path protocol described in the Mysticeti paper. Under this protocol, user transactions can be submitted to a single validator, which will use Mysticeti to collect and execute transaction certificates. While this greatly improves system efficiency, it also creates opportunities for validators to frontrun user transactions.

🌟 Mysticeti Paper: https://arxiv.org/abs/2310.14821

This risk is purely theoretical, as there is currently no evidence of frontrunning attacks occurring on Sui. In the new system, the possibility of frontrunning increases, but on the other hand, accountability becomes easier due to deterministic knowledge of which validator received the submission.

Evolution of MEV on Sui

The MEV ecosystem on Sui is still forming, with new mechanisms expected later this year. Currently, priority gas auctions and consensus amplification define the system, while upcoming innovations such as time-lock encryption and the Mysticeti fast path will reshape transaction execution and security. As these mechanisms go live, MEV on Sui will continue to evolve, creating a more dynamic and transparent ecosystem.