Skip to content

Commit 47136e2

Browse files
committed
feat(docs): add node-ops and update docs.json
1 parent b3aa5be commit 47136e2

File tree

7 files changed

+252
-5
lines changed

7 files changed

+252
-5
lines changed

docs/docs.json

Lines changed: 55 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,9 @@
3434
"groups": [
3535
{
3636
"group": "SDK",
37-
"pages": ["sdk/introduction"]
37+
"pages": [
38+
"sdk/introduction"
39+
]
3840
},
3941
{
4042
"group": "Getting Started",
@@ -105,23 +107,71 @@
105107
},
106108
{
107109
"group": "@lit-protocol/auth",
108-
"pages": ["sdk/sdk-reference/auth/functions/createAuthManager"]
110+
"pages": [
111+
"sdk/sdk-reference/auth/functions/createAuthManager"
112+
]
109113
},
110114
{
111115
"group": "@lit-protocol/networks",
112-
"pages": ["sdk/sdk-reference/networks/functions/withOverrides"]
116+
"pages": [
117+
"sdk/sdk-reference/networks/functions/withOverrides"
118+
]
113119
}
114120
]
115121
},
116122
{
117123
"group": "Resources",
118-
"pages": ["sdk/resources/supported-evm-chains"]
124+
"pages": [
125+
"sdk/resources/supported-evm-chains"
126+
]
119127
}
120128
]
121129
},
122130
{
123131
"tab": "Changelog",
124-
"pages": ["changelog"]
132+
"pages": [
133+
"changelog"
134+
]
135+
},
136+
{
137+
"tab": "Governance",
138+
"pages": [
139+
"governance/overview",
140+
"governance/governance-architecture",
141+
"governance/lit-improvement-proposals",
142+
{
143+
"group": "$LITKEY Token",
144+
"pages": [
145+
"governance/litkey/overview",
146+
"governance/litkey/initial-allocation-and-distribution"
147+
]
148+
},
149+
{
150+
"group": "Lit Protocol Airdrop: Season 1",
151+
"pages": [
152+
"governance/airdrop/overview",
153+
"governance/airdrop/eligibility-criteria",
154+
"governance/airdrop/claiming",
155+
"governance/airdrop/rewards"
156+
]
157+
}
158+
]
159+
},
160+
{
161+
"tab": "Node Operations",
162+
"pages": [
163+
"node-ops/overview",
164+
"node-ops/requirements",
165+
"node-ops/staking-and-delegation",
166+
{
167+
"group": "Lit Protocol v1: Node Operator Selection",
168+
"pages": [
169+
"node-ops/staking-contest/logistics",
170+
"node-ops/staking-contest/registration",
171+
"node-ops/staking-contest/acquire-stake"
172+
]
173+
}
174+
]
125175
}
126176
]
127177
},

docs/node-ops/overview.mdx

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
title: "Overview"
3+
---
4+
5+
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.
6+
7+
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.
8+
9+
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).
10+
11+
## Mainnet Node Operator Selection: The Staking Contest
12+
13+
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.
14+
15+
To whitelist your node, visit https://staking.litprotocol.com/
16+
17+
Refer to the next page for details on hardware specs, minimum requirements, and operational guidelines for node operators.

