Note: This template may be adapted slightly to suit the purpose and scope of each proposal.

Abstract

[A brief overview of the proposal, its main features, and expected impact]

Motivation

[Explain the motivation behind this proposal]

Features & Specification

[Introduction of any new features including detailed technical specifications for the proposed upgrade]

Rationale

[Explanation for the reasoning behind design decisions]

Security Considerations

[Discuss security implications, potential risks, and how they are being addressed]

References & Relevant Discussions

[List any relevant external references, resources, and prior discussions]

We should have this same construction, to align app developers incentives with veLITKEY voters.

Abstract

This proposal introduces the veLITKEY model, a mechanism that permanently aligns LITKEY token issuance with network productivity and revenue generation. The model transitions Lit Protocol into a self-sustaining, revenue-backed economy governed by stakeholders.

Through veLITKEY staking, token holders gain long-term governance over ecosystem funding, with inflation protection applying to voting weight. Ecosystem builders are rewarded via vote dictated rewards based on real usage, ensuring that incentives flow to productive participants.

Motivation

As Lit Protocol’s network matures beyond its initial v1 DKG launch and establishes stable on-chain revenue streams, a new token model is needed to:

• Align incentives between token holders, node operators, and application developers.

• Transition from campaign-based emissions to sustainable, revenue-linked rewards.

• Empower governance to direct ecosystem growth through transparent, data-driven voting.

• Reward productivity by subsidizing the builders and applications that drive real usage and network fees.

The veLITKEY process embeds revenue alignment and governance into the token’s issuance, while maintaining a fixed total supply.

Specification

1. Overview

After the Lit V1 Distributed Key Generation (DKG), the veLITKEY model activates with the following flow:

• LITKEY holders stake their tokens to receive veLITKEY, a time-weighted governance ability.

• veLITKEY holders earn network revenue.

• veLITKEY governance allocates periodic emissions (subsidies) toward productive builders based on voting outcomes.

2. Network Revenue Distribution

Each one month epoch, protocol revenue is distributed as follows:

Revenue is distributed in $LITKEY. When the network receives tokens other than LITKEY, these will immediately be converted to the network token.

As a result of voting, builder rewards vest linearly for three months.

Revenue Sources:

• Products & Protocols built on Lit Protocol pay directly on a per-request or compute basis.

• Applications and Wallets integrating Lit pay on a performance or swap-based model.

• Blockchains that fork Lit pay via license fees.

All of these groups are eligible to receive votes from veLITKEY holders and earn rewards.

3. Voting & Rewards

Voting

• veLITKEY holders vote monthly on which ecosystem applications receive emission subsidies.

• When veLITKEY holders unstake, their voting power decays linearly with time.

• Builders may offer bribes (token incentives) to attract votes via a canonical contract for transparency, for example:

  “Each veLITKEY vote for Project X earns you n Project tokens.”

Eligibility

• Any application that generated network revenue in the prior month is eligible for rewards.

• Rewards are distributed proportionally to the votes received.

Governance Enforcement

• A majority of veLITKEY holders can ban builders from future reward eligibility.

4. Emission & Subsidy Model

Purpose

To permanently align token issuance with network productivity while maintaining a fixed supply.

Early ecosystem growth is rewarded through the pre-allocated subsidy pool. Once the network reaches sustainable revenue, the system transitions entirely to rewards granted via the onchain endowment.

5. Endowment Transition

At genesis, no new tokens are minted and later after the 250M $LITKEY subsidy pool is exhausted, rewards for builders require a new source.

That source is an onchain endowment, funded by ongoing protocol revenues and yield from held assets.

• The endowment becomes the permanent, non-inflationary source of future builder and ecosystem rewards.

• veLITKEY governance directs how endowment yield is distributed or reinvested.

• This ensures long-term sustainability: the network lives on its own economic productivity rather than continual token issuance.

6. Bootstrapping Implementation

• During the first six months post-TGE, 2% of total supply (20 M $LITKEY) is allocated to reward emissions.

• Additional tranches from the ecosystem reward pool are released gradually as revenue milestones are achieved, up to the $100 M revenue mark.

• After that milestone, the system transitions fully to endowment-funded rewards, completing the move to a fixed-supply, self-sustaining economy.

7. Emission Function

Let:

Eₜ = f(Rₜ, Rₜₒₜₐₗ)

Where:

• Eₜ — LITKEY emitted in epoch t
• Rₜ — Revenue earned in epoch t
• Rₜₒₜₐₗ — Cumulative network revenue since DKG

Emission Function (Front-Loaded, Piecewise-Linear)

We use two straight segments that integrate exactly to 250,000,000 LITKEY over $0–$100,000,000 cumulative revenue:

• Segment A (early boost): 15.0 → 2.0 LITKEY / $ over $0–$20M
• Segment B (glide down): 2.0 → 0.0 LITKEY / $ over $20M–$100M

This front-loads the earliest revenue (bigger first-$1M payout) and trims the $30–$100M tail.

Definitions:

• R_total = cumulative revenue since DKG (USD)
• R_t = revenue in epoch t (USD)
• M(R_total) = multiplier in LITKEY per $1 revenue
• E_t = M(R_total) * R_t

Multiplier:

• If 0 ≤ R_total < 20,000,000:
  M(R_total) = 15 − 13 * (R_total / 20,000,000)

• If 20,000,000 ≤ R_total < 100,000,000:
  M(R_total) = 2 * (100,000,000 − R_total) / 80,000,000

