SettleDealPaymentsExported messages consume massive gas, fill block space, crowd out legitimate transactions, and base fee doesn't spike

[BigLep]

Background

This is a placeholder issue for the events we have seen a few times in 2025 where SettleDealPaymentsExported messages crowded out WindowPoST messages and base fee wasn't spiking. This happened most recently during the December 2025 holidays. This was created so we have a public pointer and as a public commitment by implementers to "do something".

What action will be taken

• 2026-01-06: see SettleDealPaymentsExported messages consume massive gas, fill block space, crowd out legitimate transactions, and base fee doesn't spike #1224 (comment)
• 2025-12-24: This is TBD. In January implementers will coordinate to make sure a implementation team looks into mpool selection, base fee logic, and/or gas lanes for network critical messages. At the minimum, more public clearly documented explanation about basefee behavior in the context of a sutiation like this needs to be produced.

When will action be taken

• 2025-12-24: Implementation teams are monitoring the network over December holidays so they can jump into emergency action mode. At least as of 2025-12-24, we believe we can live with the current status quo and not need to take emergency action.

Threads where this has come up or been discussed

• 2025-08-11 - #fil-lotus-dev: https://filecoinproject.slack.com/archives/CP50PPW2X/p1754972136169259
• 2025-12-23 - #fil-lotus-help: https://filecoinproject.slack.com/archives/CPFTWMY7N/p1766462911610619

Where updates will be posted

Once a better plan gets created, it will be documented here or at least linked to from here.
In the interim, the community should continue to post in their normal places and we'll link to it from here for visiblity/tracking.
For example, if there is a major slack thread investigating new instances of this behavior it will be linked from here.

Where this issue belongs

This issue is broader than the Lotus implementation which is why it has been moved to filecoin-project/FIPs. It would probably be ideal for it to be a discussion rather than an issue, but since it started as an issue, we'll keep it as one for now. Feel free to create a discussion instead though if that would help with communication and review...

[BigLep]

This was discussed in the 2026-01-06 implementers working group.

It was agreed it should be moved to filecoin-project/FIPs as this involves message selection and the base fee, which are broader than filecoin-project.

Next steps:

• Venus team is going to take a pass on understanding/documenting the base fee mechanism and mempool selection from Venus' codebase
• Cross-check with Forest and Lotus implementations

Based on what we find here, we'll figure out what next steps should be taken to avoid this event.

@ipfsforcezuofu : I am unable to assign the issue to you, but I assume the ball is in your court. #fil-implementers is here in support to help answer questions or review anything Venus produces.

[BigLep]

@ipfsforcezuofu: On the topic of why the basefee didn't increase....

@Kubuxu had some thoughts going off of his memory from multiple years ago (so this should be checked/confirmed): https://filecoinproject.slack.com/archives/CP50PPW2X/p1754999273043179?thread_ts=1754972136.169259&cid=CP50PPW2X. I also have these rough notes from a verbal discussion I was in with @Kubuxu: "We know that with deferred execution and multiple blocks, that the base fee system that we implemented was never a perfect fit. There are edge cases there. Basically being on the floor, and transactions with very high gas premium over everything else might be essentially leading to an edge case being hit, where the base fee is not increasing as quickly as we would have wanted it to increase. This leads to over-selection of those messages across all blocks, which then leads to, lower than expected gas usage from base fee system perspective because we deduplicate before we count."

Anyways, please do your own investigation here and @Kubuxu and others are more than happy to review or discuss in this issue or #fil-implementers.

[beck-8]

I think the problem does arise here
https://github.com/filecoin-project/lotus/blob/422b83c95c99781f8580c59b948acd47bdc6e671/chain/store/basefee.go#L60-L84

	seen := make(map[cid.Cid]struct{})

	for _, b := range ts.Blocks() {
		msg1, msg2, err := cs.MessagesForBlock(ctx, b)
		if err != nil {
			return zero, xerrors.Errorf("error getting messages for: %s: %w", b.Cid(), err)
		}
		for _, m := range msg1 {
			c := m.Cid()
			if _, ok := seen[c]; !ok {
				totalLimit += m.GasLimit
				seen[c] = struct{}{}
			}
		}
		for _, m := range msg2 {
			c := m.Cid()
			if _, ok := seen[c]; !ok {
				totalLimit += m.Message.GasLimit
				seen[c] = struct{}{}
			}
		}
	}
	parentBaseFee := ts.Blocks()[0].ParentBaseFee

	return ComputeNextBaseFee(parentBaseFee, totalLimit, len(ts.Blocks()), ts.Height()), nil

func ComputeNextBaseFee(baseFee types.BigInt, gasLimitUsed int64, noOfBlocks int, epoch abi.ChainEpoch) types.BigInt {
	// deta := gasLimitUsed/noOfBlocks - buildconstants.BlockGasTarget
	// change := baseFee * deta / BlockGasTarget
	// nextBaseFee = baseFee + change
	// nextBaseFee = max(nextBaseFee, buildconstants.MinimumBaseFee)

View with recent events.
https://filfox.info/en/message/bafy2bzaceadslcftv6z4wxamz5puspsx2mreec6v77uc2gdwzpozpfyffjcgy?t=4
7b 4blocks
https://filfox.info/en/message/bafy2bzaceb2ebhdrfzawonxfixob6kdro53e3g4hulhosumxjoymjfzosbfjq?t=4
5b 2blocks

Right now, these two wallets are sending a large amount of SettleDealPaymentsExported, but the message occupies 5b and can accommodate other messages, so the overall impact is not big.
f3rxshzf6sq26e72a2525qzduqdppygegvj36exo3czghavex7lrx7ein5etudmcpmp7byvajbq4vs6nlgz2sq
f3qs7p2wuytefh4bjdijmi4k22llu5uccdolnnys4lv4f7tlhjgnrv3j4xpaat6xrvjzqliyjotervt2l5pafa

We might ask, is the same situation true for other news? Why didn't this happen more often before?

• SettleDealPaymentsExported
• TerminateSectors
• ExtendClaimTerms
• ...

The same situation should be true for other messages, except that the cost and requirements for sending other messages are higher than SettleDealPaymentsExported; and the current market is sluggish, with fewer messages on the chain and less message competition.
In addition, the tool for sending SettleDealPaymentsExported has only been fully available recently. Users of this tool can control the number of transactions at will, so sometimes people will increase the concurrency to reduce gas consumption. At present, if the user does not change the default concurrency of 50, this message will consume almost 5B gas (not fully verified)

This reminds me that I had a large-scale sector termination at the end of September, and the base fee was not very volatile at that time.

[BigLep]

Thanks @beck-8 for providing input.

@@pfsforcezuofu: have you looked into this further? Are they any updates you want to share or confirm?

[ipfsforcezuofu]

@BigLep
Venus engineer has initial ideas and will post them after verification.

[LinZexiao]

This comment analyzes the interaction between the BaseFee adjustment mechanism and the miner message selection algorithm in the current Filecoin network. It offers a possible explanation for why an unintuitive drop in BaseFee might occur when specific types of messages (such as SettleDealPaymentsExported) cause congestion.

1. BaseFee Adjustment Mechanism

The BaseFee is designed to regulate network traffic through a pricing mechanism, maintaining an ideal utilization rate. In Filecoin, this depends on Tipset Efficiency.

Note: This section provides a simplified overview of the BaseFee mechanism. For the complete calculation logic (including smoothing factors, etc.), please refer to the ComputeBaseFee function in the source code chain/store/basefee.go.

1.1 Tipset Efficiency Definition

Tipset Efficiency refers to the ratio of total unique message Gas to the total Tipset capacity, representing the effective utilization rate of the Tipset capacity.

$$ \text{Tipset Efficiency} = \frac{\text{Sum(Unique Messages Gas Limit)}}{\text{Tipset Max Gas Limit}} $$

• Numerator (Unique Messages Gas Limit): The sum of the Gas Limit of all deduplicated messages in a Tipset. Note that if multiple miners include the same message, its Gas is counted only once.
• Denominator (Tipset Max Gas Limit): The sum of the theoretical maximum Gas capacity of all blocks in that Tipset.

1.2 BaseFee Adjustment Logic

Although the BaseFee calculation formula includes smoothing coefficients, its core logic is driven by Tipset Efficiency:

• Congestion (Efficiency > 50%): When unique messages in a Tipset fill more than 50% of the capacity, the protocol considers the network congested, and the BaseFee for the next Epoch will increase.
• Idle (Efficiency < 50%): When the proportion of unique messages is below 50%, the protocol considers the network idle, and the BaseFee for the next Epoch will decrease.

Critical Flaw: The protocol cannot distinguish between "the network is truly idle" and "effective payload is low due to duplicate packaging." To the protocol, if 5 miners all package the exact same single message, even though the physical blocks are full, logically this is seen as extremely low utilization (approx 20%), triggering a BaseFee drop.

2. Message Selection Algorithm (Mpool Selection)

To avoid multiple miners competing for the same message at the same height (leading to Gas waste and reduced chain utilization), Lotus implements a probabilistic greedy selection algorithm.

Note: This section outlines the message selection strategy. Actual implementation involves more complex random number generation and probability assessment details. Please refer to chain/messagepool/selection.go.

2.1 Core Principle: Ticket Quality (TQ)

Each miner has a randomly generated Ticket when producing a block. Based on Ticket Quality (TQ), block producers in the current Epoch can be implicitly ranked.

• Rule: If multiple miners include the same message, only the miner with the highest TQ receives the Gas reward from that message. Other miners receive zero reward for that message.

2.2 Evaluation Model: Expected Value

Miners cannot know others' TQ but can estimate their "win rate" based on their position in the network's total power. For each pending message $m$, the miner calculates its expected return $E[R_m]$:

$$ E[R_m] = \text{GasReward}_m \times P(\text{Win}_m) $$

• $\text{GasReward}_m$: The Gas fee reward provided by message $m$ (GasLimit $\times$ GasPremium).
• $P(\text{Win}_m)$: The probability that the message is NOT selected by another miner with better TQ. Typically, the more "popular" a message (higher GasPremium), the higher the chance a better TQ miner picks it, thus lowering $P(\text{Win}_m)$ for lower TQ miners.

2.3 Algorithm Execution Logic

1. Sort: Sort messages in the mempool by GasPremium.
2. Greedy Selection: Iterate messages from high to low, calculating $E[R_m]$ based on own TQ.
3. Decision: Miners tend to select the set of messages with the highest $E[R_m]$ to fill the block.

Under normal circumstances, this mechanism works well: low-TQ miners calculate that winning popular messages has low $P(\text{Win})$, leading to low $E[R]$. They find it better to package ordinary messages no one is competing for ($P(\text{Win})$ approx 1), achieving automatic load balancing.

3. Conflict Analysis: Mechanism Failure Triggered by Large Messages

The two mechanisms above cooperate well with regular traffic but conflict severely when handling special messages like SettleDealPaymentsExported.

3.1 Disruptive Characteristics

These messages have two key characteristics:

1. Extremely High Gas Limit: A single message occupies about 70% of block space.
2. Extremely High Gas Premium: Senders usually pay a tip far above the market average to ensure this massive message gets on-chain.

3.2 Evaluation Loophole

For such messages, the $GasReward$ is enormous. This creates a mathematical suppression:

$$ \underbrace{\text{Huge Reward}}_{\text{Mega Message}} \times \underbrace{\text{Low } P(\text{Win})}_{\text{High Conflict Prob}} \gg \underbrace{\text{Normal Reward}}_{\text{Regular Message}} \times \underbrace{\approx 100% P(\text{Win})}_{\text{No Conflict}} $$

Even a miner with poor TQ knows all other miners are fighting for this message (win rate is extremely low), but because the reward for "winning" is astronomically high, the calculated Expected Reward remains higher than packaging safe, small messages.

3.3 Consequence: BaseFee Divergence from Congestion

1. Herd Behavior: All block-producing miners, regardless of TQ, choose to stuff this 70%-size giant message into their blocks.
2. Low Efficiency After Deduplication:
   • Assume a Tipset has 5 blocks.
   • Physically: 5 blocks are full.
   • Logically: Tipset contains only 1 large message (duplicated 5 times) and a few small messages.
   • Tipset Efficiency $\approx \frac{1 \times \text{BigMessage}}{\text{5} \times \text{BlockCapacity}} &lt; 20%$.
3. BaseFee Misjudgement:
   • Since Tipset Efficiency is far below 50%, the BaseFee algorithm judges the network as "idle".
   • Result: BaseFee Decreases.
4. Actual Congestion:
   • While BaseFee drops, seemingly indicating a free network, the effective capacity of each Tipset is actually deadlocked by that duplicated huge message, preventing thousands of other pending messages from getting on-chain, causing severe immediate congestion.

4. Suggestions for Improvement

To address the conflict described above, we present the following suggestions for consideration. These aim to improve how BaseFee perceives congestion and optimize the game-theoretic balance of message selection.

4.1 Adjustment to BaseFee Mechanism: Considering GasPremium Distribution

Due to the unique multi-block nature of Filecoin, relying solely on Tipset Efficiency to adjust BaseFee might be insufficient in specific high-contention scenarios. We suggest considering GasPremium distribution as an auxiliary signal.

• Rationale: In a healthy, uncongested network, GasPremium levels generally remain low. If users consistently pay high GasPremiums, it suggests a supply-demand imbalance (congestion), regardless of block fullness.
• Suggestion: The protocol could consider monitoring the median or average GasPremium of messages in blocks. If this metric remains high, it might be beneficial to treat it as a congestion signal—potentially increasing BaseFee or halting its decrease—even if the calculated Tipset Efficiency appears low (<50%). This could help mitigate false "idle" signals caused by high duplication rates.

4.2 Optimization of Message Selection: Potential Duplication Penalty

To mitigate "herd behavior," it may be effective to adjust the expected return calculation for popular large messages, thereby discouraging risky selection strategies.

• Suggestion: Consider introducing a Duplication Penalty Factor into the Expected Value calculation $E[R_m]$.
• Concept Model:

$$ E[R_m] = \text{GasReward}_m \times P(\text{Win}_m) \times f(\text{ConflictScale}) $$

Where $f(\text{ConflictScale})$ is a coefficient negatively correlated with the message's popularity or probability of duplication.

• Expected Outcome: By artificially lowering the expected value of messages deemed "highly conflict-prone," lower-TQ miners might be encouraged to avoid "high reward but impossible to win" messages. Instead, they might prioritize smaller, less contested messages, potentially restoring Tipset message diversity and effective throughput.

[beck-8]

Next, there should be more and more SettleDealPaymentsExported messages.

It should also be a method to consider both the execution dimension (deduplication gas) and the spatial dimension (physical gas consumption).

[rjan90]

@LinZexiao is another option to have the mssage selction being non-greedy by default in implementations? I´m wondering what is the financial gain always picking these SettleDealPaymentsExported versus some other set of messages? Or would that change something fundamentally with regards to the BaseFee Mechanism?

[rvagg]

I figure we should probably make our large message submissions a bit more optimal, it doesn't fix the protocol but it will make it so that users of our stuff (unmodified) are less likely to trigger such conditions, so here's an issue: filecoin-project/lotus#13471