Between 2021 and August 2025, Solana, Ethereum, Arbitrum, and Base have captured ~4.4 billion USD in priority fees. Value capture and expressivity (or the lack thereof) are the most cited reasons for successful applications transitioning to appchains. Fortunately, there are no constraints that prevent applications from enjoying both (and still benefiting from composability) on a general-purpose blockchain. MEV Internalization and Application-Controlled Sequencing (ACS) are the paths to getting there, and we’ve made changes on Eclipse that enable app builders to implement both today with simple additions to their codebases.

Key Takeaways

• App developers can permissionlessly capture the MEV/priority fees generated by their apps.
• Using the same technology, apps can piggyback off Eclipse’s priority ordering and permissionlessly enforce their sequencing rules.
• Priority ordering makes all of this possible, no TEE necessary.
• It is live today, and the demos can be integrated into any program and deployed on Eclipse or any other SVM environment.
• The CU costs for integrating MEV Internalization and ACS are less than 400, which is ridiculously cheap for DeFi applications.

Important Definitions

• priority-fee/tip/gas-price/priority-fee-per-cu: The value per unit of resource, paid as priority-fee. If a transaction uses 100 gas and pays a fee of 100 ETH, it has a priority of 1 ETH per gas. Another transaction that uses 25 gas and pays 50 ETH has a priority of 2 ETH per gas. Ceteris paribus, the higher priority transaction is considered better.
  
  
• performance-based sequencing: Ordering transactions to maximize throughput (and minimize latency).

Priority Ordering, MEV Internalization, and Application Controlled Sequencing (ACS)

Priority Ordering

Priority ordering dictates that the block producer (L1/L2) orders transactions strictly in descending gas-price-time order, i.e., order by gas price, then tie-break based on time received.
The advantage of this ordering scheme is that it is fair, and revenue (read MEV) internalizing because competition for blockspace (and MEV) becomes a gas-price auction, i.e., searchers compete for MEV by increasing gas price, usually in the form of a priority fee or tip^[1]. 

Additionally, with perfect resource metering, priority ordering is equivalent to performance-based sequencing, which is the gold standard for utilitarian^[2] blockchains. Consequently, priority ordering is the default scheme for most blockchains, but with different levels of success depending on the size and permissioning of the validator set.

Application MEV Internalization

The MEV generated by a piece of state should be captured by the piece of state. The long-term tradition of searchers/validators capturing MEV is rent-seeking behavior, and MEV internalization is its antithesis.

The core idea underpinning most approaches to MEV internalization is that in an efficient block-space auction (price-time priority ordering with at least two rational, independent participants), the value of MEV is equal to the priority fee that the winning bid pays to capture it.

This is logical in that if there is competition, rational searchers are willing to pay up to the value of the MEV opportunity, less some epsilon, to capture the MEV. There’s empirical backing too, clearest on Ethereum, where the top MEV bot (jaredfromsubway.eth) pays 90+% of the MEV in tips to builders.

Extending from there, since you can measure the MEV and capture it (via a gas-price auction), you can return it to the state that generated it. The seminal paper on MEV Internalization, Priority Is All You Need (Dan Robinson and Dave White, 2024), describes a permissionless method of MEV Internalization called MEV Taxes.

MEV Taxes

In the MEV tax approach to MEV Internalization, application software (smart contracts) imposes a “tax” on the caller that is a function of the priority fee paid. For example, an AMM contract could require that anyone executing a swap transaction must pay 99.9 times the priority fee of the transaction set to the app. This has the effect of internalizing MEV by forcing searchers to lower the priority fee paid to the platform, and instead pay the value of the MEV to the app!

For example, if there is MEV worth 100 ETH, a rational searcher will pay up to 99.999 ETH to capture it. In the status quo, this fee is paid as a priority fee to the block producer, but in the MEV tax example above, the winning searcher would set a priority fee of 0.991 ETH; the app captures the remaining ~99 ETH as MEV tax!

‍

The general equation that relates Priority fees, MEV taxes, and MEV is $x + yx = k$

• where $x$ is the priority fee paid to the network,
• $y$ is the MEV tax 
• $yx$ is the value captured by the app and,
• $k$ is the MEV

‍

Solving for $x$ gives: $x = \frac{k}{1+y}$

It’s easy to see that by varying the MEV tax (y), the platform captures more or less of the available MEV(x), respectively, and the app internalizes the difference (yx).
This is visualized in Figures 1 and 2 below:

‍

‍

‍

The key insight is that as the MEV Tax (y) increases, the platform’s share of MEV (x) asymptotically approaches 0^[3].

MEV Taxes are a simple, permissionless approach to MEV internalization, and it only requires that the sequencer commit to priority ordering.

Application Controlled Sequencing (ACS)

