Discussion: Lava Architecture, Demand, and Tokenomics

🌋 General
1

Objective

We are opening an official, open-ended public discussion based on the three posts we published about Lava’s architecture and future direction. We want to examine what we built, how the surrounding ecosystem has changed, which architectural paths are available, and what those paths could mean for Lava’s participants and token utility.

This discussion is not a Temp Check, poll, governance proposal, formal vote request, migration approval, or tokenomics approval. No migration, destination chain, or contract deployment has been selected or approved.

What is Built, and One Open Question

Read the full post: What is Built, and One Open Question

In the first part, we described what we built and why the architecture made sense when Lava was started. We also looked at what the network has taught us through operating at scale, and at whether the assumptions behind a dedicated chain still fit the next phase of the protocol.

  • Lava is a decentralized RPC access protocol that routes application traffic to independent providers, measures the work they serve, and coordinates payment through protocol rules.
  • An app-chain was a credible choice in 2022 because a dedicated ledger provided a practical way to enforce rules, coordinate participants, and control the transaction environment.
  • The current chain is functioning and has supported meaningful provider participation, network coverage, RPC activity, settlement, and delegation. The question is not whether the chain failed.
  • The value we see in Lava is concentrated in the service layer: routing, metering, quality, provider relationships, and reliable access to blockchain data.
  • The chain performs an important settlement role, but it also depends on a wider support layer that includes wallets, explorers, indexers, SDK maintenance, CometBFT, IBC, staking interfaces, and other tooling.
  • Lava maintains a validator set, an upgrade pipeline, and a modified stack. These create ongoing operational and engineering obligations that are separate from building the service layer.
  • The open question is whether operating a dedicated Cosmos app-chain remains the best long-term fit for the protocol and its users.

The main point we want the community to challenge is the distinction between a chain that works today and an architecture that remains the best foundation for Lava over the next several years.

Evaluating the Alternatives

Read the full post: Part 2: Evaluating the Alternatives

In the second part, we examined the alternatives against the objectives raised in the first part. We compared continuing with a Lava-owned app-chain against operating Lava as a hosted smart-contract protocol, and then considered what characteristics a potential host environment would need.

  • Continuing with a Lava-owned app-chain remains the baseline and preserves direct control over rules, speed, costs, capacity, and the validator environment.
  • A hosted smart-contract model could reduce chain-specific code, validator coordination, custom upgrades, and the maintenance burden of keeping Lava’s own stack aligned.
  • A hosted model would also introduce dependencies on infrastructure maintained by others and reduce Lava’s control over speed, capacity, transaction costs, and parts of the security environment.
  • Security and key management remain central concerns. A larger host network may protect deposits and settlement, but it does not remove the responsibility for protecting the keys that control the protocol.
  • We compared the EVM and Solana families as possible environments. The comparison considered the needs of the protocol rather than assuming a particular chain in advance.
  • Relevant host-environment criteria include cost, speed, capacity, reliability, ecosystem reach, popularity, liquidity, and integration with wallets, exchanges, developers, and other infrastructure.
  • A rebuild could also make it possible to examine product improvements such as more frequent provider payments and shorter staking withdrawal periods. These are areas for evaluation, not commitments.
  • No destination chain has been selected. A specific network would require a separate evaluation against the relevant technical, security, economic, and ecosystem criteria.

The main points we want the community to examine are whether we have weighted the tradeoffs fairly, what we may have underestimated by leaving the current model, and what analysis is still missing before any future decision could be considered.

From RPC Usage to LAVA Demand

Read the full post: From RPC Usage to LAVA Demand

In the third part, we examined one limited consequence of a possible architectural change: the token mechanisms built around the current chain may not all remain relevant if the roles in the system change.

  • If Lava no longer operates its own validator set, Validator Drops may become redundant because the Lava validator role they support would no longer exist.
  • Unclaimed Provider Drops and Validator Drops are currently burned.
  • Burning tokens from non-circulating or unclaimed allocations has limited direct market impact because those tokens were not previously circulating in the market.
  • Gateway revenue paid into the Lava ecosystem is used to buy LAVA from the market, creating an existing connection between protocol activity and token demand.
  • If the architecture changes, tokenomics may need to be realigned with actual protocol usage and the roles that remain in the ecosystem.

The main point we want to raise is alignment. If the protocol architecture and participant roles change, the token utility and incentive structure should be examined against the system that actually remains.

Public Discussion

We invite the Cosmos ecosystem and the wider Lava community to engage in public discourse around the assumptions, tradeoffs, and open questions raised above. Please distinguish between facts, assumptions, questions, and recommendations, and ground responses in concrete technical, economic, operational, and ecosystem considerations.

This thread is intended to improve shared understanding and identify the questions that deserve further work. It does not ask the community to approve a migration or adopt a tokenomics policy.

3 Likes
2

I have two economic questions about the proposed relationship between real RPC usage and LAVA demand.

1. What revenue is actually required to buy LAVA?

The discussion says that Gateway revenue paid into the Lava ecosystem is used to buy LAVA from the market.

Could the team clarify exactly what qualifies as this revenue?

For example, if an enterprise customer pays Magma $100,000 for RPC services:

  • How much of that $100,000 is considered Lava ecosystem / Gateway revenue?

  • Is there a fixed contractual or protocol-defined percentage that must be used to buy LAVA?

  • How can the community independently verify that the corresponding fiat revenue resulted in actual LAVA purchases on the market?

The key issue is whether the link real commercial revenue → LAVA market demand is rule-based and auditable, rather than discretionary.

2. What creates net LAVA demand if providers need to sell their rewards?

For example:

Customer pays $100,000 → LAVA buys $100,000 worth of LAVA → providers receive LAVA → providers sell $80,000 of it to pay for servers, bandwidth, staff and other USD-denominated costs.

In that case, gross LAVA purchases are $100,000, but the net structural demand may be closer to $20,000.

So how is the model expected to avoid becoming mostly a circular:

fiat → LAVA purchase → provider reward → LAVA sale → fiat

flow?

Will providers receive part of their operating compensation directly in stablecoins, while some LAVA must remain staked/locked as economic security? And will required LAVA stake scale with provider capacity, traffic or revenue?

For me, these two points are important for understanding whether RPC growth creates persistent economic demand for LAVA, rather than only temporary trading volume.

3

Hello, Avi from Kleomedes here. Great questions from @AshPash above. I would like to build off these questions as well as add some of my own commentary on the situation.

  1. Lava Token – As an RPC provider, we definitely need to sell tokens to cover costs and also realize profit. Why does the LAVA token need to exist if the Foundation could simply pass on stablecoin revenue to providers? Governance is one utility, but beyond that, the token does not really seem necessary at this stage. In a market downtrend, if one provider sells before another is able to, it essentially results in early sellers realizing more revenue for their services than later sellers. Obviously, the converse is true for uptrends, but providers need a steady source of revenue for their operations and cannot rely on volatility to juice their profits.
  2. Chain migration – if the Lava chain is not required for the product to work, then I see no reason why we should maintain it. Building on a Layer 2 does come with its inherent limitations, but it will not stop the product from being successful, which is really what matters. Retiring the chain should not be a controversial topic as the overhead (both cost and exploit risk) is not worth it.
  3. Tokenization Sandboxes – It has been mentioned several times on ecosystem calls that these new RWA Sandboxes are good for Lava’s growth, but it is still unclear to me how Lava benefits from tokenization of assets. Who realizes the revenue for these partnerships and what exactly is involved? Does Lava get paid a one time fee for integration or is there a broader maintenance cost associated with these products? I also heard that integration of these products has created an increase in relay traffic on Lava. Is that measured thus far? If anything, I have seen traffic decline month over month, and while performance is improving due to the Smart Router and provider optimizations, I do not see an increase in revenue for providers since the integration of these RWA tokenization products. It may be easier to see the growth if there was a transparent data dashboard that showed relays in aggregate and also broke down relays by product (ie, RWA/tokenization sandboxes, subscription RPC clients, etc).

I think one of my personal biggest concerns (which was also mentioned by Ash) is that the entire business structure of Lava / Magma is very opaque. Magma and Lava both have sizable teams, how are these currently being paid for if the token price has suffered so much? Are they taking a cut from Lava RPC revenues / tokenization sandboxes? Is there a separate stablecoin treasury we aren’t aware of? Is there sufficient runway to perform the EVM migration successfully? How much RPC / tokenization revenue goes directly to those entities and how much flows to Lava buybacks? Is there a dashboard that clearly shows the flow of these tokens?

