Solana's Job Is to Sell Computational Resources. Today It Gives Them Away.

SIMD-0553 was authored by our engineer cavey (@cavemanloverboy). As the discussion period opens, he has published the full motivating argument as a paper, "Motivating a Resource and Inclusion Fee on Solana," dated August 4, 2026. This post walks through it.

Actionable insights

SIMD-0553 splits Solana's 5,000 lamport base fee into a flat 2,500 lamport inclusion fee paid to the leader and a resource fee, burned in full, computed from the cost units a transaction requests. Our earlier post covered the mechanism and the burn math. This paper covers the part that decides whether the proposal is right: the economics.

The argument in one line is that Solana's only product is computational resources, and it currently sells them for nothing. An entire day of the network's resources can be bought for as little as 72 SOL. A zero-priority transaction that does nothing costs exactly as much as one that consumes 1.4M compute units and loads 64 MB of account data.

That mispricing has four expensive consequences. Market makers pay roughly 394 SOL a year — almost $30,000 — to post one transaction per slot on a single market, on a network where every other venue in finance charges them nothing to quote. Crank searchers take just under a third of SOL-USDC arbitrage volume and about 25% of the profit while paying almost nothing for the write locks and compute they consume. App developers have no incentive to optimize, which is why several popular DEXes still spend over 100,000 cost units per swap. And SOL holders have no exposure at all to the network's actual business.

The paper also sizes the prize. On June 26, 2026, US equities traded $2.0T notional across 158M trades; NASDAQ alone did $543.8B. Supporting that on Solana requires the average swap to fit in roughly 37,000 cost units. Jupiter currently averages 51,249 compute units per successful invocation, at a 30.5% success rate. And compute units are only a subset of cost units.

Solana's only job

Solana is not a memecoin exchange. It is the world's fastest global state machine: an operating system that lets exchanges exist and compete with one another. In that role it promises builders reliable storage and availability of state, and access to compute. In other words, it promises access to computational resources. That is Solana's sole job.

Yet it sells those resources at zero cost. Fill 216,000 blocks with max-cost, zero-priority transactions and the whole day's capacity goes for 72 SOL. Across all activity on the network, roughly 3,000 SOL is burned per week, and more than half of that comes from votes. Before SIMD-0096, the network burned 17,700 SOL daily.

Not pricing resources is not just bad business economics and a nuisance-level DoS vector. It is a failure to align anyone:

• Core devs, paid in SOL, gain very little from doubling the network's resource consumption capacity, and even if they do the work, nothing guarantees the onchain systems will be efficient enough to use it.
• Validators, paid in SOL, gain little from upgrading hardware to help Solana sell even more of their resources at zero cost.
• App builders gain very little from optimizing their programs to use less state and compute.
• Crank searchers pay nothing extra for bloated onchain programs, for write-locking and serializing transaction processing, or for being toxic to market makers.
• SOL holders have no exposure to the use of computational resources on Solana.

Under an inclusion fee plus a burned resource fee, every one of those flips. Core devs and validators are rewarded for raising resource consumption capacity. Builders keep more of the user's fee by being efficient, and unlike a fee on volume, they retain all the upside from their application. Toxic takers must widen their minimum edge slightly, since swaps consume more resources than quote updates, which reduces their toxicity to market makers. Market makers see their operating costs fall on both CLOBs and prop AMMs. And SOL holders stop being guaranteed perpetual dilution.

The landscape: Solana is a memecoin chain

On August 3, 2026, the last completed day before the paper was written, Solana saw $1.54B in total DEX volume, with memes making up 34% of it. Filter out SOL-stablecoin traffic and the picture is unambiguous: the primary reason users have been on Solana for the past few years is to trade memes. Eight of the top ten protocols by 30-day app revenue service the meme sector.

Monthly spot volume by pair category, SOL-stablecoin excluded (top), and the August 3 breakdown (bottom). Source: Blockworks.

Billions of dollars have flowed to these protocols and the intermediaries around them: launchpads, terminals, transaction landing services, DEXes, routers, data providers. So how much of that value reaches SOL?

Very little. Take Pump.fun, the largest protocol in the sector and about 25% of Solana REV: roughly 12% of that value reaches validators as fees and tips, and a fraction of that reaches stakers depending on commission. Almost none of it reaches the token. Meanwhile, on any given recent day, 34.2% of the network's consumed compute units come from Pump.fun programs.

Spot markets, and what quoting costs

The other half of Solana's volume is SOL-stablecoin pairs, and it has been a resounding success. The firms operating there are highly sophisticated: globally distributed infrastructure, private fiber and microwave links, advanced quantitative pricing. These are exactly the market makers we want on Solana as tokenized stocks and real world assets come onchain.

So what are their pain points? Fees, toxic takers, and scheduling.

On every venue with meaningful volume — NASDAQ, Hyperliquid, the full suite of CEXes — market makers are not charged for updating quotes. They are charged on fills. Exchanges on Solana work this way too; the Phoenix CLOB takes 0.5–5 bps per fill depending on the market. But because those exchanges sit on Solana, makers still pay L1 fees on every quote update. They are already incentivized to optimize their programs for scheduling priority, and they receive no fee reduction for using fewer resources. The toxic takers consuming 200x more resources pay the same base fee.

These fees are not small. One transaction per market per slot costs a maker approximately 394 SOL per year, or almost $30,000 at current prices, before toxic takers or priority fees. The paper leaves it as an exercise to work out what it would cost to quote all 500 constituents of the S&P 500 if SOL returned to $200. The answer is in a footnote: $42M. Now try two updates per slot.

Toxic takers

The SOL-stablecoin markets are cutthroat, and atomic arbitrage between venues is often toxic. Searchers are clever, relentless, and will work around a prop AMM's path-dependent curve to arbitrage the same pair four times inside a single transaction for cents of edge.

One transaction, four round trips between HumidiFi and SolFi V2, cents of edge.

Solana's current architecture lets searchers hunt arbitrarily small atomic arbitrage across many venues online, and because nothing charges for resources consumed, the profitable strategy is to spam compute-intensive transactions that write-lock and load many accounts. Arbitrageurs are often credited with making markets more efficient by closing price discrepancies. Yet Solana — the validator set, and SOL the token — gets very little in exchange for providing the computational resources that make those markets possible.

Two-leg SOL/USDC atomic arbs over the trailing 30 days. Row 1: most profit and volume occurs where transaction cost is under 1% of gross profit. Row 2: when searchers are forced to bid against each other, e.g. via the Jito auction, more value returns to stakers. Row 3: most arbitrage happens outside such auction mechanisms.

Daily top-10 crank bots on SOL/USDC, same binning. Crank searchers account for just under a third of SOL-USDC volume and about 25% of the profit, overwhelmingly in the bucket where transaction cost is under 1% of gross profit.

A resource fee lets the network charge these searchers appropriately for the write locks they take, the accounts they load, and the compute they consume, which pushes the ecosystem toward informed and reactive searching rather than blind spam.

Eyes on the prize

Memes may be a significant source of revenue for Solana, and they may stay around forever, but memetic finance is utterly dwarfed by the rest of finance.

The total cumulative volume of all DEXes on Solana since genesis, across all venues and assets, is $4.3T, and that double-counts multi-leg hops. On June 26, 2026 alone, US equities traded $2.0T notional over 158M trades. The NASDAQ by itself did $543.8B that day.

What would it take for Solana to support that? With a budget of 100M cost units per block, 158M trades over 6.5 hours — 6,752 swaps per second — requires the average swap to fit in 37,025 cost units, assuming nothing else happens on the network. No failing swaps, no market makers updating quotes, no stablecoin transfers, no derivatives, no prediction markets, no credit, no memes, and no allowance for the bursty nature of trading.

