Simpler, Faster, Cheaper: Upgrading the FlowTransactionScheduler
We’re shipping an upgrade to the FlowTransactionScheduler contract that simplifies how transaction priority limits work under the hood. The result is a scheduler that’s faster to execute and cheaper to run — and you don’t need to change anything in your code to benefit from it.
Here’s what’s changing, why it matters, and what you need to know.
A Quick Primer: How the Scheduler Works
The FlowTransactionScheduler assigns transactions to time slots based on their priority — High, Medium, or Low. Each slot has a limited amount of “effort” (a measure of computational work) it can absorb, and that effort is divided up among the three priority tiers.
Before this upgrade, the scheduler used a somewhat complex model: each priority had its own reserved effort budget, but High and Medium priorities also shared a common pool of additional effort they could draw from. The logic to track and enforce that shared pool added overhead to every scheduling decision.
What’s Changing
We’re removing the shared pool entirely. Instead, each priority tier now gets its own independent, fixed budget:
| Priority | Effort Limit |
|---|---|
| High | 15,000 |
| Medium | 7,500 |
| Low | 2,500 |
These numbers are identical to the effective limits that existed before — the old reserved + shared pool math happened to produce the same ceilings. So scheduling capacity is unchanged. What’s gone is all the cross-priority bookkeeping logic that tracked how much of the shared pool each priority had consumed.
The simpler model means the scheduler can make scheduling decisions faster and with less computation, which reduces the cost of every transaction that interacts with it.
The One Behavioral Change Worth Knowing About
There is one meaningful behavioral difference, and it’s actually a good thing for developers using low priority transactions:
Previously, High and Medium priority transactions could “bump” Low priority transactions out of their slots when they needed more effort capacity. Low priority transactions would be rescheduled to a later slot.
After this upgrade, that no longer happens. Each priority operates in its own lane. Low priority transactions stay in the slot they were assigned to and are not displaced by higher priority traffic.
If you submit low priority transactions, they will now have more predictable scheduling behavior. Your transactions stay put.
No Changes Required on Your End
This upgrade is fully backward compatible. You do not need to update any transactions, scripts, or application code. The same APIs work the same way. The only thing that changes is the internal logic of how the contract tracks and enforces effort limits.
Upgrade Schedule
| Network | Upgrade Date |
|---|---|
| Testnet | March 3, 2025 |
| Mainnet | March 10, 2025 |
If you want to dig into the technical details of the changes, you can review the full PR here: onflow/flow-core-contracts #580.
As always, reach out in the Flow developer Discord if you have any questions.