Currently, the block producer (L1/L2) is responsible for ordering transactions, but some applications are only possible/efficient if they control sequencing. To that end, there are a number of approaches, most of which we go over here. A less-known approach is for the application to enforce sequencing by piggybacking off the infra-layer’s sequencing, specifically, priority ordering sequencing.

If app developers know that transactions will always be ordered by gas price, they can define a gas price range for each code path in the smart contract and error when executing transactions with gas prices outside the predefined ranges for that code path.

A simple example is, say a CLOB smart contract wants to always sequence cancels before takes, it can set a maximum_gas_price_for_takes to be 0.01 SOL. Any transaction attempting to perform a take with a gas price outside this range will fail. This forces takers to set their gas prices to a value less than or equal to 0.01 SOL. And makers wishing to be sequenced before takers can set their priority fee higher. A block producer or sequencer following the priority ordering scheme will execute transactions normally, but the app has enforced its desired sequence!

Importantly, there is no loss in composability even with full control over sequencing. The application becomes less flexible, but can still be called the same by other programs, and the execution will succeed if they follow the application’s rules.

Before priority ordering ACS, composability and ACS seemed to be opposed. In Figure 3, they are visualized as opposing ends of a spectrum, but the priority ordering approach allows full control over sequencing with little to no loss in composability.

‍

‍

In a nutshell, the priority ordering ACS is permissionless, requires no additional infrastructure, and is fully composable with other applications on the chain!

The Interplay between ACS and MEV Taxes

MEV Taxes and ACS can be combined for even better results. For example, app developers can set very low priority fees for their ACS implementations and capture most of the MEV with MEV Taxes. The possibilities are endless!

Individually, they’re great, but combining ACS and MEV taxes greatly enlarges the design surface area and unlocks unprecedented customizability and value capture for application developers!

Code Demo

In this repository, there is an SVM program that implements these three functions:

1. Read and log priority fee
2. Enforce sequencing
3. Internalize MEV

The meat of the contract is the `read_priority_fee` function that reads the priority fee of the currently executing transaction:

pub fn read_priority_fee(instructions_sysvar_account: &AccountInfo) -> 
    Result<Option<u64>, ProgramError> {
    let instructions = Instructions::try_from(instructions_sysvar_account)?;
    let num_instructions = instructions.num_instructions();

    for i in 0..num_instructions {
        // The unsafe `deserialize_instruction_unchecked` method can be used
        // here because of the implicit bounds check performed above but I'll
        // keep it safe for the purpose of this demo.
        let instruction = instructions.load_instruction_at(i as usize)?;
        let program_id = instruction.get_program_id();

        if COMPUTE_BUDGET_PROGRAM_ID.as_array() == program_id {
            let instruction_data = instruction.get_instruction_data();
            if instruction_data.is_empty() {
                continue;
            }
            if instruction_data[0] == SET_COMPUTE_UNIT_PRICE
                && instruction_data.len() >= 9 {
                return Ok(Some(u64::from_le_bytes([
                    instruction_data[1],
                    instruction_data[2],
                    instruction_data[3],
                    instruction_data[4],
                    instruction_data[5],
                    instruction_data[6],
                    instruction_data[7],
                    instruction_data[8],
                ])));
            }
        }
    }
    Ok(None)
}

‍

The operation is fairly simple:

• Load each instruction
  
  • Check if the program ID of the instruction is the Compute Budget Program
  • If yes:
    
    • Check if the specific instruction is SET_COMPUTE_UNIT_PRICE
    • If yes:
      
      • Read the compute unit price (priority fee)
    • If no:
      
      • Continue the loop.
  • If no:
    
    • Continue the loop.

Extending this to ACS and MEV Internalization is simple.

• For ACS, it is as simple as comparing the transaction priority fee to a constant:

if let Some(priority) = micro_lamports_per_cu {
                if priority > Self::PRIORITY_FOR_INSTRUCTION {
                    return Err(
                        MEVAndACSDemoError::PriorityForInstructionTooHigh.into()
                    )
                }
            }

‍

• For MEV Internalization, the contract checks the transaction for an instruction that transfers MEV Tax * Priority Fee to a predetermined vault account.:

let supposed_payment_instruction = 
                    instructions.load_instruction_at(
                        current_index as usize + 1,
                    )?;
let instruction_data = supposed_payment_instruction
    .get_instruction_data();

let transfer_amount = u64::from_le_bytes([
                    instruction_data[4],
                    instruction_data[5],
                    instruction_data[6],
                    instruction_data[7],
                    instruction_data[8],
                    instruction_data[9],
                    instruction_data[10],
                    instruction_data[11],
                ]);

let expected_mev_tax_lamports = priority
.saturating_div(LAMPORT_TO_MICRO_LAMPORTS)
       .saturating_mul(Self::MEV_TAX);

if transfer_amount != expected_mev_tax_lamports {
return Err(MEVAndACSDemoError::IncorrectMEVTaxAmount.into());
                }

let to_account_key = supposed_payment_instruction.get_account_meta_at(1)?.key;
if to_account_key != *self.accounts.vault.key() && 
to_account_key != Self::VAULT_PUBKEY {
       return Err(
       	MEVAndACSDemoError::IncorrectMEVTaxRecipient
              .into()
        );
}

‍

If all the parameters match, then the rest of the code can execute; else, the program errors.

CU Costs

Reading the priority fee costs less than 170 CUs, and extending this to ACS only adds a few more CUs for the comparison. MEV Internalization is the most expensive operation, costing around 400 CUs. 

‍

‍

The CU costs are inconsequential for DeFi apps, which often require tens of thousands of CUs per transaction, e.g., a single swap on Raydium costs over 100k CUs; however, we’re working on reducing them even further!

Addressing the “Limitations” of Priority Ordering

Priority ordering has some limitations; we’ll highlight and break down the most important:

Trusting the Ordering and the Usefulness of TEEs

The most important hurdle to implementing priority ordering on any chain is enforcing it.

At first glance, it seems trivial to enforce as part of the protocol—the list of transactions, which is publicly published, can be checked for foul play. However, a malicious validator can censor transactions that outbid it and pay a very low priority fee (and subsequently MEV tax) without violating the ordering rule.

This has led to the adoption of TEEs in block-building. However, the efficacy of TEEs for this purpose is questionable because of the “man-in-the-middle” attack. TEEs can prove that the block building program in the enclave is the specified one, but there is no way to prove that the information entering the TEE has not been tampered with. So a malicious block builder only has to censor transactions before they enter the TEE, which is trivial.

This problem is VM/layer agnostic and is arguably worse on L1s since there are many parties with less incentive to play nice. There are a number of proposed solutions, from Multiple Concurrent Leaders (MCL) to encrypted transactions to governance and social consensus. We are actively exploring these options to find the solution with the least tradeoffs. But for now, users interested in verification can permissionlessly audit the blockchain.

Low Priority Fee Due to MEV Taxes

One of the potential limitations of MEV Taxes is that they reduce the priority fee paid to the platform, which reduces the probability of inclusion.

This problem is entirely valid on chains without local fee markets, as inclusion and priority are global, but on SVM chains, it’s not a problem. Local Fee markets simulate the effect of each piece of state having its own block, so priority fees are completely isolated from each other.

As long as the transaction pays the base fee for inclusion, the exact amount of the priority fee is inconsequential, regardless of what is happening on the chain.

Auctions on Fast Blockchains

Implementing priority ordering on a fast blockchain is problematic because short block times and continuous block building amplify the time component of the price-time auction. Auction participants compete on latency instead of by bidding, and some value leaks.

This is what drives some of the spamming on chains like Solana and, to an extent, pre-timeboost Arbitrum. It’s the same reason Solana validators capture less of the total MEV than their Ethereum counterparts. In general, the shorter the block time, the shorter the auction, and the less the value of MEV that is capturable by the network. This hampers the value prop of priority ordering for a performance-focused chain.

But Eclipse has a major advantage; searchers can colocate with the sequencer and get reliably low jitter and landing time, allowing for very short auctions without leaking value. And as long as there are at least two rational, independent searchers, the network can capture (almost) all of the MEV!

Conclusion

Customizability and value capture are the missing ingredients for apps today. Exploiting priority-ordering allows application developers to permissionlessly unlock both with simple additions to new or existing codebases.

The demos attached barely scratch the surface of the design space. ASC and MEV-taxes can be used individually and combined in many ways to design applications that were previously impossible, while maintaining maximum composability with the rest of the network (no appchains needed).

Most importantly, you can start today!

Our plans for the future center around driving the compute cost as close to zero as possible. More on that soon.

Footnotes

1. In an ideal market, the base fee should be the same for everyone and should be a function of the general demand for blockspace. Dynamic or not, it should belong to the infrastructure layer. The tip/priority fee is the subject of the discussion.
2. Utilitarian in this context means the blockchain designers view the blockchain as somewhat fungible infrastructure that should only be paid for the value of the service it provides.
3. Theoretically, the function is defined for the set of complex numbers (except when y = -1), but for practical purposes, the MEV tax can be any real, positive number.

Resources

1. Priority Is All You Need, Dan Robinson and Dave White. 2024.
2. Multidimensional Fee Markets at 1M TPS. Eclipse Labs. 2025.
3. A deep dive into Application Specific Sequencing. Eclipse Labs. 2024.
4. MEV Internalization and ACS Repo. Eclipse Labs. 2025.
5. The Path to Decentralized NASDAQ. Max Resnick and Anatoly Yakovenko. 2025.
6. Priority Fee Data