For reference, Jupiter averages 51,249 compute units per successful invocation at a 30.5% success rate, and compute units are only a subset of cost units, which also cover signatures, loaded account data, instruction data size, and write locks.

We are a long way from that. But it is not otherworldly, and it is obtainable with a fair bit of work on two fronts: the clients and the onchain programs.

Front one: the clients

Agave has done an incredible amount of work over the last two years, taking the network from struggling with 48M cost unit blocks to comfortably supporting 100M. Firedancer, which had its first mainnet release the day the paper was written, shows there is further to go. And Mithril recently found a technique that gets 1M TPS of ed25519 sigverify on 8 Zen5 cores instead of 20, which meaningfully reduces CPU load during exactly the bursts we need to handle.

Runtime cost distributions for Firedancer (top) and Agave via Frankendancer (bottom) on a large representative sample of mainnet traffic. Firedancer shows significantly lower mean and variance of execution time for the same transactions.

Firedancer is a 1.48–2.26× speedup over Agave depending on the aggregation.

Having multiple client teams has been a net positive: it has cleaned up the protocol and surfaced optimizations that improve every client. But no client has yet reached anything like an optimal implementation capable of carrying the world's financial traffic, and that work needs to be supported and incentivized.

Front two: the onchain programs

Onchain programs are in a similar place, and this is where the paper is bluntest. With the latest p-token upgrade, two token transfers — the rawest form of a swap — cost on the order of 2,000 compute units after CPI overhead. Everything beyond that is the DEX's own overhead. A HumidiFi swap alone consumes on the order of 43,000 cost units, already above the 37,000 we calculated is needed to carry a record NASDAQ day. Other DEXes fare far worse, with several popular ones over 100,000 cost units per swap, and splitting a single swap across venues multiplies the problem.

Onchain programs are by far Solana's weakest link when it comes to performance, and an incentive is needed to push the ecosystem to do better.

There is hope. Archer Finance recently launched on mainnet with mind-blowing performance:

An Archer two-leg SOL/USDC arbitrage for half a cent of edge, consuming 60,366 compute units total. To be clear: that is not 60,366 CU for a swap. That is an arbitrage program, with its own overhead, invoking two swaps via Archer: the first took 19,309 CU and the second 18,460.

Those costs are far below what a record equity trading day requires, and the program is still far from optimal.

Left: Archer's CEO on SIMD-0553. Right: Archer's quote-update and cancel costs, orders of magnitude below previous central limit order books on Solana.

As written, SIMD-0553 reduces costs for makers on all prop AMMs, Archer, and Phoenix Eternal by as much as 22%, and gives users a slight incentive to route through efficient DEXes like HumidiFi and Archer because the resource fee is lower. Solana needs more programs like Archer, and a resource fee is how you get developers to build them.

The architecture, and why it burns

In order of importance, the resource fee exists to:

1. Add an incentive for builders to reduce the resource footprint of their applications. This is a blocker to bringing all of finance onchain, and a large enough reason for the resource fee on its own.
2. Slightly raise costs for inefficient searchers, encouraging informed and reactive searching over blind spam, and reducing toxicity on market makers.
3. Slightly lower market maker operating costs.
4. Stop perpetually diluting SOL holders.

Note what objective 1 is not: a tax on application revenue. Anyone building on Solana keeps their upside beyond fixed resource costs, with no incentive created for offchain payments or state rollups. Secondarily, the fee gives validators and core devs a direct reason to maximize the network's resource consumption capacity.

Why burn the resource fee? Give any portion of it to validators or their stakers and you change blockbuilding incentives: validators become incentivized to accept less efficient transactions. Prop AMMs, whose success rests in large part on the efficiency asymmetry between oracle updates and swaps, would suffer as validators start preferring toxic swaps over oracle updates. Burning keeps the market structure intact, and it is the simpler, less disruptive change. There is also a fairness argument: the fee charges for the cluster's resources, and the validator is a small part of the cluster. When a crank arbitrageur lands a 600k CU series of swaps, every validator verifies the signatures, parses the accounts, loads them, and executes.