• If R_total ≥ 100,000,000:
  M(R_total) = 0

Why it sums to 250M:

• Area [0, 20M): 170,000,000 LITKEY
• Area [20M, 100M): 80,000,000 LITKEY
• Total = 250,000,000 LITKEY

Solidity reference:

function currentMultiplier(uint256 cumulativeRevenueUsd) public pure returns (uint256) {
    if (cumulativeRevenueUsd >= 100_000_000) return 0;

    if (cumulativeRevenueUsd < 20_000_000) {
        // 15e18 - (13e18 * R / 20_000_000)
        return 15e18 - (cumulativeRevenueUsd * 13e18) / 20_000_000;
    }

    // 2e18 * (100_000_000 - R) / 80_000_000
    return (2e18 * (100_000_000 - cumulativeRevenueUsd)) / 80_000_000;
}

​​Governance

• veLITKEY holders exercise control of emission distribution via monthly votes.

• veLITKEY holders manage eligibility lists by banning malicious or inactive builders

• If desired, veLITKEY holders can establish minimum/maximum per-builder allocation per epoch for anti-dust or anti-dominance measures.

• Smart contracts execute onchain disbursements

• Lit Association manages the endowment in accordance with charter and token holder mandates.

Security Considerations

• Governance capture by large holders may skew emission distribution; mitigated through time-locking and bribe transparency.

9. Illustrative Example

To demonstrate how veLITKEY governance, revenue sharing, and reward emissions interact, consider the following simplified scenario.

Setup

Prior month network revenue (Epoch One)

• Project Alpha: $60,000
• Project Omega: $40,000
• Total: $100,000

Reward multiplier: 10× → TokenBudget₂ = 1,000,000 LITKEY

veLITKEY governance power:

• Alice — 50% → votes for Alpha with all her power
• Bob — 30% → votes for Omega with all his power
• Charlie — 20% → votes half for Alpha and half for Omega

Reward Distribution

(Payment starts at the beginning of Epoch Two, vests linearly over 3 months)

• Project Alpha: 60% of votes × 1,000,000 LITKEY = 600,000 LITKEY
• Project Omega: 40% of votes × 1,000,000 LITKEY = 400,000 LITKEY

Note: These emissions are price-agnostic — they depend only on network revenue and the multiplier, not the token’s market price.

Real-Time Revenue Sharing (during Epoch Two)

Revenue generated in Epoch Two streams directly to veLITKEY voters for each project, in proportion to their vote weight within that project (not globally).

If a voter changes allocations mid-epoch, the live revenue split updates accordingly for the remainder of that epoch.

Additionally, Team Omega could bribe ve holders (e.g., 1 Omega Token per veLITKEY vote) to attract additional votes in the next epoch, thereby influencing future reward distribution.

veLITKEY holder interface mock up for example:

veLITKEY Rationale

The veLITKEY model merges Curve-style voting escrow with real revenue coupling to align incentives between builders, holders, and the network itself.

• Incentive precision:
  Emissions and subsidies flow only to builders who generate verifiable network revenue. This ensures that inflation directly funds productive activity, not speculation.

• Community autonomy:
  veLITKEY holders direct token emissions through transparent onchain voting. Governance effectively decides where growth capital goes each epoch, making Lit a self-governing economic engine.

• Front-loaded growth:
  The bootstrap curve is intentionally steep early, concentrating rewards where they have the highest marginal impact — bootstrapping usage, liquidity, and developer activity in the first $20M of cumulative revenue.

• Sustainability:
  As network revenue scales, emissions decay linearly to zero, ensuring the token model transitions naturally into a yield driven permanence.

• Sovereign economic development:
  By tying issuance to measurable productivity of decentralized keys, the model transforms the LITKEY economy into a self-sustaining ecosystem — one where governance replaces central grants, and upgrading the world to decentralized keys becomes a collective mandate rather than a top-down mission.

Backwards Compatibility

This proposal introduces no breaking changes to the existing LITKEY token supply, holder balances, or previously deployed contracts.
The veLITKEY staking and emission logic activate only after the DKG launch and operate in parallel with existing network functionality.**

Reference Implementation**

Smart contracts governing staking, voting, emissions, and the endowment treasury will be deployed post-V1 DKG.

Reference code and simulations will be published under litprotocol/velitkey on GitHub.

1. Protocol Level Improvements: Proposals in this category should involve upgrading, improving, or expanding the feature set of the core Lit Protocol node software.

2. Ecosystem Growth and Treasury Allocation: Proposals in this category should be focused on allocating treasury funds to further the growth of the Lit Protocol ecosystem. This encompasses OSS development, hackathons, community events / activations, and related ventures.

3. Governance Improvement Proposals: Proposals in this category should concern “metagovernance” decisions, such as proposing an adjustment to governance workflows and voting thresholds.

Please follow the appropriate template according to the category you’re focused on which are included below.

Lit Protocol

The Lit Protocol Developer Forum is the home of the Lit Protocol developer community.

Here are some things you can do to get started:

Introduce yourself by adding your picture and information about yourself and your interests to your profile. What is one thing you’d like to be asked about?

Get to know the community by browsing discussions that are already happening here. When you find a post interesting, informative, or entertaining, use the to show your appreciation or support!

Contribute by commenting, sharing your own perspective, asking questions, or offering feedback in the discussion. Before replying or starting new topics, please review the Community Guidelines.

If you need help or have a suggestion, feel free to ask in Site Feedback or contact the admins.