Plugin Ideation

Plugins
1

This thread is for brainstorming and sharing ideas for future BAM Plugins.

What kinds of execution guarantees, ordering logic, or features does your application need?

Whether it’s something simple (like prioritizing certain txs over others) or ambitious (like entirely new scheduling logic), drop your thoughts below. The goal is to surface ideas the community wants to explore, build, and potentially standardize.

Looking forward to the creativity; let’s shape the future of Solana block-building together :handshake:

3 Likes
Brainstorming Paths to ACE on BAM
3

Liquidation Prioritization

A BAM plugin that enforces FIFO execution for liquidation transactions so liquidations are predictable and resistant to toxic MEV across Solana lending.

Why Liquidation Ordering Matters

Liquidations are latency sensitive. Once a position falls below its threshold, every extra second can increase bad debt exposure for the lenders. If the liquidator is unable to liquidate the position within a timely manner, the protocol will have to socialize losses amongst the lenders. That being said, liquidators play a mission-critical function in maintaining the health of a lending protocol, and their ability to execute liquidations on underwater accounts as quickly as possible is of paramount importance.

However, liquidators are forced to compete with fee bidding and transaction re-ordering, which can prevent them from liquidating accounts within a timely manner. The result is worse price for unwinds, variance for liquidators and more risk exposure for lenders.

With FIFO liquidation executions, lending protocols — such as marginfi — can guarantee faster and fairer liquidations during network stress and reduce the tail risk of bad debt.

How The Plugin Works at a High Level

  1. The plugin would watch for transactions that match known liquidation calls from supported lending programs, such as lending_account_liquidateon MarginFi V2.
    1. An optional tx level flag lets protocols opt in explicitly?
  2. Those transactions enter a dedicated queue inside the TEE and are ordered by arrival time. Tie breaking between liquidation TXs is by a stable rule like transaction hash.
  3. BAM Validators execute from this queue before non-critical flow and cannot reorder within the queue. Attestations make the rule verifiable and public
    1. If BAM nodes/validators are unable to process transactions for any reason, transactions fall back to normal ordering with a clear flag so participants know which path executed.
1 Like
4

Thanks for sharing this! Liquidation priority/ordering is a high-value BAM Plugin use case, as it improves protocol safety (less bad debt) and fairness for liquidators, making Solana lending more efficient overall. Also appreciate the concrete FIFO design ideas (i.e. the dedicated queue inside the TEE and opt-in tx-level flag)

As a complementary step, oracle priority could help make liquidations more efficient too. By ensuring oracle updates land first and are processed ahead of dependent liquidations, protocols can guarantee that liquidations always act on the freshest price data. Combined with FIFO liquidation ordering, this could tighten execution guarantees, reduce tail risk for lenders, and give liquidators more predictable outcomes.

Keep those ideas coming, these help us greatly as we continue to map the Plugin design space for BAM :handshake: