Discussion: Lava Architecture, Demand, and Tokenomics

🌋 General
21

Following up on my earlier post, now from both sides: since Sept 19 we also run a provider (AXELAR), alongside our validator.

Two concrete things from the provider side I’d want in the migration design:

  1. Claim costs. Our AXELAR provider submits around 100 relay-payment claims a day, for well under $1/day of rewards at current prices. That only works because claims are nearly free here. On a host chain where every claim pays gas, smaller specs and smaller providers stop being worth serving unless settlement is aggregated (batched claims or periodic settlement). I’d make that an explicit criterion when comparing destination chains.

  2. Stake continuity. Provider self-stake is currently delegated to validators through dual staking, and validators are going away. Carrying bonded positions over 1:1, via a snapshot or direct conversion, would avoid pushing everyone through the same 21-day unbond at the same moment, which is exactly the sell wave nobody needs.

And one from the validator side: a defined wind-down with advance notice, at least a couple of reward cycles, so validator infrastructure can move to provider work in an orderly way rather than being switched off overnight.

Happy to share our claim and traffic numbers if they help with the cost comparison.

1 Like
22

Cito mentioned that maintaining a large validator set can make it harder to build an economic flywheel where LAVA is directly tied to actual product usage. I think this is probably the key point for token holders.

Could the upcoming tokenomics framework explain what that post-migration flywheel would actually look like?

In particular:

  • what creates structural demand for LAVA once validator staking disappears;
  • what providers will be required to stake or lock, and whether that scales with traffic, capacity or revenue;
  • how delegation and slashing will work;
  • how Gateway/RPC revenue translates into persistent value capture rather than only buy → reward → provider sell;
  • and what role buybacks, burns, reserves or other mechanisms will have.

It would also be very helpful to see this framework before the migration governance vote, even if migration and tokenomics remain separate governance decisions. That way tokenholders can evaluate what economic model is expected to replace the validator-driven utility that would be removed.

23

+1 on seeing the framework before the vote, from an operator’s angle: point 2 is the one that changes our decisions right now. We’re sizing provider stake for the next specs this month, and “5k LAVA minimum per spec” vs “stake that scales with traffic or capacity” are very different capital plans. Even a direction of travel, published before the vote, would let operators plan instead of pausing.

1 Like
24

Thanks, @AshPash & @AntonM . I agree that these questions deserve clear answers, and Anton’s concerns about stake continuity and the validator wind-down also need to be addressed.

For clarification, the current model uses paid Gateway RPC revenue to purchase LAVA monthly on the open market. Those tokens are then distributed as rewards: currently 5% to validators, 2% to the community pool, any applicable spec fee, and the remainder to providers. This describes the existing model, not a proposed future model.

If Lava migrates away from operating its own Cosmos chain, the immediate impact should be lower operating costs and reduced ecosystem risk, not increased revenue. Retiring the validator set would reduce the burden of maintaining the Cosmos stack, upgrades, and related infrastructure, while also limiting Lava’s exposure to security incidents and coordination failures across the Cosmos ecosystem.

Recent hacks, together with concerns about how some incidents were handled by key ecosystem organizations, show that remaining in this environment carries meaningful risk. Staying on Cosmos is therefore not risk-free: it leaves Lava tied to infrastructure and security dependencies outside its core RPC mission. Migration should be viewed not only as a cost-reduction measure, but also as a way to reduce Lava’s exposure to those risks.

However, I think the EVM migration and any tokenomics redesign should remain separate proposals. Combining them could confuse the community about what it is actually voting on. A vote to migrate the chain should not be interpreted as approval of an unfinalized tokenomics model.

Keeping the two processes separate allows the community to evaluate the migration on its architectural, operational, and risk-reduction merits, while giving tokenomics the dedicated discussion and governance process it deserves.

1 Like
25

I understand the rationale for keeping migration and tokenomics as separate governance decisions. But I think this creates a significant sequencing risk for tokenholders.

A migration path may remove validator-driven LAVA utility while the economic model that is supposed to replace it is still undefined.

This creates an unusual governance situation: LAVA holders may be asked to use their tokens to approve a change that removes part of the existing economic utility of those same tokens, before they know what will replace it.

There is also a more fundamental theoretical risk. If the future architecture can function without a meaningful economic role for LAVA, tokenholders could effectively use LAVA governance to approve a system in which LAVA itself becomes economically unnecessary.

The tokens would still exist, of course, but holders may have voluntarily approved the removal of the utility and demand mechanisms that supported their economic relevance. In the extreme case, tokenholders could effectively vote themselves out of the economic model.

Once migration research, development and implementation are underway, the two decisions may remain formally separate, but become increasingly path-dependent and difficult to reverse in practice.

Would the Foundation therefore commit to publishing the proposed post-migration tokenomics framework and an economic impact model before any irreversible migration decision or implementation?

That would preserve separate governance decisions while allowing tokenholders to understand the full economic consequences of the architecture they are being asked to support.

Separating the votes makes sense. Separating the information needed to make those votes rationally does not.

1 Like
26

I agree that sequencing risk cuts both ways. Tokenholders should understand the potential economic consequences of migration, but delaying migration until tokenomics is finalized also carries a cost. At the time of writing, the Cosmos Hub chain has been halted for a little over 23 hours.

Whether this risk originates directly from Cosmos Hub or from an associated part of the broader Cosmos ecosystem is not the main point. The point is that Lava currently operates within an ecosystem where this kind of disruption is a real operational and security risk. Even if tokenholders approve the migration, implementation will take no less than six months, leaving Lava exposed to that environment during the transition.

