From c650fd2e34bf996c975a80f29aa0b74e4b03a451 Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 10:39:49 +0200 Subject: [PATCH 1/7] governance, token, node ops docs for governance, token, and node operations --- docs.json | 40 +++++++++ governance/airdrop/claiming.mdx | 5 ++ governance/airdrop/eligibility-criteria.mdx | 5 ++ governance/airdrop/overview.mdx | 29 +++++++ governance/airdrop/rewards.mdx | 5 ++ governance/governance-architecture.mdx | 82 +++++++++++++++++++ governance/lit-improvement-proposals.mdx | 37 +++++++++ .../initial-allocation-and-distribution.mdx | 5 ++ governance/litkey/overview.mdx | 27 ++++++ governance/overview.mdx | 36 ++++++++ node-ops/overview.mdx | 17 ++++ node-ops/requirements.mdx | 57 +++++++++++++ node-ops/staking-and-delegation.mdx | 66 +++++++++++++++ node-ops/staking-contest/acquire-stake.mdx | 11 +++ node-ops/staking-contest/logistics.mdx | 33 ++++++++ node-ops/staking-contest/registration.mdx | 13 +++ 16 files changed, 468 insertions(+) create mode 100644 governance/airdrop/claiming.mdx create mode 100644 governance/airdrop/eligibility-criteria.mdx create mode 100644 governance/airdrop/overview.mdx create mode 100644 governance/airdrop/rewards.mdx create mode 100644 governance/governance-architecture.mdx create mode 100644 governance/lit-improvement-proposals.mdx create mode 100644 governance/litkey/initial-allocation-and-distribution.mdx create mode 100644 governance/litkey/overview.mdx create mode 100644 governance/overview.mdx create mode 100644 node-ops/overview.mdx create mode 100644 node-ops/requirements.mdx create mode 100644 node-ops/staking-and-delegation.mdx create mode 100644 node-ops/staking-contest/acquire-stake.mdx create mode 100644 node-ops/staking-contest/logistics.mdx create mode 100644 node-ops/staking-contest/registration.mdx diff --git a/docs.json b/docs.json index 8830e98..5b31da7 100644 --- a/docs.json +++ b/docs.json @@ -120,6 +120,46 @@ ] } ] + }, + { + "tab": "Governance", + "pages": [ + "governance/overview", + "governance/governance-architecture", + "governance/lit-improvement-proposals", + { + "group": "$LITKEY Token", + "pages": [ + "governance/litkey/overview", + "governance/litkey/initial-allocation-and-distribution" + ] + }, + { + "group": "Lit Protocol Airdrop: Season 1", + "pages": [ + "governance/airdrop/overview", + "governance/airdrop/eligibility-criteria", + "governance/airdrop/claiming", + "governance/airdrop/rewards" + ] + } + ] + }, + { + "tab": "Node Operations", + "pages": [ + "node-ops/overview", + "node-ops/requirements", + "node-ops/staking-and-delegation", + { + "group": "Lit Protocol v1: Node Operator Selection", + "pages": [ + "node-ops/staking-contest/logistics", + "node-ops/staking-contest/registration", + "node-ops/staking-contest/acquire-stake" + ] + } + ] } ] }, diff --git a/governance/airdrop/claiming.mdx b/governance/airdrop/claiming.mdx new file mode 100644 index 0000000..8c4eb20 --- /dev/null +++ b/governance/airdrop/claiming.mdx @@ -0,0 +1,5 @@ +--- +title: "Claiming Tokens" +--- + +Coming soon. \ No newline at end of file diff --git a/governance/airdrop/eligibility-criteria.mdx b/governance/airdrop/eligibility-criteria.mdx new file mode 100644 index 0000000..5717f3b --- /dev/null +++ b/governance/airdrop/eligibility-criteria.mdx @@ -0,0 +1,5 @@ +--- +title: "Season 1 Eligibility Criteria" +--- + +Coming soon. \ No newline at end of file diff --git a/governance/airdrop/overview.mdx b/governance/airdrop/overview.mdx new file mode 100644 index 0000000..2ab6123 --- /dev/null +++ b/governance/airdrop/overview.mdx @@ -0,0 +1,29 @@ +--- +title: "Lit Protocol Airdrop: Season 1" +--- + +The Season 1 Lit Protocol Airdrop is designed to reward early contributors who played a meaningful role in bootstrapping the Lit ecosystem. + +This first distribution includes a diverse group of participants across several categories: + +1. Node Operators who supported testnet deployments and secured early network activity. + +2. Builders who shipped applications or tools using Lit infrastructure. + +3. Core Integration Partners who integrated Lit into other protocols or tooling. + +4. Quest Participants who completed tasks in campaigns such as Ciphernaut’s Path. + +5. Discord Contributors who helped moderate, educate, and onboard within the Lit ecosystem. + +6. Other Select Groups identified for their impact during Lit’s early growth phase. + +## Check Your Eligibility + +To see if you're eligible for the Season 1 airdrop, visit the [Airdrop Eligibility Checker](https://staking.litprotocol.com/airdrop) on the staking portal. You’ll need to connect your wallet or enter an address to view your claim status and allocation details. + +## Not Eligible? Get Involved + +If you’re not eligible for Season 1, don’t worry — more opportunities to get rewarded for making contributions to the ecosystem are on the way. + +Lit’s airdrop program will continue through seasonal distributions, rewarding meaningful participation across protocol governance, app development, node operations, and community engagement. Season 2 is currently active, with additional reward distributions planned for contributors and developers participating now. \ No newline at end of file diff --git a/governance/airdrop/rewards.mdx b/governance/airdrop/rewards.mdx new file mode 100644 index 0000000..ed43461 --- /dev/null +++ b/governance/airdrop/rewards.mdx @@ -0,0 +1,5 @@ +--- +title: "Staking Rewards" +--- + +Coming soon. \ No newline at end of file diff --git a/governance/governance-architecture.mdx b/governance/governance-architecture.mdx new file mode 100644 index 0000000..12737dc --- /dev/null +++ b/governance/governance-architecture.mdx @@ -0,0 +1,82 @@ +--- +title: "Governance Architecture" +--- + +Lit Protocol’s governance system is built around four core areas of responsibility: + +1. Protocol Upgrades + +2. Ecosystem Funding and Resource Distribution + +3. Node Operator Onboarding and Coordination + +4. Metagovernance + +Each of these functions is administered by the Lit Association and the core development team in collaboration with the broader $LITKEY community. + +## Protocol Upgrades + +Protocol upgrades refer to updates to the core Lit Protocol software that node operators run. These updates may include performance improvements, security patches, support for new cryptographic primitives, or entirely new functionality. + +Upgrades are reviewed and approved by the Protocol Council, a group of core maintainers who coordinate updates via the Protocol Multi-Sig. This multisig acts as the final gatekeeper for pushing updates to the network. + +**Upgrade process**: + +1. Proposal and Review: Proposed builds are posted on the [governance forum](https://litprotocol.discourse.group/categories) for public review and comment at least one week prior to implementation. + +2. Feedback Consideration: Community feedback is encouraged and incorporated wherever possible. + +3. Approval and Release: Once reviewed and finalized, the build is approved by the Protocol Council and distributed to Lit Protocol node operators for installation. + +Protocol Council Multisig Address (2 of 3): +0xC6EBB3ca53D028F419F677Ed45126490331F728b + +## Ecosystem Funding and Resource Distribution + +To support application development, experimentation, and ecosystem growth, a portion of the Lit Protocol treasury will be distributed through structured funding cycles. These cycles allocate tokens to teams building useful tools and applications with Lit Protocol and Vincent. + +The first funding campaign will distribute over $1 million in token rewards to eligible builders. This includes: + +1. Developers creating apps and agent workflows using [Vincent](https://dashboard.heyvincent.ai/) + +2. Builders integrating Lit Protocol into existing or new cryptographic systems + +For full details, eligibility criteria, and submission guidelines, please reference the Lit Protocol [governance forum](https://litprotocol.discourse.group/). + +Future campaigns will be proposed and reviewed through a combination of internal working groups and public feedback, with community-driven selection processes gradually introduced over time. + +## Node Operations + +Lit remains a federated network at this stage. This means that the set of node operators responsible for performing threshold cryptographic operations is curated, but members of the community can openly participate pending they meet the hardware and staking requirements. + +New node operators will be approved, onboarded, and rotated on a quarterly basis, or sooner in the event of major network expansion (e.g. the launch of new [Realms](https://spark.litprotocol.com/enhancing-threshold-security-and-performance-at-scale-introducing-shadow-splicing/) to scale the network). +In the future, as the network scales and new Realms are spun up, new node operators may be selected for participation in specific Realms even outside of regular onboarding windows. + +The initial node operator set will be selected via a staking contest beginning after Lit’s token generation event (TGE). + +To learn more about node operations, please reference the [node operator](/node-ops/overview) docs. + +## Metagovernance + +As the network and governance processes evolve, mechanisms for decision-making, funding, upgrades, and node coordination will require ongoing refinement. This function—metagovernance—encompasses the rules and structures that govern the governance system itself. +Metagovernance includes: + +1. Adjusting quorum or voting thresholds + +2. Creating or deprecating working groups + +3. Modifying proposal flows or funding mechanisms + +4. Delegating additional responsibilities to the community over time + +Changes to any of these governance-level systems may be proposed through the Lit Improvement Proposal (LIP) process. LIPs are the primary method for community members to formally propose changes to any category outlined above. Read about the [LIP process](/governance/lit-improvement-proposals). + +## A Note on v0 Governance + +At launch, governance operations will be handled by the core development company working in collaboration with the Lit Association. Updates and transparency reports will be posted on the governance forum so the community can track decisions and outcomes. + +Because Lit Protocol has not yet launched its Naga mainnet, the scope of governance in v0 is intentionally limited. There is comparatively little to govern before mainnet is live, and changes to the initial governance structure will be introduced prior to the launch of Naga mainnet to support a broader and more decentralized system. + +During the first 30 days following the Lit Protocol TGE, the governance process will be refined and operational responsibilities gradually delegated to key stakeholders — including node operators, teams and individuals building on Lit and Vincent, and other external contributors — giving the wider ecosystem more control over governance operations. + +Feedback and suggestions on governance are encouraged and can be submitted via the [governance forum](https://litprotocol.discourse.group/). This phased approach makes the process transparent and allows the system to mature in step with the network’s evolution. diff --git a/governance/lit-improvement-proposals.mdx b/governance/lit-improvement-proposals.mdx new file mode 100644 index 0000000..36791b0 --- /dev/null +++ b/governance/lit-improvement-proposals.mdx @@ -0,0 +1,37 @@ +--- +title: "Lit Improvement Proposals (LIPs)" +--- + +Lit Improvement Proposals (LIPs) are used to propose new features and upgrades to the core Lit Protocol architecture (including smart contracts) and surrounding ecosystem. LIPs are organized into three categories based on their specific content and area of focus. As covered in the sections above, these categories include protocol level improvements, treasury allocation, and governance improvement proposals. LIPs are used to publicly and transparently track protocol upgrades, new features, and growth initiatives through a standardized template and workflow. + +All LIPs go through the LIP process (documented below) before being passed off to the Protocol Council for final review and approval. If approved, the proposal is then passed off to the relevant parties for execution / implementation. + +## LIP Process + +All LIPs are initially submitted and discussed in the relevant category of the Lit governance forum. After a given proposal has moved past the “idea” stage, it must be submitted as a pull request to the LIP repo on GitHub. + +All LIPs are tagged on the Lit governance forum and associated GitHub repo based on the specific stage they are in: + +- “Idea”: initial proposal ideas are submitted to the governance forum for discussion and refinement. +- “Draft”: after a proposal has moved past the “idea” stage, it is submitted to the LIP repo as an official draft proposal. The template can be found here. +- “Review”: after a draft proposal has been submitted, it is reviewed by the relevant parties which vary according to the context of the proposal itself. +- “Vote”: proposals that move to the “vote” stage are passed off to the Protocol Council for final review and approval. +- “Accepted”: proposals that have been reviewed and accepted by the Protocol Council. +- “Implementing”: proposals that are actively being implemented. +- “Completed”: proposals that have been accepted and implemented. +- “Rejected”: proposals that have been rejected by the Protocol Council. +- “Closed”: proposals that have been closed. + +## Lit Protocol Council Review Process + +After a LIP has been submitted as a draft and reviewed by the relevant stakeholders, it will be passed off to the Protocol Council for final review before it is either accepted (where it is then passed off to the relevant parties for implementation) or rejected. During the review process the Protocol Council will ensure that the proposal adheres to the Lit Protocol mission, values, growth objectives, and security considerations. + +After a given LIP has been reviewed, the Protocol Council will report their decision on the relevant forum discussion post where it will be updated accordingly. If the LIP has been accepted, this will include a link to the official Protocol Council vote conducted on-chain. If the LIP is rejected, the requested revisions and / or reasons for rejection will be published accordingly. + +## Submitting LIPs + +At this time, the Lit Protocol development company will be the primary party tasked with creating and submitting new LIPs. However, anyone can suggest improvements or changes by starting a discussion on the Lit governance forum using the applicable “idea” tag. All suggestions will be reviewed and prioritized according to current protocol objectives and available resources. + +As discussed in the sections above, the Protocol Council will be the core body tasked with reviewing and approving or rejecting all LIPs at this time. Once Lit Protocol and its associated governance processes have reached a greater level of maturity and stability, the Protocol Council may be dissolved entirely with governance decision making being passed off to relevant ecosystem stakeholders and working groups. + + diff --git a/governance/litkey/initial-allocation-and-distribution.mdx b/governance/litkey/initial-allocation-and-distribution.mdx new file mode 100644 index 0000000..0788587 --- /dev/null +++ b/governance/litkey/initial-allocation-and-distribution.mdx @@ -0,0 +1,5 @@ +--- +title: "Initial Allocation and Distribution" +--- + +Coming soon. \ No newline at end of file diff --git a/governance/litkey/overview.mdx b/governance/litkey/overview.mdx new file mode 100644 index 0000000..596dcdc --- /dev/null +++ b/governance/litkey/overview.mdx @@ -0,0 +1,27 @@ +--- +title: "Overview" +--- + +The $LITKEY token underpins the entire Lit Protocol ecosystem, serving as a multi-dimensional work, payment, and governance token. Together, these dimensions aim to facilitate a self-sustaining token economy in which tokens are staked to secure the network, used as rewards to incentivize operator participation, exchanged to access cryptographic services, and to govern the continued growth and development of the Lit ecosystem. + +## Work Token: Securing and Incentivizing Service Providers + +The primary function of $LITKEY is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. + +To participate in the Lit network, node operators must stake $LITKEY tokens, committing economic value to signal their reliability and long-term alignment with network security. This staking mechanism ensures that operators have a vested interest in maintaining uptime, executing cryptographic tasks correctly, and adhering to protocol rules. + +In addition to securing the network, $LITKEY is also used to compensate node operators who perform signing, encryption, and computation operations by running the core Lit software. The protocol distributes token rewards to operators based on a time-weighted staking mechanism, covered in depth in the [$LITKEY white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). + +## Payment Token: Paying for Network Services + +Beyond its role as a work token, $LITKEY also functions as a service payment token, facilitating both on-chain and off-chain operations with Lit. + +As the native gas token for the Lit Chain, Lit’s Arbitrum Orbit-based L3 rollup, $LITKEY is required to make any transactions on-chain, such as when generating new key pairs or staking. Aside from gas, $LITKEY is also to pay for signing, encryption, and compute operations provided by the network. Users and applications consuming Lit’s cryptographic services must pay per-transaction fees, ensuring that network resources are allocated efficiently while node operators are fairly compensated. Costs fluctuate based on demand, similar to gas-metering. + +## Governance Token: Steering Protocol Development + +$LITKEY will also serve as a governance token for the Lit Protocol ecosystem, enabling token holders to direct the ecosystem’s evolution through a decentralized, on-chain governance system. Individuals holding $LITKEY will play an important role in selecting network operators, suggesting core protocol upgrades and feature enhancements, distributing public goods and grants funding, and other related functions. Additionally, token holders influence ecosystem growth by shaping strategies for partnerships, integrations, and network expansion. As the protocol matures, these governance mechanisms will continue to evolve. + +At the onset of Lit v1, the Lit Protocol Council will be tasked with overseeing the governance process in tandem with $LITKEY token holders, as covered in depth in the [governance section](/goverance/overview). + + diff --git a/governance/overview.mdx b/governance/overview.mdx new file mode 100644 index 0000000..aaee8d2 --- /dev/null +++ b/governance/overview.mdx @@ -0,0 +1,36 @@ +--- +title: "Overview" +--- + +Lit Protocol has established an initial governance system to guide and organize its development and operations. This system exists to manage decision-making related to the core protocol, the infrastructure that supports it, and the broader ecosystem of applications built on top of it. + +## Purpose + +The purpose of Lit’s initial governance structure is to coordinate and oversee four key areas: + +1. Protocol Upgrades: Reviewing, approving, and distributing new software builds to node operators. + +2. Resource Allocation and Ecosystem Funding: Distributing capital and other resources to support teams building on top of Lit infrastructure. + +3. Node Operations: Setting and managing standards for node operator participation and performance. + +4. Metagovernance: Defining and evolving the structures, roles, and processes that govern Lit itself. + + +By establishing clear decision-making and implementation workflows around these areas, governance ensures that protocol development remains coherent, auditable, and extensible. + +## Governance Composition + +At launch, governance is managed by the Lit Association, a Swiss non-profit organization dedicated to stewarding the long-term growth of the protocol. In collaboration with the core development company behind Lit, the Association is responsible for maintaining key infrastructure, initiating governance processes, and coordinating core protocol operations. +While the Association will be tasked with helping steward initial participation in governance across the Lit ecosystem, operations will be passed down progressively to a broader set of stakeholders, including ecosystem developers, node operators, researchers, and community members. + +## What This Documentation Covers + +This governance documentation is divided into three sections: + +1. Overview (this page): Context and goals of Lit’s initial governance system. + +2. Governance Architecture: Breakdown of the specific components involved in protocol decision-making. + +3. Lit Improvement Proposals (LIPs): An introduction to the process for submitting formal proposals to improve the protocol or ecosystem. This section includes details on eligibility, formatting, submission, and approval workflows. + diff --git a/node-ops/overview.mdx b/node-ops/overview.mdx new file mode 100644 index 0000000..34c66a9 --- /dev/null +++ b/node-ops/overview.mdx @@ -0,0 +1,17 @@ +--- +title: "Overview" +--- + +Lit Protocol is secured and operated by a decentralized network of validator nodes. These nodes are responsible for executing the threshold cryptographic operations that underpin the core functionality of the network, including signing, encryption, decryption, and private compute via Lit Actions. + +Each node participates in threshold signature multi-party computation (TSS MPC) protocols and operates inside a confidential compute environment (TEE), ensuring that no single operator can access plaintext key material or violate policy constraints. + +Lit node operators are responsible for configuring and maintaining their secure hardware environment which collectively facilitate all network operations (i.e. generating key shares, executing Lit Actions, etc). For an in-depth review, check out the [security docs](/learning-lit/security). + +## Mainnet Node Operator Selection: The Staking Contest + +A staking and delegation contest will be run to select the genesis validator set for Lit Protocol’s upcoming Naga mainnet. The contest is open to anyone who meets the hardware and staking requirements and expectations which are covered in depth in the next section. + +To whitelist your node, visit https://staking.litprotocol.com/ + +Refer to the next page for details on hardware specs, minimum requirements, and operational guidelines for node operators. \ No newline at end of file diff --git a/node-ops/requirements.mdx b/node-ops/requirements.mdx new file mode 100644 index 0000000..b142fb3 --- /dev/null +++ b/node-ops/requirements.mdx @@ -0,0 +1,57 @@ +--- +title: "Requirements and Expectations" +--- + +This page outlines the technical and operational requirements for running a Lit Protocol node, as well as the current selection and onboarding process. If you’re considering participating in the Lit network as a node operator, please read this carefully. + +## Selection Process + +Lit Protocol is currently a federated network, meaning node operations are not fully permissionless at this time. Instead, validator participation is governed through Lit’s governance model and managed by the Lit Protocol Council. + +- Genesis Validator Set: The first group of mainnet validators will be chosen via staking and delegation. At the end of the staking contest, the top 10 operators based on their total stake weight will be selected as the genesis validator set. Read more about the initial selection process in the Staking Contest Docs. + +- Ongoing Onboarding: After the genesis validator set has been selected, new nodes will be onboarded or rotated quarterly or as needed (for example, if a node leaves, is slashed, or a new network/Realm is spun up). + +- Transparency Reports: The Protocol Council will publish transparency reports on the [governance forum](https://litprotocol.discourse.group/categories) whenever nodes leave or join the network. + +## Hardware Requirements + +To run a Lit Protocol node you will need robust, production-grade hardware capable of supporting confidential computing workloads. The current minimum requirements are: + +1. CPU: 64-core AMD EPYC Gen 3 or a 32-core dual-CPU setup + +2. RAM: 128 GB minimum + +3. Storage: Mirrored RAID, at least 400 GB + +4. Networking: Two dedicated IPs (one for the Host and one for the Guest VM where the Lit Node software runs) + +5. Operating System: Debian 12 (required for current Lit OS builds) + +**Important**: Only 3rd generation AMD EPYC processors currently support Lit OS. Support for newer generation processors is under development. Cloud deployment costs typically range from $750–$1,000/month, depending on the selected provider. + +## KYC / KYB Requirements + +Because Lit is a [threshold-based network](learning-lit/node-architecture), all node operators on a given network must be independent entities to maintain the integrity of the decentralized cryptographic operations and keys managed by the network. KYC/KYB verification ensures that no single operator controls more than one node on any public Lit network. + +## Staking and Delegation + +All node operators must stake a minimum of $20,000 worth of $LITKEY tokens as committed self-stake. This self-stake requirement is separate from any tokens that may be delegated to your node by external token holders. This requirement ensures that operators have economic skin in the game and are aligned with the long-term success of the protocol. + +- Staking enforces liveness and reliability by incentivizing operators to maintain uptime. +- Slashing disincentives are applied for downtime or malicious behavior. + +Read more in [Staking and Delegation](/node-ops/staking-and-delegation). + +## Deployment and Maintenance + +You only need to acquire node hardware once you have been officially selected as a node operator. Currently, 3rd generation AMD EPYC chips can be difficult to source; however, Lit has secured hardware inventory and partnered with data centers capable of deploying approved nodes. Node operators are responsible for: + +- Configuring and maintaining approved hardware environment +- Updating to new software releases as directed by Lit’s governance system and the Protocol Council +- Meeting uptime and performance expectations + +## Additional Resources + +- [Lit Staking Contest](/node-ops/staking-contest/logistics) +- [Staking and Delegation](/node-ops/staking-and-delegation) diff --git a/node-ops/staking-and-delegation.mdx b/node-ops/staking-and-delegation.mdx new file mode 100644 index 0000000..28da948 --- /dev/null +++ b/node-ops/staking-and-delegation.mdx @@ -0,0 +1,66 @@ +--- +title: "Staking and Delegation" +--- + +This page explains how staking and delegation works, including how to stake as a node operator, sourcing stake from external token holders, reward calculation and distribution, and slashing. + +## Staking Overview + +**Where Staking Takes Place**: All staking for Lit Protocol takes place on the official [Lit Protocol staking dashboard](https://staking.litprotocol.com/). This is where you will register your node, stake your LITKEY tokens, and claim rewards. + +**Rewards and Timelocks**: Node operators earn rewards for participating in active Lit networks. Rewards are calculated on a cost-plus basis with a timelock mechanism (covered below) that increases rewards for operators who lock their tokens for longer periods of time. This mechanism incentivizes stable participation and long-term alignment with the protocol. + +- Rewards are distributed programmatically via the Lit staking contract. +- Rewards are configured per network and may differ between [Realms](https://spark.litprotocol.com/enhancing-threshold-security-and-performance-at-scale-introducing-shadow-splicing/). +- Only active node operators—those selected to run a node—receive rewards. Standby operators do not earn rewards at this time. + +**Minimum Self-Stake Requirements**: All node operators must stake a minimum of $20,000 worth of LITKEY tokens as self-stake to be eligible. This minimum ensures each operator has skin in the game and meets the alignment criteria outlined in the [Requirements and Expectations](/node-ops/requirements) section. + +## Calculating Staking Rewards + +The Lit Protocol employs a dual reward structure to compensate node operators: + +1. **Cost-Based Component** +A baseline reward is allocated to each node operator to offset the expenses associated with the required hardware and infrastructure. The baseline reward amount may be adjusted periodically via governance to cover the real-world costs associated with node operations (e.g., server hosting) in their entirety, ensuring operators always break even on the costs associated with running a node and never operate at a net loss. The goal is to preserve a stable pool of node operators even during periods of market volatility, essential for maintaining the shared cryptographic secrets maintained by the network in perpetuity. + +Several configurable parameters go into setting the cost-based component of the Lit node rewards budget, including the price of the $LITKEY token, the costs associated with running a node (denominated in USD), and a target profit margin factor. + +2. **Stake-Weight Component** +Beyond the cost-based component, a staker’s total earnings will be distributed according to their relative stake-weight. This stake-weight component is calculated as a function of both the quantity of $LITKEY tokens staked as well as the length of time for which they are locked. This timelock can range from two weeks to two years, depending on the preferences of each individual staker. Longer lock durations yield higher multipliers on rewards, signaling greater commitment and aligning incentives toward long-term network sustainability. The relative nature of this weighting means that overall rewards depend not only on an individual’s stake but also on the staking decisions of other participants. + +For an in-depth look at the formula used to calculate stake weight and total reward distribution, please reference the [token white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). + +## Delegation + +After meeting the minimum self-stake requirement, any node operator can increase their total stake weight via delegation from LITKEY token holders. +- Any LITKEY holder can delegate to any node operator given they have registered their node on the staking portal. +- Delegated stake allows node operators to boost their rank during the staking contest, increasing the chance of being selected for the genesis validator set. +- Delegators retain ownership of their tokens while sharing in the staking rewards distributed to each node. + +## Commission + +Each node operator has the ability to set their own commission rate, which determines the percentage of staking rewards that are retained prior to being distributed to delegators. This allows operators to compete on both performance and pricing. Commission rates are managed and displayed on the Lit staking portal. + +## Slashing + +Slashing has been implemented to ensure that node operators keep their machines online and responsive at all times, preventing any downtime that could disrupt the network. Unlike some other protocols where slashing may also enforce computational ‘correctness,’ Lit Protocol relies on Trusted Execution Environments (TEEs) and threshold consensus mechanisms to guarantee the accuracy and integrity of operations. As a result, slashing in Lit Protocol is specifically designed to enforce availability and liveness rather than correctness. + +### Slashing Conditions + +Unresponsiveness: If a node operator is detected as unresponsive by its peers, it will be kicked from the active node operator set. To safeguard the network’s security, an immediate epoch transition is triggered, recalculating the threshold to two-thirds of the remaining active nodes. The kicked node will automatically attempt to rejoin the network in the next epoch, which occurs every hour, providing a built-in opportunity to recover from temporary issues. + +To prevent persistently faulty nodes from repeatedly disrupting the network, each node has a kick counter that increments each time they’re kicked. A node can be kicked up to 5 times before it is banned from the network. Upon exceeding this limit, the node is banned, and its locked stake is slashed by 5%. Additionally, if a node goes offline and doesn’t rejoin within a 24hr period, they are also banned and slashed. Once banned, the node operator must address the underlying issues causing unresponsiveness. The Lit Advisory Council will then manually review the node’s status and unban it only after confirming that it is stable and operational, ensuring that only reliable nodes are readmitted to the active set. + +To permit occasional and minor unresponsiveness without severely penalizing operators, a ‘decay’ mechanism has been implemented. The decay mechanism resets the kick counter at the end of each week, meaning a node can be kicked up to 5 times per decay period (1 week) before being slashed. This serves to strike a balance between enforcing network liveness and giving node operators fair opportunities to rectify temporary issues while protecting the network from chronic instability. + +Node operators may be penalized for a variety of reasons, each covered in detail below. Certain behaviors will result in immediate slashing (loss of stake and removal from the node operator set) while others will result in a warning being issued to the node operator. The node operator will have a pre-defined amount of time to address said warning (known as the “grace period”) before they are slashed. If said warning is addressed in a timely manner, the node will automatically be rejoined to the active node operator set. + +### Appeals + +Slashed funds are sent to a contract that is initially administered by the Lit Protocol Council. Slashed funds may be redistributed to node operators and/or token delegators if the slashing event is contested and deemed unjust according to the offense. + +### Governance Oversight + +Outside of integrating slashing outcomes with the Lit governance process to ensure consistent enforcement of rules while maintaining flexibility to address edge cases, the Lit Protocol Council will serve an important role in overseeing the parameters associated with the slashing process itself. This includes configuring the slashing penalty itself, as well as managing the kick counter and decay mechanism. + + diff --git a/node-ops/staking-contest/acquire-stake.mdx b/node-ops/staking-contest/acquire-stake.mdx new file mode 100644 index 0000000..0b891d1 --- /dev/null +++ b/node-ops/staking-contest/acquire-stake.mdx @@ -0,0 +1,11 @@ +--- +title: "Acquiring Stake" +--- + +You'll be able to acquire stake through any combination of the following: + +1. Purchasing tokens on supported exchanges +2. Claiming and staking airdrop rewards (if applicable) +3. Securing delegated stake from $LITKEY token holders + +All node operators will need to stake a minimum of $20,000 in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file diff --git a/node-ops/staking-contest/logistics.mdx b/node-ops/staking-contest/logistics.mdx new file mode 100644 index 0000000..288a600 --- /dev/null +++ b/node-ops/staking-contest/logistics.mdx @@ -0,0 +1,33 @@ +--- +title: "Logistics" +--- + +## Staking Contest: Selecting the Genesis Validator Set for the Lit Protocol Mainnet + +The V1 Mainnet launch will commence with a distributed key generation (DKG) process initiated by the top 10 node operators by total stake weight (see sections below) to be determined through a competitive staking and delegation contest. + +Stake weight is calculated as a combination of the number of tokens as node operator self-stakes and has delegated to them, as well as a timelock mechanism which is covered in detail in the [$LITKEY token white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). + +The staking contest will be conducted in three phases: + +### 1. Whitelist Open + +The whitelist for the staking contest is now open on the [Lit Protocol staking portal](https://staking.litprotocol.com/register). This is where you will register your node for the contest and where token holders will be able to delegate stake to you once the contest begins. For a comprehensive list of requirements, please reference the [node ops documentation](/node-ops/overview). + +### 2. Contest Begins + +The staking competition will officially begin after the Lit Protocol TGE. Prospective node operators will be able to build their total stake-weight through multiple channels: + +- Purchasing tokens on supported exchanges +- Claiming and staking airdrop rewards (if applicable) +- Securing delegated stake from $LITKEY token holders + +Token holders not interested in participating as node operators can: + +- Delegate tokens to support preferred node operators +- Contribute to decentralization by spreading delegation across multiple operators +- Earn staking rewards while contributing to cryptoeconomic security + +### 3. Contest Ends and Initial Operators are Selected + +After the staking competition ends (timing TBA), the top 10 node operators by total stake-weight will be selected as a part of the initial validator set. Prior to being confirmed, all node operators will need to adhere to the [requirements and expectations](/node-ops/requirements) listed in the applicable documentation. diff --git a/node-ops/staking-contest/registration.mdx b/node-ops/staking-contest/registration.mdx new file mode 100644 index 0000000..162ed66 --- /dev/null +++ b/node-ops/staking-contest/registration.mdx @@ -0,0 +1,13 @@ +--- +title: "Whitelisting your Node" +--- + +To whitelist your node, visit the [Lit Protocol staking dashboard](https://staking.litprotocol.com/register). + +1. Login to the dashboard with the **wallet you intend to use for staking on your node**. The wallet you use to login will automatically be linked to your validator profile. Once you register, you won't be able to change it. + +2. On the registration page, you will be prompted to fill out important details concerning your validator profile. This includes your name (or the name of your organization), a short bio, and social / website links. Your bio should cover your experience as a node operator and why your node is worthy of delegated stake. + +3. After registering, look out for an email from the Lit Protocol team. If you're new to node operations (you didn't participate in Lit Protocol's test or beta networks) the team will reach out to verify your profile and confirm your ability to meet the requirements and expectations and your intention to participate in mainnet node operations. + +4. Contest begins: the staking contest will officially commence after the Lit Protocol TGE. Stay on the look out for official communication from the Lit team. \ No newline at end of file From 9e2b464e44ad7e2c240a116f9941ce8652543962 Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 11:01:07 +0200 Subject: [PATCH 2/7] fix --- governance/litkey/overview.mdx | 2 +- node-ops/staking-contest/acquire-stake.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/governance/litkey/overview.mdx b/governance/litkey/overview.mdx index 596dcdc..4aba521 100644 --- a/governance/litkey/overview.mdx +++ b/governance/litkey/overview.mdx @@ -6,7 +6,7 @@ The $LITKEY token underpins the entire Lit Protocol ecosystem, serving as a mult ## Work Token: Securing and Incentivizing Service Providers -The primary function of $LITKEY is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. +The primary function of "$LITKEY" is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. To participate in the Lit network, node operators must stake $LITKEY tokens, committing economic value to signal their reliability and long-term alignment with network security. This staking mechanism ensures that operators have a vested interest in maintaining uptime, executing cryptographic tasks correctly, and adhering to protocol rules. diff --git a/node-ops/staking-contest/acquire-stake.mdx b/node-ops/staking-contest/acquire-stake.mdx index 0b891d1..66695bb 100644 --- a/node-ops/staking-contest/acquire-stake.mdx +++ b/node-ops/staking-contest/acquire-stake.mdx @@ -8,4 +8,4 @@ You'll be able to acquire stake through any combination of the following: 2. Claiming and staking airdrop rewards (if applicable) 3. Securing delegated stake from $LITKEY token holders -All node operators will need to stake a minimum of $20,000 in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file +All node operators will need to stake a minimum of "$20,000" in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file From f33d27a933a7027a69b9a2dc97aefe69a414b236 Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 11:04:17 +0200 Subject: [PATCH 3/7] fix --- governance/litkey/overview.mdx | 4 ++-- node-ops/staking-contest/acquire-stake.mdx | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/governance/litkey/overview.mdx b/governance/litkey/overview.mdx index 4aba521..1648c2f 100644 --- a/governance/litkey/overview.mdx +++ b/governance/litkey/overview.mdx @@ -6,11 +6,11 @@ The $LITKEY token underpins the entire Lit Protocol ecosystem, serving as a mult ## Work Token: Securing and Incentivizing Service Providers -The primary function of "$LITKEY" is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. +The primary function of $LITKEY is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. To participate in the Lit network, node operators must stake $LITKEY tokens, committing economic value to signal their reliability and long-term alignment with network security. This staking mechanism ensures that operators have a vested interest in maintaining uptime, executing cryptographic tasks correctly, and adhering to protocol rules. -In addition to securing the network, $LITKEY is also used to compensate node operators who perform signing, encryption, and computation operations by running the core Lit software. The protocol distributes token rewards to operators based on a time-weighted staking mechanism, covered in depth in the [$LITKEY white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). +In addition to securing the network, $LITKEY is also used to compensate node operators who perform signing, encryption, and computation operations by running the core Lit software. The protocol distributes token rewards to operators based on a time-weighted staking mechanism, covered in depth in the [LITKEY white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). ## Payment Token: Paying for Network Services diff --git a/node-ops/staking-contest/acquire-stake.mdx b/node-ops/staking-contest/acquire-stake.mdx index 66695bb..0b891d1 100644 --- a/node-ops/staking-contest/acquire-stake.mdx +++ b/node-ops/staking-contest/acquire-stake.mdx @@ -8,4 +8,4 @@ You'll be able to acquire stake through any combination of the following: 2. Claiming and staking airdrop rewards (if applicable) 3. Securing delegated stake from $LITKEY token holders -All node operators will need to stake a minimum of "$20,000" in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file +All node operators will need to stake a minimum of $20,000 in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file From 5c4e7bfd09321c446980f49dc1d6f7675b0cbe3a Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 11:07:45 +0200 Subject: [PATCH 4/7] fixes --- node-ops/staking-contest/acquire-stake.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/node-ops/staking-contest/acquire-stake.mdx b/node-ops/staking-contest/acquire-stake.mdx index 0b891d1..507a91a 100644 --- a/node-ops/staking-contest/acquire-stake.mdx +++ b/node-ops/staking-contest/acquire-stake.mdx @@ -8,4 +8,4 @@ You'll be able to acquire stake through any combination of the following: 2. Claiming and staking airdrop rewards (if applicable) 3. Securing delegated stake from $LITKEY token holders -All node operators will need to stake a minimum of $20,000 in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file +All node operators will need to stake a minimum of $20,000.00 (USD) in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file From 7dd414d8136242c048943279b31c9f149cfa6aa6 Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 11:10:51 +0200 Subject: [PATCH 5/7] Update requirements.mdx --- node-ops/requirements.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/node-ops/requirements.mdx b/node-ops/requirements.mdx index b142fb3..31c8e86 100644 --- a/node-ops/requirements.mdx +++ b/node-ops/requirements.mdx @@ -36,7 +36,7 @@ Because Lit is a [threshold-based network](learning-lit/node-architecture), all ## Staking and Delegation -All node operators must stake a minimum of $20,000 worth of $LITKEY tokens as committed self-stake. This self-stake requirement is separate from any tokens that may be delegated to your node by external token holders. This requirement ensures that operators have economic skin in the game and are aligned with the long-term success of the protocol. +All node operators must stake a minimum of '$'20,000 worth of $LITKEY tokens as committed self-stake. This self-stake requirement is separate from any tokens that may be delegated to your node by external token holders. This requirement ensures that operators have economic skin in the game and are aligned with the long-term success of the protocol. - Staking enforces liveness and reliability by incentivizing operators to maintain uptime. - Slashing disincentives are applied for downtime or malicious behavior. From af54a1b788b83ea1d44e4ad21f486aca4b910c30 Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 11:14:13 +0200 Subject: [PATCH 6/7] Update requirements.mdx --- node-ops/requirements.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/node-ops/requirements.mdx b/node-ops/requirements.mdx index 31c8e86..1a200e0 100644 --- a/node-ops/requirements.mdx +++ b/node-ops/requirements.mdx @@ -36,7 +36,7 @@ Because Lit is a [threshold-based network](learning-lit/node-architecture), all ## Staking and Delegation -All node operators must stake a minimum of '$'20,000 worth of $LITKEY tokens as committed self-stake. This self-stake requirement is separate from any tokens that may be delegated to your node by external token holders. This requirement ensures that operators have economic skin in the game and are aligned with the long-term success of the protocol. +All node operators must stake a minimum of \$20,000 worth of \$LITKEY tokens as committed self-stake. This self-stake requirement is separate from any tokens that may be delegated to your node by external token holders. This requirement ensures that operators have economic skin in the game and are aligned with the long-term success of the protocol. - Staking enforces liveness and reliability by incentivizing operators to maintain uptime. - Slashing disincentives are applied for downtime or malicious behavior. From b694a9712d505e48128e7487410e6fa8113a9a2f Mon Sep 17 00:00:00 2001 From: alt <84208222+a1ttech@users.noreply.github.com> Date: Tue, 7 Oct 2025 11:22:29 +0200 Subject: [PATCH 7/7] fix --- governance/governance-architecture.mdx | 4 ++-- governance/litkey/overview.mdx | 16 ++++++++-------- node-ops/staking-and-delegation.mdx | 10 +++++----- node-ops/staking-contest/acquire-stake.mdx | 2 +- node-ops/staking-contest/logistics.mdx | 4 ++-- 5 files changed, 18 insertions(+), 18 deletions(-) diff --git a/governance/governance-architecture.mdx b/governance/governance-architecture.mdx index 12737dc..b47a0ee 100644 --- a/governance/governance-architecture.mdx +++ b/governance/governance-architecture.mdx @@ -12,7 +12,7 @@ Lit Protocol’s governance system is built around four core areas of responsibi 4. Metagovernance -Each of these functions is administered by the Lit Association and the core development team in collaboration with the broader $LITKEY community. +Each of these functions is administered by the Lit Association and the core development team in collaboration with the broader \$LITKEY community. ## Protocol Upgrades @@ -29,7 +29,7 @@ Upgrades are reviewed and approved by the Protocol Council, a group of core main 3. Approval and Release: Once reviewed and finalized, the build is approved by the Protocol Council and distributed to Lit Protocol node operators for installation. Protocol Council Multisig Address (2 of 3): -0xC6EBB3ca53D028F419F677Ed45126490331F728b +[0xC6EBB3ca53D028F419F677Ed45126490331F728b](https://lit-chain-explorer.litprotocol.com/address/0xC6EBB3ca53D028F419F677Ed45126490331F728b?tab=index) ## Ecosystem Funding and Resource Distribution diff --git a/governance/litkey/overview.mdx b/governance/litkey/overview.mdx index 1648c2f..91bbafe 100644 --- a/governance/litkey/overview.mdx +++ b/governance/litkey/overview.mdx @@ -2,26 +2,26 @@ title: "Overview" --- -The $LITKEY token underpins the entire Lit Protocol ecosystem, serving as a multi-dimensional work, payment, and governance token. Together, these dimensions aim to facilitate a self-sustaining token economy in which tokens are staked to secure the network, used as rewards to incentivize operator participation, exchanged to access cryptographic services, and to govern the continued growth and development of the Lit ecosystem. +The \$LITKEY token underpins the entire Lit Protocol ecosystem, serving as a multi-dimensional work, payment, and governance token. Together, these dimensions aim to facilitate a self-sustaining token economy in which tokens are staked to secure the network, used as rewards to incentivize operator participation, exchanged to access cryptographic services, and to govern the continued growth and development of the Lit ecosystem. ## Work Token: Securing and Incentivizing Service Providers -The primary function of $LITKEY is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. +The primary function of \$LITKEY is that of a work token: It plays a dual role in enforcing network security and compensating participants for maintaining protocol liveness. -To participate in the Lit network, node operators must stake $LITKEY tokens, committing economic value to signal their reliability and long-term alignment with network security. This staking mechanism ensures that operators have a vested interest in maintaining uptime, executing cryptographic tasks correctly, and adhering to protocol rules. +To participate in the Lit network, node operators must stake \$LITKEY tokens, committing economic value to signal their reliability and long-term alignment with network security. This staking mechanism ensures that operators have a vested interest in maintaining uptime, executing cryptographic tasks correctly, and adhering to protocol rules. -In addition to securing the network, $LITKEY is also used to compensate node operators who perform signing, encryption, and computation operations by running the core Lit software. The protocol distributes token rewards to operators based on a time-weighted staking mechanism, covered in depth in the [LITKEY white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). +In addition to securing the network, \$LITKEY is also used to compensate node operators who perform signing, encryption, and computation operations by running the core Lit software. The protocol distributes token rewards to operators based on a time-weighted staking mechanism, covered in depth in the [\LITKEY white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). ## Payment Token: Paying for Network Services -Beyond its role as a work token, $LITKEY also functions as a service payment token, facilitating both on-chain and off-chain operations with Lit. +Beyond its role as a work token, \$LITKEY also functions as a service payment token, facilitating both on-chain and off-chain operations with Lit. -As the native gas token for the Lit Chain, Lit’s Arbitrum Orbit-based L3 rollup, $LITKEY is required to make any transactions on-chain, such as when generating new key pairs or staking. Aside from gas, $LITKEY is also to pay for signing, encryption, and compute operations provided by the network. Users and applications consuming Lit’s cryptographic services must pay per-transaction fees, ensuring that network resources are allocated efficiently while node operators are fairly compensated. Costs fluctuate based on demand, similar to gas-metering. +As the native gas token for the Lit Chain, Lit’s Arbitrum Orbit-based L3 rollup, \$LITKEY is required to make any transactions on-chain, such as when generating new key pairs or staking. Aside from gas, $LITKEY is also to pay for signing, encryption, and compute operations provided by the network. Users and applications consuming Lit’s cryptographic services must pay per-transaction fees, ensuring that network resources are allocated efficiently while node operators are fairly compensated. Costs fluctuate based on demand, similar to gas-metering. ## Governance Token: Steering Protocol Development -$LITKEY will also serve as a governance token for the Lit Protocol ecosystem, enabling token holders to direct the ecosystem’s evolution through a decentralized, on-chain governance system. Individuals holding $LITKEY will play an important role in selecting network operators, suggesting core protocol upgrades and feature enhancements, distributing public goods and grants funding, and other related functions. Additionally, token holders influence ecosystem growth by shaping strategies for partnerships, integrations, and network expansion. As the protocol matures, these governance mechanisms will continue to evolve. +\$LITKEY will also serve as a governance token for the Lit Protocol ecosystem, enabling token holders to direct the ecosystem’s evolution through a decentralized, on-chain governance system. Individuals holding $LITKEY will play an important role in selecting network operators, suggesting core protocol upgrades and feature enhancements, distributing public goods and grants funding, and other related functions. Additionally, token holders influence ecosystem growth by shaping strategies for partnerships, integrations, and network expansion. As the protocol matures, these governance mechanisms will continue to evolve. -At the onset of Lit v1, the Lit Protocol Council will be tasked with overseeing the governance process in tandem with $LITKEY token holders, as covered in depth in the [governance section](/goverance/overview). +At the onset of Lit v1, the Lit Protocol Council will be tasked with overseeing the governance process in tandem with \$LITKEY token holders, as covered in depth in the [governance section](/goverance/overview). diff --git a/node-ops/staking-and-delegation.mdx b/node-ops/staking-and-delegation.mdx index 28da948..6075890 100644 --- a/node-ops/staking-and-delegation.mdx +++ b/node-ops/staking-and-delegation.mdx @@ -14,7 +14,7 @@ This page explains how staking and delegation works, including how to stake as a - Rewards are configured per network and may differ between [Realms](https://spark.litprotocol.com/enhancing-threshold-security-and-performance-at-scale-introducing-shadow-splicing/). - Only active node operators—those selected to run a node—receive rewards. Standby operators do not earn rewards at this time. -**Minimum Self-Stake Requirements**: All node operators must stake a minimum of $20,000 worth of LITKEY tokens as self-stake to be eligible. This minimum ensures each operator has skin in the game and meets the alignment criteria outlined in the [Requirements and Expectations](/node-ops/requirements) section. +**Minimum Self-Stake Requirements**: All node operators must stake a minimum of \$20,000 worth of \$LITKEY tokens as self-stake to be eligible. This minimum ensures each operator has skin in the game and meets the alignment criteria outlined in the [Requirements and Expectations](/node-ops/requirements) section. ## Calculating Staking Rewards @@ -23,7 +23,7 @@ The Lit Protocol employs a dual reward structure to compensate node operators: 1. **Cost-Based Component** A baseline reward is allocated to each node operator to offset the expenses associated with the required hardware and infrastructure. The baseline reward amount may be adjusted periodically via governance to cover the real-world costs associated with node operations (e.g., server hosting) in their entirety, ensuring operators always break even on the costs associated with running a node and never operate at a net loss. The goal is to preserve a stable pool of node operators even during periods of market volatility, essential for maintaining the shared cryptographic secrets maintained by the network in perpetuity. -Several configurable parameters go into setting the cost-based component of the Lit node rewards budget, including the price of the $LITKEY token, the costs associated with running a node (denominated in USD), and a target profit margin factor. +Several configurable parameters go into setting the cost-based component of the Lit node rewards budget, including the price of the \$LITKEY token, the costs associated with running a node (denominated in USD), and a target profit margin factor. 2. **Stake-Weight Component** Beyond the cost-based component, a staker’s total earnings will be distributed according to their relative stake-weight. This stake-weight component is calculated as a function of both the quantity of $LITKEY tokens staked as well as the length of time for which they are locked. This timelock can range from two weeks to two years, depending on the preferences of each individual staker. Longer lock durations yield higher multipliers on rewards, signaling greater commitment and aligning incentives toward long-term network sustainability. The relative nature of this weighting means that overall rewards depend not only on an individual’s stake but also on the staking decisions of other participants. @@ -32,8 +32,8 @@ For an in-depth look at the formula used to calculate stake weight and total rew ## Delegation -After meeting the minimum self-stake requirement, any node operator can increase their total stake weight via delegation from LITKEY token holders. -- Any LITKEY holder can delegate to any node operator given they have registered their node on the staking portal. +After meeting the minimum self-stake requirement, any node operator can increase their total stake weight via delegation from \$LITKEY token holders. +- Any \$LITKEY holder can delegate to any node operator given they have registered their node on the staking portal. - Delegated stake allows node operators to boost their rank during the staking contest, increasing the chance of being selected for the genesis validator set. - Delegators retain ownership of their tokens while sharing in the staking rewards distributed to each node. @@ -49,7 +49,7 @@ Slashing has been implemented to ensure that node operators keep their machines Unresponsiveness: If a node operator is detected as unresponsive by its peers, it will be kicked from the active node operator set. To safeguard the network’s security, an immediate epoch transition is triggered, recalculating the threshold to two-thirds of the remaining active nodes. The kicked node will automatically attempt to rejoin the network in the next epoch, which occurs every hour, providing a built-in opportunity to recover from temporary issues. -To prevent persistently faulty nodes from repeatedly disrupting the network, each node has a kick counter that increments each time they’re kicked. A node can be kicked up to 5 times before it is banned from the network. Upon exceeding this limit, the node is banned, and its locked stake is slashed by 5%. Additionally, if a node goes offline and doesn’t rejoin within a 24hr period, they are also banned and slashed. Once banned, the node operator must address the underlying issues causing unresponsiveness. The Lit Advisory Council will then manually review the node’s status and unban it only after confirming that it is stable and operational, ensuring that only reliable nodes are readmitted to the active set. +To prevent persistently faulty nodes from repeatedly disrupting the network, each node has a kick counter that increments each time they’re kicked. A node can be kicked up to 5 times before it is banned from the network. Upon exceeding this limit, the node is banned, and its locked stake is slashed by 5%. Additionally, if a node goes offline and doesn’t rejoin within a 24hr period, they are also banned and slashed. Once banned, the node operator must address the underlying issues causing unresponsiveness. The Lit Protocol Council will then manually review the node’s status and unban it only after confirming that it is stable and operational, ensuring that only reliable nodes are readmitted to the active set. To permit occasional and minor unresponsiveness without severely penalizing operators, a ‘decay’ mechanism has been implemented. The decay mechanism resets the kick counter at the end of each week, meaning a node can be kicked up to 5 times per decay period (1 week) before being slashed. This serves to strike a balance between enforcing network liveness and giving node operators fair opportunities to rectify temporary issues while protecting the network from chronic instability. diff --git a/node-ops/staking-contest/acquire-stake.mdx b/node-ops/staking-contest/acquire-stake.mdx index 507a91a..00d311e 100644 --- a/node-ops/staking-contest/acquire-stake.mdx +++ b/node-ops/staking-contest/acquire-stake.mdx @@ -6,6 +6,6 @@ You'll be able to acquire stake through any combination of the following: 1. Purchasing tokens on supported exchanges 2. Claiming and staking airdrop rewards (if applicable) -3. Securing delegated stake from $LITKEY token holders +3. Securing delegated stake from \$LITKEY token holders All node operators will need to stake a minimum of $20,000.00 (USD) in $LITKEY tokens as a self-stake requirement. Additional tokens can be acquired from $LITKEY token holders via delegation. \ No newline at end of file diff --git a/node-ops/staking-contest/logistics.mdx b/node-ops/staking-contest/logistics.mdx index 288a600..96a8b1d 100644 --- a/node-ops/staking-contest/logistics.mdx +++ b/node-ops/staking-contest/logistics.mdx @@ -6,7 +6,7 @@ title: "Logistics" The V1 Mainnet launch will commence with a distributed key generation (DKG) process initiated by the top 10 node operators by total stake weight (see sections below) to be determined through a competitive staking and delegation contest. -Stake weight is calculated as a combination of the number of tokens as node operator self-stakes and has delegated to them, as well as a timelock mechanism which is covered in detail in the [$LITKEY token white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). +Stake weight is calculated as a combination of the number of tokens as node operator self-stakes and has delegated to them, as well as a timelock mechanism which is covered in detail in the [\$LITKEY token white paper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1). The staking contest will be conducted in three phases: @@ -20,7 +20,7 @@ The staking competition will officially begin after the Lit Protocol TGE. Prospe - Purchasing tokens on supported exchanges - Claiming and staking airdrop rewards (if applicable) -- Securing delegated stake from $LITKEY token holders +- Securing delegated stake from \$LITKEY token holders Token holders not interested in participating as node operators can: