Local fee markets and account contention

Two transactions contend when they access the same state in a way that cannot be reordered freely. The precise condition follows from the locking model: two writes to the same account contend, and a read and a write to the same account contend. Two reads of the same account do not contend, because neither changes what the other sees, and they can proceed concurrently.

The practical implication is that a workload's parallelism depends on its access pattern, not on its transaction count. A thousand transfers between a thousand distinct pairs of accounts can run largely in parallel. A thousand mints against a single collection account cannot, because every one of them writes that account. The second workload is not slower because the network is busy; it is slower because the state it needs is a single serialisation point.

This is why the Sealevel runtime page and this one are read together. The runtime's account-access declaration is what makes contention visible before execution; the local fee market is the economic question of how to price it.

The prioritisation fee is the mechanism a user has today for competing on a contended account. When many transactions want to write the same account, the scheduler orders the conflicting ones by priority, and priority is derived from the fee the validator keeps against the estimated cost of the transaction. A higher prioritisation fee therefore improves a transaction's position against others touching the same state.

The fee schedule itself — the base fee, the price-times-limit formula, the distribution split — is set out on the fees and priority fees page and is not repeated here. What matters for this page is that the fee is the same instrument whether the contention is global or local: there is no separate price for writing a hot account, and no protocol-level surcharge that reflects how contended a particular account is.

That is the gap the proposals below are aimed at. A single prioritisation fee is a blunt instrument for a local problem: it raises the cost of every transaction competing for the account, but it does not distinguish between a transaction that genuinely needs the account and one that is spamming it, and it does not give the network a way to filter mispriced transactions before they reach the scheduler.

The most discussed proposal in this area is SIMD-0110, which would impose a dynamic fee on write-locking an account that is consistently in high demand. The mechanism would track an exponential moving average of compute unit utilisation for write-locked accounts and raise the cost of locking accounts whose utilisation stays above a target. Accounts that cool off would see the cost fall back toward zero.

The stated motivation is that a leader currently cannot tell whether to include a transaction that write-locks a hot account immediately or to wait for a better-priced one, and that the resulting uncertainty produces poor pricing and confirmation delays. A dynamic write-lock fee would give the network a floor price for contention that could be applied earlier in the pipeline, before transactions reach the scheduler, which is where the proposal argues filtering is most effective.

The proposal is explicit that it does not solve everything. Its own discussion notes that it does not prevent spam, that it does not fix the underlying networking problem of filtering mispriced transactions at line rate, and that it does not address competition between validators for block space. It is a pricing mechanism for one specific resource, and it is presented as such.

It is important to be clear about status. SIMD-0110 is a proposal under discussion, not a deployed feature. The write-lock fee it describes is not part of the network's current fee schedule, and a reader should not expect to encounter it when sending a transaction today. It is described here because it is the clearest articulation of what a local fee market would mean in protocol terms, and because the debate around it is the best available guide to how the network thinks about account contention.

Pricing contention directly has an obvious appeal: it makes the cost of using a scarce resource fall on the users of that resource rather than on everyone. A transaction that touches a quiet account would not pay for the congestion caused by a transaction that touches a busy one, which is closer to what the underlying costs actually are.

The objections are equally real. A dynamic fee on a hot account raises costs for ordinary users of that account, not only for spammers, and the proposal's own discussion acknowledges that oracles, market makers and other legitimate high-frequency users would pay it. There is also a question of whether the fee should be burned or paid to the validator: burning it removes any incentive for a validator to include a hot-account transaction unless it also pays a competitive prioritisation fee, which changes the economics in a way that is not obviously desirable.

The deeper question is whether a fee is the right instrument at all. The proposal's critics argue that the root problem is that validators cannot filter mispriced transactions at the networking layer, and that a fee which taxes users for capacity does not fix that. The proposal's authors agree that it does not, and present it as one component rather than a complete answer. A reader following the debate should treat the write-lock fee as a proposal with a specific and limited purpose, not as a settled solution to congestion.