docs/node-ops/requirements.mdx

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
---
2+
title: "Requirements and Expectations"
3+
---
4+
5+
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.
6+
7+
## Selection Process
8+
9+
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.
10+
11+
- 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.
12+
13+
- 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).
14+
15+
- 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.
16+
17+
## Hardware Requirements
18+
19+
To run a Lit Protocol node you will need robust, production-grade hardware capable of supporting confidential computing workloads. The current minimum requirements are:
20+
21+
1. CPU: 64-core AMD EPYC Gen 3 or a 32-core dual-CPU setup
22+
23+
2. RAM: 128 GB minimum
24+
25+
3. Storage: Mirrored RAID, at least 400 GB
26+
27+
4. Networking: Two dedicated IPs (one for the Host and one for the Guest VM where the Lit Node software runs)
28+
29+
5. Operating System: Debian 12 (required for current Lit OS builds)
30+
31+
**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.
32+
33+
## KYC / KYB Requirements
34+
35+
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.
36+
37+
## Staking and Delegation
38+
39+
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.
40+
41+
- Staking enforces liveness and reliability by incentivizing operators to maintain uptime.
42+
- Slashing disincentives are applied for downtime or malicious behavior.
43+
44+
Read more in [Staking and Delegation](/node-ops/staking-and-delegation).
45+
46+
## Deployment and Maintenance
47+
48+
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:
49+
50+
- Configuring and maintaining approved hardware environment
51+
- Updating to new software releases as directed by Lit’s governance system and the Protocol Council
52+
- Meeting uptime and performance expectations
53+
54+
## Additional Resources
55+
56+
- [Lit Staking Contest](/node-ops/staking-contest/logistics)
57+
- [Staking and Delegation](/node-ops/staking-and-delegation)
Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
---
2+
title: "Staking and Delegation"
3+
---
4+
5+
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.
6+
7+
## Staking Overview
8+
9+
**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.
10+
11+
**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.
12+
13+
- Rewards are distributed programmatically via the Lit staking contract.
14+
- Rewards are configured per network and may differ between [Realms](https://spark.litprotocol.com/enhancing-threshold-security-and-performance-at-scale-introducing-shadow-splicing/).
15+
- Only active node operators—those selected to run a node—receive rewards. Standby operators do not earn rewards at this time.
16+
17+
**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.
18+
19+
## Calculating Staking Rewards
20+
21+
The Lit Protocol employs a dual reward structure to compensate node operators:
22+
23+
1. **Cost-Based Component**
24+
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.
25+
26+
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.
27+
28+
2. **Stake-Weight Component**
29+
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.
30+
31+
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).
32+
33+
## Delegation
34+
35+
After meeting the minimum self-stake requirement, any node operator can increase their total stake weight via delegation from \$LITKEY token holders.
36+
- Any \$LITKEY holder can delegate to any node operator given they have registered their node on the staking portal.
37+
- Delegated stake allows node operators to boost their rank during the staking contest, increasing the chance of being selected for the genesis validator set.
38+
- Delegators retain ownership of their tokens while sharing in the staking rewards distributed to each node.
39+
40+
## Commission
41+
42+
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.
43+
44+
## Slashing
45+
46+
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.
47+
48+
### Slashing Conditions
49+
50+
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.
51+
52+
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.
53+
54+
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.
55+
56+
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.
57+
58+
### Appeals
59+
60+
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.
61+
62+
### Governance Oversight
63+
64+
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.
65+
66+
Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
title: "Acquiring Stake"
3+
---
4+
5+
You'll be able to acquire stake through any combination of the following:
6+
7+
1. Purchasing tokens on supported exchanges
8+
2. Claiming and staking airdrop rewards (if applicable)
9+
3. Securing delegated stake from \$LITKEY token holders
10+
11+
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.
Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
---
2+
title: "Logistics"
3+
---
4+
5+
## Staking Contest: Selecting the Genesis Validator Set for the Lit Protocol Mainnet
6+
7+
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.
8+
9+
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).
10+
11+
The staking contest will be conducted in three phases:
12+
13+
### 1. Whitelist Open
14+
15+
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).
16+
17+
### 2. Contest Begins
18+
19+
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:
20+
21+
- Purchasing tokens on supported exchanges
22+
- Claiming and staking airdrop rewards (if applicable)
23+
- Securing delegated stake from \$LITKEY token holders
24+
25+
Token holders not interested in participating as node operators can:
26+
27+
- Delegate tokens to support preferred node operators
28+
- Contribute to decentralization by spreading delegation across multiple operators
29+
- Earn staking rewards while contributing to cryptoeconomic security
30+
31+
### 3. Contest Ends and Initial Operators are Selected
32+
33+
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.
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
---
2+
title: "Whitelisting your Node"
3+
---
4+
5+
To whitelist your node, visit the [Lit Protocol staking dashboard](https://staking.litprotocol.com/register).
6+
7+
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.
8+
9+
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.
10+
11+
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.
12+
13+
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.

0 commit comments

Comments
 (0)