It is also important to be precise about what the current proposal does and does not approve. Approving a chain migration would not, by itself, change tokenomics or the current protocol revenue model. It would not automatically remove LAVA utility, change revenue distribution, introduce buybacks or burns, or approve a replacement economic model. Those questions require separate decisions.

The purpose of this proposal is to evaluate chain migration, including its risks, benefits, costs, and operational consequences. Tokenomics is relevant context, but it should not be bundled into the migration vote in a way that confuses what tokenholders are actually approving. Separate votes do not mean hiding information or avoiding the economic discussion. They ensure that the migration vote does not pre-approve future tokenomics before that model has been fully analyzed and debated.

The Foundation will publish its final tokenomics analysis and proposed model after the migration vote ends. That will allow for a longer and more focused discussion around staking, validator utility, provider incentives, revenue capture, and related mechanisms, without conflating those issues with the architectural decision.

The immediate case for migration is not increased revenue or a promised new tokenomics model. It is reducing infrastructure burden, lowering costs, and reducing Lava’s exposure to operational and security risks within the Cosmos ecosystem.

After completing the migration vote, there will be the time and bandwidth to examine every aspect of tokenomics in greater depth. Each issue needs the appropriate space, and the discussions should remain separate so tokenholders and voters clearly understand what each vote is about.

27

Fair enough on separating the votes — and honestly six months of implementation makes that easier, not harder

But the two things you said need addressing aren’t really tokenomics. They’re transition mechanics, and they belong in the migration proposal itself:

– what happens to bonded stake. Carried over 1:1, a snapshot, a conversion, something else — or does everyone get pushed through a 21-day unbond at the same time
– how much notice validators get before the set is retired

Neither needs the token model finished. Both change what operators do between now and then. I’m sizing capital for the next specs right now, and “it carries over” vs “plan for a 21-day gap” are different decisions

Say what the plan is in the proposal and people can vote on the migration on its own merits, which is what you’re asking for anyway

Happy to walk through the path from our side if it helps — we run both a validator and a provider, so we’d hit both ends of it

28

Thanks, this clarifies the sequencing. I agree migration and tokenomics do not need to be bundled into one vote.

My concern is the minimum economic information tokenholders should have before approving migration.

If final tokenomics will only be published after the migration vote, could the Foundation at least publish a clear post-migration economic framework beforehand: which LAVA utilities disappear, which remain, how provider staking/delegation/slashing are expected to work, and how RPC usage creates persistent LAVA demand and value capture?

Exact parameters can still be decided later.

Architecture and tokenomics may be separate votes, but they are not economically independent. The architecture chosen first constrains the token model that can realistically follow.

29

Thanks both (@AshPash @AntonM) I think there are two separate points here.

On validator/delegation mechanics, I agree these are migration questions rather than tokenomics. Bonded stake, delegation handling, validator wind-down and notice periods will all need to be clearly defined before the existing validator set is retired.

What I would separate is that implementation work from the decision being asked now. The upcoming proposal is simply: should Lava move away from operating its own Cosmos chain and migrate to an EVM-based environment?

It is not yet selecting the destination chain or approving the technical migration design, so we don’t want to prematurely commit to whether bonded stake is handled through a snapshot, automatic migration, unbonding process or another mechanism before that design exists.

What we can commit to is developing a clear migration plan and sharing it with the community months ahead of implementation. Once that plan is ready, if there are concerns or feedback around how bonded stake, delegations, validator wind-down or any other part of the migration is handled, we are more than happy to discuss those points publicly and work with the community toward an approach that best serves the ecosystem.

What we can already say is that the migration is intended to remain 1:1, tokenholders retain their LAVA, and under the architecture being discussed Lava would no longer require its own validator set.

On tokenomics, I also agree that architecture and economics are related, but I want to clarify one point: the Foundation is not planning to publish “final tokenomics” after the migration vote.

The Foundation intends to publish an initial tokenomics draft as the starting point for community discussion. It will outline the initial thinking, trade-offs and possible mechanisms, and then evolve based on community feedback and further analysis before any concrete changes go through governance.

So migration does not automatically approve changes to provider staking, delegation, slashing, burns, buybacks, revenue distribution or other economic mechanisms. Those remain separate decisions.

The sequencing is closer to:

Migration decision → destination and technical design → detailed migration plan and transition mechanics

and separately:

Initial tokenomics draft → community discussion and iteration → governance process for any proposed changes

There will naturally be interaction between both workstreams, but approving the migration should not implicitly approve a future economic model.

30

Thank you to everyone who participated in the discussion about Lava’s architecture, operating model, and migration direction.

The community raised important questions about the benefits and tradeoffs of continuing to operate a dedicated Cosmos chain, including developer tooling, ecosystem support, operating complexity, provider economics, claim costs, stake continuity, validator operations, security, and long-term sustainability.

Based on the discussion, Lava is preparing to ask the community whether it should proceed with a process to move away from operating its own Cosmos chain and migrate to an EVM-based chain.

The Foundation has not selected a destination chain. If the proposal passes, the Foundation will transparently identify and evaluate candidate EVM chains, with attention to developer tools, technical stack, ecosystem, cost, reliability, capacity, security, and fit for Lava’s providers and users.

The upcoming governance proposal will address one question only:

Should Lava move away from operating its own Cosmos chain and migrate to an EVM-based chain?

This proposal will not select a specific EVM chain, approve a technical migration plan, or decide tokenomics. Tokenomics are outside the scope of this vote and will be addressed through a separate forum discussion and a separate governance process.

The governance proposal is scheduled to go live on Monday, September 28 at 12:00 UTC. The voting period will remain open for 4 days, until Friday, October 2 at 12:00 UTC.

Thank you again for the thoughtful questions, constructive criticism, and firsthand input from token holders, delegators, validators, providers, and community members.

Background

1 Like