In order to be taken seriously (like Hyperliquid, Lighter, etc) there needs to be some degree of transparency when it comes to the revenue distribution / buy backs and the overall finances of the foundation & labs co supporting it. Also, given that I doubt the foundation would be in support of retiring the token entirely, I think the new tokenomics model should include a usage burn, which will also address the issue of currently burning non-circulating tokens.

For example, for every dollar spent on relays, 15% goes to the treasury, 80% is spent on buying back the token and distributing to providers, and then 5% is spent on a buy back and burn of LAVA tokens. Having a deflationary token could eventually lead to value creation for the token through scarcity as long as the demand for the product continues to increase. This could help offset some of the concerns I mentioned early about the token just being an unnecessary intermediary.

Anoter thing to consider… Pocket Network (another RPC network) performs a thorough accounting of all finances from the foundation side and publishes it quarterly. You an see the latest one from Q2 2026 here: PNF Financial Reporting - Q2 2026 P&L Statement - Announcements - Pocket Network Forum

I think it would be prudent that Lava does something like this if the goal is to maximize transparency during this transition period. Otherwise, the token and overall economics of the project are shrouded in too much ambiguity to be appealing to potential investors/funds who may otherwise want to capitalize on the infrastructure narrative this cycle.

1 Like
4

Strongly agree, especially on transparency. I would add that self-reported dashboards alone are not enough if the goal is to make the economics credible to serious investors and providers.

Ideally, Lava/Magma should combine:

  • quarterly financial reporting on revenue, expenses, treasury/runway, provider payouts and RWA-related activity;

  • full on-chain reconciliation for LAVA buybacks, burns and treasury flows;

  • and independent external attestation or audit of the fiat-side figures and the link between reported revenue and on-chain token flows.

The key point is verifiable transparency, not just published numbers.

If tokenomics are being redesigned now, this is probably the best moment to build that auditability into the model from day one.

5

Rather than adding costs to bring on an independent auditor, what Lava could do is make all of these metrics verifiable on chain by anyone. I can tell you right now there are 20+ providers who are more than happy to audit these metrics if there were public endpoints for all the metrics we mentioned above. Obviously that would mean Lava Foundation would need to provider addresses for all team related wallets, which they may not want to do, but I am just trying to be cognizant of tacking on extra costs at this stage.

6

I agree that anything already on-chain should ideally be verifiable directly by the community rather than relying on a report.

The remaining issue is the off-chain side. If Magma receives enterprise revenue through fiat, invoices or Stripe, on-chain data can prove what was transferred into the Lava ecosystem, but not whether that amount represents all eligible revenue.

So perhaps the strongest model is hybrid:

  • full public on-chain visibility for buybacks, burns, provider rewards, treasury and team-related wallets;

  • plus a lightweight independent attestation of the off-chain revenue figures and the formula connecting that revenue to on-chain flows.

That would keep costs much lower than a full quarterly audit while still making the critical fiat → protocol → LAVA relationship independently verifiable.

7

It’s important not to create new tokens and diluate investors because if not will be the end of the project .

I saw this on several projects that changed the tokenomics, like router protocol - that went from 100 M mc to 100 k and end of the project announced yesterday, ORAI that went from 150 M to 5M, and severral more . If you betray investors , you will pay it. What you think you will earn with new tokens, although are vested, you will lost with the dump of price.

The other thing that i woud suggest is that the ones that are being paid with LAVA or stable coin for their work have to hold a considerable ammount of lava on their wallet to be able to provide their work .

8

We run a validator on Lava mainnet, so I’ll comment from that side, because the three posts don’t really touch it

The options as laid out are about where the protocol lives and how the token captures value

Reasonable questions, and I don’t have a strong view on the destination. But whichever way it goes, there’s ~389M LAVA bonded to validators right now behind a 21-day unbonding period, and nothing in the discussion says what happens to it

What I’d want written down before a Temp Check rather than after:

– if the chain is retired or the protocol moves, what’s the path for bonded stake — unbond and bridge, a snapshot, something else?
– does unbonding stay at 21 days through a transition, or is there a window where it changes?
– the performance-track delegation program pays against a score that only exists on this chain

Does it end, move, or get replaced?
– if a validator set is no longer needed, is there a wind-down period, and roughly how long?

None of that is an argument against migrating. If the chain genuinely isn’t required for the product to work, Avi’s point stands and I’d rather hear it said plainly than have it drift