Why doesn't the inclusion fee scale with signatures? Because the resource fee already charges for them, at 720 cost units per top-level ed25519 signature. Signature verification is just another use of the cluster's computational resources and should never have had a special carveout.

Why have an inclusion fee at all? Four reasons, in order: validator income must not be disrupted too much; the minimum transaction cost must not fall so far that it opens a DoS vector (today's cost model does not account for broadcasting the transaction, so the inclusion fee could fairly be called a broadcast fee); with zero priority and zero inclusion fee a validator earns exactly nothing for including a transaction; and every draft of Multiple Concurrent Proposers so far has an inclusion fee paid directly to the proposer, so this design is compatible with whatever MCP turns out to be.

Picking the parameters

The two numbers to set are the inclusion fee and the resource rate. SIMD-0553 sets them at 2,500 lamports and a terminal 1/2 lamport per cost unit.

The inclusion fee is the easy one. About 96.5% of transactions carry a single signature, and the average over the last 24 hours is roughly 1.04 signatures per transaction, so there is no room to move 2,500 without materially affecting validator rewards.

The rate is harder, and the paper derives it by squeezing three separate bounds:

CDF of non-vote requested compute units (n = 6,419,833). Median request is 99,152 CU; p10 and p90 are 1,910 and 421,017.

• Requiring the most efficient transactions to get cheaper caps the rate near 2.5 lamports per cost unit. The theoretical minimum transaction is 1,020 cost units, so at 2.5 the cheapest possible fee is 5,050 lamports, just above today's 5,000. That bound is set by a noop transaction, so it would still raise fees on market makers.
• Matching the burn rate to the terminal inflation rate, at current supply and current traffic, gives about 1.5.
• Giving market makers roughly a 20% discount on their non-priority fees pulls it down to about 0.5. This leaves Solana inflationary at today's traffic but leaves room to match the burn rate if adoption grows, and pre-Alpenglow it also cuts validator operating costs.

Base fees in lamports implied by the requested-CU distribution above, for a zero-priority one-signature transaction, at each ramp rate (inclusion fee 2,500 + resource fee).

At the terminal rate, the most computationally intensive transaction anyone can construct costs 0.000789083 SOL, just over 5 cents at current prices, and just over 21 cents at all-time highs. The p90 median priority fee is currently 17,809 lamports, so the p90 resource fee would run more than ten times that. Worth repeating: these are today's requested resources, before application optimization, before people start requesting accurately, and before any second-order effects.

Total fees in lamports for example mainnet transactions, including unchanged priority fees. Low-resource traffic gets cheaper at the terminal rate; compute-heavy zero-priority traffic pays more.

One detail deserves its own callout, because it is the cheapest fix available to any developer reading this. If a transaction does not specify a limit for loaded account data, the runtime defaults to 64 MB and charges 16,384 cost units for it. Partitioning five full days of mainnet traffic by whether budgets were set explicitly or left at defaults:

Requested cost units and implied fees at the terminal 1/2 rate, where fee = 2,500 + ⌈CU/2⌉ at zero priority. Leaving the 64 MB loaded-data default roughly doubles median cost versus setting both budgets explicitly. Data from Umberto.

Setting both budgets explicitly is a one-line change that roughly halves your median fee under this proposal.

The steelman

The paper closes by making the three strongest counterarguments as well as it can, then responding. Reproduced in that spirit:

1. Validator income falls

The flat inclusion fee does not scale with signatures, so every signature beyond the first stops paying an incremental base fee. Over a recent 24-hour window there were 14,225,546 such extra signatures across all multi-signature transactions.

At 2,500 lamports each, that is a total income loss of approximately 35.56 SOL per day across all validators. A small validator with 200k SOL staked can expect to lose about 0.01 SOL per day. The paper's response is short: this is not substantial.

2. Charge fees on volume instead

Charging for resources is not enough. If exchanges on Solana succeed, it is because of Solana's network effects, and we should be able to monetize that. Resource usage and transaction value have little correlation, and SOL should have exposure to the success of the applications on top of it. There is precedent: Hyperliquid commands several bps on all volume, Apple takes 30% of in-app revenue.

Response: fees-on-volume is a way to generate revenue and a burn, but it lacks the rest of the benefits and adds unique downsides. The incentive structure is different for everyone: validators and core devs gain nothing from a faster chain, businesses are taxed and pushed toward moving activity offchain to stablecoin rails or state rollups, and developers get no reason to optimize. Every concrete proposal so far has been invasive, such as an enshrined toll in the token program, which would break many DeFi applications, is easily circumvented by forking the token program, and is incompatible with confidential transfers. And the analogy is weak: Hyperliquid and Apple both have enshrined exchanges. If Solana wants fees on volume, it must enshrine an exchange too. That is not a recommendation.

3. Transactions get more expensive and more complicated

A zero-priority Pump.fun swap jumps roughly 32× at the terminal rate, the median non-vote request goes from 5,000 to about 52,000 lamports, and p90 exceeds 200,000. Absolute lamports may still be fractions of a cent, but the proposal risks harming the activity it hopes to monetize and pricing out use cases. Because the fee keys off requested rather than consumed cost, it also taxes legacy defaults and cautious over-estimates, and users often have no way to know exactly how many resources they need, so tightening budgets will cause more failures. On complexity: it replaces a two-part fee users can reason about with three components that mix compute units (priority fee) and cost units (resource fee), at a time when core devs were planning to remove CUs from the protocol entirely because metering is inaccurate and expensive.

Response: the number one way to improve capacity on Solana right now is optimal onchain programs, which would help throughput far more than removing metering, and getting them requires incentivizing developers to write them. That easily justifies slightly more complex fees. The resource fee also adds no new metering and makes none of it more complex; it uses values already present in the protocol.

Conclusion

Solana's job is to sell computational resources. Today it gives them away. The diffuse benefit core devs and validators capture from increased network activity is not proportional to the increase in resource consumption, app developers are not incentivized to optimize, and SOL holders have no direct exposure to the network's actual business.

The inclusion and resource fee corrects this without a punitive tax on app developers or validators. At the terminal rate of 0.5 lamports per cost unit, the costliest transaction that can be constructed is about $0.05. Developers who have already gone to great lengths to optimize — market makers above all — see their costs fall. The traffic which consumes the most and pays the least sees costs rise, in proportion to what it takes from the network.

A record day on the NASDAQ is $543,800,000,000 in volume. Solana could not support that today. Closing the gap requires faster clients, lower quoting costs, and more efficient onchain programs. SIMD-0553 aligns the incentives of every participant toward exactly that, and improves the robustness of SOL's tokenomics on the way.

Temporal is a Solana R&D firm. We build some of the fastest infrastructure on the network and live downstream of its fee mechanics every day, so transaction pricing is not an abstract interest for us. If you have a counterargument we did not steelman well enough, the discussion is open.

cavey thanks Frank for reviewing the paper, and Umberto and Blockworks for the data and analysis behind several of its figures and tables.

Sources and further reading

• SIMD-0553 PR #553 and discussion #547
• Our earlier analysis: Solana Prices Signatures and Nothing Else. SIMD-0553 Prices Everything.
• Blockworks Solana spot DEX analytics and 21Shares Solana key metrics
• Dune: compute units and router stats, cumulative DEX volume, budget-setting cohorts
• Cboe US equities historical market volume
• Overclock Validator: narya-ed25519
• The Archer arbitrage transaction
• burn.cavey.xyz