Proposal: Auctioning Batch Prioritization in the Miden Node

[Dominik1999]

Proposal: Auctioning Batch Prioritization in the Miden Node

Summary

Introduce an auction mechanism for batch prioritization in the Miden Node.
Users and applications could bid in MDN for inclusion priority of their user-defined batches.
The proceeds of these auctions are then redistributed to MDN stakers through a staking contract, providing protocol-native yield derived from blockspace demand rather than inflation.

This idea came from https://github.com/yusufxzy

---

Background

Miden’s architecture allows users to define and prove their own batches — sequences of transactions that can be executed atomically and submitted to the network once proven.
The Miden Node (sequencer / block producer) is responsible for ordering these user-defined batches into blocks before consensus and finalization.

Currently, batch ordering follows a simple FIFO policy.
As network activity grows, contention for blockspace and inclusion priority will increase, especially for applications that depend on latency (trading, oracles, private settlements, etc.).

This proposal introduces a market-based prioritization layer, allowing users to compete fairly for inclusion order, while ensuring that the resulting value accrues back to the protocol and its stakers.

We can link this idea to @partylikeits1983's idea of 0xMiden/protocol#2001 or simply a native Swap-system on Miden where users create public Swapp notes and the seekers / auctioneers pick it up and arbitrage.

Motivation

• Efficient blockspace allocation: Introduce price discovery for inclusion priority.
• Align incentives: Share ordering value with stakers, not just sequencers.
• Reduce off-chain extraction: Prevent private order flow or opaque MEV channels from capturing value outside the protocol.
• Strengthen MDN utility: Require MDN for bidding and staking, linking activity directly to token demand.
• Enable privacy-friendly ordering: Since Miden batches are already commitment-based, the auction can preserve user privacy.

Design Overview

1. Auction scope

Each Miden block includes multiple user-defined batches.
Before assembling a block, the Node opens a short auction window for the upcoming block height (e.g. block N).
Bidders can submit sealed bids in MDN, referencing their batch commitment.

2. Auction mechanism

• Bid unit: MDN tokens.
• Auction type: simple first-price or second-price (Vickrey) auction.
• Execution: The sequencer ranks batches by bid amount and fills blockspace accordingly.
• Unbid batches: Any unbid batches are added in FIFO order after the auctioned ones.

3. Settlement

When the block is finalized:

• The total MDN paid by successful bidders is transferred to a Staking Reward Contract.
• The Node records the winning bids and ordering in block metadata for transparency.

4. Reward distribution

The staking contract accumulates all auction proceeds and distributes them to MDN stakers pro-rata per epoch.
This creates a native staking yield tied to blockspace demand.

Example Flow

1. Alice and Bob each submit a proven batch (B1, B2) to the Node.
2. The Node opens an auction for the next block:
   • Alice bids 10 MDN for priority 1.
   • Bob bids 5 MDN for priority 2.
3. The Node assembles the block: [B1, B2, ...remaining FIFO batches].
4. Upon block finalization:
   • 15 MDN total proceeds are deposited into the staking reward pool.
   • Rewards are distributed to stakers at the next epoch.

Implementation Notes

• Integration point: Extend the Node’s BlockProducer logic (see miden-node/src/node/execution/block_producer.rs) to handle auction logic before final ordering.
• API extension: Introduce RPC endpoints for submitting bids and retrieving auction state.
• Staking contract: A simple on-chain contract managing MDN deposits and pro-rata distribution of accumulated rewards.
• Security:
  • Bids could be commitment-based to prevent front-running. Or we allow front-running. Not sure yet.
  • Optional minimum bid or bond to prevent spam.
  • Auction can be off-chain, we need a good team to think about a good way.

Economic Considerations