The one thing I’d push back on: the discussion frames this almost entirely around demand and token utility. The validator set is also part of what makes the chain credible to the people running providers on it. If it’s being wound down, saying so early is worth more than a tidy transition later

Unrelated but possibly useful — we’ve been measuring the validator set fairly closely (we reconstructed the Polli scoring arithmetic and worked out what blockTimingScore actually measures, since it isn’t documented anywhere). If any of that data helps the tokenomics side of this discussion, it’s yours

9

Thanks everyone for the thoughtful questions and feedback. I wanted to come back and clarify a few points, particularly around how the system works today, some of the implications of the architecture being discussed, and the different considerations that remain open for the community to discuss and ultimately decide.

1. How is Gateway usage actually connected to LAVA?

Today, 100% of the revenue generated from paid RPC subscriptions through the Lava Gateway is used to purchase LAVA from the open market.

We operate this on a monthly cycle, from the 17th to the 17th. At the end of each cycle, the revenue generated during that period is used to purchase LAVA from the market, and that LAVA is then distributed back into the ecosystem as rewards.

So, at a high level, the flow today is:

Paid Gateway usage → revenue → LAVA purchased from the market → ecosystem rewards

The LAVA purchased is not simply acquired and held by the Foundation; revenue generated by the product is converted into LAVA and then distributed back into the network.

2. How are those rewards distributed today?

Once the LAVA is purchased from the open market, it is allocated across specs based on usage and demand.

Within each spec, the current distribution is:

  • 5% to validators
  • 2% to the community pool
  • 0–5% spec fee, where applicable. This mechanism is generally no longer used, although some older specs may still have a fee configured.
  • The remainder goes to providers

Providers and validators can also receive delegations and set their own commission rates. Their respective rewards are then shared with their delegators based on those commission parameters.

This is simply a description of how the network operates today. Whether these percentages remain the same, change, or are removed entirely under a future architecture is still open for discussion.

3. What about providers receiving LAVA and then selling it to cover costs?

Providers are businesses with real operating costs, so it is reasonable to expect that some will sell part of the LAVA they earn to cover infrastructure and other expenses. Others may choose to hold or stake their rewards.

I think the more fundamental question is whether the service economy of the network should continue to be aligned around LAVA.

Users don’t necessarily need to interact directly with the token. They can pay for Lava services in fiat or stablecoins, while LAVA remains the monetary reward mechanism on the service side of the network.

There are parallels with how other decentralized infrastructure networks approach this. Chainlink, for example, allows service fees to originate in fiat or other digital assets through its Payment Abstraction mechanism, with those payments converted into LINK, while LINK remains the native asset used for network payments, incentives and security.

The general principle is therefore that the payment experience for customers can be abstracted from the token while the network’s service economy remains aligned around its native asset.

That said, the future tokenomics are not predetermined. If the community wants to propose a different model for provider compensation or the broader economics of the network, that would need to be properly researched and discussed as part of this process.

4. How can the Gateway revenue → LAVA rewards flow be made more transparent and verifiable?

We agree that greater transparency is important, but we believe it should be built into the protocol design itself, rather than relying on additional reports or manual disclosures.

The goal should be for the relevant data and flows to be available onchain by design, so that anyone, through any explorer or analytics interface, can independently verify the revenue flow, the LAVA entering the system, and how those rewards are ultimately distributed across the ecosystem.

In other words, transparency should be a property of the protocol, not an additional reporting layer on top of it.

5. How do Sandboxes benefit Lava and the network?

Sandboxes are an excellent way for the Foundation to bring in new subscriptions. Through our existing network, we connect organizations looking to build, primarily tokenization projects, with experienced technical teams.

The benefit to Lava is direct: these organizations use Lava, buy Gateway subscriptions, and begin migrating their own infrastructure to Lava.

This creates paying demand for the network and contributes to ecosystem rewards.

The revenue generated by those Gateway subscriptions follows the same flow described above: it is used to purchase LAVA from the market, which is then distributed through the network.

6. Would a migration create additional LAVA or dilute existing holders?

The Foundation has never considered a migration model other than a 1:1 migration.

There is no intention for the migration itself to create additional economic supply or dilute existing holders.

If members of the community want to propose changes to supply or broader tokenomics, that would be a separate community proposal. It would need to be properly researched, openly discussed and ultimately go through the appropriate governance process.

So migration itself should not be confused with a proposal to increase LAVA supply.

