Share this post

Return to Blog

From RPC Usage to LAVA Demand

News
Lava Foundation
Aug 20, 2026

Where Post Two Left It

Post one asked whether Lava should keep running a chain of its own. Post two answered: Lava is better off as a smart contract protocol hosted by another chain, the EVM family is the better place to host it, and which network is still open.

That is a change of venue for Lava's rules, not a change of what Lava does. Providers still serve RPC requests and customers still pay for them. What changes is where the rules live, what surrounds them, and what the token is for.

This post should be read conditionally throughout. It sets out the tokenomics questions that arise if the community chooses the rebuild, and assumes no approval that has not been given.

The Big Change

Lava stops running a validator set of its own. Five things follow from that one removal.

  • A whole layer drops out. Consensus stops being something Lava pays for, operates, or writes code for. That job passes to a network that already does it for thousands of other applications, and Lava is left with the part that is actually its own.
  • The maintenance shrinks to almost nothing. 10 times since the chain went live, every machine running it has had to stop at the same point and restart on new software at the same moment. Lava also runs a modified copy of the Cosmos toolkit, and every time the original moves on, engineers redo the modifications for nothing a user ever sees. Coordinating those halts, maintaining the private copy and keeping the validator set online all go with the chain. Contracts still need care once they are deployed, but almost none of the machinery around them survives.
  • The protocol gets simpler. Lava runs 13 modules of its own, roughly 40,000 handwritten lines. One of them exists only because the chain has two different things to stake to. It duplicates every validator delegation into a parallel provider delegation so that providers get a say in consensus, and it does so through 11 hooks into the staking lifecycle. Close to 4,000 lines solving a problem that exists only because validators and providers are separate.
  • Providers become the only role, and take the rewards alone. Today the rewards are split between two groups. Of the LAVA that actually reaches anyone each month, roughly 91% goes to validators and 9% to providers, close to 8,300,000 LAVA a year paying to keep a chain secure rather than to serve requests. With no validator set there is one role in the system, one thing to stake to, and one claimant on everything distributed.
  • The security base gets larger. Rather than resting on Lava's own validator set, staked and locked LAVA would sit behind a far larger network, and fewer lines of Lava's own code means fewer places for a bug that only Lava can find. The limit is worth stating plainly. A bigger network protects the deposits, not the keys, and key control stays Lava's problem to solve.

What The EVM Ecosystem Adds

The other half of the change is where Lava lands. An established environment supplies things an app chain has to build or commission for itself.

  • Reach. LAVA today is native to Lava's own chain. Holding it, staking it or voting with it means using that chain's own wallets and explorer, and going looking for them first. As an ERC-20 it would arrive into tools that already exist and are dramatically more popular. Every major wallet already supports an established EVM network, the venues that list assets already serve it, and the largest DeFi protocols are already deployed on it. None of them would have to add support for a new chain first.
  • Fit. About 80% of the work Lava was paid for last month was serving EVM chains, and 75% of providers already run an EVM node. Standards already exist for what the design needs, including one account covering another's fee and charging per API call.
  • Consolidation. Today LAVA exists in two forms. The native token on Lava's own chain, where staking and governance happen, and a wrapped version on an EVM network, where most trading happens. A holder who wants both has to bridge between them, and neither side sees the whole picture.

Taken together, the token should end up in better shape.

  • One token rather than two forms, so a holder no longer chooses between staking and liquidity.
  • Reachable by anyone already holding a standard wallet, with no new chain to add first.
  • Listed and integrated as ordinary work by exchanges and DeFi protocols, rather than as a bespoke job for each one.
  • Rewards where users already are, so revenue and the token sit in the same environment.

What is given up. Lava would no longer set its own rules on speed, capacity and transaction cost, and it would pay those costs in a token it does not issue.

Reopening The Tokenomics

Everything above changes what the token is for. Three things put the current tokenomics in question. The first two follow from the change itself. The third does not.

  1. The validator economy goes. Block rewards, transaction fees, commissions on delegated stake and Validator Drops all exist to keep a chain of Lava's own secure. Without that chain, none of them has a job.
  2. The environment changes. A contract protocol inherits standards and payment rails an app chain has to build for itself, and gives up control over fees and block space. Rules written for a chain Lava controls do not automatically fit a protocol hosted somewhere it does not.
  3. 2 years of evidence. Some assumptions in the original design held and some did not. The burn figures below are one example.

None of the three says what the tokenomics should become. What they say together is that the current model cannot be assumed to fit the new setting. The risk lies in leaving the question closed rather than in opening it, because a model carried across unexamined would produce outcomes nobody chose. What follows are the specifics.

Burning Tokens Nobody Held

The most fundamental change is already described above. Staking stops being split, and providers become the only thing to stake to.

The burn mechanism is the next example, and the easiest one to judge, because Lava already runs it and there are 2 years of figures to look at. Current burns come mostly from unused Provider Drops and Validator Drops, tokens that are locked, undistributed, or not yet circulating. Burning them reduces total supply on paper, but it has no direct effect on the market, because those tokens were never circulating, never sold, and never bought from the market before being burned. The current working figures:

  • Average monthly burn: 1,340,274 LAVA, equal to 0.14% of total supply and 0.25% of circulating supply, almost all of it from locked or not yet circulating allocations.
  • Monthly Provider Drops: 1,375,000 LAVA. Burned: 1,305,000 LAVA, or 94.91%. Almost the entire provider allocation goes unclaimed.
  • Monthly Validator Drops: 708,333 LAVA. Burned: 20,000 LAVA, or 2.82%. Almost the entire validator allocation is claimed.

Those last two lines together are the finding. The burn looks large and does little, because what gets burned is the allocation nobody claimed, while what gets claimed is the allocation that pays for consensus. The mechanism reduces a number. It does not connect to anything a customer does.

The Alternative

The rebuilt model changes the starting point. Instead of beginning with allocations that were never distributed, it begins with money that customers actually paid.

  • Usage first. Paid RPC usage generates ecosystem revenue, and that revenue is used to purchase LAVA on the secondary market. The tokens involved are bought rather than unlocked, so they were already circulating before the mechanism touched them.
  • Providers, then the Fund. The purchased LAVA goes to providers as compensation and revenue, with a share held in the Assistance Fund.

Whether burning keeps any role alongside this is not decided here. The point is not the purchase in itself. It is that paid usage, provider compensation and the Assistance Fund would sit on one visible path, so anyone can follow how work delivered turns into LAVA allocated.

The Assistance Fund

The assistance fund was created last year as a temporary holding mechanism for LAVA, and this direction would expand and formalize its role as the link between usage and ecosystem tokenomics. A share of the purchased LAVA would be held there, giving the ecosystem a reserve funded by real usage rather than by unlocking allocations, and one the community can later point at whatever it decides serves the network, its participants and the product best.

This post does not decide how large the Fund should be, what share of purchased LAVA it should hold, or how that LAVA should later be treated. The Fund remains a holding mechanism here, not a commitment to burn, redistribute, or otherwise allocate the tokens. It is not a grants program, treasury, operating budget, maintenance reserve, or discretionary Foundation account. It gets a post of its own.

What This Means For LAVA

This would be the largest change to what LAVA is since the network launched. The token stops funding consensus and starts being bought with what customers pay.

An entire side of the economy retires with the validator set, including the 91% of monthly emission that today pays for a chain rather than for service. Providers become the only role the protocol serves and the only claimant on what is distributed. Staking, governance and liquidity end up in one token in one place, reachable from the wallets and protocols people already use.

The mechanism behind it is simple to state. Customers pay for RPC. That revenue buys LAVA on the open market. The LAVA goes to the providers who did the work, with a share held in the Assistance Fund.

This post does not ask anyone to decide policy. It asks for alignment on direction, and if the community chooses this one, the detail would be worked out publicly and a tokenholder vote would follow.


Share this post

Return to Blog