• Token utility: MDN becomes essential both for staking and for bidding on blockspace priority.
• Value capture: Converts blockspace demand and ordering value directly into yield for stakers.
• Fairness: Open, transparent mechanism reduces incentive for private relays or sequencer favoritism.
• Sustainability: Reward flow depends on real usage, aligning staker yield with network activity instead of inflation.
• MEV: MEV on Miden is not straight forward and we need to think about what we want to support here. When we allow for private trading, there will be no MEV in the classical sense, but there can still be arbitrage and even cross-chain arbitrage when we have a fast bridge.

Next Steps

• Discuss preferred auction type (first-price vs. second-price).
• Specify timing and cadence (per block vs. per epoch).
• Evaluate impact on latency and sequencer performance.
• Prototype integration into the Node’s block production flow.
• Implement a minimal staking contract for reward distribution.

---

References

• Issue #1112: User-defined batches
• Related research:
  • Burning MEV through block proposer auctions (ethresear.ch)
  • Transaction ordering & value accrual in L2s (Delphi Digital, 2024)

Discussion goal:
Gather feedback on the feasibility, architecture, and incentive implications of integrating Batch Prioritization Auctions into the Miden Node, and how it could serve as a foundation for sustainable, usage-based staking yield in the Miden ecosystem.

[huitseeker]

Thank you for the proposal! There's now solid work showing that auction-based express lanes can materially change how creation & capture of ordering values work in roll-ups, and I think it would be good to think of how to integrate those insights in Miden even if the proposal doesn’t yet fully account for Miden’s particulars.

I think proposal may benefit from a deeper look at what bidders are really bidding for, and whether these good are present in Miden’s architecture. On transparent blockchains, ordering is valuable because every transaction competes for a single shared state — priority directly determines who wins a race. But Miden’s model is different: batches are locally proven, state is sharded across accounts, and most batches commute. In that world, there isn’t a clear global “priority lane” to sell. Scarcity only appears inside conflict sets (when batches touch the same accounts or depend on shared oracles). Everywhere else, what users may want may well be predictable inclusion, not ordering.

A short per-block auction may also not always be feasible — bids would need to be proven and verified, and bidders don’t have access to the sequencer’s (or users') witness. Once Miden is decentralized, provers can only reason about "their" own transactions (possibly a "club" of mutually trusting users) and public events (oracle or bridge updates). So any priority signal must come from those shared, observable moments.

In that light, the question I'm wondering about is what the unit of demand actually is. Is it “fresh inclusion after an oracle update”? “Being early within a conflict set”? “block-height base priority” for a scheduled batch? Each interpretation implies a different, smaller market — more like a knapsack of discrete event windows than a global order book.

I’d encourage re-analyzing what bidders could rationally bid on in such a setting, and how those bids would be formed given limited visibility, high proving latency, and the need to preserve user privacy. That framing will make it clearer where an auction mechanism adds real value.

/cc @yusufxzy

[Dominik1999]

I think proposal may benefit from a deeper look at what bidders are really bidding for, and whether these good are present in Miden’s architecture.

This is for sure. So I have a couple of ideas, that we could research.

1. A in-protocol DEX (or what Alex proposes here Execute Signed `Intent` (Intent/Permit) from Wallet protocol#2001): So in theory, public Swap (or Swapp) notes are intents. Alice wants to swap token X to token Y for a price P. Whoever picks that note up, and consumes it, can swap. Bidders can bid to consume the most favorable swap notes. They do that to arbitrage, in theory even cross-chain.

2. A Miden AMM: Zoro, the first AMM on Miden, will have public and private pools. In theory, they can work the same way as on Ethereum, if Bidders can execute transactions against that pool. That way, Bidders can bit for the same reasons as they do it on Arbitrum or MegaEth.

3. Miden Flashloans: User-defined batches allow for Miden Flashloans that execute atomically. This can even happen using private notes and accounts, as long as the bidder has access to the private lending and exchange protocols.

There might be way more areas that we can look into. In theory, we can also prioritize batched bridge transactions in case our infrastructure allows this in the future. But in theory, when you use Miden as a compliant, private Mixer, Bidders can offer fast bridge solutions using prioritized batches.

On transparent blockchains, ordering is valuable because every transaction competes for a single shared state — priority directly determines who wins a race. But Miden’s model is different: batches are locally proven, state is sharded across accounts, and most batches commute. In that world, there isn’t a clear global “priority lane” to sell. Scarcity only appears inside conflict sets (when batches touch the same accounts or depend on shared oracles). Everywhere else, what users may want may well be predictable inclusion, not ordering.

I would argue that in above use cases, priority also matters in the Miden case. If many users compete for the "best" public Swap note - scarcity appears for public notes as native Miden intents. But less about ordering of transactions, but "guaranteed" inclusion into the next block.

A short per-block auction may also not always be feasible.

This is a very interesting point. I don't know how we could solve the auction itself for Miden. I personally, always like to start simple. The centralized Miden node, can just have an endpoint, where Bidders can submit their batches and a bid or a range. In the beginning, there is no need for a proof even. In the future, Bidders could always bid for the next block using an onchain transaction even. There could be the auction account, that is somehow guaranteed to be executed in every block with all incoming notes. The result determines, who can submit the prioritized batch in Block n+1. But I am sure we can come up with a better design.

Does that make sense to you? Do you have other ideas on what ppl can bid for?

[yusufxzy]

Thank you for sharing your ideas @huitseeker @Dominik1999

As for what bidders could bid for, we can target conflict sets related to hot pools, oracle updates, bridge txns (relating to cross-chain arbitrage) and run one pooled market per block with tags like pool address, intent id, oracle update id, or bridge in or out. Priority sits in that pool. The node looks at price and whether the tag is relevant right now, then places the top scores first. If someone does not care about priority, they just sit in the tail.

To keep this safe, we add a small predictable inclusion lane. Pay a low fee and get included by T plus delta or get a refund or credit. Everything else is best effort FIFO. I would also reserve some capacity for the non priority lanes so they cannot starve. Twenty to thirty percent feels like a good starting point. Add an age bump after N blocks so long waiting batches climb once. A tiny fee or refundable bond and per address caps keep the tail healthy.

So we can have 3 lanes instead of a global lane. A - Priority Lane (pooled market for conflict sets). B - Predictable inclusion (pay low fees for inclusion within n block, if not successful, user gets a refund, does not have to participate in bidding wars. C - FIFO (No extra payment, no priority but inclusion through a % of bottom of the block)

If a user finds a new edge on a quiet pool, they can still get in early by using Lane A’s pooled auction with a coarse public tag for the protocol and keep the exact pool hidden in the commit. Because that tag is not hot, a modest bid usually clears near the top without revealing the strategy. If they just want certainty, they use Lane B to buy inclusion by T+delta and let it settle on time with zero signaling.

[huitseeker]

Thanks both — this makes a lot of sense, and I like how the conversation is converging.

I agree with @yusufxzy on the economic framing: we’re not pre-selling blockspace (futures don’t fit well, blockspace is perishable / not fungible), and predictable inclusion should act like a “pay-for-inclusion-by-T+delta” lane with a small refund if the network misses its mark.

@Dominik1999's note on examples of what you call tagging @yusufxzy was especially useful — conflict pools are indeed the right unit of scarcity. Using tags like pool address, intent ID, oracle round, or bridge event gives the sequencer something concrete to rank on (perhaps app-surfaced?). Within each tag, I think there's at least one model for keeping the auction simple and still grounded in theory: DARA shows a knapsack-style double auction can be reduced to a ranking by value-per-unit plus a marginal trade reduction (dropping the lowest winning bid) w/ threshold pricing (the small trade reduction ensures that no winner sets their own price, which keeps bids truthful and prevents budget loss while staying near-optimal in welfare).

In plain terms, this might mean:

• Each tag defines its own mini-market.
• The sequencer just sorts bids, drops the lowest marginal winner, and charges everyone the same threshold price.
• It’s easy to implement, fair, and doesn’t overfit a single block’s congestion curve.

To sum up, predictable inclusion handles the congestion smoothing & priority markets live inside conflict-set tags with simple ranking. Should we go for that, it would leave a large remaining design space, but that would be mostly practical — e.g. how tags are discovered, how often auctions run, and what fraction of capacity stays reserved for baseline inclusion.

[yellowBirdy]

Hey, I like the direction and agree with the principle

As @huitseeker pointed out, competition for batch (or in fact, transaction) ordering occurs only for accounts whose state can be changed by multiple parties.

In my understanding, there are technically two kinds of accounts that fall into this category:

1. “Open” smart contracts, i.e., those exposing procedures with exec.account::incr_nonce

2. Network accounts

User-defined batches, as far as I understand, are only applicable to the former. This would indicate that such competition is not only for priority but also for inclusion itself, due to race conditions. If my understanding is correct, it would heavily limit the available use cases — not only for auctions but for user-defined batches per se.

In my view, meaningful and practical competition for transaction or batch ordering would really be relevant for network accounts and transactions. For instance, a money market, AMM, and a flash loan provider — all deployed as network accounts — would require a “network transaction batch” for atomic cross-contract use cases, such as a flash loan–based liquidation after a sudden change in oracle price.

In such a context, auctions might not only be useful but necessary for MEV management. In fact, the same applies to network transactions without batches. For example, arbitrageurs competing for constant product AMM pool opportunities — the order in which their (swap) notes are included in the network transaction — would have a direct impact on the price they receive.

[Mirko-von-Leipzig]

I feel like this complicates matters significantly but I don't really understand the details so I'll only comment on the practical problem of ordering transactions and batches.

First some corrections.

Transactions and batches are not FIFO, but rather are selected randomly from the viable subset in the mempool:

• Transactions are available for batch selection once all their ancestors have been selected for inclusion in a batch.
• Batches are available for block selection once all their ancestors have been selected for inclusion in a block.

An ancestor here means any transaction/batch which this transaction/batch must follow after in order to be a valid state transition. From the above discussion I think everyone has missed that this includes note creation and consumption - it is not only prior transactions affecting an account.

This dramatically complicates ordering requirements. User submitted batches can depend on other batches or transactions and cannot be included without the others being included first. User batches can also introduce cyclic dependencies, where batch A depends on B, and vice versa.

On a more personal note, I'm also somewhat disappointed that use cases so far seem to be entirely financial instruments related which to me is by far the least interesting side of blockchains. Does one really want chain priority to be primarily trading? Sort of feels like this would inherently skew the chain usage towards this "express" lane.

[yellowBirdy]

RE. "user defined batch dependency hell" I can very much see that as well. What we need is something along the lines of:
User defined network batches

What I mean by that is a set of network transactions that would defined by users but executed and proven by the operator together atomically.
In my mind this is necessary for any meaningful interop between contracts.

I can't exactly imagine how could it be implemented though, given that NTXs (from user POV) are just notes sent to a "network account".
It would probably require some sort of intent like system.

RE. Non financial applications , I'm personally very excited by them as well. That said, financial ones are the first practical use case. It's also extremely competitive which forces good design choices.

[yellowBirdy]

For what it's worth:
I can't stress enough that "these network tx batches" are in my view critical.

Without them race conditions will kill practical use of protocols and contracts relying on interoperability - effectively majority of use cases.

[Dominik1999]

We are discussing them right now. But it would be mixed batches, right? Some involved accounts are network accounts and some are local accounts.

[yellowBirdy]

“I was imagining something that involves only network accounts, where the local account creates a note (and possibly an intent definition as well).

Then, a batch of network transactions—potentially involving the creation and consumption of notes between contracts (according to the user’s intent)—would be executed.

This would (optionally) result in a final or net note directed back to the user.”

I'm using "intent" here in a lose sense ie. a specification of actions/txs user wants to execute.
I suspect that could be expressed and enforced on the level of notes (by specifying that in note standards)
Eg.
A SWAP_LIQUIDATE note that when consumed would yield a LIQUIDATE note targeted at a lending protocol which in tern would yield a P2ID note for the user.