7. What happens to validators and delegators if Lava moves away from its own chain?

Under the architecture currently being discussed, validators would no longer exist as a protocol role within Lava.

Existing validators could of course continue participating in the ecosystem if they choose to operate provider infrastructure.

For delegators, they will retain access to their tokens and will ultimately be able to decide whether they want to delegate to providers.

However, we are still very early in this process, and the exact mechanics for existing delegations during a migration have not yet been defined. This includes the precise treatment of delegations currently made to validators versus those already delegated to providers.

Rather than speculate on those mechanics now, we will define them properly as the migration design becomes more concrete.

8. What has actually been decided?

This is probably the most important point to reiterate: nothing being discussed here should be interpreted as a final decision.

The Foundation is creating a space for these discussions to happen openly so the community can understand the different tradeoffs and form its own position.

When we eventually reach the point where there is something concrete enough for a temp check and/or governance proposal, tokenholders will have the opportunity to vote.

Until then, these are open discussions about the direction Lava could take, not an announcement that those decisions have already been made.

10

Thanks, this clarifies the current Gateway mechanism significantly. I still have two related questions that seem important for evaluating LAVA’s long-term economics.

1. What exactly is included in the “100% of Gateway revenue” that is used to buy LAVA?

If Magma receives, for example, $100,000 from an enterprise customer, does the full $100,000 necessarily become paid Gateway subscription revenue and therefore result in $100,000 of LAVA purchases?

Or does this rule apply only to the portion specifically booked as Gateway subscription revenue, while other commercial revenue may remain outside this mechanism?

In particular, does the 100% rule include revenue from:

  • enterprise customers using Smart Router;

  • custom integrations;

  • RWA/tokenization partnerships;

  • implementation or maintenance services;

  • and other commercial activity performed by Magma?

If not, how is the portion attributable to the Lava ecosystem determined?

And because much of this revenue may originate off-chain in fiat, how will the community be able to verify that the reported eligible revenue matches the amount of LAVA actually purchased on the market?

2. What creates persistent net demand for LAVA after providers receive those tokens?

Using a simple example:

$100,000 Gateway revenue → $100,000 of LAVA purchased → most of that LAVA distributed to providers → providers sell a significant part to pay servers, bandwidth, employees and other fiat-denominated operating costs.

If providers sell, for example, $80,000 of the $100,000 they receive, the system has created $100,000 of gross buy demand, but potentially only around $20,000 of persistent net demand.

So what is expected to prevent the model from becoming mostly:

fiat → LAVA purchase → provider reward → LAVA sale → fiat?

Is the future model expected to create a meaningful reason for LAVA to remain in the system through mechanisms such as:

  • required provider staking or collateral;

  • stake that scales with traffic, capacity, revenue or economic exposure;

  • delegation;

  • locking periods;

  • meaningful slashing;

  • a reserve;

  • market-purchased burn;

  • or another form of value capture?

I think the distinction between gross LAVA purchases and persistent net LAVA demand is critical. It determines whether growing RPC revenue creates lasting economic demand for LAVA, or mainly increases token turnover between customers, the protocol and providers.

11

I think the core trade-off of the proposed migration is not simply operational complexity or cost.

It is sovereignty.

By running its own app-chain, Lava currently has direct control over its validator set, blockspace, execution environment, upgrades, fees, network parameters and settlement layer. Moving to a hosted smart-contract model means giving up a significant degree of that control in exchange for the infrastructure, security, liquidity and ecosystem of another chain.

I think this trade-off deserves much more explicit discussion.

The key question for me is therefore:

What capabilities and strategic flexibility is Lava giving up by no longer operating its own network, and are the benefits of moving to a hosted environment sufficient to justify that loss of sovereignty?

There is also an important long-term consideration: Lava is building infrastructure for decentralized RPC access. Having its own network gives Lava the ability to design the settlement and incentive layer specifically around the needs of providers, consumers and the RPC marketplace.

If Lava becomes a smart-contract protocol hosted by another chain, how much of that design freedom is lost?

I’m not necessarily against migration. But I would like to see a clear comparison of:

Lava-owned chain → maximum sovereignty, higher operational burden

vs.

Hosted smart-contract → lower operational burden, but greater dependency on another network

before making the decision.

And if migration happens, I think preserving as much economic and strategic sovereignty as possible should be an explicit design goal.

12

Lava Can have POS in a host chain like arbitrum one with contracts if you want to mantain the same method of economy, but without dedicating resources for security and mantainance of cosmos chain

13

1. What revenue is publicly reported?

The revenue we announce publicly is revenue generated by RPC services provided by the ecosystem.

Magma Devs is a separate entity from the Foundation. Smart Router is a Magma Devs product, and some Smart Router customers have purchased Gateway subscriptions through Magma Devs. In this context, Magma Devs functions as a commercial customer-acquisition channel for Gateway RPC services.

Sandboxes, through its RWA partnerships, works similarly by introducing RPC users to the Gateway.

The Gateway has only recently launched. The Foundation is currently absorbing setup, accounting, legal, and similar fees as part of the initial growth phase. We are not currently taxing or deducting from this revenue. At present, 100% of the Gateway RPC revenue goes into the network.

2. Does this create persistent demand for LAVA?

Recurring Gateway usage creates recurring demand because Gateway revenue is used to acquire LAVA from the market.

From my personal perspective I would not frame provider selling as the primary concern. Over the past year, most providers have operated infrastructure with very limited profit margins, and many remain committed to the project rather than treating their rewards as immediate sell pressure.

The relative scale also matters. Based on August’s figures:

  • Total network rewards: approximately 1.5M LAVA

  • Provider and staker allocation: approximately 1.395M LAVA

  • Estimated provider share: approximately 1.05M LAVA

  • Monthly vesting: approximately 21M LAVA

Provider rewards are therefore roughly 5% of monthly vesting, or about twenty times smaller. The larger market-supply question has historically been investor vesting and other unlocks, not provider rewards.

Chainlink is broadly similar in that service revenue, token rewards, staking, and ecosystem incentives all interact. The important point is to evaluate the full token flow across providers, validators, stakers, investors, vesting, buybacks, and burns.

We will also be proposing a new tokenomics model soon, which should provide a clearer long-term framework for demand, incentives, and value capture.

3. Why consider moving to a hosted chain?

This is a fair concern, and we agree that moving to a hosted environment involves a tradeoff in sovereignty.

The reason to consider it is that operating a base layer is not the core product we are building. Lava’s core focus is the product layer: RPC services, routing, provider coordination, customer experience, and network economics.

By externalizing the base-layer infrastructure to a specialized third party, Lava could reduce operational overhead and focus more resources on improving the network itself. EVM ecosystems are also attractive because they generally provide broader developer tooling, integrations, liquidity, audits, and ecosystem support than Cosmos.

This does not mean giving up control over the product. Lava would still need to control its application logic, provider mechanisms, reward design, and network policies. The tradeoff is that some infrastructure-level responsibilities would depend on the selected chain, including execution, fees, blockspace, upgrades, and base-layer security.

No destination chain has been selected. Any decision would need to consider security, reliability, cost, interoperability, portability, governance, and exit options.

1 Like
14

Thanks, :handshake: this makes the current economics much clearer. Since provider rewards are currently only ~5% of monthly vesting, it seems vesting is the dominant supply pressure today. As vesting declines, however, provider rewards and Gateway-driven LAVA purchases will become much more important to the equilibrium. Will the upcoming tokenomics proposal quantify this transition, including projected vesting, Gateway buy demand, provider selling/staking, burns and net circulating supply over time?

15

Thanks for raising this @AshPash. The fourth blog in this series will outline what the Foundation believes would be meaningful improvements to Lava’s tokenomics. Your suggested breakdown is useful feedback on what a detailed tokenomics proposal should address.

However, I’d like to make an important distinction: the migration decision and any tokenomics changes should be considered separately. The main purpose of this forum discussion is to gather community feedback on whether Lava should continue operating its own chain. Supporting a migration should not automatically mean approving a particular tokenomics model.

So far, most comments have been positive or neutral toward exploring a migration, with many focused on understanding the situation and its implications.

We’d like to hear from more community members, so please help bring others into the discussion. We’ll then submit a governance proposal to vote on whether to move forward with a migration. If approved, the Foundation will continue its research and begin development, openly sharing which destination chains we’re considering and the reasons behind our recommendation. Any proposed tokenomics changes will follow a separate process for community discussion and decision-making.

1 Like
16

Any public updates on the economic/tokenomics side since the last discussion? Given the recent price action, I suspect quite a few holders are wondering the same thing :slightly_smiling_face: