# Introduction to Jito > Solana's first staking product including MEV rewards Jito is the liquid staking service for Solana that distributes MEV (maximum extractable value) rewards to holders. The Jito Stake Pool enables users to stake their Solana tokens in exchange for a liquid stake pool token (JitoSOL). The JitoSOL token provides liquidity while earning a combination of staking rewards and MEV rewards. Jito's liquid staking token is unique in two ways: * JitoSOL provides additional rewards to users from MEV transactions happening on Solana * Jito exclusively stakes with validators that run software designed to improve network performance. The improvements from the introduction of an auction mechanism so network congestion is less likely. JitoSOL automatically accrues value from staking and MEV rewards. The token allows users to earn yield while also maintaining capital efficiency via DeFi integrations. JitoSOL holders can earn yield from validators while also accruing interest in lending protocols or yield farming. Jito's goal is to provide the best yield for JitoSOL while also improving Solana's network. --- # Liquid Staking Basics > The most capital efficient way to earn rewards on SOL Staking is the process by which a SOL token holder (such as someone who purchased SOL tokens on an exchange) assigns some or all of their tokens to a particular validator or validators, which helps increase those validators’ voting weight. There are two ways to participate in staking: by directly staking to a validator, or by delegating to a stake pool. In both cases, delegators still control all staked tokens that they may have chosen to stake. ### Stake Pools and Liquid Staking On Solana, stake pools are a collection of one or more validator nodes. In delegating to a stake pool, delegators can stake to many validators at once. Delegators who stake this way will receive a liquid stake pool token (e.g. JitoSOL) in exchange for staking with a pool. In this way, depositors instantly receive a liquid token which can be immediately used for DeFi. ### Network Benefits Stake pools help decentralize the network by delegating stake across many validator nodes. Each stake pool has its own unique validator criteria and delegation strategy, with some pools requiring that validators be geographically decentralized and meet minimum performance criteria in order to be added to the validator set. Stakers should not have to compromise between high yields and supporting the network's decentralization goals. JitoSOL achieves both these goals while supporting efficient MEV extraction. Nodes must meet performance and decentralization criteria in order to receive stake from JitoSOL. Reference our [delegation page](https://www.jito.network/docs/jitosol/jitosol-liquid-staking/stake-pool-operations/delegation-criteria.md) for further details. ### **Liquidity and DeFi Integrations** Liquid staking tokens derive utility from their DeFi composability. JitoSOL has several flagship partners at launch and expects to have a broad array of integrations within several months. See our [guide](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/using-overview.md) to JitoSOL's DeFi applications. --- # Maximum Extractable Value > What is Solana MEV and how does JitoSOL benefit from it? ## MEV Explained Maximum extractable value (MEV) describes profit opportunities privileged entities can extract attributable to the specific order of transaction execution. For example, a large swap on Orca can lower the pool’s price below that of Raydium or Serum. Traders will race to profit from that price difference and this arbitrage is considered MEV. Alternatively, a large account on Solend may be near liquidation. Liquidation bots will vie to be the first to process that liquidation as soon as the price threshold is exceeded. These liquidation profits are another form of MEV. MEV is a natural byproduct of financial markets with infinite examples in traditional finance and daily life. When Taylor Swift announces a new concert and fans rush to buy tickets directly to avoid reseller markups, that is also MEV. The Jito Foundation's mission is to ensure that MEV is efficiently extracted and shared with stakers and validators because it increases the security and denctralization of Solana. ## MEV Spam Problems Solana has experienced periods of network congestion from disorderly attempts by traders to capture MEV. Transaction fees are low so traders deploy bots to resend the same transactions hundreds of times, hoping one of those transactions lands profitably. Recall the earlier example about Taylor Swift fans swarming the website to buy tickets at a just-announced concert. The website may crash from everyone trying to buy but users will still refresh constantly to help their individual odds. Spam on Solana is quite similar. MEV spam will only grow as network activity increases and traders become more sophisticated. This creates significant problems for Solana's network. ## Jito's MEV Solution Jito released a new client for validators to eliminate the spam from MEV and provide rewards to stakers. The solution is an auction. Traders will submit bids for sequences of transactions they believe are profitable. Third party block engines run complex simulations to determine the combination of transactions that provides the highest value. These bids are then given to validators and stakers (JitoSOL). Jito's mechanism eliminates the benefit of spam while simultaneously increasing rewards for stakers. ## JitoSOL MEV Rewards JitoSOL directly benefits from these MEV rewards since the auction proceeds are passed through to stakers after a modest commission. JitoSOL is the first liquid staking token to offer this additional source of yield. Because the rewards are based on guaranteed auction amounts, JitoSOL has no exposure to the risks around MEV trading. For further context on the MEV solution, checkout this overview of [Jito-Solana](https://medium.com/p/e1028c53fae1). --- # Automated Management via Stakenet > How JitoSOL stake moves automatically Over time, as people deposit SOL into the reserve, or as validator performance varies, it becomes necessary to move stake around. Jito now uses **Stakenet** – a blend of on-chain programs and off-chain "keepers" – to automatically manage JitoSOL's stake distribution across validators. ## Design Principles **On-chain decision making** The Steward and Validator History programs manage stake allocation decisions directly on Solana, ensuring transparency and verifiability. **Community governance** All system parameters can be adjusted through Jito DAO governance, allowing the community to influence delegation criteria and safety mechanisms. **Decentralized execution** Multiple independent keepers execute the system's decisions, removing single points of failure while maintaining network health and optimal yields. ## Evolution from the previous stake-bot The original **Kobe** system was an automated off-chain service that stored network information about validators and delegated stake according to each validator's performance. While functional, this approach had limitations: * Centralized signing authority * Off-chain logic that was harder to audit * Limited community visibility into decision-making Stakenet addresses these limitations with an on-chain-first design where logic is transparent and keepers are permissionless. ## Stakenet architecture | Component | Function | Location | |-----------|----------|----------| | Validator History Program | Stores up to 512 epochs of validator performance, commission, and MEV data | On-chain program | | Steward Program | Evaluates validators, determines target stake allocations, and manages rebalancing via a state machine | On-chain program | | Keeper Bot | Executes the permissionless transactions required by the Steward and uploads validator data | Off-chain service (Docker or binary) | The system operates with on-chain programs making decisions and off-chain keepers executing those decisions. ## How stake rebalancing works 1. **Scoring phase** – Every 10 epochs, the Steward evaluates over 1,000 validators 2. **Target calculation** – The top 400 validators (configurable) are selected, each receiving an equal target allocation 3. **Monitoring** – Keepers continuously update validator performance data 4. **Instant unstake evaluation** – Each epoch, validators that meet certain negative criteria are marked for immediate removal from the pool 5. **Rebalancing** – Keepers execute stake delegation and undelegation transactions to move validators toward their targets, subject to safety caps 6. **Cycle repetition** – The process continues until the next scoring phase All parameters governing this process are stored on-chain and can be modified through Jito DAO governance. ## Running a keeper Community members can optionally run their own keepers. See the [Keeper Quick-Start guide](https://www.jito.network/docs/stakenet/jito-steward/developers/keeper-bot-quick-start.md) for detailed setup instructions. ## Monitoring and transparency * Current parameters: * StakeNet Steward dashboard: * StakeNet History dashboard: * Event API: `https://kobe.mainnet.jito.network/api/v1/steward_events` --- # Delegation Criteria > JitoSOL delegation criteria and methodology ## Overview The aim of Jito's Liquid Staking is to decentralize the network and improve the performance of the Solana blockchain. Validators that meet the minimum criteria may become eligible for a stake delegation. Stakenet automates this process using transparent scoring algorithms and safety mechanisms. See current delegates at [jito.network/stakepool](https://www.jito.network/stakepool/Jito4APyf642JPZPx3hGc6WWJ8zPKtRbRs4P815Awbb/). ## Delegation requirements Validators must meet all of the following binary criteria to be eligible for delegation (subject to change): - Run the Jito MEV-enabled client (have MEV commission in the last 30 epochs) - MEV commission ≤ 10% (evaluated over the last 30 epochs) - Validator commission ≤ 5% (evaluated over the last 30 epochs) - Historical commission ≤ 50% (across all validator history) - Not belong to the validator superminority (top 33.3% of total stake) - Not run unsafe consensus modifications - Using acceptable Tip Distribution merkle root upload authority (TipRouter or OldJito) - Not blacklisted by governance - Maintain ≥ 5 epochs of continuous voting with ≥ 5,000 SOL minimum stake - Vote on ≥ 97% of expected slots in each of the last 30 epochs Failing any single criterion results in an overall score of zero, making the validator ineligible for delegation. ## Scoring mechanism Validators that pass all binary criteria are ranked using a 4-tier hierarchical scoring system. The score is encoded as a 64-bit value with the following priority order: 1. **Inflation commission** (highest priority): Lower commission validators are always preferred 2. **MEV commission**: Among validators with equal inflation commission, lower MEV commission is preferred 3. **Validator age**: Among validators equal on commissions, older validators (more epochs with vote credits) are preferred 4. **Vote credits ratio**: Among validators equal on all above, higher performance is preferred The 4-tier score ensures that differences in higher-priority tiers (like inflation commission) always dominate lower-priority tiers. This raw score is then multiplied by all binary eligibility factors - if any factor is zero, the final score becomes zero. The top 400 validators by overall score are selected for delegation in each 10-epoch cycle. ## Delegation methodology - Each selected validator receives a target allocation of 1/400th of the total pool - Target allocations are percentage-based and scale automatically with pool growth - New deposits increase all validators' target stake proportionally ## Rebalancing and safety caps To protect JitoSOL yield, the system limits the amount of stake that can be moved per cycle: | Rebalancing type | Maximum unstake per cycle | |------------------|---------------------------| | Performance-based rebalancing | 7.5% of total pool | | Instant unstake triggers | 10% of total pool | | Stake deposit management | 10% of total pool | Priority is given to removing stake from the lowest-performing validators first. ## Instant unstaking criteria The system evaluates validators each epoch for immediate removal based on: - Delinquency: Voting on less than 70% of expected slots (lower threshold than the 97% scoring requirement) - Commission manipulation: Increasing commission above 5% or MEV commission above 10% - Blacklist addition by governance - Using unacceptable Tip Distribution merkle root upload authority Validators meeting any of these criteria are unstaked within the same epoch, subject to the 10% cap. ## Parameters and transparency All delegation parameters are stored on-chain and can be viewed at [jito.network/stakenet/steward/config](https://www.jito.network/stakenet/steward/config) or queried using the steward CLI. Changes to delegation requirements and parameters may occur based on Jito DAO governance decisions. The community will be notified in advance of any significant changes. --- # Overview > JitoSOL is fully audited and non-custodial JitoSOL is built on the stake pool program developed by Solana Labs. The program has been supporting numerous implementations since the network launched and three firms have completed audits ([reports](https://spl.solana.com/stake-pool#security-audits)). Liquid staking is non-custodial so Jito does not have access to funds deposited in JitoSOL. Even if Jito were to disappear, holders could still withdraw their SOL from validators along with accumulated rewards. Jito DAO has the manager role for the JitoSOL pool with limited responsibilities around validator selection and fees. Validator selection is run by StakeNet. --- # Deployed Programs Jito Network uses the Solana Program Library deployed stake pool program at address `SPoo1Ku8WFXoNDMHPsrGSTSG1Y47rzgn41SLUNakuHy` on Mainnet. Audits: - Quantstamp - Initial review commit hash [99914c9](https://github.com/solana-labs/solana-program-library/tree/99914c9fc7246b22ef04416586ab1722c89576de)​ - Re-review commit hash [3b48fa0](https://github.com/solana-labs/solana-program-library/tree/3b48fa09d38d1b66ffb4fef186b606f1bc4fdb31)​ - Final report [https://solana.com/SolanaQuantstampStakePoolAudit.pdf](https://solana.com/SolanaQuantstampStakePoolAudit.pdf)​ - Neodyme - Review commit hash [0a85a9a](https://github.com/solana-labs/solana-program-library/tree/0a85a9a533795b6338ea144e433893c6c0056210)​ - Report [https://solana.com/SolanaNeodymeStakePoolAudit.pdf](https://solana.com/SolanaNeodymeStakePoolAudit.pdf)​ - Kudelski - Review commit hash [3dd6767](https://github.com/solana-labs/solana-program-library/tree/3dd67672974f92d3b648bb50ee74f4747a5f8973)​ - Report [https://solana.com/SolanaKudelskiStakePoolAudit.pdf](https://solana.com/SolanaKudelskiStakePoolAudit.pdf)​ Upgrade keys for this program are owned by a committee of Solana Staking Ecosystem participants. Leveraging this program provides minimal risk compared to deploying or writing our own stake pool implementation, in case of a network fork or loss of funds. ### Jito Stake Pool Addresses All networks use the SPL Stake Pool program at `SPoo1Ku8WFXoNDMHPsrGSTSG1Y47rzgn41SLUNakuHy`. **Mainnet & Testnet:** - Stake Pool: `Jito4APyf642JPZPx3hGc6WWJ8zPKtRbRs4P815Awbb` - JitoSOL Mint: `J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn` **Devnet:** The Devnet deployment on `SPoo1Ku8WFXoNDMHPsrGSTSG1Y47rzgn41SLUNakuHy` is deployed to an outdated version (v0.6.4) and no longer upgradable. For up-to-date testing, use: - Program: `DPoo15wWDqpPJJtS2MUZ49aRxqz5ZaaJCJP4z8bLuib` - Stake Pool: `JitoY5pcAxWX6iyP2QdFwTznGb8A99PRCUCVVxB46WZ` - JitoSOL Mint: `J1tos8mqbhdGcF3pgj4PCKyVjzWSURcpLZU7pPGHxSYi` ### Interceptor Program The Jito Interceptor program manages stake account deposits with a time-decaying fee mechanism to protect against toxic flow. For details, see the [Interceptor user guide](https://www.jito.network/docs/jitosol/user-guides/interceptor.md). - Mainnet: `5TAiuAh3YGDbwjEruC1ZpXTJWdNDS7Ur7VeqNNiHMmGV` - Testnet & Devnet: `2KVTQFqDBoq1BZhYf6NVUYbrTf7Ff2e3UMWf6jRT5GHV` --- # MEV & Claims API > Individual reward claims, validator commissions, and distribution mechanics # MEV Rewards API Documentation ## Overview The MEV Rewards API provides access to Maximal Extractable Value (MEV) and priority fee rewards distributed through the Jito network. The API offers two main endpoints for querying rewards data for different participants in the ecosystem. ## What are MEV Rewards? **MEV (Maximal Extractable Value)** refers to the additional profit that validators can earn by reordering, including, or excluding transactions within the blocks they produce. ## What are Priority Fee Rewards? **Priority Fees** are additional fees that users pay to prioritize their transactions. These fees are distributed between validators and their stakers similar to MEV rewards. --- ## API Endpoints ### 1. Staker Rewards **Purpose**: Retrieve individual claimable MEV and priority fee rewards from the tip distribution merkle trees. This includes both: - Rewards claimable by actual stakers (delegators) who have staked SOL with validators - Rewards claimable by validators for their own commission portion (when they act as their own claimant) **Key Insight**: When `stake_authority` and `withdraw_authority` are both the system program (`11111111111111111111111111111111`), and `claimant` equals `validator_vote_account`, these are validator self-rewards for their commission. **Endpoint**: `/api/v1/staker_rewards` **Method**: `GET` or `POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| | `stake_authority` | string | No | - | Filter by stake authority public key | | `validator_vote_account` | string | No | - | Filter by validator vote account public key | | `epoch` | number | No | - | Filter by specific epoch | | `page` | number | No | 1 | Page number for pagination | | `limit` | number | No | 100 | Results per page (max: 10,000) | | `sort_order` | string | No | "desc" | Sort order: "asc" or "desc" | #### Response Fields | Field | Type | Description | |-------|------|-------------| | `claimant` | string | The public key that can claim these rewards | | `stake_authority` | string | The authority that controls the stake account (system program for validator self-rewards) | | `withdraw_authority` | string | The authority that can withdraw from the stake account (system program for validator self-rewards) | | `validator_vote_account` | string | The vote account of the validator these rewards came from | | `claim_status_account` | string | Account tracking the claim status for MEV rewards | | `priority_fee_claim_status_account` | string | Account tracking the claim status for priority fee rewards (may be null) | | `epoch` | number | The epoch when these rewards were earned | | `amount` | number | MEV reward amount in lamports | | `priority_fee_amount` | number | Priority fee reward amount in lamports (may be null) | #### Example Request ```bash curl "https://kobe.mainnet.jito.network/api/v1/staker_rewards?limit=2" ``` #### Example Response ```json { "rewards": [ { "claimant": "DdCNGDpP7qMgoAy6paFzhhak2EeyCZcgjH7ak5u5v28m", "stake_authority": "11111111111111111111111111111111", "withdraw_authority": "11111111111111111111111111111111", "validator_vote_account": "DdCNGDpP7qMgoAy6paFzhhak2EeyCZcgjH7ak5u5v28m", "epoch": 824, "amount": 348145740523, "claim_status_account": "DQ3CwqPPCkRqkDyNvMMhNW5i5HJhQ733XoTez3BWkCBS", "priority_fee_amount": null, "priority_fee_claim_status_account": null }, { "claimant": "9QU2QSxhb24FUX3Tu2FpczXjpK3VYrvRudywSZaM29mF", "stake_authority": "11111111111111111111111111111111", "withdraw_authority": "11111111111111111111111111111111", "validator_vote_account": "9QU2QSxhb24FUX3Tu2FpczXjpK3VYrvRudywSZaM29mF", "epoch": 824, "amount": 242405379963, "claim_status_account": "2Ykg9QPDqAXkNk4ChTcLKKEaiAp3WVra5Kqeozt1T5EW", "priority_fee_amount": null, "priority_fee_claim_status_account": null } ], "total_count": 0 } ``` *Note: This example shows validator self-rewards. Delegator leaves look identical except `stake_authority` / `withdraw_authority` will be real stake-account keys and `claimant` will **not** equal the validator vote account.* --- ### 2. Validator Rewards **Purpose**: Retrieve aggregated MEV and priority fee rewards data per validator. This provides a high-level summary of each validator's performance including total revenue, commission rates, and number of stakers. **Key Difference**: Unlike staker rewards which show individual claimable amounts, this endpoint aggregates data to show totals per validator. **Endpoint**: `/api/v1/validator_rewards` **Method**: `GET` or `POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| | `vote_account` | string | No | - | Filter by validator vote account public key | | `epoch` | number | No | - | Filter by specific epoch | | `page` | number | No | 1 | Page number for pagination | | `limit` | number | No | 100 | Results per page (max: 10,000) | | `sort_order` | string | No | "desc" | Sort order: "asc" or "desc" | #### Response Fields | Field | Type | Description | |-------|------|-------------| | `vote_account` | string | The validator's vote account public key | | `mev_revenue` | number | Total MEV revenue earned in lamports | | `mev_commission` | number | MEV commission rate in basis points (bps) | | `num_stakers` | number | Number of stakers delegated to this validator | | `epoch` | number | The epoch when these rewards were earned | | `claim_status_account` | string | Account tracking the claim status for MEV rewards | | `priority_fee_commission` | number | Priority fee commission rate in basis points (bps) | | `priority_fee_revenue` | number | Total priority fee revenue earned in lamports | #### Example Request ```bash curl "https://kobe.mainnet.jito.network/api/v1/validator_rewards?epoch=678&limit=2" ``` #### Example Response ```json { "rewards": [ { "vote_account": "he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk", "mev_revenue": 934451876628, "mev_commission": 0, "priority_fee_revenue": 0, "priority_fee_commission": null, "num_stakers": 13222, "epoch": 678, "claim_status_account": "2aT6uw4FAnMr32JJLEQf5xDALHFcHTJDBBQKwsZfgsUa" }, { "vote_account": "CvSb7wdQAFpHuSpTYTJnX5SYH4hCfQ9VuGnqrKaKwycB", "mev_revenue": 922545272656, "mev_commission": 2500, "priority_fee_revenue": 0, "priority_fee_commission": null, "num_stakers": 558, "epoch": 678, "claim_status_account": "BJKb86G3Ed3B7Mz1cdsEB49u5d1mjehGpK6fxoKofFZa" } ], "total_count": 1083 } ``` --- ## Key Differences Between Endpoints ### Staker Rewards vs Validator Rewards | Aspect | Staker Rewards | Validator Rewards | |--------|---------------|-------------------| | **Data Granularity** | Individual claimable amounts | Aggregated totals per validator | | **What it shows** | Each specific reward claim from merkle trees | Summary statistics per validator | | **Use case** | Finding specific claims, tracking individual rewards | Validator performance analysis, commission rates | | **Includes** | Both delegator rewards AND validator self-rewards | Only validator-level aggregates | | **Commission info** | Not included | Commission rates and revenue splits | ### Understanding Validator Self-Rewards In the staker rewards endpoint, when you see: - `claimant` = `validator_vote_account` - `stake_authority` = `withdraw_authority` = `11111111111111111111111111111111` (system program) This indicates the validator claiming their own portion of MEV rewards. ### Reward Distribution Flow 1. **MEV Tips Generated**: Searchers submit bundles with tips to validators 2. **Merkle Tree Creation**: Tips are distributed via merkle trees to eligible claimants 3. **Staker Rewards Endpoint**: Shows individual entries from these merkle trees (one per claimant) 4. **Validator Rewards Endpoint**: Shows aggregated view with total revenue and commission data --- ## Important Notes ### Commission Rates - **MEV Commission**: Percentage of MEV rewards that the validator keeps (rest goes to stakers) - **Priority Fee Commission**: Percentage of priority fee rewards that the validator keeps - Rates are expressed in basis points (bps), where 10,000 bps = 100% ### Claim Status Accounts - **Stakers**: Have separate claim status accounts for MEV and priority fee rewards - **Validators**: Only have MEV claim status accounts (priority fees flow directly to validators) ### Reward Distribution Flow 1. Searchers submit bundles with tips to validators 2. Validators earn MEV revenue and priority fees from successful bundles 3. Validators keep their commission and distribute the rest to stakers 4. Rewards are tracked per epoch and can be claimed using the respective claim status accounts ### Data Availability - All amounts are denominated in lamports (1 SOL = 1,000,000,000 lamports) - Data is available on a per-epoch basis - Historical data is preserved for all previous epochs --- ## Error Handling The API returns standard HTTP status codes: - `200 OK`: Successful request - `400 Bad Request`: Invalid parameters - `500 Internal Server Error`: Server error In case of errors, both endpoints return appropriate error responses with details about what went wrong. --- ## Rate Limiting The API implements caching with a 60-second lifespan to ensure optimal performance. Identical requests within this timeframe will return cached results. --- # Validator API > Network analytics, validator rankings, and stake pool APY metrics ## API Endpoints ### 1. Validators **Purpose**: Returns validator state for a given epoch (defaults to latest). The current epoch will always report `mev_rewards = 0` because rewards settle at epoch boundary. **Endpoint**: `/api/v1/validators` **Method**: `GET or POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | | `epoch` | number | No | - | Filter by specific epoch | #### Response Fields | Field | Type | Description | | ------------------------------ |-------- | ------------------------------------------------------------- | | `vote_account` | string | Validator vote account public key | | `mev_commission_bps` | number | Validator’s MEV commission in basis-points | | `mev_rewards` | number | Post-commission MEV lamports paid to validator + stakers | | `priority_fee_commission_bps` | number | Priority-fee commission (bps) | | `priority_fee_rewards` | number | Post-commission priority-fee lamports | | `running_jito` | boolean | `true` if validator is running Jito-Solana | | `running_bam` | boolean | `true` if validator is running BAM | | `active_stake` | number | Lamports actively staked with this validator | | `jito_directed_stake_target` | boolean | Whether or not this is a jito directed stake target validator | | `jito_directed_stake_lamports` | number | Total stake amount in lamports for Jito directed stake | #### Example Request ```bash curl -X POST \ https://kobe.mainnet.jito.network/api/v1/validators \ -H 'Content-Type: application/json' \ -d '{ "epoch":600 }' ``` #### Example Response ```json { "validators": [ { "vote_account": "GdRKUZKdiXMEATjddQW6q4W8bPgXRBYJKayfeqdQcEPa", "mev_commission_bps": 10000, "mev_rewards": 4438669326, "priority_fee_commission_bps": 5000, "priority_fee_rewards": 31269273876, "active_stake": 57968373482697, "running_jito": true, "running_bam": false, "jito_directed_stake_target": null, "jito_directed_stake_lamports": null, } // … ] } ``` --- ### 2. JitoSOL Validators **Purpose**: Returns JitoSOL stake pool validators for a given epoch (defaults to latest). Only includes validators that are actively part of the JitoSOL validator set. **Endpoint**: `/api/v1/jitosol_validators` **Method**: `GET | POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | | `epoch` | number | No | - | Filter by specific epoch | #### Response Fields | Field | Type | Description | | ----------------------------- |-------- | ----------------------------------------------------------------------------- | | `vote_account` | string | Validator vote account public key | | `mev_commission_bps` | number | Validator’s MEV commission in basis-points | | `mev_rewards` | number | Post-commission MEV lamports paid to validator + stakers | | `priority_fee_commission_bps` | number | Priority-fee commission (bps) | | `priority_fee_rewards` | number | Post-commission priority-fee lamports | | `running_jito` | boolean | `true` if validator is running Jito-Solana | | `running_bam` | boolean | `true` if validator is running BAM | | `active_stake` | number | Lamports actively staked with this validator | | `jito_sol_active_lamports` | number | Active stake lamports delegated to this validator from the JitoSOL stake-pool | #### Example Request ```bash curl -X POST \ https://kobe.mainnet.jito.network/api/v1/jitosol_validators \ -H 'Content-Type: application/json' \ -d '{ "epoch":600 }' ``` #### Example Response ```json { "validators": [ { "vote_account": "CviQXDMPZPVAZ5qgVGN2gSBSD9GqqwRt7VZidoHMpArr", "mev_commission_bps": 10000, "mev_rewards": 3204800942, "priority_fee_commission_bps": null, "priority_fee_rewards": null, "running_jito": true, "running_bam": false, "active_stake": 47753222427851, "jito_sol_active_lamports": 3282880 }, // … ] } ``` --- ### 3. Validator Historical Reward **Purpose**: Returns historical reward data for a single validator, sorted by epoch (desc). **Endpoint**: `/api/v1/validators/{vote_account}` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | #### Response Fields | Field | Type | Description | | ----------------------------- |-------- | -------------------------------------------------------- | | `epoch` | number | The epoch when these rewards were earned | | `mev_commission_bps` | number | Validator’s MEV commission in basis-points | | `mev_rewards` | number | Post-commission MEV lamports paid to validator + stakers | | `priority_fee_commission_bps` | number | Priority-fee commission (bps) | | `priority_fee_rewards` | number | Post-commission priority-fee lamports | #### Example Request ```bash curl https://kobe.mainnet.jito.network/api/v1/validators/GdRKUZKdiXMEATjddQW6q4W8bPgXRBYJKayfeqdQcEPa ``` #### Example Response ```json [ { "epoch": 608, "mev_commission_bps": 10000, "mev_rewards": 59355050, "priority_fee_commission_bps": 5000, "priority_fee_rewards": 43328291 } // … ] ``` --- ### 4. Jito Stake Over Time **Purpose**: Returns a map of epoch → percentage of **all Solana stake** that is delegated to Jito-running validators. **Endpoint**: `/api/v1/jito_stake_over_time` **Method**: `GET | POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | #### Response Fields | Field | Type | Description | | ----------------------- |-------- | --------------------------------------------------------------------------------------------------------------------- | | `stake_ratio_over_time` | object | Map of epoch → decimal ratio representing the percentage of total Solana stake delegated to Jito validators (0.0-1.0) | #### Example Request ```bash curl https://kobe.mainnet.jito.network/api/v1/jito_stake_over_time ``` #### Example Response ```json { "stake_ratio_over_time": { "484": 0.27771625202212147, "485": 0.27866636980357196 } } ``` --- ### 5. MEV Rewards **Purpose**: Network-level statistics for a single epoch. **Endpoint**: `/api/v1/mev_rewards` **Method**: `GET | POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | | `epoch` | number | No | - | Filter by specific epoch | #### Response Fields | Field | Type | Description | | ---------------------------- |-------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `epoch` | number | The epoch number for which MEV rewards data is provided | | `total_network_mev_lamports` | number | Total MEV rewards generated across the entire Solana network during this epoch, measured in lamports | | `jito_stake_weight_lamports` | number | Total amount of stake (in lamports) delegated to validators running Jito software during this epoch | | `mev_reward_per_lamport` | number | MEV rewards earned per lamport of stake for Jito validators in this epoch (calculated as total_network_mev_lamports / jito_stake_weight_lamports) | #### Example Request ```bash curl -X POST https://kobe.mainnet.jito.network/api/v1/mev_rewards -H 'Content-Type: application/json' -d '{ "epoch": 600 }' ``` #### Example Response ```json { "epoch": 600, "total_network_mev_lamports": 19630470685094, "jito_stake_weight_lamports": 273972433518536409, "mev_reward_per_lamport": 0.0000716512622565213 } ``` --- ### 6. Daily MEV Rewards **Purpose**: Aggregated MEV tips per calendar day. **Endpoint**: `/api/v1/daily_mev_rewards` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | #### Response Fields | Field | Type | Description | | ---------------- |-------- | ---------------------------------------------------------------------------------------------------------- | | `day` | string | The calendar date in UTC format (YYYY-MM-DD HH:MM:SS.sss UTC) for which the MEV rewards data is aggregated | | `count_mev_tips` | number | Total number of individual MEV tip transactions that occurred on this day | | `jito_tips` | number | Total amount of MEV tips paid to Jito (in SOL) on this day | | `tippers` | number | Total number of unique accounts that submitted MEV tips on this day | | `validator_tips` | number | Total amount of MEV tips distributed to validators (in SOL) on this day | #### Example Request ```bash curl https://kobe.mainnet.jito.network/api/v1/daily_mev_rewards ``` #### Example Response ```json [ { "day": "2025-07-29 00:00:00.000 UTC", "count_mev_tips": 23899823, "jito_tips": 385.815098392558, "tippers": 898619, "validator_tips": 7330.48686946401 }, { "day": "2025-07-30 00:00:00.000 UTC", "count_mev_tips": 16157401, "jito_tips": 232.975239402936, "tippers": 581839, "validator_tips": 4426.5295486581 } ] ``` --- ### 7. Stake Pool Stats **Purpose**: Stake pool analytics including TVL, APY, validator count, supply metrics, and aggregated MEV rewards over time. **Endpoint**: `/api/v1/stake_pool_stats` **Method**: `GET` or `POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default. | Description | | -------------------- | ------ | -------- |------------- | ----------------------------------------------------------------- | | `bucket_type` | string | No | "Daily". | Time bucket aggregation type. Currently only "Daily" is supported | | `range_filter` | object | No | Last 7 days | Date range filter with `start` and `end` DateTime fields | | `range_filter.start` | string | No | 7 days ago | Start date in ISO 8601 format (e.g., "2025-08-15T22:55:06Z") | | `range_filter.end` | string | No | Now. | End date in ISO 8601 format (e.g., "2025-08-22T22:55:06Z") | | `sort_by` | object | No | Default sort | Sort configuration object | | `sort_by.field` | string | No | "BlockTime" | Sort field. Currently only "BlockTime" is supported | | `sort_by.order` | string | No. | "Asc" | Sort order: "Asc" or "Desc" | #### Response Fields | Field | Type | Description | | ------------------------ |------- | ---------------------------------------------------------------------- | | `aggregated_mev_rewards` | number | Total aggregated MEV rewards across all time periods (in lamports) | | `mev_rewards` | array | Time series data of MEV rewards with integer data points | | `tvl` | array | Time series data of Total Value Locked in the stake pool (in lamports) | | `apy` | array | Time series data of Annual Percentage Yield as decimal values | | `num_validators` | array | Time series data of validator count in the stake pool | | `supply` | array | Time series data of JitoSOL token supply as decimal values | #### Example Request ```bash curl -X POST \ https://kobe.mainnet.jito.network/api/v1/stake_pool_stats \ -H 'Content-Type: application/json' \ -d '{ "bucket_type": "Daily", "range_filter": { "start": "2025-08-15T00:00:00Z", "end": "2025-08-16T00:00:00Z" }, "sort_by": { "field": "BlockTime", "order": "Asc" } }' ``` #### Example Response ```json { "aggregated_mev_rewards": 17917503591959, "mev_rewards": [ { "data": 841552703382, "date": "2025-08-15T22:55:06Z" }, { "data": 5244986563088, "date": "2025-08-16T23:20:47Z" } ], "tvl": [ { "data": 15209213875510266, "date": "2025-08-15T22:55:06Z" }, { "data": 15211604884230567, "date": "2025-08-16T23:20:47Z" } ], "apy": [ { "data": 0.07184861225308525, "date": "2025-08-15T22:55:06Z" }, { "data": 0.07184861239211937, "date": "2025-08-16T23:20:47Z" } ], "num_validators": [ { "data": 1040, "date": "2025-08-15T22:55:06Z" }, { "data": 1040, "date": "2025-08-16T23:20:47Z" } ], "supply": [ { "data": 12420237.336776868, "date": "2025-08-15T22:55:06Z" }, { "data": 12422189.896316852, "date": "2025-08-16T23:20:47Z" } ] } ``` --- ### 8. MEV Commission Average Overtime **Purpose**: Returns stake-weighted average MEV commission rates by epoch for all Jito-running validators. **Endpoint**: `/api/v1/mev_commission_average_over_time` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Response Fields | Field | Type | Description | | ---------------------------------- |------- | ------------------------------------------------------------------- | | `average_mev_commission_over_time` | object | Map of epoch numbers to stake-weighted average MEV commission rates | #### Calculation Method The average MEV commission is calculated as a **stake-weighted average**: 1. **Filter**: Only includes validators running Jito (`running_jito: true`) 2. **Weight by Stake**: Each validator's commission rate is weighted by their active stake amount 3. **Aggregate by Epoch**: Results are grouped and averaged per epoch 4. **Formula**: `(Sum of [MEV Commission × Active Stake]) / (Sum of Active Stake)` This provides a more accurate representation of the effective commission rate experienced by stakers, as validators with more stake have proportionally more influence on the average. #### Example Request ```bash curl https://kobe.mainnet.jito.network/api/v1/mev_commission_average_over_time ``` #### Example Response ```json { "aggregated_mev_rewards": 841552703382, "mev_rewards": [ { "data": 841552703382, "date": "2025-08-15T22:55:06Z" } ], "tvl": [ { "data": 15209213875510266, "date": "2025-08-15T22:55:06Z" } ], "apy": [ { "data": 0.07184861225308525, "date": "2025-08-15T22:55:06Z" } ], "num_validators": [ { "data": 1040, "date": "2025-08-15T22:55:06Z" } ], "supply": [ { "data": 12420237.336776868, "date": "2025-08-15T22:55:06Z" } ] } ``` --- ### 9. JitoSOL/SOL Ratio **Purpose**: Retrieve the historical exchange ratio between JitoSOL and SOL over time. **Endpoint**: `/api/v1/jitosol_sol_ratio` **Method**: `GET` or `POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | |--------------------- | ------ | -------- | ----------- |------------------------------------------------------------- | | `range_filter` | object | No | Last 7 days | Date range filter with `start` and `end` DateTime fields | | `range_filter.start` | string | No | 7 days ago | Start date in ISO 8601 format (e.g., "2025-08-15T00:00:00Z") | | `range_filter.end` | string | No | Now | End date in ISO 8601 format (e.g., "2025-08-22T00:00:00Z") | #### Response Fields | Field | Type | Description | | -------- | ------ | -------------------------------------------------- | | `ratios` | array | Time series data of JitoSOL to SOL exchange ratios | #### Example Request ```bash curl -X POST \ https://kobe.mainnet.jito.network/api/v1/jitosol_sol_ratio \ -H 'Content-Type: application/json' \ -d '{ "range_filter": { "start": "2025-08-15T00:00:00Z", "end": "2025-08-16T00:00:00Z" } }' ``` #### Example Response ```json { "ratios": [ { "data": 1.224550985871672, "date": "2025-08-15T22:55:06Z" } ] } ``` --- ### 10. Preferred Withdraw Validator List **Purpose**: Retrieve a list of validators with lower rank (borderline of delegation) that are optimal candidates for withdrawal operations. These validators have sufficient withdrawable stake while being the least impactful to remove stake from. Withdrawing from these validators minimizes rebalancing needs and helps maintain optimal APY for the stake pool. **Endpoint**: `/api/v1/preferred_withdraw_validator_list` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| | `min_stake_threshold` | number | No | 10000 | **Denominated in SOL.** Minimum stake threshold. Only validators with withdrawable stake above this threshold will be included | | `limit` | number | No | 50 | Number of validators to return in the response | | `randomized` | boolean | No | false | Whether to randomize the order of validators. Use this when you want to minimize the chance of unstaking from the same validators as other clients. Useful in multisig or durable nonce scenarios where transactions are sitting for extended periods of time | **Important:** Query parameters are denominated in SOL for convenience. #### Response Fields | Field | Type | Description | |-------|------|-------------| | `rank` | number | The position of the validator in the ranked list (1-indexed) | | `vote_account` | string | The validator's vote account public key | | `withdrawable_lamports` | number | **Denominated in lamports.** Amount of lamports available for withdrawal from this validator (1 SOL = 1,000,000,000 lamports) | | `stake_account` | string | The validator's stake account address from the stake pool | **Important:** Response amounts are denominated in lamports, not SOL. #### Example Request ```bash # Get default list (50 lower-ranked validators optimal for withdrawal) curl "https://kobe.mainnet.jito.network/api/v1/preferred_withdraw_validator_list" # Get top 20 lower-ranked validators with at least 5,000 SOL withdrawable stake curl "https://kobe.mainnet.jito.network/api/v1/preferred_withdraw_validator_list?min_stake_threshold=5000&limit=20" # Get randomized list for multisig scenarios to avoid transaction conflicts curl "https://kobe.mainnet.jito.network/api/v1/preferred_withdraw_validator_list?limit=30&randomized=true" ``` #### Example Response ```json [ { "rank": 1, "vote_account": "J2nUHEAgZFRyuJbFjdqPrAa9gyWDuc7hErtDQHPhsYRp", "withdrawable_lamports": 95000000000000, "stake_account": "6USTT5jBUBRgZMGRkG7QX2S5MjQ8wVwSYMRfRRhJMqDj" }, { "rank": 2, "vote_account": "Certusm1sa411sMpV9FPqU5dXAYhmmhygvxJ23S6hJ24", "withdrawable_lamports": 87500000000000, "stake_account": "3kxSvADSt7N8LKNRVK5DW7xNVQRszK3VUvkUPMmJPcWo" }, { "rank": 3, "vote_account": "DfXygSm4jCyNCybVYYK6DwvWqjKee8pbDmJGcLWNDXjh", "withdrawable_lamports": 73200000000000, "stake_account": "8ZfVWmhFZHCRvU7uuS9MbVbxDtB1uH7kdUPnnPFKoQRi" }, { "rank": 4, "vote_account": "HxRrsnbc6K8CdEo3LCTrSUkFaDDxv9BdJsTDzBKnUVWH", "withdrawable_lamports": 65000000000000, "stake_account": "AyPMvRePEuQuaBQn2JHXWVkGmUGQpCfgKQCBPBxyqbia" }, { "rank": 5, "vote_account": "EARNynHRWg6GfwJBmRAYa9C1zDa6Vq7AWTLS2hZaL9a", "withdrawable_lamports": 52000000000000, "stake_account": "FJemUNBmezZ5FFKpQQFvag4g9x4TjBKN7tCnQPJzUXQ7" } ] ``` --- ### 11. BAM Epoch Metrics **Purpose**: Returns BAM delegation metrics for a given epoch. **Endpoint**: `/api/v1/bam_delegation_metrics` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | | `epoch` | number | Yes | - | Filter by specific epoch | #### Response Fields | Field | Type | Description | | ------------------------------- |-------- | ----------------------------------------------------------------------------- | | `allocation_bps` | number | Allocation tier based on JIP-28 in BPS | | `available_bam_delegation_stake`| number | Total JitoSOL stake available for BAM delegation in lamports | | `bam_stake` | number | Total stake amount of BAM eligible validators in lamports | | `eligible_bam_validator_count` | number | Eligible BAM validator count | | `epoch` | number | Epoch number | | `jitosol_stake` | number | Total Jitosol stake amount | | `timestamp` | number | Timestamp | | `total_stake` | number | Total stake amount of all validators in lamports | #### Example Request ```bash curl -X GET \ https://kobe.mainnet.jito.network/api/v1/bam_epoch_metrics?epoch=895 ``` #### Example Response ```json { "bam_epoch_metrics": { "allocation_bps": 3000, "available_bam_delegation_stake": 4206990925405254, "bam_stake": 14856675235224159, "eligible_bam_validator_count": 49, "epoch": 895, "jitosol_stake": 14023303084684180, "timestamp": 1765846141, "total_stake": 417067545601353217 } } ``` --- ### 12. BAM Validators **Purpose**: Returns a list of BAM validators for a given epoch, including their eligibility status and stake-related metrics. **Endpoint**: `/api/v1/bam_validators` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | | `epoch` | number | Yes | - | Filter by specific epoch | #### Response Fields | Field | Type | Description | | ------------------------------- |-------- | ----------------------------------------------------------------------------- | | `active_stake` | number | Active stake in lamports | | `epoch` | number | Epoch number | | `identity_account` | string | Identity account public key | | `is_eligible` | boolean | Is eligible validator for BAM delegation | | `ineligibility_reason` | string | The reason of ineligibility | | `timestamp` | number | Timestamp | | `vote_account` | string | Vote account public key | #### Example Request ```bash curl -X GET \ https://kobe.mainnet.jito.network/api/v1/bam_validators?epoch=895 ``` #### Example Response ```json { "bam_validators": [ { "active_stake": 550051344710010, "epoch": 895, "identity_account": "6XKqyUVUcpe3CNucjF6gk5zonJDqNGvob6kaTy4Ps1U", "is_eligible": true, "ineligibility_reason": null, "timestamp": 1765846137, "vote_account": "SKRuTecmFDZHjs2DxRTJNEK7m7hunKGTWJiaZ3tMVVA" }, ... ] } ``` --- ### 13. BAM Delegation Blacklist **Purpose**: Returns a list of vote accounts that are blacklisted from BAM delegation. **Endpoint**: `/api/v1/bam_delegation_blacklist` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | --------- | ------ | -------- |-------- | ------------------------------ | | N/A | N/A | N/A | N/A | No query parameters. | #### Response Fields | Field | Type | Description | | ------------------------------- |-------- | ------------------------- | | `added_epoch` | number | Epoch number | | `vote_account` | string | Vote account public key | #### Example Request ```bash curl -X GET \ https://kobe.mainnet.jito.network/api/v1/bam_delegation_blacklist ``` #### Example Response ```json [ { "vote_account": "12345......", "added_epoch": 892 } ] ``` --- ### 14. BAM Validator Scoring **Purpose**: Returns the scoring components of a specific validator **Endpoint**: `/api/v1/bam_validator_score` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | -------------- | ------- | -------- |-------- | ------------------------------- | | `epoch` | number | Yes | - | Filter by specific epoch | | `vote_account` | string | Yes | - | Filter by specific vote account | #### Response Fields | Field | Type | Description | | -------------- |-------- | ------------------------- | | `vote_account` | string | Vote account public key | | `score` | number | Score number | #### Example Request ```bash curl -X GET \ https://kobe.mainnet.jito.network/api/v1/bam_validator_score?epoch=902&vote_account=48oxpSHQkM4sdXUY9NQ8KnEtebzZbyk8uUT7JRdVQNuf ``` #### Example Response ```json { "vote_account": "48oxpSHQkM4sdXUY9NQ8KnEtebzZbyk8uUT7JRdVQNuf", "score": 1 } ``` --- ## Frontend APY Calculation The Jito frontend calculates the current APY displayed to users by fetching historical stake pool data and using the most recent available data point. ### Jito Frontend Implementation Here's how the Jito frontend retrieves and processes APY data: ```javascript export default async function handler(req, res) { const apiUrl = 'https://kobe.mainnet.jito.network/api/v1/stake_pool_stats' // Set up start and end dates const start = new Date('2022-10-31T00:00:00Z') // Launch date const end = new Date() const statsRequest = { bucket_type: 'Daily', range_filter: { start: start.toISOString(), end: end.toISOString(), }, sort_by: { field: 'BlockTime', order: 'Asc', }, } try { const response = await fetch(apiUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify(statsRequest), }) if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`) } const data = await response.json() if (data) { const { aggregated_mev_rewards: aggregatedMevRewards, apy, mev_rewards: mevRewards, num_validators: numValidators, supply, tvl, } = data const camelCaseData = { getStakePoolStats: { aggregatedMevRewards, apy, mevRewards, numValidators, supply, tvl, }, } res.status(200).json(camelCaseData) } else { res.status(200).json(data) } } catch (error) { console.error('Error fetching data:', error) res.status(500).json({ message: `Error fetching data: ${error.message}` }) } } ``` ### APY Selection Logic To display the current APY on the frontend: 1. **Fetch Complete History**: The API call retrieves all historical data from JitoSOL's launch date (October 31, 2022) to the present 2. **Select Most Recent**: The frontend uses the most recent data point from the `apy` array 3. **Display Current Rate**: This most recent APY value represents the current annualized yield rate shown to users The `apy` field in the response contains time-series data where each entry includes: - `data`: The APY as a decimal value (e.g., 0.07184861225308525 = ~7.18%) - `date`: The timestamp when this APY was calculated Note that the stake_pool_stats endpoint returns smoothed values when requesting for periods longer than 10 epochs. Hence, the APY data we show on our frontend is smoothed. --- ## Notes & Caveats * The **current epoch** always reports `mev_rewards = 0` because rewards are finalized at epoch-close. * All lamport values are **post-commission** – delegators receive their share via separate claim paths documented in the *MEV Rewards API* page. * Pagination caps: `limit ≤ 10 000` for list endpoints. * All endpoints are cached for at least 60 s; identical requests within this window return cached data. --- # Steward API > Steward program event monitoring ## API Endpoints ### 1. Steward Events **Purpose**: Retrieves Jito Steward program events with filtering and pagination support. Returns detailed information about stakenet decisions and operations. **Endpoint**: `/api/v1/steward_events` **Method**: `GET or POST` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | -------------- | ------ | -------- |-------- | ------------------------------------------------------------- | | `event_type` | string | No | - | Filter by specific steward event type (see Event Types below) | | `vote_account` | string | No | - | Filter by validator vote account public key | | `epoch` | number | No | - | Filter by specific epoch number | | `limit` | number | No | 100 | Number of results to return (used with skip for pagination) | | `skip` | number | No | 0 | Number of results to skip for pagination | #### Event Types | Event Type. | Versions Supported | Description | | -------------------------- | ------------------ | ------------------------------------------------------ | | `ScoreComponents` | V1, V2, V3 | Validator scoring calculations and performance metrics | | `InstantUnstakeComponents` | V1, V2, V3 | Emergency unstaking events for problematic validators | | `RebalanceEvent` | V1 | Stake rebalancing operations across validators | | `DecreaseComponents` | V1 | Stake reduction events for underperforming validators | | `StateTransition` | V1 | Steward operational state changes | | `AutoAddValidatorEvent` | V1 | Automatic validator additions to the stake pool | | `AutoRemoveValidatorEvent` | V1 | Automatic validator removals from the stake pool | | `EpochMaintenanceEvent` | V1 | Routine epoch-boundary maintenance operations | #### Special Event Type Handling - **ScoreComponents**: Queries all versions (ScoreComponents, ScoreComponentsV2, ScoreComponentsV3) - **InstantUnstakeComponents**: Queries all versions (InstantUnstakeComponents, InstantUnstakeComponentsV2, InstantUnstakeComponentsV3) #### Response Fields | Field | Type | Description | | -------- |-------- | ------------------------------ | | `events` | array | Array of steward event objects | #### Steward Event Object Fields | Field | Type | Description | | -------------- |------------ | ----------------------------------------------------------------- | | `signature` | string | Transaction signature where the event occurred | | `event_type` | string | Type of steward event (e.g., "AutoAddValidatorEvent") | | `vote_account` | string | Validator vote account public key associated with the event | | `timestamp` | string | ISO 8601 timestamp when the event occurred | | `epoch` | number | Epoch number when the event took place | | `slot` | number | Blockchain slot number where the event occurred | | `data` | object | Event-specific data (varies by event type) | | `tx_error` | string/null | Transaction error message if the event failed, null if successful | #### Sorting and Pagination - **Default Sort**: Events are sorted by slot number in descending order (newest first) - **Pagination**: Use `limit` and `skip` parameters for pagination - **Total Count**: Response includes total count for pagination calculation #### Example Request ```bash curl -X POST \ https://kobe.mainnet.jito.network/api/v1/steward_events?event_type=ScoreComponents | jq ``` #### Example Response ```json { "events": [ { "signature": "48TciVTNG2kVVE8CnCbAQjRG7qCk7HMyunNRZR1zT8gYNWRvg2kPPjSDuwwrHnTjvXGAqQ6WJY18DQybQPBGw2Uc", "event_type": "AutoAddValidatorEvent", "vote_account": "Csp2hDVRX4cRitFEswJJcoH9ju4rcPUSsqU9pkh5JBQU", "timestamp": "2025-08-21T18:42:42Z", "data": { "validator_list_index": 1039 }, "epoch": 837, "tx_error": null }, // … ] } ``` --- # Staking Integration > Code examples for integrating JitoSOL staking functionality ## Developer Integration Guide This guide shows how to integrate JitoSOL staking and unstaking functionality using both assisted (SPL stake pool library) and manual transaction building methods. ## Installation ```bash npm install @solana/spl-stake-pool npm install @solana/web3.js npm install @solana/spl-token npm install @jito-foundation/stake-deposit-interceptor-sdk ``` ## Basic Setup ```typescript import * as solanaStakePool from '@solana/spl-stake-pool' import { Connection, PublicKey, LAMPORTS_PER_SOL } from '@solana/web3.js' // JitoSOL stake pool address (Mainnet) const JITO_STAKE_POOL_ADDRESS = new PublicKey('Jito4APyf642JPZPx3hGc6WWJ8zPKtRbRs4P815Awbb') // JitoSOL mint address const JITO_MINT_ADDRESS = new PublicKey('J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn') const connection = new Connection('YOUR_RPC_ENDPOINT') ``` ## Assisted Staking (Recommended) ### Staking SOL for JitoSOL ```typescript async function stakeSOL(amount: number, userWallet: any) { // Convert SOL to lamports const lamports = Math.floor(amount * LAMPORTS_PER_SOL) // Get deposit instructions from SPL stake pool library const { instructions, signers } = await solanaStakePool.depositSol( connection, JITO_STAKE_POOL_ADDRESS, userWallet.publicKey, lamports ) // Create and send transaction const transaction = new Transaction() transaction.add(...instructions) const { blockhash } = await connection.getLatestBlockhash('finalized') transaction.recentBlockhash = blockhash transaction.feePayer = userWallet.publicKey // Sign with any additional signers if (signers.length > 0) { transaction.sign(...signers) } const signedTransaction = await userWallet.signTransaction(transaction) const signature = await connection.sendRawTransaction(signedTransaction.serialize()) return signature } ``` ### Unstaking JitoSOL for SOL ```typescript async function unstakeJitoSOL(amount: number, userWallet: any, useReserve: boolean = false) { // Get withdraw instructions from SPL stake pool library const { instructions, signers } = await solanaStakePool.withdrawStake( connection, JITO_STAKE_POOL_ADDRESS, userWallet.publicKey, amount, // Amount in JitoSOL tokens useReserve // false = withdraw to stake account, true = instant SOL via reserve ) const transaction = new Transaction() transaction.add(...instructions) const { blockhash } = await connection.getLatestBlockhash('finalized') transaction.recentBlockhash = blockhash transaction.feePayer = userWallet.publicKey if (signers.length > 0) { transaction.sign(...signers) } const signedTransaction = await userWallet.signTransaction(transaction) const signature = await connection.sendRawTransaction(signedTransaction.serialize()) return signature } ``` ### Depositing Stake Accounts with Interceptor When depositing existing stake accounts (as opposed to native SOL), the Jito Interceptor program handles the transaction. The interceptor implements a 10-hour cooldown period with a time-decaying fee to protect against toxic flow. For more details, see the [Interceptor user guide](https://www.jito.network/docs/jitosol/user-guides/interceptor.md). ```typescript import { depositStake } from '@jito-foundation/stake-deposit-interceptor-sdk' async function depositStakeAccount( stakeAccount: PublicKey, validatorVote: PublicKey, userWallet: any ) { // Get deposit instructions from interceptor SDK const { instructions, signers } = await depositStake( connection, userWallet.publicKey, // payer for deposit receipt rent JITO_STAKE_POOL_ADDRESS, // stake pool to deposit into userWallet.publicKey, // authorized withdrawer/staker validatorVote, // validator vote account for the stake stakeAccount, // stake account to deposit null // poolTokenReceiverAccount (optional, will create associated token account if not provided) ) // Create and send transaction const transaction = new Transaction() transaction.add(...instructions) const { blockhash } = await connection.getLatestBlockhash('finalized') transaction.recentBlockhash = blockhash transaction.feePayer = userWallet.publicKey // Sign with any additional signers if (signers.length > 0) { transaction.sign(...signers) } const signedTransaction = await userWallet.signTransaction(transaction) const signature = await connection.sendRawTransaction(signedTransaction.serialize()) return signature } ``` **Note:** When depositing stake accounts, JitoSOL tokens are minted and held by the interceptor program's vault, not immediately sent to your wallet. A deposit receipt is created that will be auto-claimed after the 10-hour cooldown (with no fees) or and can be claimed earlier with a time-decaying fee. For SDK documentation and claiming examples, see the [@jito-foundation/stake-deposit-interceptor-sdk](https://github.com/jito-foundation/stake-deposit-interceptor/tree/master/package). ## Getting Pool Information ```typescript async function getPoolInfo() { const stakePoolAccount = await solanaStakePool.getStakePoolAccount( connection, JITO_STAKE_POOL_ADDRESS ) if (!stakePoolAccount?.account?.data) { throw new Error('Failed to fetch stake pool account data') } const stakePoolData = stakePoolAccount.account.data // Calculate conversion rate const solJitoConversion = !stakePoolData.poolTokenSupply.isZero() ? Number(stakePoolData.totalLamports.toString()) / Number(stakePoolData.poolTokenSupply.toString()) : 0 return { totalLamports: stakePoolData.totalLamports, totalPoolTokens: stakePoolData.poolTokenSupply, solJitoConversion, poolMint: stakePoolData.poolMint, reserveStake: stakePoolData.reserveStake, validatorList: stakePoolData.validatorList, manager: stakePoolData.manager } } ``` ## Manual Transaction Building For developers who need more control or want to understand the underlying mechanics, transactions can be built manually instead of using the SPL stake pool library helpers. ### High-Level Manual Approach **Manual Staking:** - Create associated token account for JitoSOL if needed - Build `DepositSol` instruction (instruction index 14) with proper account metas - Handle withdraw authority PDA derivation - Manage compute budget and transaction signing **Manual Unstaking:** - Create approval instruction for token transfer - Find suitable validator stake account within the pool - *Tip: Use the [Preferred Withdraw Validator List API](https://www.jito.network/docs/jitosol/jitosol-liquid-staking/for-developers/stake-pool-api.md#10-preferred-withdraw-validator-list) to get optimal validators for withdrawal that minimize rebalancing needs* - Create temporary stake account for receiving unstaked funds - Build `WithdrawStake` instruction (instruction index 10) - Handle all required account metas and signers The manual approach involves: 1. **Account Discovery**: Finding the right accounts (withdraw authority, validator stake accounts, etc.) 2. **Instruction Building**: Manually constructing the raw instruction data and account metas 3. **Signer Management**: Handling ephemeral keypairs and approval authorities 4. **Error Handling**: Managing edge cases like insufficient validator balances ### Detailed Manual Implementation For complete manual implementation examples, see the reference repository at: **[https://github.com/jito-foundation/jito-stake-unstake-reference](https://github.com/jito-foundation/jito-stake-unstake-reference)** The repository includes: - `useManualStake.ts` - Manual DepositSol instruction building - `useManualUnstake.ts` - Manual WithdrawStake instruction building with validator selection - Working examples of account derivation, instruction data encoding, and transaction construction ## Important Considerations ### Unstaking Options - **Withdraw to Stake Account** (`useReserve: false`): Creates a stake account that requires deactivation (1 epoch) before SOL is liquid - **Instant Reserve Withdrawal** (`useReserve: true`): Immediate SOL but subject to available liquidity and fees ### Network Differences - Pool parameters and minimum balances differ between Mainnet and Testnet - Always verify addresses and test on Testnet first ## Additional Resources - [Solana Stake Pool Documentation](https://spl.solana.com/stake-pool) - [SPL Stake Pool TypeScript SDK](https://github.com/solana-program/stake-pool/tree/main/clients/js-legacy) - [Jito Interceptor SDK](https://github.com/jito-foundation/stake-deposit-interceptor/tree/master/package) - TypeScript SDK for stake account deposits - [JitoSOL Stake/Unstake Reference Implementation](https://github.com/jito-foundation/jito-stake-unstake-reference) - [Jito Network Documentation](https://docs.jito.network/) This guide provides both assisted (library-based) and manual transaction building approaches. For production applications, transaction confirmation, and user experience considerations. --- # BAM Boost API > JIP 31 BAM Early Adopter Subsidy Programme ## API Endpoints ### 1. BAM Boost Validators **Purpose**: Returns BAM boost information for all validators in a given epoch **Endpoint**: `/api/v1/bam_boost_validators` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Query Parameters | Parameter | Type | Required | Default | Description | | -------------- | ------- | -------- |-------- | ------------------------------- | | `epoch` | number | Yes | - | Filter by specific epoch | #### Response Fields The response contains a `bam_boost_validators` array with the following fields per entry: | Field | Type | Description | | ---------------------- | -------------- | ------------------------------------ | | `name` | string \| null | Validator name (null if not set) | | `epoch` | number | Epoch number | | `identity_account` | string | Validator identity public key | | `amount` | number | BAM boost amount in lamports | | `claimed` | boolean | Whether the boost has been claimed | | `claim_status_address` | string | Claim status account public key | #### Example Request ```bash curl -X GET \ https://kobe.mainnet.jito.network/api/v1/bam_boost_validators?epoch=900 ``` #### Example Response ```json { "bam_boost_validators": [ { "name": "IBB Club", "epoch": 900, "identity_account": "2KFrkqEeSBKEHiMjUugPxTkBJ2jXepgFBqHu5ZFxtaFg", "amount": 5185289422, "claimed": false, "claim_status_address": "Grhjd1iPxRbDpdcpMnHTjj6gHgPLqqny8yVzRYX1DHFk" }, { "name": null, "epoch": 900, "identity_account": "Ha1CoNmAcbCQbg9QcCjLH79gLCqVZdxABwccQH3xexXE", "amount": 5243935756, "claimed": false, "claim_status_address": "58ic9vW34xN8FyPAm4guHgJxvcQ37peXJeamNjuNFVUk" } ] } ``` --- ### 2. Claim **Purpose**: Returns the claim proof and details required to claim BAM boost rewards for a specific validator **Endpoint**: `/api/v1/claim/{network}/{epoch}/{identity_account}` **Method**: `GET` **Base URL**: `https://kobe.mainnet.jito.network` #### Path Parameters | Parameter | Type | Required | Description | | ------------------ | ------ | -------- | ------------------------------------------------ | | `network` | string | Yes | Network name (e.g., `mainnet`) | | `epoch` | number | Yes | Epoch number for the claim | | `identity_account` | string | Yes | Validator identity public key | #### Response Fields | Field | Type | Description | | ---------------------- | ---------- | ----------------------------------------------------- | | `amount` | number | Claimable amount in lamports | | `claimant` | string | Public key of the claimant | | `proof` | number[][] | Merkle proof as array of 32-byte arrays | | `merkle_root` | number[] | 32-byte merkle root | | `distributor_address` | string | Merkle distributor program address | | `claim_status_address` | string | Account address tracking the claim status | #### Example Request ```bash curl -X GET \ https://kobe.mainnet.jito.network/api/v1/claim/mainnet/915/5zuNci3TV79w6zLoJZzbZujMvkVZb2FcSPhgv9aT24AK ``` #### Example Response ```json { "amount": 1014322740, "claimant": "5zuNci3TV79w6zLoJZzbZujMvkVZb2FcSPhgv9aT24AK", "proof": [ [...], [...] ], "merkle_root": [...], "distributor_address": "CCRhL2ynYebEzxLWNUHCcEXrKqmJa2jJjnZrr7bDbgnb", "claim_status_address": "FYvKEnv3i36SwNRwFTvAKaQH8oo1F3EFTGfVc55oVkqm" } ``` --- # Staking SOL for JitoSOL > Complete guide to staking your SOL ## Overview **Time Required:** 2-5 minutes **Prerequisites:** Solana wallet with SOL tokens and small amount for transaction fees ### Step 1: Prepare Your Wallet **Supported Wallets:** - [Phantom](https://phantom.app/) (Beginner-friendly) - [Solflare](https://solflare.com/) (Beginner-friendly) - [Backpack](https://backpack.app/) - [Ledger](https://www.ledger.com/) (Hardware wallet via browser) - [Squads](https://squads.so/) (Multi-signature) - [Fireblocks](https://www.fireblocks.com/) (Institutional) **What You Need:** - SOL to deposit (or other SPL tokens you want to convert) - ~0.01 SOL minimum for transaction fees - If you don't have SOL: Buy from Coinbase, Kraken, or Binance and transfer to your wallet **Ledger Users:** JitoSOL works with Ledger wallets directly or through browser extensions. Approve transactions on your device when prompted. ### Step 2: Connect to Jito 1. Go to [jito.network/staking](https://www.jito.network/staking/) 2. Ensure you're on the "Stake" tab ![Stake/Unstake Toggle](https://www.jito.network/omnidocs/jitosol/images/stake-page-toggle-stake-unstake.png) 3. Click **"Connect Wallet"** and select your wallet type 4. Approve the connection request 5. Verify your wallet address appears in the top right **Wallet-Specific Guides:** - [Phantom Guide](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/staking-with-phantom.md) - [Solflare Guide](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/staking-with-solflare.md) - [Fireblocks Guide](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/stake-with-fireblocks.md) - [Squads Guide](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/staking-with-squads.md) ### Step 3: Choose Staking Method and Deposit **Option 1: SOL Staking** ![Direct Staking Flow](https://www.jito.network/omnidocs/jitosol/images/stake-page-stake-section-direct-stake-flow.png) 1. Enter SOL amount to stake 2. Choose method: - **Direct Mint:** Mint JitoSOL via Stake Pool contract (Recommended, no slippage) - **via Jupiter:** Swap SOL for JitoSOL via Jupiter DEX 3. Review how much JitoSOL you'll receive 4. Click "Convert to JitoSOL" **Option 2: Convert Stake Accounts to JitoSOL** 1. Click on the stake accounts row to view your existing stakes 2. Select stake accounts to convert 3. Confirm conversion to liquid JitoSOL - Note: deposited stake will be temporarily held by Jito's Interceptor program **Option 3: Convert SPL Tokens to JitoSOL** ![SPL Token Options](https://www.jito.network/omnidocs/jitosol/images/stake-page-stake-section-convert-spl-token-options.png) 1. Select source token from the dropdown (USDC, USDT, WBTC, mSOL, etc.) 2. Enter amount to convert 3. Review Jupiter's conversion route and rates 4. Execute the swap to receive JitoSOL ![Convert via Jupiter](https://www.jito.network/omnidocs/jitosol/images/stake-page-stake-section-via-jup-flow.png) ### Step 4: Complete Transaction ![Wallet Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-wallet-confirm-deposit-via-direct-mint.png) **Review Transaction:** - Check JitoSOL amount you'll receive (+ amount) - Verify SOL being spent (- amount) - Confirm network fees - **Ledger users:** Ensure transaction hash matches your device **Confirm in Wallet:** 1. Click "Confirm" in your wallet 2. Wait for blockchain confirmation (typically 10-30 seconds) ![Success Toast](https://www.jito.network/omnidocs/jitosol/images/stake-page-toast.png) **Verify Success:** - Look for success notification - Check JitoSOL appears in your wallet ## What Happens Next **Immediate Benefits:** - Start earning staking and MEV rewards immediately - Rewards automatically compound into your JitoSOL value **Using JitoSOL:** - **Hold:** Simply hold to accrue rewards - **DeFi:** Use in lending, DEXs, and yield farming - **Trade:** Exchange on Jupiter anytime **Next Steps:** - [Track Performance](https://www.jito.network/docs/jitosol/get-started/viewing-jitosol-rewards.md) - [Explore DeFi Opportunities](https://www.jito.network/defi/) ## Method Comparison **SOL Staking:** - Straightforward SOL to JitoSOL conversion - Choose Direct Mint for simple, no slippage staking. (Recommended) - Or, choose Via Jupiter to swap via DEX if needed **Stake Account Conversion:** - Convert existing SOL stakes to liquid JitoSOL via Interceptor - Keep earning rewards while gaining liquidity **SPL Token Conversion:** - Convert any supported asset (USDC, USDT, WBTC, mSOL, stSOL, etc.) to JitoSOL - Uses Jupiter for optimal swap routes ## Troubleshooting **Transaction Failed?** - Ensure sufficient SOL for fees - Increase priority fees or tip amount - Check slippage if converting via Jupiter - Refresh page and reconnect **Need Help?** - Review [FAQ section](https://www.jito.network/docs/jitosol/faqs/general-faqs.md) - Use wallet-specific guides above Ready to start? Visit [jito.network/staking](https://www.jito.network/staking/) --- # Staking with Phantom > Step-by-step guide for staking SOL using Phantom wallet **Time Required:** 2-5 minutes **Prerequisites:** Phantom wallet with SOL ## Prerequisites **What You Need:** - SOL to stake (purchase from Coinbase, Kraken, or Binance if needed) - Small amount of SOL for transaction fees **Ledger Users:** If using Phantom with Ledger: 1. Connect Ledger and open Solana app 2. Connect via Phantom browser extension 3. Approve transactions on your Ledger device when prompted ## Step 1: Connect Phantom Wallet 1. Go to [jito.network/staking](https://www.jito.network/staking/) ![Jito Header Before Connecting](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-header-with-connect-button-before-connecting.png) 2. Click **"Connect Wallet"** in the top right corner ![Choose Wallet Options](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-choose-wallet-options.png) 3. Select **"Phantom"** from the wallet options ![Phantom Connection Prompt](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-connect-wallet.png) 4. Click **"Connect"** to authorize the connection ![Connected Wallet Address](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-wallet-address-button.png) 5. Verify your wallet address appears in the top right corner ## Step 2: Stake SOL via Direct Mint 1. Ensure you're on the **"Stake"** tab ![Stake/Unstake Toggle](https://www.jito.network/omnidocs/jitosol/images/stake-page-toggle-stake-unstake.png) 2. Enter SOL amount to stake 3. Select **"Direct Mint"** (recommended due to no slippage) 4. Review JitoSOL amount you'll receive 5. Click **"Convert to JitoSOL"** ![Direct Staking Flow](https://www.jito.network/omnidocs/jitosol/images/stake-page-stake-section-direct-stake-flow.png) **Other Options:** You can also convert existing stake accounts or other SPL tokens (USDC, USDT, mSOL, etc.) to JitoSOL. See the [main staking overview](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/overview.md) for details on these methods. ## Step 3: Complete Transaction ![Phantom Wallet Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-wallet-confirm-deposit-via-direct-mint.png) **Review Transaction:** - Check JitoSOL amount you'll receive (+ amount) - Verify SOL being spent (- amount) - Confirm network fees **Approve in Phantom:** 1. Click **"Confirm"** in your Phantom wallet 2. Wait for blockchain confirmation (typically 10-30 seconds) ![Success Toast](https://www.jito.network/omnidocs/jitosol/images/stake-page-toast.png) **Verify Success:** - Look for success notification - Check JitoSOL appears in your Phantom wallet - Your JitoSOL balance represents staked SOL plus accumulated rewards ## What Happens Next **Immediate Benefits:** - Start earning staking and MEV rewards immediately - Rewards automatically compound into your JitoSOL's value - Track earnings in the [Rewards section](https://www.jito.network/docs/jitosol/get-started/viewing-jitosol-rewards.md) **Using JitoSOL:** - Hold to accrue rewards - Use in DeFi protocols (see [guide](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/using-overview.md) or go to our [DeFi opportunities page](https://www.jito.network/defi/)) - Trade anytime ## Troubleshooting **Transaction Failed?** - Ensure sufficient SOL for fees (~0.01 SOL minimum) - Check Phantom wallet connection - Refresh page and reconnect **Need Help?** - Review [main staking overview](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/overview.md) - Check [FAQ section](https://www.jito.network/docs/jitosol/faqs/general-faqs.md) --- # Staking with Solflare > Step-by-step guide for staking SOL using Solflare wallet **Time Required:** 2-5 minutes **Prerequisites:** Solflare wallet with SOL ## Prerequisites **What You Need:** - SOL to stake (purchase from Coinbase, Kraken, or Binance if needed) - Small amount of SOL for transaction fees ## Step 1: Connect Solflare Wallet 1. Go to [jito.network/staking](https://www.jito.network/staking/) ![Jito Header Before Connecting](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-header-with-connect-button-before-connecting.png) 2. Click **"Connect Wallet"** in the top right corner ![Choose Wallet Options](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-choose-wallet-options.png) 3. Select **"Solflare"** from the wallet options ![Solflare Authorization](https://www.jito.network/omnidocs/jitosol/images/solflare-connect-wallet-screen.png) 4. Click **"Connect"** to authorize the connection (you may choose "Trust this app" to prevent future prompts) ![Connected Wallet Address](https://www.jito.network/omnidocs/jitosol/images/solflare-unstake-sol-wallet-address-button.png) 5. Verify your wallet address appears in the top right corner ## Step 2: Stake SOL via Direct Mint 1. Ensure you're on the **"Stake"** tab ![Stake/Unstake Toggle](https://www.jito.network/omnidocs/jitosol/images/stake-page-toggle-stake-unstake.png) 2. Enter SOL amount to stake 3. Select **"Direct Mint"** (recommended due to no slippage) 4. Review JitoSOL amount you'll receive 5. Click **"Convert to JitoSOL"** ![Direct Staking Flow](https://www.jito.network/omnidocs/jitosol/images/stake-page-stake-section-direct-stake-flow.png) **Other Options:** You can also convert existing stake accounts or other SPL tokens (USDC, USDT, mSOL, etc.) to JitoSOL. See the [main staking overview](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/overview.md) for details on these methods. ## Step 3: Complete Transaction ![Solflare Wallet Confirmation](https://www.jito.network/omnidocs/jitosol/images/staking-page-staking-with-solflare-confirm-stake-tx.png) **Review Transaction:** - Check JitoSOL amount you'll receive (+ amount) - Verify SOL being spent (- amount) - Confirm network fees **Approve in Solflare:** 1. Click **"Approve"** in your Solflare wallet 2. Wait for blockchain confirmation (typically 10-30 seconds) ![Success Toast](https://www.jito.network/omnidocs/jitosol/images/stake-page-toast.png) **Verify Success:** - Look for success notification - Check JitoSOL appears in your Solflare wallet - Your JitoSOL balance represents staked SOL plus accumulated rewards ## What Happens Next **Immediate Benefits:** - Start earning staking and MEV rewards immediately - Rewards automatically compound into your JitoSOL's value - Track earnings in the [Rewards section](https://www.jito.network/docs/jitosol/get-started/viewing-jitosol-rewards.md) **Using JitoSOL:** - Hold to accrue rewards - Use in DeFi protocols (see [guide](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/using-overview.md) or go to our [DeFi opportunities page](https://www.jito.network/defi/)) - Trade anytime ## Troubleshooting **Transaction Failed?** - Ensure sufficient SOL for fees (~0.01 SOL minimum) - Check Solflare wallet connection - Refresh page and reconnect **Need Help?** - Review [main staking overview](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/overview.md) - Check [FAQ section](https://www.jito.network/docs/jitosol/faqs/general-faqs.md) --- # Stake with Fireblocks JitoSOL's is integrated with Fireblocks for secure institutional custody. - The [jito.network](https://www.jito.network/staking) site enables minting directly from Fireblocks. Select WalletConnect and pair using the Fireblocks app. Note, Fireblocks has not upgraded many customers to WalletConnect v2, which is required for usage. If you get "Error: Unable to init wallet, please try again later", your account is likely using the wrong WalletConnect version. Open a ticket with customer service and they can switch your service in an hour. - Follow the traditional workflow on [jito.network](https://www.jito.network/staking) and assets will be minted to your account. - JitoSOL is included in the Fireblocks asset list and it will be shown like SOL or any other SPL token. Jito maintains a Fireblocks account and can provide real-time support through the process. --- # Staking With Squads Squads, a turnkey multisig program for Solana, has integrated with JitoSOL. This enables teams or individuals to stake with JitoSOL in a secure environment. See their [documentation page](https://docs.squads.so/squads-v3-docs/integrations/staking/jitosol) for a step-by-step guide and Jito can assist with any other questions. --- # Buying or Selling JitoSOL > JitoSOL can be purchased with any mainstream SPL tokens ## Jupiter Jupiter ([jup.ag](https://jup.ag)) is the recommended venue for any purchases or sales of JitoSOL. The exchange aggregates liquidity across the entire Solana network and suggests the best route based on sizing and token pairs. Trades can also be split automatically across multiple routes if that provides better execution. Jupiter does not currently charge fees. See [here](https://jup.ag/onboard) for additional Jupiter instruction. After navigating to the site, connect your wallet and enter the payment token (USDC, SOL, etc.) along with JitoSOL in the "You Receive" section. Click "Swap" and the trade will be immediately executed. ![Buying Selling Jitosol](https://www.jito.network/omnidocs/jitosol/images/Buying_Selling_Jitosol-2025-jup.png) Check the trade price and ensure there is not a slippage warning for poor execution. If you receive this notice, consider reducing your trade size or minting JitoSOL directly on our website with no slippage. ## Alternate Venues JitoSOL is available directly from [Orca](https://www.orca.so/). Note Jupiter integrates these pools so no need to visit Orca or any other venue directly. --- # Unstaking Overview > Compare instant trading vs direct unstaking to choose the best method ## Two Ways to Convert JitoSOL When you want to convert your JitoSOL back to SOL (or other tokens), you have two main options: ### Method Comparison | Method | Speed | Typical Fee | Best For | |--------|-------|-------------|----------| | **Jupiter Trading** | Instant | <0.3% | Most users | | **Direct Unstaking** | Up to 2 days | 0.1% | Large amounts, fee optimization | ## Option 1: Instant Trading (Recommended) **Use the integrated Jupiter interface for instant conversion** ![Instant Unstaking via Jupiter](https://www.jito.network/omnidocs/jitosol/images/stake-page-unstake-section-unstake-via-jup-flow.png) **Advantages:** - Instant settlement - Get your SOL immediately - No waiting period - No need to track cooldown periods - Simple process - Single transaction, no multi-step workflow - Best liquidity - Often better exchange rates due to deep liquidity **How it works:** 1. Go to [jito.network/staking](https://www.jito.network/staking/) and select "Unstake" tab 2. Choose "Immediately via Jupiter" option 3. Enter JitoSOL amount to convert 4. Review the SOL amount you'll receive 5. Click "Unstake SOL" and approve in your wallet ![Jupiter Unstaking Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-wallet-confirm-jup-flow-unstake-jitosol.png) **Alternative:** You can also trade JitoSOL directly on [Jupiter](https://jup.ag/) for any other token. ## Option 2: Direct Unstaking **Use the delayed unstaking interface for direct conversion** ![Delayed Unstaking Interface](https://www.jito.network/omnidocs/jitosol/images/stake-page-unstake-section-delayed-unstake.png) **Advantages:** - Fixed 0.1% unstaking fee - No slippage. Get exact exchange rate - Direct from protocol. No third-party dependencies **Disadvantages:** - 2 day waiting period: Must wait for Solana epoch completion - Multi-step process: Requires multiple wallet interactions - Timing complexity: Need to track and complete withdrawal **When to use direct unstaking:** - Very large amounts where fee difference is significant - You specifically need the exact exchange rate without slippage - You're not in a hurry and can wait up to 2 days - Market liquidity on Jupiter is temporarily insufficient ### How Direct Unstaking Works ![Delayed Unstaking Process](https://www.jito.network/omnidocs/jitosol/images/stake-page-unstake-section-delayed-unstake-flow.png) The waiting period is a requirement of the Solana protocol, not specific to JitoSOL. All staked SOL requires a "cooldown" period of 1 epoch (up to 2 days) before it can be withdrawn. **Process Overview:** 1. **Initiate unstaking** - Press "Unstake SOL" button to transfer your stake from the pool to a stake account in your wallet 2. **Deactivate stake account** - Click "Deactivate" on the Manage page or in your wallet. Your stake will be available at the next epoch boundary (up to 2 days) 3. **Withdraw SOL** - Click "Withdraw" to move SOL to your wallet once deactivation is complete **Important:** This action is irreversible. Once initiated, Jito will remove your stake from the stake pool. ### How to Complete Direct Unstaking **Step 1: Access the Interface** 1. Go to [jito.network/staking](https://www.jito.network/staking/) and select "Unstake" tab 2. Connect your wallet and enter amount to unstake 3. Select the delayed unstaking option (shows 0.1% fee and waiting time) **Step 2: Review and Confirm** ![Delayed Unstaking Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-confirm-modal-delayed-flow-unstake-jitosol.png) **Step 3: Wallet Confirmation** ![Delayed Unstaking Wallet Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-wallet-confirm-delayed-unstake-jitosol.png) Review the transaction details and approve in your wallet to initiate the unstaking process. **Step 4: Complete the Process** - **Monitor Progress:** Check the [Manage page](https://www.jito.network/manage/) for your new stake account - **Deactivate:** Click "Deactivate" when ready (can be done immediately) - **Wait:** Your stake will be ready at the next epoch boundary (up to 2 days) - **Withdraw:** Click "Withdraw" once deactivation is complete **Wallet-Specific Guides:** - [Phantom Wallet Guide](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-with-phantom.md) - [Solflare Wallet Guide](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-with-solflare.md) ## Choosing the Right Method ### Use Jupiter Trading When: - You need SOL immediately - You want to convert to other tokens (USDC, mSOL, etc.) - You prefer simple, one-step transactions - The amount is moderate (fee difference isn't significant) ### Use Direct Unstaking When: - You're unstaking very large amounts (>100 SOL) - You can wait up to 2 days for completion - You want to minimize fees (0.1% vs potentially higher slippage) - You prefer interacting directly with the protocol ## Troubleshooting **Instant unstake transaction failing?** - Increase your slippage setting - Increase priority fees or tip amount **Direct unstaking seems complex?** - Use our wallet-specific guides for step-by-step instructions - Most users find Jupiter conversion much simpler ## Summary Most users should use Instake Unstaking for instant, convenient conversion with competitive rates. Direct unstaking is primarily useful for very large amounts or when you specifically need to minimize fees and can wait several days. --- # Unstaking with Phantom > Step-by-step guide for delayed unstaking using Phantom wallet This guide covers **delayed unstaking** using Phantom wallet. For most users, we recommend [instant trading via Jupiter](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md#option-1-instant-trading-recommended) instead. **Time Required:** Setup (5 minutes) + waiting period (up to 2 days) **Fee:** 0.1% unstaking fee ## Step 1: Connect Your Phantom Wallet 1. Go to [jito.network/staking](https://www.jito.network/staking/) ![Jito Header Before Connecting](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-header-with-connect-button-before-connecting.png) 2. Click **"Connect Wallet"** in the top right corner ![Choose Wallet Options](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-choose-wallet-options.png) 3. Select **"Phantom"** from the wallet options ![Phantom Connection Prompt](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-connect-wallet.png) 4. Click **"Connect"** to authorize the connection ![Connected Wallet Address](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-wallet-address-button.png) 5. Verify your wallet address appears in the top right corner ## Step 2: Choose Delayed Unstaking Option 1. Select the **"Unstake"** tab 2. Enter JitoSOL amount to unstake 3. Choose **"Delayed in X days"** (shows 0.1% fee) 4. Click **"Unstake SOL"** ![Delayed Unstaking Process](https://www.jito.network/omnidocs/jitosol/images/stake-page-unstake-section-delayed-unstake-flow.png) ![Delayed Unstaking Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-confirm-modal-delayed-flow-unstake-jitosol.png) ## Step 3: Access SOL in Your Phantom Wallet After initiating unstaking, your stake account will appear in Phantom. Navigate to your SOL holdings: ![Phantom Home Screen Options](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-option-step-1.png) Click on **Solana (SOL)** to access the detailed view. ![Phantom SOL Detail Page](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-detail-page-step-2.png) ## Step 4: View Your Stakes In the SOL detail page, you'll see your stake accounts: ![Phantom Your Stakes View](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-your-stakes-step-3.png) ![Phantom Stakes with Active](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-your-stakes-with-active-step-3a.png) **Stake Status:** - **Active**: Earning rewards, needs deactivation - **Activating**: Becoming active - **Deactivating**: Cooling down, will become inactive at next epoch - **Inactive**: Ready to withdraw ## Step 5: Deactivate Active Stakes For any stakes showing as **"Active"**, you need to deactivate them: ![Phantom Deactivate Process](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-active-unstake-deactivate-step-4a.png) 1. Select the active stake account 2. Click **"Unstake"** to begin deactivation 3. Confirm the transaction ![Phantom Deactivated Confirmation](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-active-unstaked-deactivated-confirmed-step-5a.png) **Note:** Deactivate each active stake account individually. ## Step 6: Wait for Epoch Completion **Waiting Period:** Up to 2 days (1 Solana epoch) The stake needs to cool down due to Solana's protocol requirements. This applies to all unstaking methods, not just JitoSOL. You can check the status in Phantom. Once it shows **"Inactive"**, it's ready to withdraw. ## Step 7: Withdraw Your SOL Once your stakes show as **"Inactive"**: 1. Select the inactive stake account 2. Click **"Withdraw Stake"** 3. Confirm the withdrawal transaction ![Phantom Withdraw Stake](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-withdraw-stake-step-4.png) ![Phantom Withdraw Confirmed](https://www.jito.network/omnidocs/jitosol/images/phantom-unstake-sol-withdraw-confirmed-step-5.png) SOL will then be available as regular SOL in your wallet. ## Key Points - **Multiple Accounts**: You may have multiple stake accounts to process individually - **Timing**: Up to 2-day wait is a Solana protocol requirement - **Process**: Irreversible once initiated - **Fees**: 0.1% unstaking fee applies ## Need Instant Access? If you can't wait up to 2 days, consider [instant trading via Jupiter](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md#option-1-instant-trading-recommended) instead: - Immediate settlement - Single transaction - Convert to any token, not just SOL ## Troubleshooting **Don't see your stake accounts?** - Ensure you've initiated unstaking from the Jito website first - Check that your Phantom wallet is properly connected - Refresh your wallet or reconnect if needed **Stakes still showing as Active?** - You must manually deactivate each Active stake account - This step cannot be skipped. It's required by Solana's protocol **Need help?** - Review [unstaking overview](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md) --- # Unstaking with Solflare > Step-by-step guide for delayed unstaking using Solflare wallet This guide covers **delayed unstaking** using Solflare wallet. For most users, we recommend [instant trading via Jupiter](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md#option-1-instant-trading-recommended) instead. **Time Required:** Setup (5-10 minutes) + waiting period (up to 2 days) **Fee:** 0.1% unstaking fee ## Step 1: Connect Solflare Wallet 1. Go to [jito.network/staking](https://www.jito.network/staking/) ![Jito Header Before Connecting](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-header-with-connect-button-before-connecting.png) 2. Click **"Connect Wallet"** in the top right corner ![Choose Wallet Options](https://www.jito.network/omnidocs/jitosol/images/wallet-unstake-sol-choose-wallet-options.png) 3. Select **"Solflare"** from the wallet options ![Solflare Connection Method](https://www.jito.network/omnidocs/jitosol/images/solflare-unstake-sol-wallet-address-button.png) 4. Select to connect ![Solflare Authorization](https://www.jito.network/omnidocs/jitosol/images/solflare-connect-wallet-screen.png) 5. Click **"Connect"** to authorize the connection (you may choose "Trust this app" to prevent future prompts) ![Connected Wallet Address](https://www.jito.network/omnidocs/jitosol/images/solflare-unstake-sol-wallet-address-button.png) 6. Verify your wallet address appears in the top right corner ## Step 2: Initiate Delayed Unstaking 1. Select the **"Unstake"** tab 2. Enter JitoSOL amount to unstake 3. Choose **"Delayed in X days"** (shows 0.1% fee) 4. Click **"Unstake SOL"** ![Delayed Unstaking Process](https://www.jito.network/omnidocs/jitosol/images/stake-page-unstake-section-delayed-unstake-flow.png) ![Delayed Unstaking Confirmation](https://www.jito.network/omnidocs/jitosol/images/stake-page-confirm-modal-delayed-flow-unstake-jitosol.png) ## Step 3: Access Staking in Solflare Click the **"Staking"** tab in the bottom navigation of your Solflare wallet to access your stake accounts. ![Solflare Staking Options Overview](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-staking-options-step-1.png) ## Step 4: View Your Stake Accounts Check your stake accounts and their status: ![Solflare Full Stakes List](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-staking-options-step-1-full-list.png) **Stake Status:** - **Active**: Earning rewards, needs unstaking - **Unstaked**: Ready to withdraw - Various validators with different APY rates ## Step 5: Unstake Active Stakes For stakes showing as **"Active"**: ![Solflare Active Stake Details](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-unstake-active-sol-step-2.png) 1. Click on the active stake account to see validator details and APY ![Solflare Unstake Review](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-unstake-active-sol-review-step-3.png) 2. Review the unstaking details. Then click the **"Unstake"** button to initiate 3. Click the yellow **"Review"** button ![Solflare Unstake Confirmation](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-unstake-active-sol-confirm-step-4.png) 4. Confirm the unstaking transaction by clicking **"Confirm"** ![Solflare Now Unstaking Status](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-active-sol-now-unstaking-step-4.png) After confirmation, your stake will show as **"Unstaking"** with a countdown timer. **Note:** Unstake each active stake account individually. ## Step 6: Wait for Epoch Completion **Waiting Period:** Up to 2 days (1 Solana epoch) Stakes need to cool down due to Solana protocol requirements. Check status in Solflare. Once showing **"Unstaked"**, they're ready to withdraw. ## Step 7: Withdraw Your SOL Once your stakes show as **"Unstaked"**: ![Solflare Unstaked SOL Ready](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-inactive-sol-step-1a.png) Your stake will show as **"Unstaked"** when available for withdrawal. ![Solflare Withdraw Interface](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-inactive-sol-withdraw-step-2a.png) 1. Click **"Withdraw"** to start the withdrawal process 2. Review the withdrawal details (token amount, destination, network fees) ![Solflare Withdraw Confirmation](https://www.jito.network/omnidocs/jitosol/images/solfare-unstake-sol-inactive-sol-withdraw-confirm-step-3a.png) 3. Click **"Confirm"** to complete the process Your SOL will now be available as regular SOL in your wallet for immediate use. ## Key Points - **Multiple Accounts**: You may have multiple stake accounts to process individually - **Timing**: Up to 2-day wait is a Solana protocol requirement - **Process**: Irreversible once initiated - **Fees**: 0.1% unstaking fee applies - **Timer Display**: Solflare shows countdown timer for unstaking progress ## Need Instant Access? Consider [instant trading via Jupiter](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md#option-1-instant-trading-recommended): - Immediate settlement - Single transaction - Convert to any token ## Troubleshooting **Don't see stake accounts?** - Ensure you initiated unstaking from Jito website first - Click "Staking" tab in bottom navigation - Refresh wallet if needed **Stakes still Active?** - Manually unstake each Active stake account **Can't find Staking section?** - Look for "Staking" tab in bottom navigation bar - Should be visible alongside "Tokens", "Stocks", "Earn", and "Collect" **Need help?** - Review [unstaking overview](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md) --- # Using JitoSOL Overview > JitoSOL integrates with 20+ leading Solana DeFi protocols for enhanced yield opportunities JitoSOL has extensive integrations across the Solana DeFi ecosystem, with over 40% of JitoSOL supply actively used as collateral and liquidity provision. JitoSOL has 16M SOL TVL and 180,000 holders as of July 2025. ### **Lending & Borrowing Protocols:** [marginfi](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/mrgnfi.md) - Leading lending protocol [Drift](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/drift.md) - Cross-margined perpetuals and spot trading [Save](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/save.md) - Decentralized lending protocol ### **Liquidity Provision & DEXs:** [Raydium](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/raydium.md) - Solana's largest DEX and go-to for new token launches [Orca](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/orca.md) - Leading DEX with concentrated liquidity and excellent UX [Meteora](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/meteora.md) - Dynamic liquidity market maker (DLMM) with innovative features [Kamino Finance](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/kamino.md) - Automated vault management and lending protocol ### **Getting Started:** 1. **For Beginners**: Start with [Kamino](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/kamino.md) vaults for automated yield farming 2. **For Active Traders**: Try [marginfi](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/mrgnfi.md) for lending/borrowing or [Drift](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/drift.md) for trading 3. **For Liquidity Providers**: Use [Raydium](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/raydium.md) for new opportunities or [Orca](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/orca.md) for stable pairs 4. **For Automated LP**: Let [Kamino](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/kamino.md) manage concentrated liquidity positions automatically ### **Risk Considerations:** All DeFi protocols carry smart contract risks. JitoSOL itself is built on the audited Solana Labs Stake Pool program with 9+ security audits. Each integration has its own risk profile - always DYOR before depositing funds. ### **New Integrations:** Jito actively works with leading Solana protocols to expand JitoSOL utility. Recent growth includes expanded lending options and automated vault strategies. --- # Kamino Finance > Automated liquidity vaults with $1.6B+ TVL for optimized JitoSOL yields Kamino Finance is Solana's leading automated vault protocol with over $2.4 billion TVL. Kamino creates actively managed liquidity strategies that optimize yield farming across concentrated liquidity AMMs like Orca, Meteora, and Raydium. ## JitoSOL Integration Kamino offers multiple vault strategies featuring JitoSOL, with the **JitoSOL-SOL vault** being the largest liquidity vault on the platform. ![kamino 1](https://www.jito.network/omnidocs/jitosol/images/kamino_1.png) ### **Key Advantages** **Automated Management**: Kamino removes the complexity of maintaining concentrated liquidity positions by: - Automatically rebalancing positions based on market conditions - Compounding rewards continuously - Optimizing fee collection ranges **Enhanced Yields**: Vault strategies earn from multiple sources: - Base JitoSOL staking + MEV rewards (~7.5%) - Trading fees from liquidity provision - Additional protocol incentives when available - Automated compounding for maximum efficiency ## Major Vault Strategies ### **JitoSOL-SOL Vault (Recommended)** - **TVL**: Largest vault on Kamino - **Platform**: Primarily Raydium with Orca integration - **Risk**: Low (both assets are SOL-based) - **Yield**: Staking rewards + trading fees + incentives ![kamino 2](https://www.jito.network/omnidocs/jitosol/images/kamino_2.webp) **Benefits**: - No impermanent loss risk (assets are price-correlated) - Earn full staking rewards on both sides - Additional trading fees from JitoSOL-SOL swaps - Automated position management ## Getting Started 1. **Visit Kamino**: 2. **Connect Wallet**: Link your Solana wallet containing JitoSOL 3. **Choose Vault**: Select JitoSOL-SOL for lowest risk or mSOL-JitoSOL for diversification 4. **Deposit**: Add your JitoSOL (and SOL if needed for balanced deposits) 5. **Earn**: Automated yield optimization begins immediately ### **Performance & Fees** **Fee Structure**: - **Management Fee**: Typically 2-5% of yield (varies by vault) - **Performance Fee**: Percentage of profits generated - **Withdrawal Fee**: Usually minimal or none **Historical Performance**: While displayed APY may appear lower (1-5%), this excludes the underlying staking rewards from JitoSOL and mSOL. **Combined yields are higher** when including: - Base staking rewards - MEV rewards - Trading fees (0.5-2% depending on volume) - Additional incentives when available ## Resources - **Platform**: - **Documentation**: **Important**: Always understand the specific strategy and risks before depositing. Start with smaller amounts to familiarize yourself with the platform's mechanics. --- # Raydium > Hybrid DEX with concentrated liquidity and solid platform for new token launches Raydium is a leading Solana DEX with over $2.3B+ TVL that combines automated market making with central limit order books. ## JitoSOL Integration **Primary Pool**: JitoSOL-SOL concentrated liquidity - Earn trading fees + staking rewards - Lower slippage than traditional AMMs - Efficient for stable pairs like JitoSOL-SOL ![Raydium](https://www.jito.network/omnidocs/jitosol/images/Raydium.png) ## Getting Started 1. Visit 2. Search for JitoSOL-SOL pair 3. Set price range and deposit liquidity 4. Earn trading fees + JitoSOL staking yield ## Key Features **Concentrated Liquidity**: Focus capital in specific price ranges for higher efficiency **Permissionless Farms**: Anyone can create liquidity pools and bootstrap tokens **Hybrid Model**: Combines AMM with order book liquidity from OpenBook ## Kamino Alternative For automated management, Kamino offers Raydium vaults: - **JitoSOL-SOL Vault**: $34M+ TVL with automated optimization - Professional rebalancing and fee compounding ## Resources - **Platform**: - **CLMM Guide**: --- # Orca > Solana's leading DEX with concentrated liquidity and JitoSOL pools Orca is one of Solana's largest DEXes with over $40M+ in LP fees generated. The platform offers multiple JitoSOL liquidity pools through their concentrated liquidity system. ## JitoSOL Pools View all available JitoSOL pools at **Popular Pairs** - **JitoSOL-SOL**: Stable pair with minimal impermanent loss - **JitoSOL-mSOL**: LST-to-LST with dual staking rewards - **JitoSOL-USDC**: Earn fees on JitoSOL trading activity ## Getting Started 1. Visit 2. Connect your Solana wallet 3. Select from available JitoSOL pairs 4. Set price range (use "Passive" option for beginners) 5. Deposit liquidity and start earning fees ![Orca 1](https://www.jito.network/omnidocs/jitosol/images/Orca_1.webp) ## Pools **Concentrated Liquidity**: Focus your capital in specific price ranges for higher efficiency **Price Range Options**: - **Passive**: Wide range, lower maintenance - **Stable**: Tight range for correlated assets - **Custom**: Set your own parameters ![Orca 2](https://www.jito.network/omnidocs/jitosol/images/Orca_2.png) ## Yield Sources - **JitoSOL Staking Rewards**: Continue earning staking rewards and MEV rewards - **Trading Fees**: Earn from swaps in your price range - **Potential Incentives**: Additional rewards during campaigns ## Kamino Integration For automated management, consider [Kamino's](https://www.jito.network/docs/jitosol/get-started/using-jitosol-flow/kamino.md) Orca-based vaults that handle: - Automatic rebalancing - Fee compounding - Range optimization ## Resources - **Platform**: - **Documentation**: - **JitoSOL Pools**: **Risk Note**: Providing liquidity involves impermanent loss risk. --- # Meteora > Dynamic liquidity market maker with JitoSOL-SOL pools Meteora offers Dynamic Liquidity Market Maker (DLMM) pools that arrange liquidity into distinct price bins, providing concentrated liquidity with automated optimization. ## JitoSOL-SOL Pool Meteora's **JitoSOL-SOL stable dynamic pool**: - Earns trading fees and lending fees - Automatically rebalances between AMM and lending based on demand - Designed for stablecoin and correlated asset pairs ![Meteora](https://www.jito.network/omnidocs/jitosol/images/Meteora.png) ## How DLMM Works **Price Bins**: Liquidity is organized into discrete price ranges - Each bin has specific price and liquidity amounts - Eliminates slippage within individual bins - Hybrid between order book and AMM **Dynamic Strategies**: - **Spot**: Uniform distribution across price ranges - **Curve**: Concentrated around current price (low volatility) - **Bid-Ask**: Inverse curve for high volatility assets ## Getting Started 1. Visit 2. Connect your Solana wallet 3. Choose distribution strategy 4. Add JitoSOL and SOL to the pool 5. Collect trading fees + staking rewards ## Yield Sources - **Trading Fees**: From JitoSOL-SOL swaps - **Lending Fees**: When pool assets are lent out - **Staking Rewards**: Continue earning on JitoSOL position - **Dynamic Rebalancing**: Optimized fee collection ## Resources - **Pool**: - **Documentation**: **Best For**: Users wanting automated liquidity management with minimal impermanent loss on correlated assets. --- # marginfi > Leading Solana lending protocol with $400M+ TVL and JitoSOL integration marginfi is one of Solana's largest lending protocols with over $400 million in deposits. The platform offers lending, borrowing, and leveraged staking strategies using JitoSOL as collateral. ## JitoSOL Integration marginfi supports JitoSOL with competitive loan-to-value ratios and yield opportunities. ## Core Strategies **Basic Lending** 1. Deposit JitoSOL to earn interest + points 2. Maintain liquidity while earning staking rewards 3. Borrow assets against JitoSOL collateral (up to 77% LTV) **Leveraged Staking (Advanced)** The Loop Strategy: 1. Deposit JitoSOL as collateral 2. Borrow SOL against JitoSOL value 3. Convert borrowed SOL to more JitoSOL 4. Repeat process to amplify exposure **Example**: - Start with 100 JitoSOL - Borrow 70 SOL (70% LTV) - Convert to ~57 more JitoSOL - Total position: ~157 JitoSOL - **Amplified yield**: Earn on 157 JitoSOL instead of 100 - **Cost**: SOL borrowing rate (~7.7%) ## Getting Started 1. Visit 2. Connect your Solana wallet 3. Deposit JitoSOL to start earning 4. Monitor position health (keep above 25% to avoid liquidation) 5. Optimize strategy based on borrowing costs vs. staking yields **Safety Tips** - Start small with test amounts - Monitor rates - SOL borrow rates change based on utilization - Maintain health ratio well above liquidation threshold - Be aware during high volatility periods ## Resources - **Platform**: - **Documentation**: **Risk Warning**: Leveraged strategies can result in liquidation and loss of funds. Interest rates fluctuate based on market conditions. --- # Save (Solend) > Decentralized lending protocol with JitoSOL support (Formerly Solend) JitoSOL is included in UXD's Solend pool. Users can deposit JitoSOL to earn interest, borrow assets against its value, or perform leveraged [staking](https://blog.texture.finance/leveraged_staking_oct22/). **Important**: This is a permissionless pool and not insured by Solend. It has a higher level of risk. Please understand the [risks of permissionless pools](https://docs.solend.fi/permissionless-pools/risks) before using them. ![Solend](https://www.jito.network/omnidocs/jitosol/images/Solend.png) --- # Drift > Open-source decentralized exchange for transparent, non-custodial trading Drift Protocol is an open-source decentralized exchange built on Solana, offering transparent and non-custodial trading with support for JitoSOL as collateral. ## JitoSOL Integration **Collateral Support**: Use JitoSOL for: - Perpetual futures trading - Cross-margin positions - Earning yield while trading **Benefits**: - Continue earning staking + MEV rewards - Use as collateral for leveraged positions - Maintain liquidity for trading opportunities ## Key Features **Cross-Margin Trading**: Single collateral pool supports multiple positions **Transparent Operations**: Fully open-source and verifiable **Non-Custodial**: Maintain control of your JitoSOL ## Getting Started 1. Visit 2. Connect your Solana wallet 3. Deposit JitoSOL as collateral to your account 4. Use for perpetuals or spot trading ## Resources - **Platform**: - **Documentation**: **Best For**: Traders who value transparency and open-source protocols while earning on JitoSOL collateral. --- # Viewing JitoSOL Rewards > Learn how to track your staking and MEV rewards over time. JitoSOL automatically earns both staking rewards and MEV rewards. The rewards interface provides tracking tools to help you monitor your earnings. **Important:** All reward values are approximate and for informational purposes only. ## How to Access Your Rewards 1. Go to [jito.network/staking/?mode=rewards_view](https://www.jito.network/staking/?mode=rewards_view) 2. Connect your wallet ## Key Metrics **Balance Tracking** - JitoSOL balance with historical chart - USD value of your position - Balance growth over time **Reward Metrics** - All time estimated total rewards - Year-to-date reward earnings - Year-to-date estimated MEV rewards ## Export Data Download CSV files for record keeping: - All time complete history - Previous year data - Current year YTD data **Note:** Does not track JitoSOL used in DeFi protocols. ## How Rewards Work **Automatic Compounding** - JitoSOL value increases automatically as rewards are earned - No manual claiming required - Includes both Solana staking rewards (\~5-7% APY) and MEV rewards (\~1-2% APY) ## Troubleshooting ### Important Limitations - **Approximate Values:** All calculations are estimates for informational purposes - **DeFi Exclusions:** Does not track JitoSOL used in lending, LPs, or other DeFi protocols - **Network Variations:** Actual rewards fluctuate based on network conditions ## Common Questions **"I don't see any reward data"** - Ensure your wallet is connected and shows the correct address - You need to hold JitoSOL for at least one epoch to see rewards - Try refreshing the page or reconnecting your wallet **"My rewards seem lower than expected"** - Check that you're viewing the right time period using the filters - MEV rewards flunctuate significantly over time - JitoSOL used in DeFi protocols won't be tracked here **"Can I export my data for taxes?"** - Yes, use the export dropdown to download CSV files - Choose "All Time" for complete history or specific years - Remember these are approximate values for informational purposes ## Additional Resources - **Manage Stakes:** [jito.network/manage](https://www.jito.network/manage/) to convert stake accounts - **Transaction History:** [jito.network/history](https://www.jito.network/history/) for complete history - **FAQ:** [FAQ section](https://www.jito.network/docs/jitosol/faqs/general-faqs.md) for common issues --- # DeFi Page Guide > Educational guide to understanding the Jito DeFi page interface. ## Understanding the DeFi Page The [jito.network/defi](https://www.jito.network/defi/) page displays third-party DeFi protocols where JitoSOL is supported. **Important Disclaimers:** * All DeFi activities involve significant risks including potential total loss of funds * This information is educational only and not financial advice * Jito does not endorse, recommend, or guarantee any third-party protocols * Always do your own research before using any DeFi protocol * Past performance does not indicate future results ### What You'll Find **Various Strategies** across major DeFi categories - from simple lending to complex yield farming setups. **Quick Filters:** * **Strategy type** - Lending, Liquidity Pools, Looping, Restaking * **Protocol** - Filter by specific platforms (Kamino, Drift, etc.) * **JTO Boost** - Strategies with additional JTO token rewards **Live Data:** Each protocol shows real TVL, so you can see which strategies have the most activity. The green "JTO Boost" badges highlight where you can earn extra JTO tokens on top of base rewards. ## Strategy Breakdown ### Borrow/Lend (Simple Start) **The concept:** Lend your JitoSOL to earn interest, or use it as collateral to borrow other tokens. **Popular on:** Drift, Solend, MarginFi - protocols with $10M+ TVL typically offer more stable rates. **Watch out for:** Liquidation if you're borrowing. Interest rates can spike during market stress. ### Liquidity Pools (Trading Fees) **The concept:** Pair JitoSOL with another token (like SOL or JTO) so traders can swap between them. You earn a cut of trading fees. **Biggest pools:** JitoSOL/SOL pairs dominate with $35M+ TVL. JitoSOL/JTO and other pairs are also active. **The catch:** "Impermanent loss" - if one token outperforms the other significantly, you might end up with less value than just holding. ### Looping (Advanced) **The concept:** Automatically borrow against your JitoSOL to buy more JitoSOL, amplifying both gains and losses. **Risk level:** High. Market drops get magnified, potentially triggering liquidations. ### Restaking (Cutting Edge) **The concept:** Your JitoSOL secures additional networks beyond Solana, earning extra rewards. **Current leader:** Jito's own restaking with $200M+ TVL. Still relatively new with additional technical risks. ## The Reality Check **⚠️ DeFi can be unforgiving.** Even "safe" protocols have seen major losses from hacks, governance attacks, and market crashes. **Common ways things go wrong:** * **Smart contracts get exploited** - bugs in code can drain funds instantly * **Liquidations during volatility** - your collateral gets sold when markets move fast * **Governance attacks** - protocol changes that hurt users * **Bridge hacks** - cross-chain transfers are particularly vulnerable **The TVL game:** High TVL doesn't mean safe - some of the biggest protocols have had the largest exploits. But extremely low TVL often signals untested code. **Important:** This page shows third-party protocols. Jito doesn't control them, audit them, or guarantee anything about them. Each has its own risks, terms, and team. ## Before You Dive In **Do your homework:** * Read the protocol's docs (not just the marketing page) * Check recent audit reports - look for "High" or "Critical" findings * Browse their Discord/Twitter for recent drama or issues * Use [DeFiLlama](https://defillama.com) to track TVL trends and yields **Start small:** Even experienced DeFi users lose money regularly. Treat your first positions as education. **This guide is educational only.** Not financial advice. The protocols shown are third-party services with their own risks. --- # (Re)staking Overview > Understanding Jito (Re)staking, vaults, NCNs, and node operators ## What is Jito (Re)staking? Jito (Re)staking is liquid staking infrastructure on Solana. It allows external networks to build staking protocol on Solana and enables users to (re)stake JitoSOL and other SPL tokens across these networks, simultaneously. (Re)staked assets provide economic security to these networks and earn rewards, creating opportunities for additional yield beyond traditional staking. ## Terminology - **Delegation**: The act of assigning staked assets to specific operators within the network. - **Epoch**: A fixed period in the blockchain during which staking rewards are calculated and distributed. - **Multi-Asset Staking**: The ability to stake various types of SPL tokens, not limited to native blockchain tokens. - **Liquid Staking**: A form of staking that provides liquidity to Solana stakers. - **Node Consensus Network (NCN)**: A set of node operators running software for the same network, working together to achieve consensus and provide services. - **Node Operator (or Operator)**: A specialized party who runs core functionalities for NCNs, such as performing specific offchain computations and participating in consensus - **(Re)staking**: The process of staking already-staked assets, such as liquid staking tokens. E.g. Whereas users can “stake” SOL to NCNs, users can “(re)stake” JitoSOL to NCNs. - **Staking**: The process of collateraliziung assets to support network operations and earn rewards. - **Slashing**: A penalty mechanism where a portion of staked assets and/or expected rewards are forfeited if an operator misbehaves or fails to meet performance requirements. - **SPL Token**: Solana Program Library Token, a standard for creating and managing tokens on the Solana blockchain. - **Vault**: A smart contract that securely holds staked assets and delegates them to operators. - **Vault Receipt Token (VRT)**: A tokenized representation of staked assets inside a vault, allowing for liquidity and composability. ## Key Concepts ### Vaults **What are Vaults?** Vaults serve as deposit pools that hold SPL tokens (e.g. JitoSOL) and issue vault receipt tokens (VRTs) representing those positions. Users retain ownership of their stake via liquid VRTs, enabling utility and composability in Solana's DeFi ecosystem. VRTs are burned when users withdraw their assets from the vault. Vaults opt into supporting specific NCNs and delegate stake to approved operators. Each vault defines key parameters, including how much stake is allocated to each node operator and fees. ### NCNs (Node Consensus Networks) **What are NCNs?** NCNs are a set of node operators and onchain programs that reach consensus on offchain workloads and enforce onchain state transitions. In most cases, NCNs will include their own custom onchain programs to handle proof submissions, verify work, and distribute rewards. Consensus can take place onchain or offchain. For example, oracle networks, DePINs, bridges, DeFi apps, or entire blockchains can deploy an NCN to achieve consensus on an arbitrary result and finalize and distribute rewards, payments, and penalties. NCNs build custom staking mechanisms and use (re)staked assets for economic security, ensuring node operators have an economic commitment to follow protocol and maintain operation. **How NCNs Work:** - NCNs define an offchain protocol, and node operators opt in to service these operations. - (Re)staked assets are delegated to node operators to provide economic security to underlying network operations. - Each NCN has specific penalties or slashing conditions for node operators. - NCNs pay rewards to (re)stakers and node operators for participating in the network and following protocol according to established standards. ### Node Operators Node operators are infrastructure providers that run the offchain protocol for NCNs and are delegated stake. They opt in to serve specific NCNs and receive stake from approved vaults. Operators have no direct control of the stake, and they are usually rewarded in proportion to the stake they have. Operators can serve multiple NCNs simultaneously, enabling efficient resource usage and shared security. **Node Operator Selection:** - Through (re)staking, node operators can choose to support multiple networks and accept stake from multiple vaults. - Performance and reliability are key criteria for selection. - Operators must maintain good behavior to avoid penalties and/or slashing. ## JitoSOL supported NCNs Currently you can (re)stake JitoSOL to: - **TipRouter** - Jito's REV distribution protocol - **Switchboard** - a decentralized oracle network - **Note:** Visit the [Jito (Re)staking website](https://www.jito.network/restaking/) to view other supported assets and NCNs. Additional assets and NCNs will be supported as the protocol expands. ## Using the (Re)staking Interface ### Accessing (Re)staking 1. Navigate to [jito.network/restaking/](https://www.jito.network/restaking/) 2. Connect your Solana wallet (Phantom, Solflare, etc.) 3. Review available vaults and their strategies ![(Re)staking Home Page - Vaults View](https://www.jito.network/omnidocs/jitosol/images/restaking-home-vaults-view.png) ### Deposit Process Overview **Two Approaches:** The (re)staking interface provides a toggle to choose your deposit method: ![(Re)staking Home Page - Assets View](https://www.jito.network/omnidocs/jitosol/images/restaking-home-assets-view.png) - **Select Asset First (Tokens):** Choose your token, then select a compatible vault - **Select Vault First (Vaults):** Choose a vault, then deposit compatible assets **Steps for Depositing:** 1. **Choose where to stake** - Select your preferred approach via the toggle 2. **Select asset/vault** - Pick your token and compatible vault 3. **Enter deposit amount** - Specify how much to deposit 4. **Review and confirm** - Verify details and execute transaction **What Happens After Deposit:** - Your assets are stored securely in the vault smart contract - You receive VRT tokens representing your proportional share - VRT tokens are required for managing your position and withdrawals ### Understanding Risks **Vault-Specific Risks:** - Strategy execution risk based on vault design - Liquidity and exit risks during high demand periods if using secondary markets for selling - Slashing due to operator misbehavior - Custom vault programs - Vault fees can be updated by admins **NCN-Related Risks:** - Network adoption and usage may affect rewards - Technical implementation risks from new NCNs - NCNs may cease operations **Operator Risks:** - Performance and reliability of infrastructure providers - Potential fee changes or policy updates **Slashing Risk:** - Your vault assets may be slashed if operators delegated to misbehave or fail to follow NCN rules - This security feature helps ensure the network remains secure - The slashing feature may or may not be turned on. Check before you deposit if you are concerned. ## Rewards and Economics ### How You Earn Rewards Rewards are generated through a combination of: - **Base staking yields** from the underlying staked assets (if they are staked assets) - **Additional rewards from NCNs** for providing economic security - Exact reward structure varies by vault strategy and supported NCNs ### Fee Structure **(Re)staking Program Fees:** - **4% fee on rewards** to fund protocol development - **0.1% (10 bps) withdrawal fee** for exiting positions **Vault-Specific Fees:** - Each vault has different deposit, withdrawal, and reward fee structures - Always check the specific fee structure before depositing - Fees vary based on vault strategy and complexity **Node Operator Fees** - Each node operator can enforce a fee for their services. ### Withdrawal Process **Standard Withdrawal (Most Common):** 1. **Initiate withdrawal** - Select amount and start the process 2. **Two-epoch cooldown period** - Wait approximately 4-5 days 3. **Complete withdrawal** - Claim your assets after cooldown **Why the Waiting Period:** - The protocol requires a two-epoch cooldown for security - This helps maintain system stability and protects all deposited assets - Your funds remain locked during this period ## Security and Audits **Audit History:** Jito (Re)staking has been audited by multiple security firms: - **Ottersec** - Comprehensive (re)staking audit - **Offside Labs** - (Re)staking vault audit - **Certora** - Additional security review **Security Features:** - Two-epoch cooldown period for withdrawals - Multi-signature controls for critical functions - Regular monitoring and security updates ## Getting Started ### Prerequisites - Solana wallet (Phantom, Solflare, etc.) - Supported assets (SOL, JitoSOL, mSOL, bSOL) - Small amount of SOL for transaction fees - Understanding of (re)staking risks and **two-epoch withdrawal cooldown** ### Useful Resources - [(Re)staking Dashboard](https://www.jito.network/restaking/dashboard/) - Monitor your positions - [Vault Explorer](https://www.jito.network/restaking/vaults/) - Browse available vaults - [NCN Directory](https://www.jito.network/restaking/ncns/) - View supported networks - [Node Operator List](https://www.jito.network/restaking/node-operators/) - See infrastructure providers This overview provides the foundation for understanding Jito (Re)staking. For specific instructions on using the interface, see the individual user guides for depositing and withdrawing. --- # Restaking Deposit Guide > Step-by-step guide for depositing assets into restaking vaults ## Before You Start **Prerequisites:** - Solana wallet connected (Phantom, Solflare, etc.) - Sufficient assets for deposit (e.g. SOL or JitoSOL) - Small amount of SOL for transaction fees - Understanding of restaking risks and two-epoch withdrawal cooldown **Important Reminders:** - The (re)staking protocol charges a 4% fee on rewards and 0.1% (10 bps) withdrawal fee - Individual vaults may have additional deposit, withdrawal, and reward fees - Operators may also apply fees for their services. - Program fee of 0.10% also applies on withdrawals (as shown in interface) - Start with small amounts to learn the interface and mechanics - Always check vault-specific fee structures before depositing ## Step 1: Access the Restaking Interface 1. Navigate to [jito.network/restaking/](https://www.jito.network/restaking/) 2. Click "Connect Wallet" in the top right 3. Select your wallet type and approve connection 4. Ensure you're on the correct network (Solana mainnet) ## Step 2: Choose Your Approach The (re)staking interface provides a convenient toggle to switch between two deposit approaches: ![Restaking Deposit - Asset Selection](https://www.jito.network/omnidocs/jitosol/images/restaking-start-restaking-asset-view.png) **Path 1: Select Asset First (Tokens Tab)** - Choose your token (SOL, JitoSOL, etc.) from your wallet - Browse vaults that support your selected asset - Compare strategies and expected returns ![(Re)staking Deposit - Vault Selection](https://www.jito.network/omnidocs/jitosol/images/restaking-start-restaking-vault-view.png) **Path 2: Select Vault First (Vaults Tab)** - Browse all available vaults and their strategies - Choose based on NCNs, operators, and risk profile - Deposit any supported asset into the selected vault **Vault Selection Criteria:** - **Strategy Type:** Single vs multi-asset support - **Risk Level:** Conservative (established) vs aggressive (newer NCNs) - **Supported Assets:** Ensure your tokens are compatible - **Fee Structure:** Compare deposit, withdrawal, and reward fees - **Performance:** Review current and historical returns **Key Vault Information:** - Current reward sources (base staking + NCN rewards) - Vault capacity and current utilization levels - Underlying NCNs (oracles, bridges, L2s) and their operators - Security audit status and vault age/maturity ## Step 3: Choose Your Vault **For Beginners:** - Look for established vaults with proven track records - Choose single-asset vaults to start (simpler mechanics) - Prefer vaults with longer operational history - Avoid experimental strategies or newly launched NCNs **Vault Details Page:** - Click on a vault to see detailed information - Review strategy explanation and mechanics - Check recent performance and metrics - Read risk disclosures carefully ## Step 4: Enter Deposit Details ![(Re)staking Deposit - Enter Amount](https://www.jito.network/omnidocs/jitosol/images/restaking-start-restaking-start-deposit-screen.png) **Specify Deposit Amount:** - Enter the amount of assets you want to deposit in the input field - The interface shows your current wallet balance for reference - Use the "Max" button to deposit your full balance - Ensure you meet minimum deposit requirements - Keep some SOL for transaction fees **Asset Exchange Information:** - The interface displays exchange rates (e.g., "1 JitoSOL ≈ 0.998 ezSOL") - Shows how much VRT tokens ("To Receive") you'll get for your deposit - VRT amounts represent your proportional share in the vault **Multi-Asset Vault Considerations:** - If the vault supports multiple assets, choose which tokens to deposit - Check the vault's current asset allocation targets - Consider any rebalancing that may be needed ## Step 5: Review and Confirm ![Restaking Deposit - Review and Confirm](https://www.jito.network/omnidocs/jitosol/images/restaking-start-restaking-confirm-deposit-screen.png) **Review Transaction Details:** - Verify your deposit amount and selected asset - Check the vault details including NCNs and Node Operators - Review deposit fee (often 0% as shown) - Confirm VRT tokens you'll receive (e.g., "0.199570065 ezSOL") - Note any applicable fees **Vault Information Display:** - **Node Consensus Networks (NCNs):** Shows which networks your deposit will help secure (e.g., TipRouter) - **Node Operators:** Lists the infrastructure providers (e.g., Helius, Pier Two, Temporal) - **Deposit Fee:** Usually 0% for deposits - **Fee Amount:** Shows exact fee calculation **Execute Deposit Transaction:** - Click "Deposit and Mint VRT" to proceed - Your wallet will prompt for transaction approval - Pay the required transaction fees (in SOL) - Wait for blockchain confirmation (usually 2-20 seconds) ## Step 6: Verify Your Position **Check Your VRT Balance:** - VRT tokens should appear in your wallet automatically - Verify you received the expected VRT amount based on your deposit - Note the VRT token address and amount for future reference - VRT tokens represent your proportional share of the vault **Access Your Dashboard:** ![Restaking Dashboard - My Vaults](https://www.jito.network/omnidocs/jitosol/images/restaking-dashboard-my-vaults-vrts.png) - Navigate to [jito.network/restaking/dashboard/](https://www.jito.network/restaking/dashboard/) - Your dashboard shows all active positions under "My Vaults" - Each row displays: - **Vault Name** (e.g., bzSOL Vault, rstSOL Vault) - **VRT Balance** (your vault receipt tokens) - **Staked Asset Equivalent** (underlying asset amount) - **USD Value** of your position - **Initiate Withdrawal** button for each position **Position Tracking:** - Monitor your underlying asset allocation within each vault - Track position values and equivalent asset amounts - Watch for vault strategy changes or announcements - Use the dashboard to manage multiple vault positions simultaneously ## Understanding Your VRT Tokens **What VRTs Represent:** - Your proportional ownership share of the vault's total assets - Proof of deposit in the restaking protocol - Claim on underlying assets and any accrued rewards - Required for managing your position and future withdrawals **VRT Token Usage:** Your VRT tokens can be: - **Held to maintain** your restaking position and earn rewards - **Used in supported DeFi applications** for additional yield opportunities - **Transferred between wallets** if needed for management - **Burned to withdraw** your original assets (with two-epoch cooldown) **Important VRT Guidelines:** - Store VRT tokens securely in your wallet - Never lose access to your VRT tokens (they're required for withdrawals) - Check compatibility before using VRTs in external DeFi protocols This guide covers the basic deposit process. For withdrawal instructions, see the [Restaking Withdrawal Guide](https://www.jito.network/docs/jitosol/user-guides/restaking/restaking-withdrawal-guide.md). Always do your own research and understand the risks before depositing significant amounts. --- # (Re)staking Withdrawal Guide > Step-by-step guide for withdrawing assets from (re)staking vaults ## Understanding Withdrawals **Standard Withdrawal Process:** The primary method for exiting (re)staking positions follows a three-step process: 1. **Initiate withdrawal** - Choose amount and start cooldown 2. **Two-epoch cooldown period** - Wait approximately 4-5 days 3. **Complete withdrawal** - Claim your assets after cooldown **Why the Waiting Period:** - The protocol requires a two-epoch cooldown for security - This helps maintain system stability and protects all deposited assets - Your funds remain locked during this period and stop earning rewards - Cooldown cannot be cancelled once initiated **Important Considerations:** - Withdrawal incurs both a 0.1% withdrawal fee and 0.1% program fee (0.2% total) - Individual vaults may have additional withdrawal fees - Assets stop earning rewards during the cooldown period - Market conditions may affect the timing of your exit strategy ## Before You Withdraw **Review Your Position:** - Check current vault value and performance - Calculate potential fees and costs - Consider timing and market conditions - Evaluate alternative strategies **Understand Timing:** - Two-epoch cooldown period (approximately 4-5 days) - Plan for asset unavailability during the entire cooldown - Consider current epoch timing when initiating withdrawals - Account for potential network congestion affecting transaction speed ## Step 1: Access Your (Re)staking Position ![(Re)staking Dashboard - My Vaults](https://www.jito.network/omnidocs/jitosol/images/restaking-dashboard-my-vaults-vrts.png) 1. Navigate to [jito.network/restaking/dashboard/](https://www.jito.network/restaking/dashboard/) 2. Connect your wallet if not already connected 3. Locate the vault position you want to exit in the "My Vaults" section 4. Click the **"Initiate Withdrawal"** button next to your chosen position ## Step 2: Initiate Withdrawal ![(Re)staking Withdrawal - Enter Amount](https://www.jito.network/omnidocs/jitosol/images/restaking-initiate-withdrawal-screen.png) **Select Withdrawal Amount:** - Choose between partial or full withdrawal from your position - Enter the VRT token amount you want to redeem (e.g., "bzSOL" tokens) - Use the "Max" button to withdraw your full position - Review the exchange rate shown (e.g., "1 bzSOL ≈ 1.0031 BNSOL") **Review Withdrawal Details:** - **To Receive:** Shows the underlying asset amount you'll get (e.g., "BNSOL") - **Fees:** Displays withdrawal fees - typically "0.10% withdrawal fee & 0.10% program fee" - **Net Amount:** Final amount after fees are deducted **Withdrawal Process:** - **Standard Process:** Normal two-epoch cooldown with standard fees - **Cooldown Period:** Approximately 4-5 days before assets are claimable - **You cannot cancel or modify** the withdrawal once initiated - Click **"Initiate Withdrawal"** to begin the cooldown process and claim your original assets ## Step 3: Choose Withdrawal Method ### Standard Withdrawal Process **Unbonding Period (Two Epochs):** - Assets enter a secure unbonding queue - Cooldown period lasts approximately 4-5 days - Your VRT tokens are locked during this time - Duration is fixed and cannot be shortened **During the Cooldown:** - Your assets stop earning rewards immediately - Withdrawal cannot be cancelled once initiated - You can monitor progress on your dashboard - VRT tokens remain in your wallet but are marked for withdrawal **Completion Process:** - After cooldown completes, claim becomes available - Navigate to "In Withdrawal" section of your dashboard - Execute the final "Complete Withdrawal" transaction - Your original assets are returned to your wallet - VRT tokens are burned in the process ## Step 4: Execute Withdrawal **Review Transaction Details:** - Verify withdrawal amount and method - Check all fees and expected outputs - Confirm asset types you'll receive - Review timing expectations **Approve Transaction:** - Sign the withdrawal initiation transaction in your wallet - Pay the required transaction fees (in SOL) - Wait for blockchain confirmation (usually 30-60 seconds) - Save the transaction signature for your records **Track Progress:** ![(Re)staking Dashboard -- In Withdrawal](https://www.jito.network/omnidocs/jitosol/images/restaking-dashboard-in-progress-withdrawals.png) - Monitor unbonding status on your (re)staking dashboard - Check the **"In Withdrawal"** section for progress updates - Each withdrawal shows: - **Asset type** being withdrawn (e.g., JitoSOL, JTO) - **Withdrawal amount** and source vault - **Status:** "Ready to Withdraw" when cooldown completes - **Withdraw button** to claim when ready - Note the expected completion date (approximately 4-5 days) - Set calendar reminders for when you can complete the withdrawal ## Step 5: Complete Withdrawal ### Completing Your Withdrawal **Monitor the Cooldown:** - Regularly check your dashboard for status updates - Look for notifications when the cooldown period ends - Prepare to execute the final claim transaction - Ensure you have SOL for the completion transaction fees **Claim Your Assets:** ![(Re)staking Complete Withdrawal](https://www.jito.network/omnidocs/jitosol/images/restaking-complete-withdrawal-burn-withdrawal-ticket.png) - Go to the "In Withdrawal" section of your dashboard - Find your withdrawal marked as "Ready to Withdraw" - Click the **"Withdraw"** button next to your completed cooldown - The interface shows: - **Amount available** to withdraw (e.g., "0.00001432 ezSOL") - **Final confirmation:** "In finalizing this withdrawal, X JitoSOL will be transferred to your wallet and the VRTs will be burned" - Click **"Complete Withdrawal"** to finalize - Sign the final claim transaction in your wallet - Pay transaction fees for processing the claim - Verify your original assets appear in your wallet and VRTs are burned **Final Verification:** - Confirm you received the expected amount of assets - Account for any withdrawal fees that were deducted - Check that your VRT tokens were properly burned - Save transaction records for tax and accounting purposes ## Alternative Exit Strategies **VRT Token Trading:** - Sell VRT tokens on secondary markets (if liquidity exists) - Avoids the two-epoch unbonding period for immediate liquidity - May trade at premium or discount to underlying asset value - Check market depth and slippage before trading **Position Management:** - Add more assets to existing positions anytime - Transfer VRT tokens between wallets if needed - Use VRT tokens in compatible DeFi protocols for additional yield This guide covers standard withdrawal processes. Specific vaults may have unique requirements or procedures. Always check vault-specific documentation and current terms before initiating withdrawals. --- # Jito Interceptor Program > Understanding the Interceptor protection system for stake account deposits. ## What is the Jito Interceptor? Interceptor temporarily holds JitoSOL from stake account deposits for 10 hours, then automatically delivers it to you with no fees. **You don't need to do anything.** ### Why Interceptor Exists Interceptor protects against "toxic flow" - when other liquid staking protocols use JitoSOL's liquidity to facilitate their own swaps, draining liquidity that should benefit JitoSOL users. Without Interceptor, competing LSTs can mint JitoSOL and immediately swap it for SOL, siphoning millions from JitoSOL pools. **Key Benefits:** - **Protects JitoSOL liquidity:** Prevents other protocols from draining pools - **Automatic processing:** Your stakes are handled automatically - **Full rewards:** You earn staking and MEV rewards during cooldown - **Better stability:** Helps maintain JitoSOL's peg and liquidity depth ## How It Works ### 10-Hour Cooldown Process **For stake account deposits:** 1. **Immediate conversion:** Your stake account instantly becomes JitoSOL 2. **Secure holding:** JitoSOL held by Interceptor program for 10 hours 3. **Continuous rewards:** You earn full staking and MEV rewards throughout 4. **Automatic delivery:** Jito delivers your JitoSOL with no fees after cooldown ### Automatic Processing **You don't need to do anything!** Jito's system automatically: - Monitors all intercepted deposits - Claims your JitoSOL after 10 hours - Transfers JitoSOL directly to your wallet - Charges no fees for automatic processing ### When You'll See Interceptor **Interceptor applies to:** - Depositing existing SOL stake accounts to JitoSOL **Interceptor does NOT apply to:** - Native SOL staking (direct SOL → JitoSOL) - SPL token conversions (USDC, WBTC, etc.) - Jupiter-based swaps to JitoSOL ## Managing Your Intercepted Stakes Visit [jito.network/interceptor](https://www.jito.network/interceptor/) to see pending deposits with countdown timers: ![Interceptor Features](https://www.jito.network/omnidocs/jitosol/images/interceptor-page-list-of-intercepted-stakes.png) **Interface shows:** JitoSOL amount, time remaining, early claim fee, and claim button ## Early Claiming (Optional) **Most users should wait** for free automatic delivery. Only claim early if you urgently need the tokens and can't wait the remaining time. ### How Early Claiming Works If you need your JitoSOL before the 10-hour cooldown ends: ![Early Claim Modal](https://www.jito.network/omnidocs/jitosol/images/interceptor-page-confirm-claim-with-fee.png) 1. **Review the fee:** Fee starts at ~10% and decreases linearly to 0% over 10 hours 2. **Acknowledge cost:** Check the box confirming you understand the fee 3. **Claim with fee:** Pay the fee to receive your JitoSOL immediately **Fee Structure:** - **Hour 0:** ~10% fee (maximum) - **Hour 5:** ~5% fee (halfway) - **Hour 10:** 0% fee (automatic delivery) ### When to Consider Early Claiming **Good reasons:** - Urgent DeFi opportunity requiring immediate liquidity - Time-sensitive arbitrage or trading needs **Not good reasons:** - Impatience (better to wait for free delivery) - Small amounts (fees often exceed gas costs) ## Frequently Asked Questions **"Why is my stake being intercepted?"** You deposited a stake account rather than native SOL. This protects the JitoSOL ecosystem from toxic flow. **"Do I need to do anything?"** No! Your JitoSOL will be automatically delivered after 10 hours with no fees. **"Am I earning rewards during the cooldown?"** Yes, you earn full staking and MEV rewards throughout the entire cooldown period. **"Can I cancel or modify my deposit?"** No, deposits cannot be cancelled. You can either wait for automatic delivery or claim early with a fee. **"What if I forget about my deposit?"** No problem! Jito automatically delivers your JitoSOL after 10 hours. You don't need to remember or take any action. **"Why doesn't this apply to regular SOL staking?"** Native SOL deposits don't create the same toxic flow issues that Interceptor prevents. ## Key Takeaways ✅ **Set and forget:** Interceptor handles everything automatically ✅ **Full rewards:** Earn staking and MEV rewards during the entire cooldown ✅ **Free delivery:** No fees when you wait the full 10 hours ✅ **Ecosystem protection:** Helps maintain JitoSOL's liquidity and stability ✅ **Optional early access:** Available if you urgently need tokens (with declining fee) **Remember:** Interceptor protects all JitoSOL holders from toxic flow. Most users should wait for automatic delivery to avoid fees and support ecosystem health. ## Additional Resources - **[Interceptor GitHub Repository](https://github.com/jito-foundation/stake-deposit-interceptor)** - Open source code and technical documentation - **[Interceptor SDK Documentation](https://github.com/jito-foundation/stake-deposit-interceptor/tree/master/package)** - TypeScript SDK for developers integrating stake deposits - **[Developer Integration Guide](https://www.jito.network/docs/jitosol/jitosol-liquid-staking/for-developers/staking-integration.md)** - Code examples for staking integrations - **Security Audits:** [Certora Report](https://github.com/jito-foundation/stake-deposit-interceptor/blob/master/Certora_interceptor_security_report.pdf) and [OffsideLabs Report](https://github.com/jito-foundation/stake-deposit-interceptor/blob/master/OffsideLabs_interceptor_report.pdf) --- # Managing Your Stake Accounts > Utility for SOL stake account holders to manage and convert stakes. ## Managing Your SOL Stake Accounts **This page is for holders of native SOL stake accounts, not JitoSOL holders.** If you already have JitoSOL, you don't need this page - your JitoSOL automatically earns rewards and can be traded anytime. The [Jito Manage page](https://www.jito.network/manage/) is a utility for users who have existing SOL stake accounts. You can: - View and manage your current stake accounts - Deactivate and withdraw existing stakes - **Convert stake accounts to JitoSOL** for liquid staking benefits ## Why Convert to JitoSOL? **Benefits of converting your stake accounts to JitoSOL:** - **Instant liquidity:** Trade JitoSOL anytime without waiting for epochs - **Additional MEV rewards:** Earn extra yield on top of staking rewards - **DeFi opportunities:** Use JitoSOL in lending, DEXs, and yield farming - **No management needed:** JitoSOL automatically optimizes validator selection ## How to Use the Manage Page ### Getting Started 1. **Visit the page:** Go to [jito.network/manage](https://www.jito.network/manage/) 2. **Connect wallet:** Click "Connect Wallet" and select your preferred wallet 3. **View stake accounts:** See all your SOL stake accounts organized by status ![Manage Page Overview](https://www.jito.network/omnidocs/jitosol/images/manage-page-active-stake-list.png) The Manage Stake page contains: - **Interceptor notification:** Info about pending stake account deposits to JitoSOL pool - **Stake account tables:** Organized by status (Active, Activating, Deactivating, Inactive) - **Account details:** Amount, validator, and available actions for each stake ## Stake Account States ### Active Stake Your currently earning stake accounts. Each shows amount, validator, and action buttons. **Available actions:** - **Deactivate:** Begin unstaking process (takes up to 2 days) - **Convert to JitoSOL:** Instantly convert to liquid staking tokens ### Deactivating Stake Stakes in the process of being deactivated. Shows "Deactivation Pending" status. ![Deactivating Stakes](https://www.jito.network/omnidocs/jitosol/images/manage-page-deactivating-stake-section.png) **What happens next:** Stakes move to "Inactive" at the next epoch boundary (up to 2 days), then can be withdrawn. ### Inactive Stake Fully deactivated stakes that are ready for withdrawal or conversion. ![Inactive Stakes](https://www.jito.network/omnidocs/jitosol/images/manage-page-inactive-stake-list.png) **Available actions:** - **Withdraw:** Get your SOL back immediately - **Convert to JitoSOL:** Still available for liquid staking benefits ## Step-by-Step Processes ### Deactivating a Stake Account 1. **Click "Deactivate"** on any active stake account 2. **Review the modal:** Understand the 1-2 epoch waiting period ![Deactivate Confirmation](https://www.jito.network/omnidocs/jitosol/images/manage-page-deactivate-confirm-modal.png) 3. **Confirm in wallet:** Approve the deactivation transaction ![Wallet Confirmation - Deactivate](https://www.jito.network/omnidocs/jitosol/images/manage-wallet-confirm-deactivate-stake.png) 4. **Wait for completion:** Stake moves to "Deactivating" then "Inactive" status ### Withdrawing Inactive Stakes 1. **Click "Withdraw"** on any inactive stake account 2. **Confirm the action:** Review that SOL returns to your wallet ![Withdraw Confirmation](https://www.jito.network/omnidocs/jitosol/images/manage-page-withdraw-stake-modal.png) 3. **Approve in wallet:** Complete the withdrawal transaction ![Wallet Confirmation - Withdraw](https://www.jito.network/omnidocs/jitosol/images/manage-wallet-confirm-withdrawal-stake.png) ### Converting Stakes to JitoSOL **The conversion process:** 1. **Click "Convert to JitoSOL"** on any stake account (active or inactive) 2. **Review exchange rate:** See how much JitoSOL you'll receive 3. **Confirm transaction:** Approve the conversion in your wallet 4. **Automatic delivery:** JitoSOL delivered after 10-hour [Interceptor](https://www.jito.network/docs/jitosol/user-guides/interceptor.md) cooldown ## Frequently Asked Questions **"I have JitoSOL - do I need this page?"** No! This page is only for people with native SOL stake accounts. JitoSOL holders don't need to manage anything. **"What's the difference between the states?"** - **Active:** Currently earning staking rewards - **Activating:** Stakes becoming active at next epoch - **Deactivating:** Stakes being unstaked (ready in up to 2 days) - **Inactive:** Ready for immediate withdrawal **"Should I convert my stakes to JitoSOL?"** Converting gives you instant liquidity, auto-compounding MEV rewards, and DeFi opportunities. Keep native stakes if you prefer direct validator control. **"Can I convert inactive stakes?"** Yes! Both active and inactive stake accounts can be converted to JitoSOL. **"Why does stake account conversion take 10 hours?"** Stake account conversions go through the [Interceptor system](https://www.jito.network/docs/jitosol/user-guides/interceptor.md) to protect JitoSOL liquidity. Your JitoSOL is automatically delivered after the cooldown. **"How long does deactivation take?"** Deactivation completes at the start of the next epoch, which can take up to 2 days depending on timing. ## Need Help? **Stake accounts not showing?** Make sure you're connected to the wallet that owns the stake accounts. **Transaction failing?** Ensure you have enough SOL for transaction fees (~0.00008 SOL as shown in screenshots). --- # MEV Harvesting Guide > Guide for stake account holders to claim unclaimed MEV rewards. ## MEV Harvesting for Stake Account Holders **This page is only for holders of native SOL stake accounts, not JitoSOL holders.** If you have JitoSOL, your MEV rewards are automatically included and compounded - you don't need to do anything. The [Jito Harvest page](https://www.jito.network/harvest/) allows stake account holders to claim accumulated MEV rewards that haven't been automatically distributed. ![MEV Harvest Interface](https://www.jito.network/omnidocs/jitosol/images/harvest-page-list-of-stakes-with-unclaimed-mev.png) ### Who Gets MEV Rewards? **MEV rewards are only distributed if your validator is running the Jito client.** Rewards are determined by: - **Stake amount:** Larger stakes earn proportionally more MEV - **Duration:** How long your stake has been active - **Validator participation:** Your validator must run Jito client software ### Understanding the Interface **Unclaimed MEV Column:** Shows rewards in Lamports (1 SOL = 1 billion Lamports) - Small amounts like "2 Lamports" = 0.000000002 SOL - Larger amounts like "500,000,000 Lamports" = 0.5 SOL **Stake Address:** The public key of your stake account **Claim MEV Toggles:** Choose which stake accounts to harvest from **Status Indicators:** - **Inactive:** Stake account is deactivated but may still have unclaimed MEV - **Locked:** Stake account is currently locked/delegated ### How to Harvest MEV 1. **Visit the harvest page:** Go to [jito.network/harvest](https://www.jito.network/harvest/) 2. **Connect your wallet:** Same wallet that owns the stake accounts 3. **Review available rewards:** Check unclaimed MEV amounts for each stake account 4. **Select accounts:** Toggle on the stake accounts you want to claim from 5. **Choose reward type:** - Keep toggle off for SOL rewards - Turn on "Convert MEV to JitoSOL" to receive liquid staking tokens instead 6. **Confirm harvest:** Click "Harvest MEV as SOL" to proceed ### The Harvest Process ![Harvest Confirmation](https://www.jito.network/omnidocs/jitosol/images/harvest-page-confirm-modal.png) **Important details:** - **Multiple transactions:** The process may require several transactions depending on how many stake accounts you're claiming from - **All enabled rows:** The operation claims from all stake accounts you've toggled on ### When to Harvest **Consider harvesting when:** - You have meaningful amounts accumulated (worth more than transaction fees) - You want to convert MEV rewards to JitoSOL for liquidity **You might skip harvesting if:** - Amounts are very small (may not cover transaction costs) - Your validator isn't running Jito client (no rewards to claim) - You prefer to leave rewards in the stake account ### MEV Rewards vs JitoSOL **Stake Account MEV:** Manual claiming required, only works with Jito-enabled validators **JitoSOL MEV:** Automatic inclusion, no manual claiming needed, benefits from all Jito validators **Converting to JitoSOL:** If you toggle "Convert MEV to JitoSOL", your claimed MEV becomes liquid staking tokens that: - Earn ongoing staking + MEV rewards automatically - Can be used in DeFi or traded anytime - Don't require validator-specific Jito client participation ## Frequently Asked Questions **"I have JitoSOL - do I need to harvest?"** No! JitoSOL automatically includes MEV rewards. This page is only for native stake account holders. **"I don't see any unclaimed MEV"** Your validator may not be running the Jito client. **"Should I convert MEV to JitoSOL?"** Converting gives you liquid staking benefits and automatic future MEV rewards, vs keeping as SOL which earns no additional rewards. **"Why are the amounts so small?"** MEV rewards are distributed frequently in small amounts. --- # General FAQs > This page is being continuously developed. ## Staking and Unstaking #### Q: How long does unstaking stake? Users choosing to unstake via Delayed Unstake in the Jito.network staking interface must wait up to 1 epoch (about 2 days) to receive their SOL. This delay is attributable to Solana's underlying design and applies to any staking platform. We suggest users sell their JitoSOL on [Jupiter](https://jup.ag/) to receive instant liquidity and avoid any withdrawal fees. See our detailed article on [unstaking](https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview.md) JitoSOL. For large transactions, double check the spread/slippage on Jupiter. The Jito website will always provide direct unstaking with no slippage except for the 10bps fee and the 1 epoch waiting period. **Q: How long does staking take?** Depositors will receive JitoSOL instantly after staking on the Jito website and it begins accruing rewards immediately. Here is our step-by-step [staking guide](https://www.jito.network/docs/jitosol/get-started/stake-sol-for-jitosol-flow/overview.md). ## Rewards **Q: How do I collect my rewards?** JitoSOL's rewards accrues in its price rather than an ongoing distribution. At launch, 1 JitoSOL = 1 SOL. As rewards are accrued, JitoSOL will appreciate vs. SOL (e.g. 1 JitoSOL = 1.20 SOL). The price appreciation guarantees all JitoSOL holders receive rewards regardless of how the token is stored. **Q: What are staking rewards?** Validators receive new Solana issuance in return for voting on new blocks as they are issued. This issuance (or inflation) is distributed every epoch (about 2 days). Validators pass this onto their stakers less some commission. Further [reading](https://docs.solana.com/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards). **Q: What are MEV rewards?** MEV describes trading profits based on specific transaction ordering or timing. Jito's validator client implemented an auction mechanism where traders bid on these opportunities. The winning bids are distributed to validators and then stakers. This is a second source of rewards for JitoSOL holders. **Q: Why do my MEV rewards vary so much between periods?** MEV rewards naturally fluctuate based on market activity: - **High volatility periods** = more arbitrage opportunities = higher MEV - **Busy DeFi days** = more liquidations and trades = higher MEV - **Quiet markets** = fewer opportunities = lower MEV **Q: Can my JitoSOL ever lose value compared to SOL?** Under normal conditions, JitoSOL is designed to appreciate against SOL as rewards accumulate. The only scenarios for value loss would be extreme events like massive validator slashing (which currently doesn't exist on Solana) or critical smart contract bugs. ## Fees #### Q: What fees does JitoSOL collect? JitoSOL charges an annual management equal to 4% of total rewards. This fee is applied to staking rewards and MEV revenue after validator commissions. This charge equals approximately ~0.3% of deposited SOL's value per year or 30 cents on every $100 in deposits. JitoSOL also collects a fee of 0.1% on withdrawal value. This fee only applies if users directly unstake via the website. The charge is unfortunately required to prevent certain abuses in the protocol design. We suggest users sell their JitoSOL on [Jupiter](https://jup.ag/) to receive instant liquidity and avoid any withdrawal fees. #### Q: Are there other fees? What about validators? JitoSOL deposits the SOL with a carefully selected group of validators. These validators charge fees to fund their operations. Jito maintains its rewards by excluding validators with high fees or poor performance. Jito's fees are calculated after the direct validator commissions are already charged. ## Validators and Security **Q: How does Jito choose which validators to stake with?** Jito uses an automated system called **StakeNet** that selects the top 400 validators based on performance, fees, and reliability. The system checks things like: - Low commission rates - Good voting performance - Running Jito's MEV software - Not being too large (to help decentralization) This happens automatically every ~20-30 days with no human intervention, ensuring your stake always goes to high-performing validators. ## Security #### Q: Is JitoSOL audited and safe? JitoSOL is built on the stake pool program developed by Solana Labs. The program has been supporting numerous implementations since the network launched and three firms have completed audits ([reports](https://spl.solana.com/stake-pool#security-audits)). Security is assured with this proven implementation and JitoSOL's non-custodial nature. **Q: Does Jito control my SOL?** JitoSOL is non-custodial and holders always maintain control over their SOL. ## Interceptor and Stake Accounts **Q: I deposited a stake account for JitoSOL but now it's "stuck" in the Interceptor. What's happening?** Don't worry! This is normal and automatic. When you deposit an existing stake account (not regular SOL), the **Interceptor program** holds your JitoSOL for 10 hours as protection against abuse, then automatically delivers it to your wallet with no fees. **What you need to know:** - **You don't need to do anything** - Jito automatically handles delivery after 10 hours - **You're earning full rewards** during the entire cooldown period - **No fees for waiting** - automatic delivery is completely free - **Check status at** [jito.network/interceptor](https://www.jito.network/interceptor/) if curious This only happens with stake account deposits. Regular SOL staking gives you JitoSOL instantly. **Q: Why does Interceptor only apply to stake accounts and not regular SOL?** Interceptor prevents issues where other protocols exploit JitoSOL's liquidity. Stake account deposits create specific risks that regular SOL deposits don't, so the 10-hour cooldown protects all JitoSOL holders by ensuring deposits are genuine rather than exploitative. --- # Technical FAQs > Technical questions about JitoSOL mechanics and implementation ## JitoSOL Token Mechanics **Q: How is the JitoSOL exchange rate calculated?** The JitoSOL exchange rate can be calculated using the standard SPL stake pool formula: ``` Exchange Rate = Total Pool Lamports / Pool Token Supply ``` Where: - **Total Pool Lamports**: The total amount of SOL staked in the pool (including accumulated rewards) - **Pool Token Supply**: The total supply of JitoSOL tokens in circulation As staking and MEV rewards accumulate in the pool, the total pool lamports increase while the token supply remains constant, causing the exchange rate to appreciate over time. **Q: When exactly do rewards get distributed to JitoSOL holders?** JitoSOL holders receive rewards automatically through the appreciating exchange rate rather than direct token distributions: **Staking Rewards:** - Distributed by the Solana protocol at each epoch boundary (approximately every 2 days) - As stakes earn rewards, the pool and pool tokens grow proportionally in value - The SPL stake pool program automatically incorporates these rewards into the total pool lamports **MEV Rewards:** - MEV rewards are handled by the TipRouter system at epoch boundaries - At the end of every epoch, a state snapshot is taken of the last slot in an epoch. A script generates a merkle tree which contains information about the amount of MEV distributed to a validator and their stakers on a pro-rata basis - Each TipRouter operator calculates the merkle tree to produce merkle root then cast vote with produced merkle root. After consensus reached with more than 2/3, the cranker can upload the merkle tree from which claims can be made against **Q: Can the JitoSOL exchange rate ever go down?** Under normal circumstances, the JitoSOL exchange rate is designed to increase as rewards accumulate. However, it could decrease in extreme scenarios: - **Validator Slashing**: If validators in the pool are slashed for malicious behavior (though slashing does not really exist right now on Solana) - **Smart Contract Issues**: Critical bugs in the stake pool program (mitigated by multiple security firms have audited the stake pool program to ensure total safety of funds) The StakeNet system provides additional protection by automatically removing underperforming or malicious validators from the pool. ## Validator Management **Q: How does Jito select which validators to delegate to?** Jito uses **StakeNet**, an automated validator selection system with transparent on-chain criteria: **Binary Requirements (must meet ALL):** - Run the Jito MEV-enabled client (have MEV commission in the last 30 epochs) - MEV commission ≤ 10% (evaluated over the last 30 epochs) - Validator commission ≤ 5% (evaluated over the last 30 epochs) - Historical commission ≤ 50% (across all validator history) - Not belong to the validator superminority (top 33.3% of total stake) - Not run unsafe consensus modifications - Using acceptable Tip Distribution merkle root upload authority (TipRouter or OldJito) - Not blacklisted by governance - Maintain ≥ 5 epochs of continuous voting with ≥ 5,000 SOL minimum stake - Vote on ≥ 97% of expected slots in each of the last 30 epochs **Scoring System:** Validators that pass all binary criteria are ranked using a 4-tier hierarchical scoring system with the following priority order: 1. **Inflation commission** (highest priority): Lower commission validators are always preferred 2. **MEV commission**: Among validators with equal inflation commission, lower MEV commission is preferred 3. **Validator age**: Among validators equal on commissions, older validators (more epochs with vote credits) are preferred 4. **Vote credits ratio**: Among validators equal on all above, higher performance is preferred The 4-tier score ensures that differences in higher-priority tiers (like inflation commission) always dominate lower-priority tiers. This raw score is then multiplied by all binary eligibility factors - if any factor is zero, the final score becomes zero. The top 400 validators by overall score are selected for delegation in each 10-epoch cycle. *StakeNet parameters and thresholds are subject to change through Jito DAO governance.* **Q: What happens if a validator in the Jito pool performs poorly?** The StakeNet system automatically handles underperforming validators: **Performance-based Rebalancing (every 10 epochs):** - Maximum 7.5% of total pool can be unstaked per cycle - Priority given to removing stake from lowest-performing validators **Instant Unstaking Triggers (evaluated each epoch):** - **Delinquency**: Voting on <70% of expected slots - **Commission manipulation**: Increasing above 5% validator or 10% MEV commission - **Blacklist addition** by governance - **Unacceptable Tip Distribution merkle root upload authority** - Maximum 10% of total pool can be instantly unstaked per epoch **Q: How often does Jito rebalance stake between validators?** - **Regular Rebalancing**: Every 10 epochs (approximately 20-30 days) - **Instant Unstaking**: Evaluated every epoch for critical issues - **Target Allocation**: Each selected validator gets 1/400th of the total pool - **Safety Caps**: Various limits protect against excessive stake movement ## MEV and Priority Fee Distribution **Q: How are MEV and priority fee rewards calculated and distributed?** Both MEV and priority fee rewards flow through the **TipRouter** system: **Collection Process:** 1. **MEV Tips**: Block builders and searchers pay tips to validators for transaction inclusion 2. **Priority Fees**: TipRouter now distributes priority fees (commonly referred to as block rewards) to stakers 3. **Accumulation**: Tips accumulate in designated accounts during each epoch **Distribution Process:** 1. **Snapshot**: TipRouter operators take a snapshot of Solana validator and stake accounts at the end of the last slot of each epoch 2. **Calculation**: Operators calculate the distribution split: - **MEV**: 97% to validators/stakers, 3% protocol fee - **Priority Fees**: 1.5% fee on priority fee distributions, split between LST vault operators (5%), JTO vault operators (5%), and the Jito DAO (90%) 3. **Consensus**: TipRouter operators submit the merkle root of the tree to a BallotBox. Once quorum is reached, the winning merkle root is set 4. **Execution**: Rewards are distributed via merkle trees for gas-efficient claiming **Q: Why do MEV rewards vary between epochs?** MEV rewards fluctuate based on: - **Network Activity**: More transaction volume = higher MEV opportunities - **Market Conditions**: Volatility creates arbitrage and liquidation opportunities - **Searcher Competition**: More searchers bidding = higher tips - **Protocol Adoption**: DeFi activity drives MEV generation - **Seasonal Patterns**: Trading patterns vary by time and market cycles **Q: How can I track my MEV rewards separately from staking rewards?** You can track MEV rewards using several methods: **Jito Rewards Interface:** - Visit [jito.network/staking/?mode=rewards_view](https://www.jito.network/staking/?mode=rewards_view) - Shows **YTD Estimated MEV Rewards** as a separate metric from total rewards - Displays cumulative MEV rewards over different timeframes (7d, 30d, 180d, 1y, YTD, All) - Export options available for CSV downloads with MEV breakdowns **Key Limitations:** - Values are approximate and for informational purposes only - Does not account for JitoSOL used in DeFi protocols - MEV rewards fluctuate significantly between epochs based on network activity **MEV Rewards API (Advanced Users):** - **Base URL**: `https://kobe.mainnet.jito.network` - **Staker Rewards Endpoint**: `/api/v1/staker_rewards` - Individual claimable MEV amounts - **Validator Rewards Endpoint**: `/api/v1/validator_rewards` - Aggregated MEV revenue data For most users, the rewards interface provides sufficient MEV tracking. ## Smart Contract and Technical Details **Q: What is the JitoSOL token contract address?** **JitoSOL Token Address:** `J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn` **Additional Details:** - **Stake Pool Address:** `Jito4APyf642JPZPx3hGc6WWJ8zPKtRbRs4P815Awbb` - **Token Program:** SPL Token Program (`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`) - **Decimals:** 9 - **Token Standard:** SPL Token You can verify this information on [Solscan](https://solscan.io/token/J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn) or [Solana Explorer](https://explorer.solana.com/address/J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn). **Q: Is JitoSOL compatible with all Solana wallets and dApps?** Yes, JitoSOL is a standard SPL token and is compatible with: - **All Solana Wallets**: Phantom, Solflare, Backpack, Ledger, etc. - **DeFi Protocols**: Can be used in lending, DEXs, yield farming - **Bridges**: Supported for cross-chain transfers via Wormhole NTT - **Custodial Services**: Compatible with institutional custody solutions The only requirement is that the wallet/dApp supports SPL tokens, which is standard across the Solana ecosystem. **Q: How does the underlying stake pool program work?** JitoSOL is built on Solana Labs' audited Stake Pool program (SPL): - **Aggregation**: Pools together SOL to be staked by a manager, allowing SOL holders to stake and earn rewards without managing stakes - **Delegation**: Automatically distributes stake across selected validators using StakeNet - **Token Minting**: Users deposit SOL in exchange for SPL tokens (staking derivatives) that represent their ownership in the stake pool - **Reward Handling**: As stakes earn rewards, the pool and pool tokens grow proportionally in value - **Withdrawal**: Allows conversion back to SOL through unstaking or burning tokens The program is battle-tested and used by multiple liquid staking protocols on Solana. ## Integration Questions **Q: Can I use JitoSOL as collateral in lending protocols?** Yes, JitoSOL is widely accepted as collateral in major Solana lending protocols: - **Supported Protocols**: Most major Solana lending platforms accept JitoSOL - **Loan-to-Value**: Typically competitive with other liquid staking tokens - **Liquidation Risk**: Standard liquidation mechanics apply based on JitoSOL price - **Rewards**: You continue earning staking+MEV rewards while using as collateral Always check the specific protocol's documentation for current LTV ratios and supported assets. **Q: Are there any restrictions on transferring JitoSOL?** No, JitoSOL transfers freely like any SPL token: - **No Lock-ups**: Unlike direct staking, no waiting periods for transfers - **No Minimum Amounts**: Can transfer any amount - **Cross-wallet**: Transfer between any Solana wallets - **Programmatic**: Full support for automated/smart contract transfers ## Advanced Topics **Q: How does the Interceptor mechanism work technically?** The **Jito Interceptor** protects against "toxic flow" during stake account deposits using an on-chain program that controls the stake pool's deposit authority: **Program Architecture:** - **Deposit Authority**: Interceptor program becomes the `stake_deposit_authority` of the JitoSOL stake pool - **Deposit Receipts**: Creates on-chain receipt accounts (PDAs) tracking each deposit with timestamp and amount - **Temporary Vault**: Holds minted JitoSOL tokens in a program-controlled account during cooldown **Technical Flow:** 1. **Intercept**: When users deposit stake accounts, program mints JitoSOL but holds it in vault 2. **Time Lock**: On-chain timestamp enforcement prevents early claims for 10 hours (36,000 seconds) 3. **Fee Calculation**: Early claim fee decreases linearly from ~10% to 0% over the cooldown period 4. **Automatic Claim**: Cranker service automatically delivers JitoSOL after cooldown with no fees This creates an economic moat around JitoSOL's liquidity while maintaining full on-chain transparency and decentralization. **Q: What are the differences between direct unstaking and selling on Jupiter?** | Aspect | Direct Unstaking | Jupiter Trading | |--------|------------------|-----------------| | **Speed** | Up to 1 epoch (~2-3 days max) | Instant | | **Fee** | 0.1% fixed | Market spread (variable) | | **Process** | Multi-step (deactivate + withdraw) | Single transaction | | **Slippage** | None (exact rate) | Possible on large trades | | **Destination** | SOL only | Any supported token | | **Requirements** | Epoch waiting period | Sufficient liquidity | Most users prefer Jupiter for convenience, while direct unstaking is better for very large amounts or fee optimization. **Q: How does JitoSOL maintain its peg to SOL?** JitoSOL doesn't maintain a fixed peg, it appreciates against SOL as rewards accumulate: - **Exchange Rate Growth**: Designed to increase over time as rewards accrue - **Arbitrage Mechanisms**: Price differences between DEXs and direct unstaking create arbitrage opportunities - **Liquidity Provision**: Deep liquidity pools on Jupiter and other DEXs help maintain efficient pricing - **Redemption Backstop**: Direct unstaking always available at exact on-chain rate **Q: How does StakeNet ensure decentralization and transparency?** **On-Chain Decision Making:** - All validator selection logic runs on-chain via the Steward Program - Validator performance data stored on-chain via the Validator History Program - All parameters and decisions are publicly verifiable **Community Governance:** - All system parameters can be adjusted through Jito DAO governance - Changes require community consensus before implementation **Decentralized Execution:** - Multiple independent keepers can execute the system's decisions - No single point of failure in the operational layer - Anyone can run a keeper to help maintain the system **Transparency Tools:** - Current parameters viewable at [jito.network/stakenet/steward/config](https://www.jito.network/stakenet/steward/config) - Event API: `https://kobe.mainnet.jito.network/api/v1/steward_events` - Real-time validator selection and scoring visible on-chain --- # Troubleshooting > Common issues and solutions when using JitoSOL ## Transaction Issues **Q: My staking transaction failed. What should I do?** Common causes: - Network congestion - Insufficient SOL for fees (need 0.001-0.004 SOL depending on activity) - Wallet connection issues Solutions: 1. Wait for lower congestion or increase priority fees/tips 2. Check SOL balance covers staking amount + fees 3. Refresh browser tab and wallet connection 4. Try multiple times - persistence is key **Q: My transaction is pending for a long time. What's happening?** Transactions can be dropped due to network congestion, block capacity limits, or blockhash expiration (~2 minutes). Solutions: 1. Wait 2-5 minutes during congestion 2. Check transaction status on Solana Explorer 3. Retry if no confirmation after 5 minutes 4. Refresh/resync wallet **Q: Unstaking shows successful but I haven't received SOL. Why?** If you used delayed unstaking: - Check stake status on [Stake Manage Dashboard](https://www.jito.network/manage/) - If your new stake account is still active, you need to unstake/deactivate it - If already deactivated, you need to wait up to 1 epoch (about 2 days) to withdraw. This is a Solana protocol feature If you used instant unstaking (Jupiter): - Refresh and check wallet balance and transaction history ## Wallet Connection Issues **Q: Can't connect wallet to Jito website?** Solutions: 1. Use Chrome, Firefox, or Edge (latest versions) 2. Clear browser cache and cookies 3. Update wallet extension 4. Disable ad blockers 5. Try different browser or restart current one Wallet-specific fixes: - Phantom: Disconnect/reconnect in settings - Solflare: Clear site data for jito.network - Ledger: Ensure Solana app is open and updated **Q: Wallet balance differs from Jito website?** Solutions: 1. Manual refresh wallet (most have refresh/sync button) 2. Wait 1-2 minutes for sync 3. Compare with Solana Explorer for your address ## Slippage and Pricing Issues **Q: Got less JitoSOL than expected when staking?** This is normal. JitoSOL appreciates vs SOL over time due to rewards. At launch 1 JitoSOL = 1 SOL, but as rewards accrue, you receive fewer (but more valuable) JitoSOL tokens. Example: If rate is 1.2 SOL = 1 JitoSOL, staking 10 SOL gives ~8.33 JitoSOL, but that 8.33 JitoSOL is worth the same as 10 SOL. **Q: Instant Unstake shows high spreads or price impact for JitoSOL swaps?** Solutions: 1. Use delayed unstaking: Direct via Jito = no slippage, only 0.1% fee + 1 epoch wait 2. Split large trades into smaller amounts 3. Check deeper liquidity pools on different DEXs ## Network and Performance Issues **Q: Jito website loading slowly or not responding?** Solutions: 1. Clear browser cache for jito.network 2. Try incognito mode 3. Test on mobile browser 4. Wait 10-15 minutes if high traffic ## Mobile Device Issues **Q: JitoSOL staking features don't work on mobile?** Solutions: 1. Use Phantom app: Open app → Explore tab → search "Jito" 2. Update mobile wallet to latest version 3. Try mobile browser (Safari/Chrome) if app fails 4. Switch between WiFi and mobile data 5. Force close and reopen wallet app 6. Clear app cache in device settings ## Getting Additional Help Include when asking for help: - Transaction signature (88-character string) - Wallet type and version - Browser/device info - Exact error message - Screenshots if helpful Never share: - Private keys or seed phrases - Passwords --- # JitoSOL Glossary > Key terms and definitions for understanding JitoSOL ## Core Terms **JitoSOL** A liquid staking token representing staked SOL in the Jito stake pool. Earns staking + MEV rewards while remaining tradeable and usable in DeFi. **JTO** Governance token for the Jito Network and DAO. JTO holders can vote on protocol proposals, parameter changes, and fee structures. **Exchange Rate** Current value of JitoSOL relative to SOL. Starts at 1:1 and increases over time as staking and MEV rewards accumulate in the token price. **MEV (Maximum Extractable Value)** Additional profit from reordering, including, or excluding transactions within blocks. Also known as Maximal Extractable Value. Jito captures MEV through validator auction mechanisms and shares it with JitoSOL holders. **Stake Pool** Smart contract that aggregates SOL from many users and delegates to multiple validators. Built on Solana Labs' audited Stake Pool program. **Liquid Staking** Staking method that provides a tradeable receipt token (JitoSOL) representing your staked position while earning rewards. ## Technical Terms **Epoch** Solana time period lasting approximately 2-3 days. Staking rewards are calculated and distributed at each epoch boundary. **Validator** Network participant that processes transactions and secures the blockchain. Jito delegates to high-performing validators with competitive commission rates. **StakeNet** Jito's automated validator selection and management system that uses on-chain performance data and algorithmic scoring. **Jito Steward Program** On-chain program that continuously evaluates validators and automatically rebalances stake allocation to optimize network security and returns. **Jito Interceptor** Protection mechanism that applies during the 10-hour cooldown period after staking, ensuring continuous rewards while preventing exploitation. ## Fees and Rewards **Management Fee** 4% of total rewards (staking + MEV) used to fund protocol development and operations. Applied after validator commissions. **Withdrawal Fee** 0.1% fee charged only for direct unstaking via the Jito website. Avoided by trading JitoSOL on DEXs like Jupiter. **Validator Commission** Fees charged by individual validators (typically 0-5% for Jito-selected validators). Jito selects validators with competitive rates to maximize user returns. **APY (Annual Percentage Yield)** Estimated annual percentage yield based on recent performance, including both staking rewards and MEV rewards. Historical performance does not guarantee future results. ## DeFi Terms **Yield Farming** Using JitoSOL in DeFi protocols (lending, liquidity pools) to earn additional rewards beyond base returns. **Impermanent Loss** Potential loss when providing JitoSOL to liquidity pools if the relative price changes compared to the paired token. **Slippage** Price difference between expected and actual execution price when trading, especially relevant for large JitoSOL trades. **Collateral** Using JitoSOL as backing for loans in lending protocols like Solend or Kamino, unlocking liquidity without unstaking. ## Cross-Chain Terms **Bridge** Infrastructure enabling JitoSOL transfers between different blockchains while maintaining its liquid staking properties. **Wormhole** Cross-chain protocol that facilitates secure JitoSOL transfers to other networks like Ethereum or Arbitrum. **NTT (Native Token Transfer)** Advanced bridging technology that preserves JitoSOL's native properties and metadata across different chains. ## Security Terms **Non-Custodial** Users maintain full control of their funds through smart contracts without relying on centralized intermediaries. **Smart Contract Risk** Potential for bugs or vulnerabilities in code affecting user funds. Mitigated through multiple security audits, including nine audits of the underlying SPL Stake Pool program. **Validator Risk** Impact of individual validator performance, downtime, or poor behavior on overall pool returns. **Slashing Risk** Theoretical penalty for severe validator misconduct. Risk is distributed across multiple validators. Slashing is currently not implemented on Solana. ## Operational Terms **RPC Endpoint** Remote Procedure Call endpoints that wallets and applications use to interact with the Solana blockchain. **Transaction Signature** Unique 88-character identifier for each blockchain transaction, used for tracking and verification. **Cooldown Period** Wait time of up to 1 epoch (~2-3 days maximum) when directly unstaking through the Jito protocol. **Instant Liquidity** Immediate conversion of JitoSOL to SOL through DEX trading, avoiding cooldown periods but potentially incurring slippage. **Priority Fees** Optional higher transaction fees users can pay during network congestion to increase chances of transaction success. ## Comparison Terms **Native Staking** Traditional direct staking to validators without receiving a liquid token, requiring epoch-long lockup periods. **LST (Liquid Staking Token)** Category of tokens like JitoSOL that represent staked positions while maintaining tradability and DeFi utility. **TVL (Total Value Locked)** Approximate total amount of SOL currently staked in the Jito pool, indicating protocol size and adoption. **Fair Value** Theoretical direct conversion rate between JitoSOL and SOL without market premiums or discounts. Calculated based on the stake pool's exchange rate. ## Network Terms **Congestion** High network activity causing slower transaction processing and higher failure rates, common during memecoin activity. **Dropped Transaction** Transaction that fails to be included in a block, requiring retry. Common during network congestion periods. **Block Space** Limited transaction capacity per block. High demand can cause competition and congestion. ## Important Notice These definitions are for informational purposes only and do not constitute financial advice. Cryptocurrency staking involves risks including potential loss of funds. Past performance does not guarantee future results. Users should conduct their own research and consider their risk tolerance before participating in any staking activities. For detailed explanations and current rates, see the relevant documentation sections. --- # Terms of Use **Last updated : April 10, 2025** I. An Introduction to the Terms These Terms of Use (these “Terms of Use”) provide the terms and conditions under which you, whether personally or on behalf of an entity (“you” or “your”), are permitted to use, interact with or otherwise access the Interfaces or Features provided by Jito Foundation (together with its affiliates, “Foundation,” “we,” “us,” or “our”). These Terms of Use, together with any documents and additional terms or policies that are appended hereto or that expressly incorporate these Terms of Use by reference as well as our Privacy Policy (collectively, the “Terms”), constitute a binding agreement between you and us. These Terms are applicable to (i) all content, functionality, and features (the “Content Features”) available on any website or graphical user interface hosted by Foundation to which the Terms are posted (each, as applicable, an “Interface”) and (ii) software that Foundation operates or hosts, or makes available via an Interface (the “Technology Features” and together with the Content Features, the “Features”). NOTICE: PLEASE REVIEW THE TERMS CAREFULLY. BY ACCESSING, INTERACTING WITH OR USING ANY INTERFACE OR ANY FEATURE, YOU AGREE THAT YOU ARE ABLE TO ENTER INTO A BINDING AGREEMENT AND, AS SUCH, HAVE READ, UNDERSTOOD, AND AGREE TO BE BOUND BY THE TERMS, INCLUDING THE BINDING ARBITRATION AGREEMENT AND CLASS ACTION WAIVER BELOW. IF YOU DO NOT AGREE TO ALL OF THE TERMS, YOU ARE NOT AUTHORIZED TO INTERACT WITH, ACCESS OR USE ANY INTERFACE OR FEATURE. II. The Interfaces and Features A. Overview of Interfaces and Features Each of the Interfaces are websites, and each have different functionality – some of which only provide information while others contain Features that allow users to send messages to blockchain networks in an entirely self-directed manner. None of the Interfaces allow us to engage in any transaction with you, nor do the Interfaces facilitate your transactions. Even when the Interfaces appear to be dynamic (e.g., updating or providing new displays when you – on your own accord – provide certain information), at no time is Foundation taking action directed by you or on your behalf. In addition, if you click the “Connect Wallet” feature on one of the Interfaces such that your self-hosted cryptocurrency wallet (“Wallet”) is able to provide information to be transmitted to a blockchain network or other blockchain-based application, you should note that (except as otherwise noted herein) Foundation (i) is not involved in providing or transmitting any such information to networks, (ii) cannot transmit any information to networks or otherwise assist in any transaction, (iii) never has access to and cannot control or provide guarantees relating to your Wallet and (iv) has no authority over and does not take possession or custody of your cryptoassets at any time, each except as otherwise discussed herein. This also means that Foundation is unable to assist with transactions: please be vigilant in interacting with any immutable blockchain technology. You are solely responsible for familiarizing yourself with your Wallet and its safety and security features, including any private keys and passwords associated therewith. Foundation will not and cannot access your private key, password, or any cryptoassets held within your Wallet nor can it reverse any transactions you initiate with your Wallet (or otherwise). Foundation shall not be responsible or liable in any way for how you use your Wallet. You should also familiarize yourself with the risks associated with transacting on blockchain networks, including but not limited to smart contract vulnerabilities, front end vulnerabilities, hacks, phishing attacks, social engineering attacks, cryptoasset volatility and transaction irreversibility. Foundation has no ability in any way to control, maintain, provide, operate, or improve the smart contract or blockchain protocols underlying the tools and applications displayed on the Interfaces, except as noted herein. We do not effectuate, facilitate or control any transactions initiated via the Interfaces, and Foundation will not be responsible for the result of any transactions, including but not limited to failed, inadvertent, or fraudulent transactions that may result in loss of funds or transaction fees or any other loss or harm to you. All transactions broadcast to the applicable blockchain network via your Wallet may require the payment of non-refundable network transaction fees (“gas” fees), which shall be borne entirely by you. Certain of the Interfaces and Features covered by these Terms include, but are not limited to: ● Staking, which requires you to connect your Wallet and which allows you to transfer Solana tokens ("SOL") to the Jito network's stake pool smart contracts for purposes of delegating such SOL to Solana validators running the Jito-Solana validator client ("Jito PoS") to provide additional security to the Solana network. This Interface also provides information about validators on Jito PoS, amounts being staked and the general status of Jito PoS. ● Restaking, which requires you to connect your Wallet and which allows you to transfer certain cryptoassets to vaults to then be delegated to certain node operators to provide additional security to node consensus networks ("NCNs") on the Jito network. This Interface also provides information about NCNs, node operators, amounts being staked and the general status of Jito restaking. ● Airdrop, which requires you to connect your Wallet and which allows you to both check whether a Wallet is eligible to receive $JTO tokens and also claim those $JTO tokens directly from a related claims smart contract. ● Forum, which redirects you to forum.jito.network, a forum webpage (the "Forum") for discussions concerning the Jito decentralized autonomous organization. The Forum may require you to sign-up or log-in to an account to engage with certain Features, like posting or responding to posts on the Forum. The Forum may also connect you to certain third party service providers. ● StakeNet, which provides information, data, and explanations about StakeNet, the decentralized Solana stake pool manager and the validators to whom staked SOL is delegated. ● DeFi, which provides information about third parties who have integrated JitoSOL. This Interface also provides links to third-party websites and interfaces. Except as noted herein, (1) Foundation does not control, maintain, provide, operate, or improve any blockchain networks nor the activity or data thereon and (2) Foundation is not responsible for the activities of persons or entities who develop or use applications or who validate or verify transactions or other operations related to blockchain networks operated by third parties. Foundation cannot control how blockchain networks operated by third parties market their blockchain networks and users should not assume any blockchain networks operated by third parties are affiliated with Foundation, notwithstanding any marketing materials created by such third party that could imply otherwise. ‍ B. Your Acknowledgement Relating to Information on the Interfaces You hereby acknowledge and agree that all information provided in connection with your access and use of the Interfaces and as it relates to the Features is intended for informational purposes only. Foundation strives to provide accurate information, but it does not guarantee or otherwise warrant that the information is updated, complete, or timely. For this reason, you acknowledge and agree that you are not relying on any of the information on the Interfaces for any purpose and expressly (i) disclaim any reliance on any information on the Interface or within the Features, and (ii) acknowledge that Foundation will not be liable for any such information provided. You should take all steps to independently verify any information on any Interface on which you intend to rely and should not take action based solely on any information contained on any Interfaces, including blog posts, data, articles, links to third-party content, social media content (including Discord, Telegram or X), news feeds, tutorials and videos. None of the information provided on the Interfaces or through the Features should be construed as professional or investment advice, and Foundation does not owe any duties and does not have any obligations to you based on the information provided on the Interfaces or through the Features. None of the information provided on the Interfaces or any of the Features shall be interpreted as an invitation or inducement to (A) exercise any rights to acquire, dispose of, underwrite, or convert any cryptoassets or digital assets or (B) buy, sell, or induce a user to buy or sell any cryptoassets or digital assets. III. Modifications We reserve the right, in our sole discretion, to modify the Terms at any time or from time to time. The modified Terms will be posted on an Interface, and will provide the last updated date at the top. Any modified Terms will become effective upon posting. By continuing to access, use or otherwise interact with any Interface or Feature after the effective date of any modification to the Terms, you are providing your explicit agreement to be bound by the Terms as modified. If you do not agree to be bound by any updated Terms, you are prohibited from using, accessing, or otherwise interacting with the Interfaces or Features. It is your responsibility to check any Interface you use regularly for modifications to the Terms of Use. We also reserve the right, in our sole discretion, to modify the Interfaces or Features at any time and from time to time, with or without notice to you. We may also eliminate any Interface or Feature, at our sole discretion, with or without notice, including deleting or otherwise materially modifying information, and we owe you no obligation to continue to provide any Interface or Feature under any circumstances. IV. Your Responsibilities and Representations A. Your Representation The Interfaces and Features are intended only for users who are 18 years of age or older. If you are entering into the Terms on behalf of an entity, such as the company you work for, you represent to us that you have the legal authority to bind such an entity. If you do not meet these requirements, you are prohibited from accessing, using or otherwise interacting with the Interfaces or Features. You represent and warrant that you are not, and for the duration of the time you use the Interfaces and Features, will not be (i) the subject of economic or trade sanctions administered or enforced by any governmental authority or otherwise designated on any list of prohibited or restricted parties; (ii) in contravention of any laws and regulations pertaining to anti-money laundering or terrorist financing; (iii) included on the List of Specially Designated Nationals and Blocked Persons maintained by the US Treasury Department’s Office of Foreign Assets Control (OFAC) or on any list pursuant to European Union (EU) and/or United Kingdom (UK) regulations (as the latter are extended to the Cayman Islands by statutory instrument); or (iv) operationally based or domiciled in a country or territory in which sanctions imposed by the United Nations (whether through the Security Council or otherwise), OFAC, the EU and/or the UK apply, or otherwise pursuant to sanctions imposed by the United Nations, OFAC, EU, or UK. If at any point the above is no longer true, then you must immediately cease using the Interfaces and Features. You acknowledge that you – and only you – are responsible for properly configuring, as applicable, and using the Features or incorporating the Features into your applications or Wallet and for taking appropriate action to secure your data, including without limitation, financial or token information and private keys. You acknowledge and agree that you have the financial and technical sophistication to properly use and interact with the Interfaces and Features and that you understand the inherent risks of blockchain technology. You understand that transacting in cryptoassets and applications utilizing cryptoassets is risky and may subject you to cyberattack, loss of cryptoassets, unknown exploits, smart contract risks, governance attacks, and other risks related to blockchain transactions. You also understand that transactions executed and settled via smart contracts are not reversible and you may not have recourse in the event of a malicious, fraudulent, or inadvertent transaction. B. Your Responsibilities & Prohibited Conduct You agree to access, use or otherwise interact with the Interfaces and Features only in an authorized, proper and appropriate manner and in accordance with these Terms and with all applicable laws. You agree that you will not: ● violate any applicable laws or regulations through your access to or use of the Interfaces and Features; ● violate the Terms; ● exploit the Interfaces or Features for any unauthorized purpose; ● harvest or otherwise collect information from the Interfaces or Features for any unauthorized purpose; ● use the Interfaces or Features in any manner that could disable, overburden, damage, or impair the Interfaces or Features or interfere with any other party's use or enjoyment of the Interfaces or Features; ● reverse engineer, disassemble, or decompile the Interfaces or Features or apply any other process or procedure to derive the source code of any software included in the Interfaces or Features except to the extent applicable law does not allow this restriction or such rights have been expressly granted to you under a separate license; ● sublicense, sell, or otherwise distribute the Interfaces or Features, or any portion thereof; ● use any data mining tools, robots, crawlers, or similar data gathering and extraction tools to scrape or otherwise remove data from the Interfaces or Features; ● use any manual process to monitor or copy any of the material on the Interfaces or Features or for any other unauthorized purpose without our prior written consent; ● introduce any viruses, trojan horses, worms, logic bombs, or other material which is malicious or technologically harmful to the Interfaces or Features; ● attempt to gain unauthorized access to, interfere with, damage, or disrupt any parts of the Interfaces or Features, the server(s) on which the Interfaces or Features are stored, or any server, computer or database connected to the Interfaces or Features; or ● attack the Interfaces or Features via a denial-of-service attack or a distributed denial-of-service attack or otherwise attempt to interfere with the proper working of the Interfaces or Features. You acknowledge and agree that in the event that you use an Interface or Feature in a prohibited manner, we may investigate or take any other action we deem necessary, including cooperating with law enforcement or bringing claims against you if they result in harm or damage to Foundation, to rectify the prohibited conduct or any consequences resulting therefrom. You hereby acknowledge and agree that using the Interfaces or Features may result in tax consequences. It is solely your responsibility to determine whether there are any tax consequences from any transactions you initiate using the Interfaces or Features, and you are solely responsible for ensuring compliance with applicable tax laws in your tax resident jurisdiction. C. Your Feedback You may provide feedback to us or otherwise submit questions and inquiries through some of the Interfaces (“Feedback”). We welcome Feedback relating to improvements or updates to the Interfaces or Features, or inquiries about the same. We will try to review your Feedback, but are not obligated to do so nor are we obligated to release any modifications or improvements you submit to us based on your Feedback. You acknowledge and agree that we will own all right, title, and interest in and to all Feedback you submit. You represent and warrant that (i) you and your licensors own all right, title, and interest in and to your Feedback; and (ii) you will not violate any intellectual property or other rights of third parties in providing Feedback to us. V. Intellectual Property Rights A. Ownership & License Foundation or its licensors own all right, title, and interest, including all intellectual property rights, in and to the Interfaces and Features, including any related content and technology, unless otherwise indicated. Subject to the Terms, Foundation hereby grants you a personal, limited, revocable, non-exclusive, non-sublicensable, non-transferable license to use, copy, and distribute in connection with such use the Interfaces and Features. This license is solely intended to allow you to access, use or otherwise interact with the Interfaces and Features. You acknowledge and agree that you do not receive any other rights to the Interfaces or Features other than those specified in the Terms. Certain Features may be provided to you under a separate license; third party features or applications integrated into the Interfaces or Features may be subject to other or additional intellectual property licenses and thus, you must review any terms relevant to those third party features or applications to determine the relevant license applicable thereto. You agree you will not violate the terms of any such separate license. B. Reciprocal License By using any Interface or Feature, you grant us a limited, non-exclusive, sublicensable, worldwide, royalty free license to use, copy, modify and display any content or Feedback you provide to us or that you post on or through any of the Interfaces or Features solely for our business purposes, including but not limited to the purpose of providing the Interfaces or Features for so long as is necessary to do so. C. Foundation’ Trademarks Jito graphics, logos, page headers, button icons, scripts, and service names are trademarks, registered trademarks or trade dress of Foundation (the “Foundation Marks”). All other trademarks not owned by Foundation that appear on this Site are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Foundation. You may use the Foundation Marks only in accordance with, and subject to the terms of, these Terms. By using any of the Foundation marks, or any variation thereof, you acknowledge that Foundation owns the Foundation Marks (or variation thereof), and you agree that all use of the mark or any variation thereof inures to the benefit of Foundation. To the extent you use the mark or any variation thereof in connection with any illegal or dishonest activity, we have the right to revoke this trademark license, and at that time, you will cease any and all use of the mark and any variation thereto. You may link to the Interfaces, provided you do so in a way that is fair and legal and does not damage our reputation or take advantage of it, but you must not establish a link in such a way as to suggest any form of association, approval or endorsement on our part without our express written consent. VI. Third Party Information or Services As discussed throughout the Terms, the Interfaces and Features may be integrated with or otherwise give access to applications, services, sites, technology, data, operations, features and resources that are provided or otherwise made available by third parties (“Third Party Services”). If the Interfaces or Features contain links to such Third Party Services, they are provided for your convenience only. We have no control over the contents of those sites or resources, and accept no responsibility for them or for any loss or damage that may arise from your use of them. If you decide to access a Third Party Service integrated with or linked to any Interface or Feature, you do so entirely at your own risk and subject to the terms and conditions of use for such websites. We reserve the right to withdraw linking permission without notice. As further noted throughout these Terms, your access and use of Third Party Services may be subject to additional terms and conditions, privacy policies, or other agreements with those third parties, which Foundation does not control and otherwise may have no relationship with. Foundation also has no control over and is not responsible for such Third Party Services, including for the accuracy, availability, reliability, verification, or completeness of information or content shared by or available through Third Party Services, or the privacy practices of Third Party Services. Your use of any Third Party Services is directly between you and that third party, and you acknowledge and agree that Foundation will not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any Third Party Services. You, and not Foundation, will be responsible for any and all costs and charges associated with your use of any Third Party Services. Please review any applicable terms, privacy policies or agreements of Third Party Services prior to using such services. The integration or inclusion of such Third Party Services does not imply an endorsement or recommendation of such Third Party Services. VII. Indemnification A. General You agree to defend, indemnify, and hold harmless us, our representatives, contributors, contractors, employees, supervisors, representatives and directors, and our licensors, and each of their respective employees, officers, directors, and representatives (collectively, the “Foundation Parties”) from and against all liability for monetary damages, contractual claims of any nature, economic loss (including direct, incidental or consequential damages), loss of income or profits, fines, penalties, exemplary or punitive damages, and any other injury, damage, or harm, including reasonable attorney’s fees (“Damages”) that relate in any way to any demand, claim, regulatory action, proceeding or lawsuit, regardless of the cause or alleged cause, whether the allegations are groundless, fraudulent, false, or lack merit and regardless of the theory of recovery (“Claim(s)”) arising out of or relating to: (i) your use of the Interfaces or Features (including any use by your customers, users, employees, and other personnel); (ii) breach of the Terms or violation of applicable law by you, your customers, users, employees and other personnel; (iii) a dispute between you and any third party; (iv) your alleged or actual infringement or misappropriation of any third party’s intellectual property or other rights; and (v) your Feedback. In the event we receive any third party subpoena or other compulsory legal order or process associated with Claims described in (i) through (v) above, then in addition to the indemnification set forth above, you will reimburse us for our employees’ and contractors’ time and materials spent responding to such matters at our then-current hourly rates as well as our reasonable attorneys’ fees. B. Process If you are obligated to indemnify us, then you agree that we will have the right, in our sole discretion, to control any action or proceeding and to determine whether we wish to settle, and if so, on what terms, and you agree to fully cooperate with us in the defense or settlement of such Claim. VIII. Disclaimers And Limitations of Liability A. Interfaces and Features By accessing the Interfaces or Features, you hereby acknowledge and agree that Foundation cannot and does not guarantee the functionality, security, or availability of the Interfaces or Features. The technologies on which the Interfaces or Features rely may be subject to sudden changes and we cannot and do not guarantee that your access to the Interfaces or Features or the ability to transact thereon will be uninterrupted or error free or that your cryptoassets will be secure at all times. You assume all risks related thereto. B. No Representations or Warranties THE INTERFACES OR FEATURES ARE PROVIDED “AS IS.” EXCEPT TO THE EXTENT PROHIBITED BY LAW, OR TO THE EXTENT ANY STATUTORY RIGHTS APPLY THAT CANNOT BE EXCLUDED, LIMITED OR WAIVED, NEITHER WE NOR ANY OTHER FOUNDATION PARTY MAKES ANY REPRESENTATIONS OR WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED, STATUTORY OR OTHERWISE REGARDING THE INTERFACES OR FEATURES, AND THE FOUNDATION PARTIES EXPRESSLY DISCLAIM ALL WARRANTIES, INCLUDING ANY IMPLIED OR EXPRESS WARRANTIES (i) OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR QUIET ENJOYMENT, (ii) ARISING OUT OF ANY COURSE OF DEALING OR USAGE OR TRADE, (iii) THAT THE INTERFACES OR FEATURES WILL BE ACCURATE, UNINTERRUPTED, ERROR FREE OR FREE OF HARMFUL COMPONENTS, AND (iv) THAT ANY CONTENT OR ASSETS WILL BE SECURE OR NOT OTHERWISE LOST OR ALTERED. C. Limitations of Liability THE FOUNDATION PARTIES WILL NOT BE LIABLE TO YOU FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES (INCLUDING DAMAGES FOR LOSS OF PROFITS, REVENUES, CUSTOMERS OR USERS, OPPORTUNITIES, GOODWILL, USE, DATA, CONTENT OR OTHER ASSETS), EVEN IF ANY OF THE FOUNDATION PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. FURTHER, NONE OF THE FOUNDATION PARTIES WILL BE RESPONSIBLE FOR ANY COMPENSATION, REIMBURSEMENT, OR DAMAGES ARISING IN CONNECTION WITH (i) YOUR INABILITY TO USE, OR ANY DELAY IN THE USE OF, THE INTERFACES OR FEATURES, INCLUDING AS A RESULT OF ANY (A) TERMINATION OF THE TERMS OR YOUR USE OF OR ACCESS TO THE INTERFACES OR FEATURES, (B) OUR SUSPENSION OR DISCONTINUATION OF ANY OR ALL OF THE INTERFACES OR FEATURES, OR, (C) ANY UNANTICIPATED OR UNSCHEDULED DOWNTIME OF ALL OR A PORTION OF THE INTERFACES OR FEATURES FOR ANY REASON; (ii) THE COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; (iii) ANY INVESTMENTS, EXPENDITURES, OR COMMITMENTS BY YOU IN CONNECTION WITH THE TERMS OR YOUR USE OF OR ACCESS TO THE INTERFACES OR FEATURES; (iv) ANY UNAUTHORIZED ACCESS TO, ALTERATION OF, OR THE DELETION, DESTRUCTION, DAMAGE, LOSS OR FAILURE TO STORE ANY OF YOUR DATA; OR (v) ANY CHANGE IN VALUE OF ANY CRYPTOASSET. IN ANY CASE, THE FOUNDATION PARTIES’ AGGREGATE LIABILITY UNDER THESE TERMS WILL NOT EXCEED $100. THE LIMITATIONS IN THIS SECTION APPLY ONLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW. ‍ IX. Governing Law, Dispute Resolution and Class Action Waiver A. Governing Law The Terms – and your use of the Interfaces and Features – are governed by the laws of the Cayman Islands, without regard to conflict of laws rules. Any arbitration commenced against us is subject to the Arbitration Rules of the Cayman International Mediation and Arbitration Centre. B. Dispute Resolution Prior to commencing any legal proceeding against us of any kind, including an arbitration, you and we agree that we will attempt to resolve any Claim by engaging in good faith negotiations. Such negotiations require that the aggrieved party provide a written notice to the other party specifying the nature and details of the dispute (the “Initial Notice”). The party receiving such notice shall have twenty days to respond, and within forty-five days after the Initial Notice was sent, the parties shall meet and confer in good faith to try and resolve the Claim. If the parties are unable to do so within ninety days of the Initial Notice, the parties may agree to mediate their dispute or either party may submit to arbitration according to these Terms. C. Mandatory Arbitration Provision Any dispute, claim or controversy arising out of or relating to the Terms, Interfaces or Features, or the breach, termination, enforcement, interpretation or validity of the Terms, including the determination of the scope or applicability of this agreement to arbitrate, will be determined by arbitration in the Cayman Islands before one arbitrator. This clause will not preclude parties from seeking provisional remedies in aid of arbitration from a court of appropriate jurisdiction. YOU UNDERSTAND THAT BY AGREEING TO THE TERMS, THE PARTIES ARE EACH WAIVING THE RIGHT TO TRIAL BY JURY OR TO PARTICIPATE IN A CLASS ACTION OR CLASS ARBITRATION. D. Waiver of Right to Bring Class Action or Representative Claims Any arbitration under the Terms will take place on an individual basis – class arbitrations and class actions are not permitted. To the fullest extent permitted by applicable law, you agree that any proceeding to resolve any dispute, claim or controversy will be brought and conducted only in your individual capacity and not as a party (plaintiff or otherwise) or member of any class (or purported class), consolidated proceeding, multi-plaintiff proceeding or representative action or proceeding. Any arbitration will not be permitted to be consolidated or aggregated with any other arbitration and the arbitrator will not have any authority to do so, and will not have the authority to make an award to any person or entity not a part of the individual arbitration in which you are a party. You further agree that any arbitrator may not preside over any form of class action involving you and us. E. Updated Terms Require Arbitration If you have been using an Interface or Feature, and thus, have agreed to the Terms, but determine eventually to cease doing so based on updates made to any Terms, your agreement to arbitrate any dispute with us and your waiver of any class action or representative claims remains in full force and effect. X. No Relationship or Assignments Nothing in the Terms shall be construed to create any relationship between you and us other than as defined herein. Neither you nor us is an agent of each other under these Terms or otherwise, and you shall have no right to hold yourself out as in any way having a relationship with us other than as someone using, accessing or otherwise interfacing with the Interface and/or Features. You agree that you are not permitted to assign or otherwise transfer any of your rights and obligations under the Terms, but Foundation may assign or transfer the Terms, in whole or in part, without restriction. Any assignment or transfer in violation of this Section will be void. Subject to the foregoing, the Terms will be binding upon, and inure to the benefit of, the parties and their respective permitted successors and assigns. XI. Entire Agreement The Terms, including any policies that expressly incorporate the Terms by reference, constitute the entire agreement between you and us regarding the subject matter herein. The Terms supersede all prior or contemporaneous representations, understandings, agreements, or communications between you and us, if any, whether written or verbal, regarding the subject matter of the Terms. XII. No Waiver The failure by us to enforce any provision of the Terms will not constitute a present or future waiver of such provision nor limit our right to enforce such provision at a later time. All waivers by us must be in writing to be effective. XIII. Severability If any portion of the Terms are held to be invalid or unenforceable, the remaining portions of the Terms will remain in full force and effect. Any invalid or unenforceable portions will be interpreted to effectuate the intent of the original portion. If such construction is not possible, the invalid or unenforceable portion will be severed from the Terms but the rest of the Terms will remain in full force and effect. --- # Cookie Policy **Last updated: April 10, 2025** **I. Introduction** This cookie policy (this “Cookie Policy”) explains how the Jito Foundation (“we”, “us,” or “our”) uses cookies and similar technologies to recognize you when you visit the website available at www.jito.network (the “Site”). This Cookie Policy explains what these technologies are, why we use them, and your rights with respect to the use of these technologies. In some cases we may use cookies to collect personal information, or information that becomes personal information if we combine it with other information. For more details on how we process your personal information, please review our Privacy Policy. We may update this Cookie Policy from time to time. If we make any changes, we will change the Last Updated date above. We encourage you to periodically review the Cookie Policy for the latest information on our privacy practices. **II. What are cookies?** We, as well as third parties that provide content, advertising, or other functionality on the Site, may use cookies, pixel tags, and other technologies (“Technologies”) to automatically collect information through your use of the Site. Cookies are small data files that are placed on your computer or mobile device when you visit a website. Cookies are widely used by website owners to make their website function, work more efficiently, or provide reporting information. Cookies set by the website owner are called “first party cookies”. Cookies set by parties other than the website owner are called “third party cookies.” Third party cookies enable third party features or functionality to be provided on or through the Site (e.g., like advertising, interactive content, and analytics). The parties that set these third party cookies can recognize your computer or device when it visits the website in question. **III. Why do we use cookies?** We use cookies for several reasons. Some cookies are required for technical reasons in order for our Site to operate, and we refer to these as “essential” or “strictly necessary” cookies. Other cookies enable us to understand the interests of our website visitors and users to enhance the user experience on our Sites. Third parties serve cookies through our Sites for our own advertising, analytics and other purposes. This is described in more detail below. The specific types of first and third party cookies served through our Sites and the purposes they perform are described below (please note that the specific cookies served may vary depending on the specific Site you visit). Our uses of these Technologies generally facilitate the following: ● Allow you access to the Site, applications, and tools that are required to identify irregular website behavior, prevent fraudulent activity, improve security, or allow you to make use of our functionality; ● Assess the performance of the Site, including as part of our analytic practices to help us understand how individuals use the Site; ● Offer you enhanced functionality when accessing or using the Site, which may include identifying you when you use the Site or keeping track of your specified preferences, interests, or past items viewed; ● Deliver content, through first or third party services, including ads relevant to your interests, on the Site or on third-party digital properties; and ● Process analytics information on the Site to allow us to better understand how the Site is used and to continually improve and personalize the Site. **IV. What about other web tracking technologies?** Cookies are not the only way to recognize or track visitors to a website. We may use other, similar technologies from time to time, like web beacons (sometimes called “tracking pixels” or “clear gifs”). These are tiny graphics files that contain a unique identifier that enables us to recognize when someone has visited our Sites or opened an email from us. This allows us, for example, to monitor the traffic patterns to our Sites, to deliver or communicate with cookies, to improve Site performance, and to measure the success of email marketing campaigns. In many instances, these technologies are reliant on cookies to function properly, and so declining cookies will impair their functionality. **V. Contact Us** If you have any questions about cookies or other tracking technologies that we use, please contact us at legal@jito.network. --- # Privacy Policy **Jito Foundation Privacy Policy** Last Updated:  March 4, 2025 This Privacy Policy is designed to help you understand how Jito Foundation , Inc. (“**Jito Foundation**”, “**we**”, “**us**,” or** **“**our**”), collect, use, process, and share your personal information, and to help you understand and exercise your privacy rights.   **About Our Services and the Blockchain** Our Services (as defined below) may facilitate interaction with certain decentralized cryptographic protocols like blockchains, which we do not own or control (each, a “**Protocol**”).  Our Services may also facilitate the creation of a digital wallet through third party services that we do not own and control that enable you to take self-custody and manage digital assets (such as NFTs, cryptocurrency, or blockchain tokens), and enable you to interact with third party services and supported Protocols to support the sale, purchase, trade, staking, distribution of digital assets and other transactions on the decentralized blockchains on which the supported digital assets are recorded (each, a “**Blockchain**”).   **An Important Note Regarding Blockchain Technologies: **If you participate in our Services relating to the creation and management of a digital assets, smart contracts will be employed that necessarily collect information, such as your digital wallet address (which some legal jurisdictions may consider personal information), and that information will be stored on a public blockchain that we do not control.  A smart contract is computer code that automatically processes events when certain conditions are met; for example, when a transaction is conducted to add a token to a digital wallet, a smart contract would automatically execute the proposed action.  In these situations, your personal information, such as a digital wallet address, will be stored on that blockchain through the execution of a smart contract and that personal information may not be able to be modified or deleted due to the immutable nature of the blockchain.   Please make sure to review our [Terms of Use](https://www.jito.network/docs/jitosol/resources/terms-of-use.md) for more information, including specific terms and obligations for the use of our Services that may include dispute resolutions.  **Table of Contents** **Page** 1. SCOPE OF THIS PRIVACY POLICY 2. PERSONAL INFORMATION WE COLLECT 3. HOW WE USE YOUR PERSONAL INFORMATION 4. HOW WE DISCLOSE YOUR PERSONAL INFORMATION 5. YOUR PRIVACY CHOICES AND RIGHTS 6. INTERNATIONAL DATA TRANSFERS 7. RETENTION OF PERSONAL INFORMATION 8. SUPPLEMENTAL NOTICE FOR CALIFORNIA RESIDENTS 9. SUPPLEMENTAL NOTICE FOR NEVADA RESIDENTS 10. CHILDREN’S INFORMATION 11. OTHER PROVISIONS, INCLUDING FOR EU/UK CITIZENS 12. CONTACT US # **1. SCOPE OF THIS PRIVACY POLICY** This Privacy Policy applies to personal information processed by us, including on our websites, and other online or offline offerings.  To make this Privacy Policy easier to read, our websites, and other offerings are collectively called the “**Services**.” **Changes to our Privacy Policy**.  We may revise this Privacy Policy from time to time in our sole discretion.  If there are any material changes to this Privacy Policy, we will notify you as required by applicable law.  You understand and agree that you will be deemed to have accepted the updated Privacy Policy if you continue to use our Services after the new Privacy Policy takes effect.   # **2. PERSONAL INFORMATION WE COLLECT** The categories of personal information we collect depend on how you interact with us, our Services, and the requirements of applicable law.  We collect information that you provide to us, information we obtain automatically when you use our Services, and information from other sources such as third-party services and organizations, as described below.   ## **A. Personal Information You Provide to Us Directly** We may collect personal information that you provide to us.   - **Contact Information.** We may collect personal information when you purchase certain products from us, including your phone number, email and mailing address. - **Account Creation**.  We may collect personal information when you connect to the Services, such as your digital wallet address. - **Online Transactional Information.  **We may collect transactional information, such as your wallet address.  We may collect personal information and details associated with your transactions including, but not limited to, information about the transactions you make using the Services, the purpose of the transactions, and information on sources of your funds. - **Your Communications with Us**.  We may collect personal information, such as email address, digital wallet address or online handle (for example, Discord) when you request information about our Services, register for our newsletter, request customer or technical support, or otherwise communicate with us. - **Surveys**.  We may contact you to participate in surveys.  If you decide to participate, we may collect personal information from you in connection with the survey. - **Interactive Features**.  We and others who use our Services may collect personal information that you submit or make available through our interactive features (for example, blockchain, messaging and chat features, commenting functionalities, forums, blogs, and social media pages).  Any information you provide using the public sharing features of the Services will be considered “public,” unless otherwise required by applicable law, and is not subject to the privacy protections referenced herein. - **Sweepstakes or Contests**.  We may collect personal information you provide for any sweepstakes or contests that we offer.  In some jurisdictions, we are required to publicly share information of sweepstakes and contest winners. - **Conferences, Trade Shows, and Other Events**.  We may collect personal information from individuals when we attend or host conferences, trade shows, and other events. - **Business Development and Strategic Partnerships**.  We may collect personal information from individuals and third parties to assess and pursue potential business opportunities. - **Job Applications**.  We may post job openings and opportunities on our Services.  If you respond to one of these postings, we may collect your personal information, such as your application, CV, cover letter, and/or any other information you provide to us. ## **B. Personal Information Collected Automatically** We may collect personal information automatically when you use our Services.   - **Automatic Collection of Personal Information**.  We may collect certain information automatically when you use our Services, such as your Internet protocol (IP) address, user settings, MAC address, cookie identifiers, mobile carrier, mobile advertising and other unique identifiers, browser or device information, location information (including approximate location derived from IP address), and Internet service provider.  We may also automatically collect information regarding your use of our Services, such as pages that you visit before, during and after using our Services, information about the links you click, the types of content you interact with, the frequency and duration of your activities, and other information about how you use our Services. - **Cookie Policy (and Other Technologies)**.  We, as well as third parties that provide content, advertising, or other functionality on our Services, may use cookies, pixel tags, and other technologies (“**Technologies**”) to automatically collect information through your use of our Services. - **Cookies**.  Cookies are small text files placed in device browsers that store preferences and facilitate and enhance your experience. - **Pixel Tags/Web Beacons**.  A pixel tag (also known as a web beacon) is a piece of code embedded in our Services that collects information about engagement on our Services.  The use of a pixel tag allows us to record, for example, that a user has visited a particular web page or clicked on a particular advertisement.  We may also include web beacons in e-mails to understand whether messages have been opened, acted on, or forwarded. Our uses of these Technologies fall into the following general categories: - **Operationally Necessary**.  This includes Technologies that allow you access to our Services, applications, and tools that are required to identify irregular website behavior, prevent fraudulent activity, improve security, or allow you to make use of our functionality; - **Performance-Related**.  We may use Technologies to assess the performance of our Services, including as part of our analytic practices to help us understand how individuals use our Services (*see Analytics below*); - **Functionality-Related**.  We may use Technologies that allow us to offer you enhanced functionality when accessing or using our Services.  This may include identifying you when you sign into our Services or keeping track of your specified preferences, interests, or past items viewed; - **Advertising- or Targeting-Related**.  We may use first party or third-party Technologies to deliver content, including ads relevant to your interests, on our Services or on third-party digital properties. *See “Your Privacy Choices and Rights” below to understand your choices regarding these Technologies.  * - **Analytics**.  We may use Technologies and other third-party tools to process analytics information on our Services.  These Technologies allow us to better understand how our digital Services are used and to continually improve and personalize our Services.  Some of our analytics partners include: - **Google Analytics**.  For more information about how Google uses your personal information (including for its own purposes, for example, for profiling or linking it to other data), please visit [Google Analytics’ Privacy Policy](http://www.google.com/policies/privacy/partners/).  To learn more about how to opt-out of Google Analytics’ use of your information, please click [here](http://tools.google.com/dlpage/gaoptout). - **PostHog**: For more information about how PostHog uses your personal information, please visit [PostHogs’ Privacy Policy](https://posthog.com/privacy). - **X/Twitter**: For more information about how X/Twitter uses your personal information, please visit [X/Twitter’s Privacy Policy](https://x.com/en/privacy). ## **C. Personal Information Collected from Other Sources** **Third-Party Services and Sources**.  We may obtain personal information about you from other sources, including through third-party services and organizations.  For example, if you access our Services through a third-party application, such a third-party login service or a social networking site, we may collect personal information about you from that third-party application that you have made available via your privacy settings.   **Blockchain Information**.  We may obtain personal information about you through our analysis of blockchain information.   # **3. HOW WE USE YOUR PERSONAL INFORMATION** We use your personal information for a variety of business purposes, including to provide our Services, for administrative purposes, and to market our products and Services, as described below.   ## **A. Provide Our Services** We use your information to fulfil our contract with you and provide you with our Services, such as: - Fulfilling purchase orders; - Managing your information and accounts; - Facilitating transactions you enter into; - Providing access to certain areas, functionalities, and features of our Services; - Answering requests for customer or technical support; - Communicating with you about your account, activities on our Services, and policy changes; - Processing applications if you apply for a job we post on our Services; and - Allowing you to register for events. ## **B. Administrative Purposes** We use your information for various administrative purposes, such as: - Pursuing our legitimate interests such as direct marketing, research and development (including marketing research), network and information security, and fraud prevention; - Detecting security incidents, protecting against malicious, deceptive, fraudulent or illegal activity, and prosecuting those responsible for that activity; - Measuring interest and engagement in our Services; - Improving, upgrading, or enhancing our Services; - Developing new products and services; - Ensuring internal quality control and safety; - Authenticating and verifying individual identities, including requests to exercise your rights under this Privacy Policy; - Debugging to identify and repair errors with our Services; - Auditing relating to interactions, transactions, and other compliance activities; - Sharing personal information with third parties as needed to provide or improve the Services; - Enforcing our agreements and policies; and - Carrying out activities that are required to comply with our legal obligations. ## **C. Marketing and Advertising our Products and Services** We may use personal information to tailor and provide you with content and advertisements.  We may provide you with these materials as permitted by applicable law.   Some of the ways we market to you include email campaigns or custom audiences advertising.   If you have any questions about our marketing practices, you may contact us at any time as set forth in “Contact Us” below.   ## **D. Other Purposes** We also use your personal information for other purposes as requested by you or as permitted by applicable law.   - **With Your Consent** We may use personal information for other purposes that are clearly disclosed to you at the time you provide personal information or with your consent. - **De-identified and Aggregated Information**.  We may use personal information to create de-identified and/or aggregated information, such as demographic information, information about the device from which you access our Services, or other analyses we create. # **4. HOW WE DISCLOSE YOUR PERSONAL INFORMATION** We disclose your personal information to third parties for a variety of business purposes, including to provide our Services, to protect us or others, or in the event of a major business transaction such as a merger, sale, or asset transfer, as described below.   ## **A. Disclosures to Provide our Services** **Notice Regarding Use of the Blockchain**.  Aspects of our Services may be hosted on or interact with the blockchain.  Where you use aspects of our Services that are hosted on or interact with the blockchain, information about your interactions and/or transactions will be provided to the applicable blockchain network and may be accessible to third parties due to the nature of the blockchain protocol.   The categories of third parties with whom we may share your personal information are described below.   - **Service Providers**.  We may share your personal information with our third-party service providers and vendors that assist us with the provision of our Services.  This includes service providers and vendors that provide us with IT support, hosting, payment processing, customer service, and related services. Some of the service providers we may use include:  1. **Jito Labs**: We may share your personal information with Jito Labs, Inc. to allow them to assist in improving the Services. 2. **PostHog**: We may share your personal information with PostHog Inc. to allow them to provide us with data storage services. 3. **X/Twitter**: We may share your personal information with X Corp. to allow them to provide us with attribution services. 4. **Business Partners**.  We may share your personal information with business partners to provide you with a product or service you have requested.  We may also share your personal information with business partners with whom we jointly offer products or services. 5. **Affiliates**.  We may share your personal information with our Jito Foundation affiliates. 6. **Other Users or Third Parties You Share or Interact With**.  As described above in “Personal Information We Collect,” our Services may allow you to share personal information or interact with third parties (including individuals and third parties who do not use our Services and the general public, such as those on the blockchain). 7. **Advertising Partners**.  We may share your personal information with third-party advertising partners.  These third-party advertising partners may set Technologies and other tracking tools on our Services to collect information regarding your activities and your device (for example, your IP address, cookie identifiers, page(s) visited, location, time of day).  These advertising partners may use this information (and similar information collected from other services) for purposes of delivering personalized advertisements to you when you visit digital properties within their networks.  This practice is commonly referred to as “interest-based advertising”, “targeted advertising,” “personalized advertising, or cross-context behavioral advertising.” 8. **APIs/SDKs**.  We may use third-party application program interfaces (“**APIs**”) and software development kits (“**SDKs**”) as part of the functionality of our Services.  SDKs typically collect your mobile device identifier and information related to your use of the Services.  SDKs may allow third parties including analytics and advertising partners to collect your information for various purposes including to provide analytics services and personalized advertising.  For more information about our use of APIs and SDKs, please contact us as set forth in “Contact Us”** **below. ## **B. Disclosures to Protect Us or Others** We may access, preserve, and disclose any information we store associated with you to external parties if we, in good faith, believe doing so is required or appropriate to: comply with law enforcement or national security requests and legal process, such as a court order or subpoena; protect your, our, or others’ rights, property, or safety; enforce our policies or contracts; collect amounts owed to us; or assist with an investigation or prosecution of suspected or actual illegal activity.   ## **C. Disclosure in the Event of Merger, Sale, or Other Asset Transfers** If we are involved in a merger, acquisition, financing, reorganization, bankruptcy, receivership, purchase or sale of assets, or transition of service to another provider, your information may be sold or transferred as part of such a transaction.   # **5. YOUR PRIVACY CHOICES AND RIGHTS** **Your Privacy Choices**.  The privacy choices you may have about your personal information are determined by applicable law and are described below.   - **Email Communications**.  If you receive an unwanted email from us, you can use the unsubscribe link found at the bottom of the email to opt out of receiving future emails.  Note that you will continue to receive transaction-related emails regarding products or Services you have requested.  We may also send you certain non-promotional communications regarding us and our Services, and you will not be able to opt out of those communications (for example, communications regarding our Services or updates to our Terms or this Privacy Policy). - **“Do Not Track**.**”** Do Not Track (“**DNT**”) is a privacy preference that users can set in certain web browsers.  Please note that we do not respond to or honor DNT signals or similar mechanisms transmitted by web browsers. - **Cookies and Personalized Advertising**.  You may stop or restrict the placement of Technologies on your device or remove them by adjusting your preferences as your browser or device permits.  However, if you adjust your preferences, our Services may not work properly.  Please note that cookie-based opt-outs are not effective on mobile applications.  However, you may opt-out of personalized advertisements on some mobile applications by following the instructions for [Android](https://support.google.com/googleplay/android-developer/answer/6048248?hl=en), [iOS](https://support.apple.com/en-us/HT202074), and [others](https://www.networkadvertising.org/mobile-choice/). The online advertising industry also provides websites from which you may opt out of receiving targeted ads from data partners and other advertising partners that participate in self-regulatory programs.  You can access these and learn more about targeted advertising and consumer choice and privacy by visiting the [Network Advertising Initiative](http://www.networkadvertising.org/managing/opt_out.asp), [the Digital Advertising Alliance](http://www.aboutads.info/choices/), [the European Digital Advertising Alliance](https://www.youronlinechoices.eu/), and [the Digital Advertising Alliance of Canada](https://youradchoices.ca/choices/).   Please note you must separately opt out in each browser and on each device.   **Your Privacy Rights**.  In accordance with applicable law, you may have the right to: - **Confirm Whether We Are Processing Your Personal Information **(the right to know); - **Access to and Portability of Your Personal Information**, including: (i) obtaining access to or a copy of your personal information; and (ii) receiving an electronic copy of personal information that you have provided to us, or asking us to send that information to another company in a structured, commonly used, and machine readable format (also known as the “right of data portability”); - **Request Correction **of your personal information where it is inaccurate or incomplete; - **Request Deletion **of your personal information; - **Request to Opt-Out of Certain Processing Activities** including, as applicable, if we process your personal information for “targeted advertising” (as “targeted advertising” is defined by applicable privacy laws), if we “sell” your personal information (as “sell” is defined by applicable privacy laws), or if we engage in “profiling” in furtherance of certain “decisions that produce legal or similarly significant effects” concerning you (as such terms are defined by applicable privacy laws); - **Request Restriction of or Object to **our** **processing of your personal information; - **Withdraw your Consent** to our processing of your personal information.  Please note that your withdrawal will only take effect for future processing, and will not affect the lawfulness of processing before the withdrawal; and - **Appeal our Decision **to decline to process your request. If you would like to exercise any of these rights, please contact us as set forth in “Contact Us”** **below.  We will process such requests in accordance with applicable laws.   If your personal information is subject to the applicable data protection laws of the European Economic Area or the United Kingdom, you have the right to lodge a complaint with the competent supervisory authority if you believe our processing of your personal information violates applicable law.  # **6. INTERNATIONAL DATA TRANSFERS** All information processed by us may be transferred, processed, and stored anywhere in the world, including, but not limited to, the United States or other countries, which may have data protection laws that are different from the laws where you live.  We endeavor to safeguard your information consistent with the requirements of applicable laws.   If we transfer personal information which originates in the European Economic Area, Switzerland, and/or the United Kingdom to a country that has not been found to provide an adequate level of protection under applicable data protection laws, one of the safeguards we may use to support such transfer is the [EU Standard Contractual Clauses](https://ec.europa.eu/info/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc/standard-contractual-clauses-international-transfers_en).   For more information about the safeguards we use for international transfers of your personal information, please contact us as set forth below.   # **7. RETENTION OF PERSONAL INFORMATION** We store the personal information we collect as described in this Privacy Policy for as long as you use our Services, or as necessary to fulfill the purpose(s) for which it was collected, provide our Services, resolve disputes, establish legal defenses, conduct audits, pursue legitimate business purposes, enforce our agreements, and comply with applicable laws.   To determine the appropriate retention period for personal information, we may consider applicable legal requirements, the amount, nature, and sensitivity of the personal information, certain risk factors, the purposes for which we process your personal information, and whether we can achieve those purposes through other means.   # **8. SUPPLEMENTAL NOTICE FOR CALIFORNIA RESIDENTS** **California Shine the Light**.  The California “Shine the Light” law permits users who are California residents to request and obtain from us once a year, free of charge, a list of the third parties to whom we have disclosed their personal information (if any) for their direct marketing purposes in the prior calendar year, as well as the type of personal information disclosed to those parties.   If you are a California resident and would like to exercise any of your California rights, please contact us as set forth in “Contact Us” below.  We will process such requests in accordance with applicable laws.   # **9. CHILDREN’S INFORMATION** The Services are not directed to children under 13 (or other age as required by local law outside the United States), and we do not knowingly collect personal information from children.   If you are a parent or guardian and believe your child has uploaded personal information to the Services in violation of applicable law, you may contact us as described in “Contact Us” below.   # **10. OTHER PROVISIONS, INCLUDING FOR EU/UK CITIZENS** **Sensitive Personal Information**.  We do not generally require you to disclose any sensitive personal information (for example, details of race, religious belief, sexual orientation, or membership of a trade union) to us.  If you do provide us with sensitive personal information for any reason, you consent to us collecting that information and then using and disclosing that information for the purpose for which you disclosed it to us.   **Third-Party Websites/Applications/Services**.  The Services may contain links to other websites/applications and other websites/applications may reference or link to our Services or the Services may allow you to interact with Third-Party Services.  These third-party services are not controlled by us.  We encourage our users to read the privacy policies of each website and application with which they interact.  We do not endorse, screen, or approve, and are not responsible for the third party’s actions or omissions, including but not limited to their privacy practices, content of such other websites or applications, and errors or bugs in their software.  Providing personal information to third-party websites or applications is at your own risk.   **Our Lawful Basis for Processing Personal Information**.  If your personal information is subject to the EU General Data Protection Regulation or other related legislation, our processing of your personal information may be supported by the following lawful bases:
Lawful Basis: Performance of a Contract (i.e., to Provide Our Services to You) Lawful Basis: Legitimate Interest Lawful Basis: Consent Lawful Basis: For Compliance with Legal Obligations
To Provide the Services or Information Requested ✓ ✓ ✓
To Measure Performance and Carry Out Research ✓ ✓
For Customer Support ✓ ✓ ✓ ✓
For Advertising Purposes ✓ ✓
For Administrative or Legal Purposes ✓ ✓ ✓
**Supervisory Authority**.  If your personal information is subject to the applicable data protection laws of the European Economic Area, Switzerland, or the United Kingdom, you have the right to lodge a complaint with the competent supervisory authority or attorney general if you believe our processing of your personal information violates applicable law.   - [EEA Data Protection Authorities (DPAs)](https://edpb.europa.eu/about-edpb/board/members_en) - [Swiss Federal Data Protection and Information Commissioner (FDPIC)](https://www.edoeb.admin.ch/edoeb/en/home/the-fdpic/contact.html) - [UK Information Commissioner’s Office (ICO)](https://ico.org.uk/global/contact-us/)** ** # **11. CONTACT US** Jito Foundation is the controller of the personal information we process under this Privacy Policy.   If you have any questions about our privacy practices or this Privacy Policy, are seeking to reach our EU or UK Representative, or to exercise your rights as detailed in this Privacy Policy, please contact us at: Jito Foundation, Inc. legal@jito.network --- # Github + Other Links Github: [link](https://github.com/jito-foundation) Medium: [link](https://medium.com/@Jito-Foundation) Jito Foundation Docs (validators, etc.): [link](https://www.jito.network/docs/hub/) Jito Labs Docs (block engine): [link](https://docs.jito.wtf) Jito Validator Docs: [link](https://jito-foundation.gitbook.io/mev/) --- # Constitution of the Jito Foundation > Jito Foundation Constitution This Constitution provides an overview of the governing framework for the holders of JTO (each, a “**Tokenholder**”, and collectively, the "**DAO**"), which is the governing body for the Jito Network (as defined below). Defined terms in this Constitution shall have the meaning ascribed to those terms in the Bylaws of the Foundation (as defined below), as amended from time to time, unless otherwise defined in this Constitution. Some of the rules and procedures in this Constitution will be enforced directly on a blockchain, and some will not. All rules are equally binding. Actions taken under this Constitution may be on-chain or off-chain actions. On-chain actions are those that are actuated directly by the governance parameters of the DAO as transactions on a blockchain. Off-chain actions are those that are actuated by other means. The "**Jito Network**” is the decentralized Solana-based protocol that enables users to stake SOL to validators participating in efficient block organization and receive a liquid staking token (JitoSOL) representing accumulated validator rewards and tips. The DAO can direct changes to the protocol source code or related parameters. Anyone can access the Jito Network. The Foundation (defined below) maintains a browser-based dashboard facilitating easy access at jito.network. ## The Foundation Jito Foundation, a Cayman Islands foundation company (the "**Foundation**"), has been formed to serve the DAO. The Foundation aims to facilitate the growth of the Jito Network. The Foundation has adopted Bylaws and other required formation documents, necessary to establish the Foundation’s initial governance structure. The Tokenholders have the authority to make certain decisions in relation to the Foundation and the Jito Network as set forth in the Foundation Documents. The DAO will govern the Foundation via Tokenholder Vote, in accordance with the Foundation Documents (including through submitting and voting on JIPs). ### Bylaws The Foundation’s Bylaws detailing the underlying governance structure for the Foundation can be found at [https://jito.network/docs/governance](https://jito.network/docs/governance). ### Formation Documents The Foundation’s formation documents, including the Amended and Restated Memorandum of Association and Articles of Association (the "**A&R M&A'**) can be found at [https://jito.network/docs/governance](https://jito.network/docs/governance). ## Foundation Governance Procedures ### Jito Improvement Proposals (JIPs) Jito Improvement Proposals ("**JIPs"**) are the primary mechanism for introducing, discussing, and implementing changes to the DAO’s governance and operations, and the Jito Network. JIPs serve as a means of fostering community discourse and decision-making within the organization. The JIP procedures consist of the following stages (the “**Governance Procedures**”): #### Community Discussion Ideas are discussed in a public governance forum (as designated by the Foundation from time to time which initially shall be the website located at the following link: https://forum.jito.network) by the community, with the author addressing feedback, questions, and suggestions. Upon an author’s request, a DAO moderator ("**DAO Moderator**") will confirm that an idea generally conforms to proposal guidelines (including that it fits within one of the categories initially enumerated below, which categories may be subject to further changes in accordance with a JIP related to the governance process). Once confirmed, and subject to the then applicable proposal threshold, the author(s) may move on to the next stage. #### Proposal Drafting Authors shall use the JIP outline below to write their proposal: *1. Title and Category* The name must be descriptive enough to understand what is being suggested but no longer than 4 sentences. The category must be one of the following: **Treasury** (allocation of developer grants, funds, incentives, etc. from the Foundation’s on-chain treasury (the “**Realms Treasury**”)) **Protocol Development** (protocol upgrades via code contributions, developer relations and growth etc.) **Structure** (changes to committees, special working groups, existing/new positions) **Process** (changes to voting procedure, governance tools, guidelines, etc.) **Operations** (special initiatives relating to branding, marketing, and operations) *2. Abstract* A summary of the entire proposal, no more than a single paragraph. *3. Motivation* A statement on why the DAO or the Foundation (as applicable) should implement this proposal. *4. Key Terms* Definitions of terms specific to the proposal or industry related jargon. *5. Specification* A detailed breakdown of what the proposal aims to change, the technologies/route of change needed to implement changes, and a concrete plan which outlines the steps and timeline required to make the change. *6. Benefits/Risks* A brief analysis of the benefits and risks involved with the proposal. *7. Outcomes* A brief summary of the desired goals and outcomes of the proposal. *8. Cost Summary* The total cost of the proposal, broken down if needed. *9. Performance Milestones, if applicable* The performance milestones for any JIPs submitted in the Treasury category. The author should incorporate any feedback received from the community and may alter the template if absolutely necessary to communicate effectively. It is recommended that the DAO Moderator confirm that the draft conforms to the proposal guidelines ([https://jito.network/docs/governance](https://jito.network/docs/governance)) before submitting the proposal and inform the Administrator. After the Administrator has confirmed proposals meet the above criteria, the proposal will be posted on Jito’s governance forum ([https://forum.jito.network/](https://forum.jito.network/)) for community discussion. Until a DAO Moderator is initially appointed by the Administrator and in the event that at any point in time there is no appointed DAO Moderator, the Administrator will perform these duties. If a Tokenholder does not meet the minimum token threshold for submitting proposals, they may work with someone who does to submit their proposal on their behalf. See [https://jito.network/docs/governance](https://jito.network/docs/governance) for more details. #### Proposal Discussion Once proposals have been posted to the forum, they will initially stay open for community discussion for 30 days (the “**Discussion Period**”). #### Proposal Submission Proposals can be submitted to Realms (as defined below) after the Discussion Period is complete. Realms has a 250,000 JTO token minimum for proposals to be submitted from the community. Any Tokenholder who meets this proposal threshold may submit their proposal directly. If not, the Administrator can assist to have the proposal submitted on their behalf. The Administrator will review the proposal for practicality and safety for the DAO once submitted and will ensure the proposal strictly adheres to applicable laws and regulations. The JIP release will take place on the DAO’s interface located at [https://gov.jito.network](https://gov.jito.network). #### Voting Tokenholders will be allowed to vote on JIPs for three (3) days (the “**Voting Period**”), followed by a two (2) day delay period (the “**Delay Period**”). #### Implementation Approved proposals will be treated differently based on the nature of the change. For those including on-chain executable code, these can be executed by anyone via the Realms interface immediately following the conclusion of the Voting Period and Delay Period. For proposals requiring implementation by the Foundation, the Administrator will work with the author, appropriate service providers of the Foundation, and other parties as needed to execute the proposal. The Administrator will provide updates on Jito’s governance forum ([https://forum.jito.network/](https://forum.jito.network/)) no less than every two weeks on the status of any such implementation. #### Proposal Requirements By submitting your JIP to vote in accordance with the Governance Procedures, you agree to submit your grant to certain conditions, including any requirements under applicable laws and regulations and AML/KYC processes deemed necessary or advisable by the Foundation. ### Proposal Guidelines Proposals should not break any of the governing principles of the Foundation (as set out in the Bylaws) and all proposals must strictly adhere to applicable laws and regulations. Furthermore, any actions or initiatives proposed must be within the permissible bounds as set forth by the laws of the Cayman Islands, under which the Foundation operates. Non-compliance or contravention of these legal parameters may result in the immediate rejection or invalidation of the proposal. Proposals that do not adhere to these guidelines may not be considered or vetoed by the Security Council. It is essential to review and ensure alignment with the Foundation's governing principles and legal constraints before submission. ### Voting Parameters The initial voting parameters for Tokenholders is as follows, which may be subject to further changes in accordance with a JIP related to the governance process (the “**Voting Parameters**”): Voting Period: 3 days (Length of the period during which people can cast “Yes” or “No” votes) Delay Period: 2 days. The delay period takes place after the voting period has ended and before the proposal is executed. During the Delay Period, token holders can only vote against open proposals. “Yes” votes cast during the Voting Period can be switched to “No” votes during this period. Upon completion of the Delay Period, if the number of “No” votes is greater than the number of “Yes” votes, the proposal will not pass. Proposal Threshold: 250,000 JTO (Minimum number of tokens a holder must have, or be delegated by third parties, to submit a proposal for a vote of the DAO) Voting Threshold: At least 3% (30,000,000 JTO) of the 1,000,000,000 JTO total token supply must vote “yes” and the number of “yes” votes must be more than the number of “no” votes. ### Implementation Period #### On-Chain Actions For programmatic changes, token holders can execute approved proposals instantly following completion of the Delay Period. #### Off-Chain Actions Due to the nature of off-chain actions, execution may not be immediate following the passing of a JIP. Certain off-chain actions may require Foundation Director approval, which may be vetoed in accordance with applicable law or for other reasons including inconsistencies with the Foundation’s purpose as set out in the Foundation's A&R M&A. If Foundation Directors exercise veto authority, disclosure and explanation for the veto shall be posted on the relevant JIP within two weeks of the proposal’s passing. ### Voting Power One (1) JTO token equals one (1) vote over any proposals submitted to the DAO (the “**Voting Power**”). This will allow Tokenholders to participate in the governance process proportionally to their holdings. The DAO, by Tokenholder Vote, may establish guidelines for evaluating and approving the inclusion of additional tokens in governance in the future. Tokenholders have governance power over components of the Jito Network such as Realms Treasury management to allocate funds for community growth, protocol fee splits, stake pool fees, and other features including the ability to adjust the on-chain functions outlined at [https://jito.network/docs/governance](https://jito.network/docs/governance). ### Amendments to Governance The JIP procedures, Voting Parameters, Voting Power and all other governance mechanics can be amended or modified through JIP and a Tokenholder Vote. The above describes only the initial state of governance mechanics. The community is encouraged to decide the future state of governance, the DAO and the Jito Network. Amendments to the Foundation’s Bylaws can be made in accordance with the terms of the Bylaws and the Foundation Articles. ### Proposal Conflicts Should a proposal be in direct conflict with a proposal presently under consideration for voting, the latter proposal ought to be held back from voting until a resolution is reached on the initial proposal. This is to prevent the endorsement of contradictory stipulations. In the event that a proposal is in direct opposition to an already approved proposal or identical to a previously unsuccessful proposal, it is not permitted to proceed to voting until three months post the implementation of the original proposal. This measure is in place to prevent the squandering of community resources. ### On-chain Realms JIPs that can be executed on-chain will be submitted and implemented via the DAO's Realms interface located at [https://gov.jito.network](https://gov.jito.network) (the “**Realms**") JIPs that require allocations from the Realms Treasury may be executed via Realms. ### Off-chain (Foundation Directors and Administrator) JIPs that must be executed off-chain will also be submitted via the Realms interface. In the event that a JIP requires actions be taken by the Foundation to execute, the Foundation Directors or the Administrator, as appropriate, will take such actions as needed to execute the JIP, while adhering to the Foundation Documents (including the Bylaws and this Constitution). ## Security Council A Security Council (the “**Security Council**”) should be established by the Foundation Directors. At all times, the Security Council shall be composed of at least five (5) Security Council Members who are appointed in accordance with the Bylaws. If a Security Council Member position is or will become vacated, such that the Security Council would be less than five (5) Security Council Members, the Tokenholders shall elect a replacement by Tokenholder Vote as quickly as is practical. The Security Council may use discretion to bypass ordinary Tokenholder Vote or JIP procedures to implement emergency proposals and actions necessary to preserve the safety or security of the Foundation, the DAO and/or the Jito Network, its users, or the Foundation’s assets. Examples of emergencies include but are not limited to security breaches, violations of core principles, network attacks, etc. ### Emergency Actions The Security Council shall have a veto right on JIPs put forward by the Tokenholders if such JIP: (i) violates any provision of the Bylaws, the Foundation Articles, this Constitution or any other document, policy or regulation as may be adopted by the Foundation; (ii) violates any applicable law or regulation; or (iii) is detrimental to the interests of the Foundation or the DAO (as determined by the Foundation Directors). The Security Council must not use its power to perform such Emergency Actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the integrity, confidentiality or availability of the Jito Network or the Realms Treasury. After performing any Emergency Action, the Security Council must issue a full transparency report (at an appropriate time after the security emergency has passed) to explain what was done and why such Emergency Action was justified. The DAO is able to curtail or eliminate the Security Council's power to perform Emergency Actions via approval and implementation of a JIP. ### Non-Emergency Actions For legal or other reasons, including inconsistency with the Foundation’s purposes, the Security Council shall also maintain the ability to act outside of an Emergency Action pursuant to JIPs that have been approved by Tokenholders in accordance with the JIP Process to perform protocol improvements and adjustments to certain parameters including, without limitation JitoSOL validator delegations or technical upgrades to programs critical to Jito Network’s operation. During the first six months of the DAOs existence, the Security Council is also permitted to execute regular course transactions, within reason, including (i) Realms Treasury transfers for incentivizing the Jito Network’s growth, (ii) other de minimis payments not related to incentivizing the Jito Network’s growth, which shall not exceed 5,000,000 JTO or (iii) technical upgrades. This provides operational flexibility as Tokenholders organize around the JIP process. Any such non-Emergency Action shall be communicated to the DAO by the Security Council and/or Administrator in the form of updates at [https://forum.jito.network](https://forum.jito.network). Notwithstanding the above, the Security Council shall act in good faith and in accordance with the purposes of the Foundation as set out in the Foundation's A&R M&A and applicable JIP. ### DAO Security Council Meeting Procedures and Frequency #### Regular Meetings Regular Meetings (as defined below) enable the Security Council to vote on JIPs and take any other acts within the Security Council’s authority. #### Scheduling The Security Council may convene every four (4) weeks, or at its discretion, subject to a reasonable amount of notice to Security Council Members (each, a “**Regular Meeting**”). A Regular Meeting may take place via telephone, videoconference, or through a group chat application. ### Attendees Only Security Council Members will be permitted to attend Regular Meetings, provided that the Security Council may permit any Foundation Representative (including the Foundation Directors, the Foundation Supervisor or the Administrator) to attend Regular Meetings, and may provide the Foundation Representatives with any and all information relevant to the business of a Regular Meeting. The invited Foundation Representatives will not be counted towards the satisfaction of a quorum for a Security Council Vote. A Security Council Member may invite a non-Foundation Representative third party to observe or participate in Security Council discussion or to take notes of the Regular Meeting, subject to a simple majority vote of the other Security Council Members. The third party must be bound by a non-disclosure agreement with the Foundation or with the member that invited the third party. The third party will not be counted towards the satisfaction of a quorum. #### Quorum A quorum of a Regular Meeting consists of at least 3 Security Council Members. A Regular Meeting may not proceed without a quorum. #### Procedures for Review of JIPs For JIP review procedures, the Foundation will post to [https://jito.network/docs/governance](https://jito.network/docs/governance) a DAO Administrator Work Instruction to be mutually agreed by the Foundation and DAO Administrator. #### Procedure for Proposals from Security Council Members Any Security Council Member may raise proposals for actions to be taken by the Security Council Members (a "**Proposal**"), among the Security Council Members, outside of Regular Meetings, in any written medium, including a Telegram chat. After a Security Council Member makes a Proposal, the Security Council should discuss the Proposal, giving sufficient time for dissenting views. Security Council Members should also describe any conflicts of interest. Security Council Members may request that any Proposals made outside of Regular Meetings be deferred to a Regular Meeting for a fuller discussion. The Security Council may choose to discuss such Proposal during the next scheduled Regular Meeting or to schedule a Regular Meeting more immediately. After a discussion, the Security Council will vote on the Proposal according to the voting procedure described below. #### Meeting Notes The Security Council may appoint a Security Council Member, Foundation Representative, or an authorized third party to take notes of the Regular Meeting (the "**Meeting Notes**"). Meeting Notes may exclude the following topics, which may be discussed at a Regular Meetings from time to time: Individual financial or investment positions of Security Council Members Unremedied security vulnerabilities affecting the Network, or other projects therein Foundation activities that are subject to non-disclosure agreements with third parties Compensation information of Security Council Members and Foundation Representatives Subject to a reasonable Security Council review and comment period chosen by the Security Council, Meeting Notes will be shared publicly with the community on Jito’s governance documentation page ([https://jito.network/docs/governance](https://jito.network/docs/governance)). #### Advisory Meetings A portion of the Security Council may convene irregularly scheduled advisory meetings ("**Advisory Meetings**"). Advisory Meetings enable the Security Council to discuss a specific subject matter among a smaller group of Security Council Members. The same rules that apply to Regular Meetings will apply to Advisory Meetings, except that: There is no quorum requirement for an Advisory Meeting. No Security Council Member may introduce a Proposal or vote on any outstanding Proposal at an Advisory Meeting. The Security Council may or may not publish Meeting Notes from Advisory Meetings, at its discretion. #### Emergency Meetings In response to an imminent security threat to the Jito Network or the Jito Network community, any protocol utilizing the Token, or the Foundation, the Security Council may convene irregularly scheduled emergency meetings ("**Emergency Meetings**"). The same rules that apply to Regular Meetings will apply to Emergency Meetings, except that: An Emergency Meeting does not need to be convened with reasonable notice to Security Council Members or the Foundation Directors. There is no quorum requirement for an Emergency Meeting. The Security Council will not publish Meeting Notes from Emergency Meetings until the underlying security threat has been remedied or judged to no longer be a threat, in the Security Council’s sole discretion. Each member of the Security Council shall have one (1) vote in Emergency Meetings. #### Compensation Initially, the Security Council Member position will be paid an amount equal to $1,000, which shall be paid, at the election of the Foundation, in (a) USDC or (b) JTO. If paid in JTO, the Security Council Member compensation shall be calculated on an as-converted to U.S. dollars basis, with such amount being the number of JTO that is the equivalent of USD $1,000, at a conversion price equal to the trailing seven (7) day time weighted average price of JTO recorded on [https://coinmarketcap.com/](https://coinmarketcap.com/). Any changes to the Security Council Member compensation shall be subject to approval by Tokenholders by Tokenholder Vote. --- # Bylaws of the Jito Foundation > (a Cayman Islands foundation company) As Adopted by directors resolution on December 6, 2023 #### 1.     Defined Terms (a) “***Administrator***” means the administrator of the DAO, which has certain powers and duties as further described in these Bylaws. (b) “***Applicable Law***” means the legal and regulatory requirements and obligations applicable to the Foundation, including U.S. federal, U.S. state, and non-U.S. laws, as well as the relevant regulatory schemes, including Cayman Islands law. (c) “***Bylaws***” means these governing bylaws of the Foundation, as may be amended from time to time in accordance with the Foundation Documents. (d) “**Constitution**” means the Constitution of the Foundation as available at https://jito.network/docs/governance, as may be amended from time to time in accordance with the Foundation Documents. (e) “***DAO***” means, collectively, the on-chain decentralized community of individuals or entities that own a Token. (f) “***Foundation***” means Jito Foundation, a Cayman Islands foundation company. (g) “***Foundation Articles***” means the Memorandum of Association and Articles of Association of the Foundation, as may be amended from time to time. (h) “***Foundation Director(s)***” means the director(s) of the Foundation, who have certain powers and duties pursuant to Cayman Islands law and as further described in the Foundation Articles. (i) “***Foundation Documents***” mean these Bylaws, Constitution and Foundation Articles. (j) “***Foundation Representative(s)***” means the Foundation Directors, Foundation Supervisor and the Administrator. (k) “***Foundation Supervisor***” means the supervisor of the Foundation, which has certain powers and duties pursuant to Cayman Islands law and as further described in the Foundation Articles. (l) “***JIP***” means a Jito Improvement Proposal, which is a proposal put forth by a Tokenholder to a vote of the Tokenholders in accordance with the JIP Process. (m) “***JIP Process***” means the rules and procedures of submitting and voting on JIPs as described in the Constitution. (n) “***Network***” means the decentralized Solana-based protocol that enables users to stake SOL to validators participating in efficient block organization and receive a liquid staking token (JitoSOL) representing accumulated validator rewards and tips. (o) “***Security Council***” means the council established in accordance with the Foundation Documents to represent the Tokenholders. (p) "***Security Council Member(s)***" means the person or entity elected by the Tokenholders to, among other things, facilitate the implementation of JIPs or other matters as the Tokenholders may direct from time to time. (q) “***Security Council Vote***” means a vote of the Council Members in accordance with the Constitution. (r) “***Token***” means the governing token of the DAO, known as JTO, represented on the Solana blockchain. (s) “***Tokenholder***” means any holder of the Token. (t) “***Tokenholder Vote***” means a vote of the Tokenholders passed pursuant to a successful JIP in accordance with the JIP Process. #### 2.     Voting Matters The Tokenholders have the authority to engage in the following activities: (a) appoint or remove Security Council Members subject to Section 4(c) below (b) remove individuals or organisations from the role of Foundation Director (provided that the Foundation may not, at any time, be left with no directors); (c) elect individuals or organisations into the role of Foundation Supervisor and the remuneration of such newly appointed individuals or organisations; (d) remove individuals or organisations from the role of Foundation Supervisor (provided that the Foundation may not, at any time, be left with no supervisor); (e) provide consent to any proposed changes to the Foundation's Articles which remove or otherwise alter the rights of the Tokenholders under the Foundation's Articles; (f) approve grants that further the purpose of the foundation; (g)  wind-up the Foundation; (h) approve changes to the parameters of the protocol; and (i) any other vote that is lawful and consistent with the purpose of the foundation. #### 3.     Governing Principals The Foundation Representatives will strive to act in accordance with the following governing principles: (a) Act in the best interest of the Solana network (b) Act in the best interest of Tokenholders and JitoSOL token holders (c) The Foundation strives to create a safe and welcoming environment for all would-be community members, regardless of age, gender, ethnicity, religion, disability, sexual orientation, education, national origin, or any other differentiating factors. The Foundation is committed to maintaining an environment in which all individuals are treated with respect and dignity. The Foundation expects that all relationships among Foundation Representatives, the Foundation and Tokenholders will be free of unlawful bias, prejudice and harassment. Foundation Representatives are strictly forbidden from engaging in any type of discrimination or sexual harassment. (d) Critique Ideas, Not People. In evaluating JIPs and other issues, Foundation Representatives should focus on the substance of such discussions without criticizing individuals or engaging in personal attacks. (e) Consistency with the Foundation’s mission, which is to facilitate the growth of the Network and the Solana validator economy. Foundation Representatives should not use their role in a way that conflicts with the Foundation’s governing principles and the Foundation’s mission. As part of their service to the DAO or the Foundation, as applicable, each Foundation Representative will: - Adhere to these Bylaws and other applicable Foundation Documents. - Attend meetings and unofficial DAO events hosted by the Foundation and Tokenholders. Foundation Representatives may choose the frequency with which they perform these activities at their own discretion, bearing in mind that if they fail to adequately represent the Foundation or the DAO, as applicable, due to infrequency of participation, they may be removed from their position in accordance with the Foundation Documents. - Ensure that they are adequately informed on JIPs. - Share their contact information with the Foundation. - Announce as soon as possible if they will be unable, even temporarily, to fulfill their duties, for example, due to vacation, illness, or personal emergencies. - Understand Applicable Law, obey and act in accordance with Applicable Law and act ethically at all times. Foundation Representatives should ask their own legal counsel for advice when they are uncertain about Applicable Law. For the avoidance of doubt and notwithstanding anything in the contrary here, no Foundation Representative may take actions, directly or indirectly, which violate Cayman Islands law or any other Applicable Law. - Maintain and monitor relevant websites, forums, or other governance mediums and communications of the Foundation and the DAO. - As appropriate, elect, nominate, promote, hire, or contract with individuals or organizations into important administrative, governance, engineering, legal, or other roles established to serve the Foundation and the DAO. - No Foundation Representative should speak on behalf of the DAO or Foundation, unless explicitly authorized by the DAO or the Foundation. This provision does not in any way restrict a Foundation Representative from publicly discussing their personal opinion about a JIP or other matter affecting the DAO or the Foundation, provided that such communication is clearly presented as a personal opinion in light of the circumstances or context. #### 4.     Service Providers of the Foundation **(a) Foundation Directors** *(i) Appointment of Foundation Directors* Foundation Directors shall be appointed in accordance with the Foundation Articles and these Bylaws. *(ii) Removal of Foundation Directors* Foundation Directors shall be removed in accordance with the Foundation Articles and these Bylaws. *(iii) Role of Foundation Directors* The role of the Foundation Directors is as set forth in the Foundation Articles. *(iv) Compensation of Foundation Directors* Foundation Director compensation shall be determined in accordance with the Foundation Articles. The Directors must be: (i) at least eighteen (18) years of age; (ii) with no disqualifying attributes under Cayman Islands law, (iii) with no personal financial insolvency for the past ten (10) years, (iv) with no convictions or guilty pleas for mishandling or embezzlement of funds of any organization, and (v) have not been involuntarily removed, with cause, or forced to resign from any directorship, or similar executive or high-level position, within any organization. The Foundation Supervisor(s) must have no disqualifying attributes under Cayman Islands law. The Director(s) of the Foundation shall observe, implement, carry out, act upon, and execute any and all approved JIPs, provided that any Director(s) may veto an JIPs or place any limitations on its observation and implementation as a Director(s) of the Foundation in their discretion deemed necessary or appropriate to ensure compliance with: - any fiduciary duties to the Foundation; - statutory requirements of the Acts or regulations of any jurisdiction; - the Foundation Articles; and - to prevent any harm (including reputational harm) to the Foundation and, where applicable and necessary, for entering into or complying with any agreements or arrangements on behalf of the Foundation. The Director(s) of the Foundation are authorised to take any actions reasonably necessary on behalf of the Foundation to give effect to an approved JIP including passing any director resolutions to memorialise such approved JIP. **(b) Supervisor** *(i) Appointment of supervisors* Supervisors shall be appointed in accordance with the Foundation Articles. *(ii) Removal of supervisors* Supervisors shall be removed as set forth in the Foundation Articles. *(iii) Role of supervisors* The role of the supervisor is set forth in the Foundation Articles. *(iv) Compensation of supervisors* Supervisor compensation shall be determined by the Security Council pursuant to a Security Council Vote or as set forth in Section 2(c) above. **(c) Security Council** *(i) Appointment of Security Council Members* The Security Council are advisors to the Foundation Directors and shall be initially appointed by the Foundation Directors for a term of 12 months by director's resolution in accordance with the Foundation Articles. Thereafter, at all times the Security Council shall be comprised of at least five (5) Security Council Members who are appointed in the following manner: - One (1) member who shall be the Administrator (or an affiliate, employee or service provider thereof). The individual appointed as the member of the Security Council shall then be serving as Administrator (or an affiliate, employee or service provider thereof) and shall be elected as a Security Council Member by the Tokenholders by Tokenholder Vote at regular twelve (12) month intervals, unless otherwise replaced or removed prior to the end of their current term in accordance with these Bylaws and the other Foundation Documents; - Other members shall be appointed by Tokenholders by Tokenholder Vote at regular twelve (12) month intervals, unless otherwise replaced or removed prior to the end of their current term in accordance with these Bylaws and the other Foundation Documents. In the event that the Administrator (or an affiliate, employee or service provider thereof) is not willing to serve as a Security Council Member and there are not at least 5 appointed Security Council Members, a fifth Security Council Member shall be elected by Tokenholders by Tokenholder Vote, except that the Administrator (or an affiliate, employee or service provider thereof) will be appointed as a Security Council Member in replacement of this fifth Security Council Member appointed in accordance with this section as soon as a willing Administrator (or an affiliate, employee or service provider thereof) becomes available to serve and be appointed as a Security Council Member. *(ii) Removal of Security Council Members* A Security Council Member may only be removed: (a) by the Foundation Directors in connection with their violation of these Bylaws or their failure to fulfill their duties to the Foundation (in each case as determined by the Foundation Directors), including those described in the Foundation Documents; (b) pursuant to a Security Council Vote or a Tokenholder Vote (such Security Council Member in violation, the “***Breaching Member***”). In respect to (b), a Breaching Member may be removed as a Security Council Member (i) pursuant to a vote of all other Security Council Members or (ii) by the Tokenholders by Tokenholder Vote. If removed by the Foundation Directors, such removal of a Breaching Member shall be conditioned by a thirty (30) day notice, during which notice period the Breaching Member may consult with the Foundation Supervisor. If removed pursuant to a Security Council Vote: - An action to remove a Security Council Member for violation of these Bylaws may be presented as a Proposal by a non-breaching Security Council Member (a “***Removal Proposal***”) at a Regular Meeting. - A Removal Proposal will pass in accordance with the voting procedures set forth in the Constitution. - If the Removal Proposal passes, the Security Council may choose to replace the Breaching Member with a new, interim Security Council Member to serve until the end of term of the replaced Security Council Member’s term. An action to add a new Security Council Member must be presented at a Regular Meeting (a “***Replacement Proposal***”). - A Replacement Proposal will pass in accordance with the voting procedures set forth in the Constitution. If removed by Tokenholders by Tokenholder Vote: - An action to remove a Breaching Member may be presented by Tokenholders as a JIP (a “***Tokenholder Removal Proposal***”). - If the Tokenholder Removal Proposal passes in accordance with the JIP Process, the Tokenholders may choose to replace the Breaching Member with a new Security Council Member. An action to add a new Security Council Member may be presented as a JIP and in accordance with the JIP Process *(iii) Role of the Security Council* The Security Council shall operate pursuant to the rules in the Foundation Documents as may be amended in accordance with their terms going forward. The Security Council plays a supporting and coordinating role for the DAO, as set forth in the Constitution. The Security Council serves to represent the Tokenholders and assist with the implementation of JIPs and activity on the Network with guidance from the Administrator and as directed by the Foundation Directors, in accordance with the Foundation Documents. Security Council Members should act in the best interest of the DAO. Neither the Security Council nor the Security Council Members owe any fiduciary duties to the Foundation or the Tokenholders. *(iv) Compensation of Security Council Members* Security Council Member compensation shall be initially determined by the Foundation Directors by director’s resolution. Thereafter, Security Council Member compensation shall be determined by Tokenholders pursuant to JIPs and in accordance with the JIP Process.1 **(d) Administrator** *(i) Appointment of Administrator* The Administrator is a service provider of the Foundation and shall be initially appointed by the Foundation Directors and thereafter by the Tokenholders by Tokenholder Vote and shall serve for a period of twelve (12) months from the date appointed (the “***Administrator Term***”). The Administrator Term shall be automatically extended until such time as the Administrator is terminated or replaced pursuant to a JIP and in accordance with the JIP Process. (ii) *Removal of Administrators* An Administrator may be removed by Tokenholders by Tokenholder Vote, or by the Foundation Directors. *(iii) Role of the Administrators* The Administrators are persons or entities elected by the Tokenholders and thereafter engaged by the Foundation to manage the JIP process or other matters as determined by Tokenholders from time to time. All actions of the Administrator, as the Foundation’s service provider, remain subject to the review and veto by the Foundation Directors. The Administrators shall implement any such proposals as promptly as possible following the determination of approval unless otherwise indicated by the Tokenholders. In the event there is no Administrator, the Tokenholders shall advise the Foundation Directors in respect to the implementation of the proposals. The Administrator may not bring forward a JIP in their capacity as the Administrator or otherwise act without: (i) direction by the Tokenholders by Tokenholder Vote; or (ii) direction of the Foundation Directors. *(v) Compensation of Administrators* Administrator compensation shall be initially determined by the Foundation Directors by director’s resolution in accordance with the Foundation Articles. Thereafter, Administrator compensation shall be determined by Tokenholders pursuant to JIPs and in accordance with the JIP Process. #### 5.     Amendments to the Bylaws These Bylaws may be amended in accordance with the procedure set out in the Foundation Articles. #### 6.     Dispute Resolution To the extent there is ever a conflict between decisions made by the Foundation Directors and any other Foundation Representative, the Foundation Directors’ decision will prevail, unless a different outcome is required under Cayman Islands law. To the extent there is ever a conflict between decisions made by the Foundation Directors and the Tokenholders, the Tokenholders’ decision will prevail, unless a different outcome is required under Cayman Islands law. To the extent there is ever a conflict between decisions of the Administrator and the Tokenholders acting pursuant to a JIP and in accordance with the JIP Process, then the decisions of the Tokenholders will prevail, unless a different outcome is required under Cayman Islands law. Should a controversy, dispute or claim arise out of or in relation to these Bylaws ("***Dispute***"), the Foundation, the Foundation Directors and/or the Foundation Supervisor (as appropriate) must give thirty (30) days' notice of such Dispute to the relevant party/ies (the "***Notice of Dispute***"). Should the Dispute not be resolved at the expiration of thirty (30) days after service of the Notice of Dispute, the relevant party may commence arbitration proceedings in accordance with this clause 6. In any dispute involving the actions of the Foundation Directors, the Foundation Supervisor may commence arbitration proceedings against the Directors in accordance with this clause 6. Should the Dispute remain at the expiration of thirty (30) days after service of the Notice of Dispute, the Dispute shall be settled by arbitration administered by the International Centre for Dispute Resolution in accordance with its International Arbitration Rules (the "***Rules***"). The arbitration shall be seated in George Town, Grand Cayman, Cayman Islands and governed by the law of the Cayman Islands. The language of the arbitration shall be English. The arbitration shall be determined by a sole arbitrator to be appointed in accordance with the Rules. Any award or decision made by the arbitrator shall be in writing and shall be final and binding on the parties without any right of appeal, and judgment upon any award thus obtained may be entered in or enforced by any court having jurisdiction thereof. No action at law or in equity based upon any claim arising out of or related to these Bylaws shall be instituted in any court of any jurisdiction. #### 7.     Controlling Authority These Bylaws are subject to the provisions set forth in other sources of authority binding on the Foundation. In the event of any conflict between these Bylaws and such authority enumerated herein, such authority shall supersede these Bylaws and be controlling in the following order: (i) Cayman Islands law, and (ii) The Foundation Articles. --- # Amended And Restated Memorandum Of Association **THE COMPANIES ACT (AS AMENDED)** **THE FOUNDATION COMPANIES ACT, 2017** **AMENDED AND RESTATED** **MEMORANDUM OF ASSOCIATION** **of** **JITO FOUNDATION** **a foundation company limited by guarantee without share capital** \*\*A FOUNDATION COMPANY LIMITED BY GUARANTEE WITHOUT SHARE CAPITAL (ADOPTED BY DIRECTOR'S RESOLUTION DATED DECEMBER 6, 2023) \*\* WALKERS (Cayman) LLP 190 Elgin Avenue, George Town, Grand Cayman, KY1-9001, Cayman Islands T +1 345 949 0100 F +1 345 949 7886 www.walkersglobal.com \*\*Ref: KG/CK/185745 \*\* **THE COMPANIES ACT (AS AMENDED)** **THE FOUNDATION COMPANIES ACT, 2017** **AMENDED AND RESTATED** **MEMORANDUM OF ASSOCIATION** **OF** **JITO FOUNDATION** **(ADOPTED BY DIRECTOR'S RESOLUTION DATED DECEMBER 6, 2023)** 1. The name of the foundation company is Jito Foundation (the "**Foundation Company**"). 2. The registered office of the Foundation Company will be situated at the offices of FFP (Corporate Services) Limited of 2nd Floor, Harbour Centre, 159 Mary Street, George Town, Grand Cayman, Cayman Islands. 3. The Foundation Company's secretary shall be FFP (Corporate Services) Limited of 2nd Floor, Harbour Centre, 159 Mary Street, George Town, Grand Cayman, Cayman Islands or such other qualified person (as defined in the Foundation Companies Act, 2017) as the directors may at any time decide. 4. The Foundation Company is a company within the meaning of the Companies Act (as amended) and a foundation company within the meaning of the Foundation Companies Act, 2017. 5. The objects for which the Foundation Company is established are: 1. to support the growth and development of a blockchain-based protocol that enables users to stake SOL to validators participating in efficient block organization and receive a liquid staking token (JitoSOL) representing accumulated validator rewards and tips; 2. to support the growth and development of the Solana validator economy and related services; and 3. to do all such things as in the opinion of the directors are or may be incidental or conducive to the above objects or any of them. 6. The Foundation Company shall have and be capable of exercising all the functions of a natural person of full capacity irrespective of any question of corporate benefit, as provided by section 27(2) of the Companies Act (as amended). 7. The Foundation Company may not carry on a business for which a licence is required under the Acts of the Cayman Islands unless duly licensed. 8. No portion of the income or property of the Foundation Company from whatever place or source shall be paid or transferred directly or indirectly by way of dividend, bonus or otherwise by way of distribution of profit to the members, directors or supervisors of the Foundation Company, as such, apart from authorised remuneration for services to the Foundation Company. 9. The liability of the members is limited to the undertaking as set out in clause 11. 10. The Foundation Company may cease to have members. 11. Each person who is a member undertakes to contribute to the assets of the Foundation Company in the event of the Foundation Company being wound up during the time that the person is a member, or within one year afterwards, for payment of the debts and liabilities of the Foundation Company contracted before the time at which the person ceases to be a member, and the cost, charges and expenses of the winding-up of the Foundation Company, and for the adjustments of the rights of the contributories amongst themselves, such amounts as may be required, not exceeding the sum of one United States dollar (US$1.00). 12. If on the winding-up or dissolution of the Foundation Company there remain surplus assets after the satisfaction of its debts and liabilities the same shall be paid or transferred as shall be decided by the Tokenholders, which may include another foundation company or similar entity governed by the Tokenholders. 13. This memorandum and the articles of association may be altered by written consent of a majority of the directors, with notice of such consent provided to the Foundation Company and the Tokenholders (or to the extent required by law, by Special Resolution), except that neither clause 8 nor clause 12 of this memorandum may be altered in any way such that distributions of assets from the Foundation Company are, or will be, made for the benefit of the members or future members of the Foundation Company. Dated this 6th day of December 2023. **THE COMPANIES ACT (AS AMENDED)** **THE FOUNDATION COMPANIES ACT, 2017** **AMENDED AND RESTATED** **ARTICLES OF ASSOCIATION** **of** **JITO FOUNDATION** **A FOUNDATION COMPANY LIMITED BY GUARANTEE WITHOUT SHARE CAPITAL** \*\*(ADOPTED BY DIRECTOR'S RESOLUTION DATED DECEMBER 6 2023) \*\*WALKERS (Cayman) LLP 190 Elgin Avenue, George Town, Grand Cayman, KY1-9001, Cayman Islands T +1 345 949 0100 F +1 345 949 7886 www.walkersglobal.com **Ref: KG/CK/185745** \*\* INTERPRETATION\*\* 14. In these Articles, unless the context requires otherwise: "**Acts**" means the Foundation Companies Act, the Companies Act applicable to foundation companies, and every statutory modification or re-enactment of them; "**Bylaws**" means the Jito Foundation bylaws dated on or around the date hereof (and as may be amended or revised from time to time); "**Cause**" means wilful misconduct or fraud; "**Companies Act**" means the Companies Act (as amended) of the Cayman Islands; "**Foundation Companies Act**" means the Foundation Companies Act, 2017 of the Cayman Islands; “**JIP**” means a Jito Improvement Proposal, which is a proposal put forth by a Tokenholder to a vote in accordance to the JIP Process; "**JIP Process**" means the rules and procedures of submitting and voting on JIPs as described in the Jito Constitution, as may be amended from time to time pursuant to a JIP; “**Jito Constitution**” means the Constitution of the Jito Foundation available at https://jito.network/docs/governance including amendments thereto; "**Memorandum of Association**" means the memorandum of association of the Foundation Company, as amended and substituted from time to time; "**Ordinary Resolution**" means a resolution passed at a general meeting of the Foundation Company by a simple majority of votes cast or by a written resolution in writing under Article 52; "**Special Resolution**"means a resolution passed at a general meeting of the Foundation Company by not less than a two-thirds majority of votes cast or by a resolution in writing under Article 52; "**Tokenholders**" means the holders of the Tokens from time to time as evidenced by the Solana blockchain; "**Tokenholder Vote**" means a vote of the Tokenholders validly proposed and executed in accordance with the voting mechanism set forth in the Bylaws; "**Tokens**"means the JTO tokens represented by the following Solana token mint address jtojtomepa8beP8AuQc6eXt5FriJwfFMwQx2v2f9mCL; and "**written**"and"**in writing**"include all modes of representing or reproducing words in visible form. 2. Except as provided above, words and expressions defined or used in the Acts have the same meaning in these Articles. **PRELIMINARY** 3. The business of the Foundation Company may be commenced immediately upon registration pursuant to the Acts. 4. The Foundation Company may ratify any contract or other transaction entered into in its name or on its behalf prior to registration. 5. The preliminary expenses of incorporating the Foundation Company shall be paid by the Foundation Company, including any expenses concerning any contract or transaction ratified under Article 4. **MEMBERS** 6. The subscriber to the Memorandum of Association was the first member of the Foundation Company (the "**Initial Member**"). 7. The Initial Member's membership of the Foundation Company terminated when the Initial Member resigned as a member by notice to the Foundation Company. 8. It is not a condition of these Articles that the Foundation Company continues to have one or more members.     9. There shall be no subsequent admission of members.  **DIRECTORS** 10. The Foundation Company shall at all times have at least one director. 11. The first director(s) may be appointed by the subscriber(s) to the Memorandum of Association. 12. The Tokenholders have the power, exercisable by Tokenholder Vote, to remove directors in accordance with the JIP Process and the Bylaws. The directors have the power, exercisable by directors’ resolution, to appoint directors. 13. In the event that the Foundation Company has less than two directors, the supervisors have the power to appoint one additional director via a supervisor notice to the Foundation Company. 14. The supervisors have the power to remove directors for Cause via a supervisor notice to the Foundation Company. 15. A person ceases to be a director if removed under the foregoing provisions or: (a) if the person dies or becomes bankrupt or, being a corporation, enters into winding-up or is dissolved; or (b) if the person resigns as a director by notice to the Foundation Company. The resignation shall be effective immediately unless the notice states otherwise. 16. Subject to these Articles and the bylaws (if any), the business and affairs of the Foundation Company shall be managed by or under the control of the directors, who may exercise all the powers of the Foundation Company other than those that are required by these Articles or the Bylaws to be exercised by the Tokenholders, the supervisors or others. 17. The directors may from time to time and at any time by power of attorney (whether under seal or under hand) or otherwise appoint any company, firm or person or body of persons, whether nominated directly or indirectly by the directors, to be the attorney or attorneys or authorised signatory (any such person being an "**Attorney**" or "**Authorised Signatory**", respectively) of the Foundation Company for such purposes and with such powers, authorities and discretion (not exceeding those vested in or exercisable by the directors under these Articles) and for such period and subject to such conditions as they may think fit, and any such power of attorney or other appointment may contain such provisions for the protection and convenience of persons dealing with any such Attorney or Authorised Signatory as the directors may think fit , and may also authorise any such Attorney or Authorised Signatory to delegate all or any of the powers, authorities and discretion vested in them. 18. The directors may from time to time provide for the management of the affairs of the Foundation Company in such manner as they shall think fit and the provisions contained in the three next following articles shall not limit the general powers conferred by this article. 19. The directors from time to time and at any time may establish any committees, local boards or agencies for managing any of the affairs of the Foundation Company and may appoint any person to be a member of any such committees or local boards and may appoint any managers or agents of the Foundation Company and may fix the remuneration of any such person. Any committee so formed shall in the exercise of the powers so delegated pursuant to Article 20 conform to any regulations that may be imposed on it by the written consent of a majority of the directors. 20. The directors from time to time and at any time may delegate to any such committee, local board, manager or agent, including the Tokenholders, any of the powers, authorities and discretions for the time being vested in the directors and may authorise the members for the time being of any such committee, local board, manager or agent to fill any vacancies therein and to act notwithstanding vacancies and any such appointment or delegation may be made on such terms and subject to such conditions as the directors may think fit and the directors may at any time remove any person so appointed and may annul or vary any such delegation, but no person dealing in good faith and without notice of any such annulment or variation shall be affected thereby. 21. The directors may from time to time appoint any person, whether or not a director to hold such office in the Foundation Company as the directors may think necessary for the administration of the Foundation Company, including but not limited to, the office of president, one or more vice-presidents, treasurer, assistant treasurer, manager or controller, and for such term and at such remuneration (whether by way of salary or commission or participation in profits or partly in one way and partly in another), and with such powers and duties as the directors may think fit. Any person so appointed by the directors may be removed by the directors. The directors may also appoint one or more of their number to the office of managing director upon like terms, but any such appointment shall ipso facto terminate if any managing director ceases from any cause to be a director, or if the directors resolve that their tenure of office be terminated. 22. Any such delegates as aforesaid may be authorised by the directors to sub-delegate all or any of the powers, authorities, and discretion for the time being vested in them. 23. The directors shall observe these Articles and the Bylaws, and shall at all times act in the interests of the Foundation Company and its objects. 24. The directors shall give to the supervisor(s) (or the persons who have the right to attend the general meeting) such reports, accounts, information and explanations concerning the business and affairs of the Foundation Company, and the discharge of the directors’ duties and the exercise of their powers, as may be required by: (a) notice from the supervisor(s); or (b) an Ordinary Resolution of the Foundation Company. 25. The duties of the directors are owed to the Foundation Company only. 26. Directors' remuneration shall be at such rates and on such terms as may be agreed by the Directors with consent of the supervisors. 27. A director who is in any way, whether directly or indirectly, interested in a contract or proposed contract with the Foundation Company (the “**Interested Director**”) shall declare the nature of his interest at a meeting of the directors. A general notice given to the directors by any director to the effect that he is to be regarded as interested in any contract or other arrangement which may thereafter be made with that company or firm shall be deemed a sufficient declaration of interest in regard to any contract so made. An Interested Director may not vote in respect of any contract or proposed contract or arrangement that he may be interested therein and if he does so his vote shall not be counted. The Interested Director may be counted in the quorum at any meeting of the directors at which any such contract or proposed contract or arrangement shall come before the meeting for consideration. 28. A director may hold any other office or place of profit under the Foundation Company (other than the office of auditor) in conjunction with his office of director for such period and on such terms (as to remuneration and otherwise) as the directors may determine and no director or intending director shall be disqualified by his office from contracting with the Foundation Company either with regard to his tenure of any such other office or place of profit or as vendor, purchaser or otherwise, nor shall any such contract or arrangement entered into by or on behalf of the Foundation Company in which any director is in any way interested, be liable to be avoided, nor shall any director so contracting or being so interested be liable to account to the Foundation Company for any profit realised by any such contract or arrangement by reason of such director holding that office or of the fiduciary relation thereby established. A director, notwithstanding his interest, may be counted in the quorum present at any meeting of the directors whereat he or any other director is appointed to hold any such office or place of profit under the Foundation Company or whereat the terms of any such appointment are arranged but he may not vote on any such appointment or arrangement. 29. Any director may act by himself or his firm in a professional capacity for the Foundation Company, and he or his firm shall be entitled to remuneration for professional services as if he were not a director; provided that nothing herein contained shall authorise a director or his firm to act as auditor to the Foundation Company. **SUPERVISORS** 30. The first supervisor is FFP (Corporate Services) Limited. 31. The Tokenholders have the power, exercisable by Tokenholder Vote in accordance with the JIP Process and the Bylaws, to appoint or remove Cayman Islands-based supervisors to supervise the management of the Foundation Company,. 32. The Tokenholder Vote appointing a supervisor may: (a) restrict, enlarge or exclude any or all of the voting and other rights or powers of supervisors under these Articles (save in respect of the right to attend and vote at general meetings); (b) impose any supervisory or other duty or disability, grant a related exculpation, and waive conflicting interests or duties; (c) give the supervisor rights to remuneration or indemnity by the Foundation Company; and (d) provide for the termination of the supervisor’s appointment at a specified time or in specified circumstances. 33. A person ceases to be a supervisor: (a) if the person dies or becomes bankrupt or, being a corporation, enters into winding-up or is dissolved; (b) if the person resigns as a supervisor by notice to the Foundation Company. The resignation shall be effective immediately unless the notice states otherwise; (c) if the person becomes a director or acquires any interest or duty that conflicts with any duty of the person as a supervisor, unless authorised by the Directors; (d) as provided in the person’s terms of appointment as a supervisor; or (e) if removed in accordance with these Articles. 34. For such time as the Foundation Company has no members, the Foundation Company is required to have at least one supervisor who is able and willing to supervise the management of the Foundation Company. If this requirement is not met and the Tokenholders by Tokenholder Vote have not appointed a supervisor, the directors shall appoint one or more supervisors, on such terms as they think fit, to make up the shortfall, failing which the directors shall apply to the Court under section 19(2) of the Foundation Companies Act. 35. A supervisor: (a) may require access during normal working hours to the files, books, accounts and records of the Foundation Company; (b) may by notice to the Foundation Company call for such reports, accounts, information and explanations from the directors as to the administration of the Foundation Company as are described in the notice; (c) has the right to receive notice of, and attend and vote at, general meetings; and (d) shall observe these Articles and the Bylaws. 36. The powers granted to a supervisor under these Articles may only be exercised in the interests of the Foundation Company and its objects. 37. Any duties of a supervisor are owed to the Foundation Company only. 38. The remuneration of the supervisor shall be at such rate and on such terms as set out in the Bylaws. **BENEFICIARIES** 39. The Foundation Company shall not have any person(s) designated as beneficiaries. **SECRETARY** 40. The first secretary is FFP (Corporate Services) Limited. 41. The directors have the power, exercisable by directors' resolution, to appoint or remove the secretary or any assistant secretary provided always that there shall at all times be a qualified person as defined under the Foundation Companies Act appointed as the secretary and no secretary shall cease to hold office until a qualified person has been appointed in the secretary's place and the Registrar has been notified. 42. The remuneration of the secretary shall be at such rate and on such terms as agreed in writing by the directors. 43. The secretary shall at all times comply with the requirements of regulatory laws as defined in section 2 of the Companies Act and shall be entitled to receive from the Foundation Company and any interested person such information as the secretary may reasonably require for such compliance. 44. Section 16 of the Foundation Companies Act shall be observed. **GENERAL MEETINGS** 45. The Foundation Company shall hold a general meeting when required to do so in accordance with Article 46. 46. The secretary shall convene a general meeting of the Foundation Company when required to do so by written requisition of: (a) the supervisors; (b) any person who has the right to attend general meetings; or (c) the directors. 47. The persons who have the right to receive notice of, and to attend and have one vote each at, general meetings are: (a) any members; and (b) the supervisors 48. General meetings shall be convened by not less than 21 days' notice (exclusive of the day notice was served) to everyone entitled to attend, unless all persons entitled to attend agree to short notice (or no notice). The notice shall state the place, day and hour of the meeting and the general nature of the business to be transacted. 49. The accidental omission to give notice of a general meeting to any person so entitled or the non-receipt of a notice of a meeting shall not invalidate the proceedings at that meeting. 50. No business shall be transacted at a general meeting unless a quorum is present in person or by proxy when the meeting proceeds to business. The quorum is a majority of the persons entitled to attend and vote. 51. At any general meeting of the Foundation Company, unless the Foundation Companies Act or these Articles otherwise provide, every motion proposed shall be decided by Ordinary Resolution of those present in person or by proxy and entitled to vote. 52. A resolution in writing signed by all persons for the time being entitled to vote at general meetings shall be as valid and effective as if the same had been passed at a general meeting of the Foundation Company duly convened and held. 53. A general meeting may be held, and any person may participate in a meeting, by means of a conference telephone or similar communications equipment by means of which all persons participating in the meeting are capable of hearing each other, and such participation shall be deemed to constitute presence in person at the meeting. **PROXIES** 54. Any person entitled to attend and vote at a general meeting of the Foundation Company mayby written instrument under hand, or if the appointor is a corporation, either under the corporation's seal or under the hand of an officer or attorney duly authorised, appoint a proxy to represent at the general meeting of the Foundation Company. 55. The instrument appointing a proxy may be in any usual or common form or as otherwise acceptable to the chairperson of the meeting for which the instrument is first presented. **DIRECTORS MEETINGS** 56. The directors may meet together (either within or outside the Cayman Islands) for the despatch of business, adjourn, and otherwise regulate their meetings and proceedings as they think fit. Questions arising at any meeting shall be decided by a majority of votes. In case of an equality of votes the chairperson shall have a second or casting vote. A director may, and a secretary or assistant secretary on the requisition of a director shall, at any time summon a meeting of the directors. 57. The directors may elect a chairperson of their meetings and determine the period for which such chairperson is to hold office but if no such chairperson is elected, or if at any meeting the chairperson is not present within fifteen minutes after the time appointed for holding the meeting, the directors present may choose one of their number to be chairperson of the meeting. 58. A director may participate in any meeting of the directors, or of any committee appointed by the directors of which such director is a member, by means of telephone or similar communication equipment by way of which all Persons participating in such meeting can communicate with each other and such participation shall be deemed to constitute presence in person at the meeting. 59. The quorum necessary for the transaction of the business of the directors may be fixed by the directors, and unless so fixed, if there be two or more directors the quorum shall be two, and if there be one director the quorum shall be one. A director represented by an alternate director at any meeting shall be deemed to be present for the purposes of determining whether or not a quorum is present. 60. A resolution in writing signed by all the directors for the time being shall be as valid and effectual as if it had been passed at a meeting of the directors duly convened. When signed a resolution may consist of several documents each signed by one or more of the directors or their duly appointed alternate. **ACCOUNTS** 61. The directors shall cause proper books of account to be kept for: (a) all funds received, expended or distributed by the Foundation Company and the matters in respect of which the receipt or expenditure takes place; and (b) the assets and liabilities of the Foundation Company, and proper books of account shall not be deemed to be kept if there are not kept such books as are necessary to give a true and fair view of the state of the Foundation Company’s affairs and to explain its transactions. Such books shall be kept at the registered office or such other place as may be determined by the directors of the Foundation Company. 62. The books of account shall be open at any time in ordinary business hours to inspection by a supervisor, and any other person to whom a right of access has been granted pursuant to these Articles. 63. By notice to the Foundation Company a supervisor may call for such reports, accounts, information and explanations from the directors as to the administration of the Foundation Company as are described in the notice. **FINANCIAL YEAR END** 64. The financial year of the Foundation Company shall end on 31 December of each year or such other date as the directors may determine. **AUDITORS** 65. The Foundation Company may by directors' resolution at any time appoint or replace an auditor or auditors of the Foundation Company. The remuneration of an auditor shall be fixed by the directors. 66. Every auditor shall have a right of access at all times in ordinary business hours to the books of account of the Foundation Company and shall be entitled to require from the directors and officers of the Foundation Company such information and explanation, and access to vouchers and other documents, as the auditor considers necessary for the performance of the auditor’s duties. **WINDING-UP** 67. The Foundation Company shall be wound-up if approved by Tokenholder Vote. Following approval by Tokenholder Vote, Tokenholders will deliver a notice to the supervisor or to the Foundation Company at its registered office declaring that it is to be wound-up. The person designated in the notice shall be the liquidator, or if no liquidator is so appointed, then the directors or such person as they shall appoint shall be the liquidator. Following the receipt of such notice, the Foundation Company shall be wound-up in accordance with the provisions of the Companies Act. 68. Surplus assets shall be distributed in accordance with clause 12 of the Memorandum of Association. In no event may any surplus assets of the Foundation Company be distributed to any of the members, directors, supervisors or Tokenholders. 69. Members, directors and supervisors as such have no power or authority to wind-up the Foundation Company or petition the Court to wind-up the Foundation Company, except: (a) in the case of insolvency; (b) for the purposes of a *bona fide* reorganisation intended to enable the Foundation Company to carry out its objects more efficiently; or (c) where the Foundation Company has no present Tokenholders. **INDEMNITY** 70. To the fullest extent permitted by law, the directors, members of committees or councils, supervisors, secretary and other officers of the Foundation Company shall not be liable for and shall be indemnified out of the assets of the Foundation Company from and against all actions, proceedings, costs, charges, losses, damages and expenses which they or any of them would otherwise be liable for or shall or may incur or sustain by reason of any act done or omitted in or about the execution of their duties in their respective offices, except such as they shall incur or sustain by or through their dishonesty, wilful default or fraud. **BYLAWS** 71. The directors by directors' resolution may adopt initial bylaws that are not inconsistent with the Acts or the Memorandum of Association and Articles. 72. Bylaws may relate to any aspect of the business or affairs of the Foundation Company, or any of the duties or powers of the directors or their delegates, or others who have duties or powers under these Articles including the manner of achieving the Foundation Company’s objects, the investment, management and protection of the Foundation Company’s assets, the remuneration of directors and their delegates, the delegation of the directors’ duties and powers, the supervision of the management of the Foundation Company, and the appointment of advisers, council members and other service-providers. 73. The Bylaws may be varied or revoked by the directors by directors' resolution provided that the Bylaws shall not be amended so as to amend or remove the rights of the Tokenholders, unless such amendment has been approved by the Tokenholders in accordance with the RDIP Process. 74. The adoption or variation of Bylaws shall not render any director or other person liable for prior conduct. 75. No third party dealing in good faith with the Foundation Company need be concerned with the Bylaws or their observance. **ALTERATION OF ARTICLES** 76. Subject to provisions of the Memorandum of Association and Articles restricting alterations, in particular Article 77, these Articles may be altered by Tokenholder Vote by notice to the Foundation Company (or to the extent required by law, by Special Resolution). 77. The Memorandum of Association and/or the Articles shall not be amended so as to modify the rights, powers or duties of the supervisor without the prior written consent of such supervisor, nor shall either be amended to remove or otherwise alter the rights or powers conferred on Tokenholders unless such amendment has been approved by Tokenholder Vote, provided that if a Tokenholder Vote cannot be held within 90 days following notice to the Foundation Company and the Tokenholders, then such amendment may take effect upon the consent of the supervisor. --- # Realms Interface Guide The Jito DAO operates primarily through two venues: the Forum for discussion and ideation of proposals, and the Realms portal for voting and execution of proposals.  In order to access the Realms portal, visit gov.jito.network. Because the Jito DAO leverages an individual Realms program, it cannot be found by searching for the DAO on the Realms homepage.  **Voting** To participate in governance, begin by connecting your wallet.  ![realms1](https://www.jito.network/omnidocs/governance/images/pasted_image_0.png) Once your wallet is connected, click “view” under “my governance power.”  ![pasted image 0 (1)](https://www.jito.network/omnidocs/governance/images/pasted_image_0_1.png) Here, you can deposit JTO governance tokens to the DAO. This will grant you token voting power, enabling you to vote on proposals. ![pasted image 0 (2)](https://www.jito.network/omnidocs/governance/images/pasted_image_0_2.png) Alternatively, you can delegate your token voting power. This allows you to retain custody of your tokens, but enables a delegate you select to use your tokens to influence governance. To do this, simply copy-paste your chosen delegate address from the forum, and approve the transaction.  ![pasted image 0 (3)](https://www.jito.network/omnidocs/governance/images/pasted_image_0_3.png) The Forum has a list of delegation candidates with a questionnaire giving you insight into their views.  You can also view a tutorial here: [https://twitter.com/Realms_DAOs/status/1757344471170064567](https://twitter.com/Realms_DAOs/status/1757344471170064567) --- # Jito Foundation Actions **Jito Foundation Delegation** On January 24th, the Jito Foundation put out a [public call](https://www.jito.network/blog/community-call-for-jito-dao-delegates/) for delegates to address the DAO’s inability to achieve quorum. At the time, 180 users had deposited 100,000 JTO in voting power to the DAO – well short of the 30m quorum limit While initial communications indicated that the Foundation would delegate 5 million JTO in token voting power, this figure was later adjusted to 12 million to better address quorum requirements.  The Foundation delegated a total of 12 million JTO in token voting power to 17 individuals and entities, with each receiving the equivalent of 705,882.35294 in voting power. This delegation was made from a Squads account which can be found here: [https://app.squads.so/squads/7SK8JMBUdStZdGVZGKaRmMV3zSaUUZ6YekuYAyWZY3hy](https://app.squads.so/squads/7SK8JMBUdStZdGVZGKaRmMV3zSaUUZ6YekuYAyWZY3hy).   The full list of delegates can be found here:  - Felix Lutsch - Community - MultichainMike - EmpireDAO - Andrew Allen- Coinbase Cloud - 0xjaypeg - Community - Ben Hawkins - Solana Foundation - Michael Hubbard - Laine - Ian Unsworth - Community - 7Layer - Overclock - Flipside Ecosystem Growth & Innovation team - Juanbug - PGov - Mark Hull - Kamino - Blockworks Research - Gauntlet - 0xNallok - Lode Ventures - Douro Labs - Chainflow - Joebuild - Community As governance participation increases, delegation parameters and selections may be adjusted periodically.  **Quorum modification** In tandem with the Jito Foundation delegation, the Jito Security Council voted to change the DAO’s quorum limit from 30 million tokens to 10 million.  Quorum was initially set at a high bar to protect the DAO’s treasury assets after the token generation event. However, with a circulating supply of just over 110 million, it was improbable that the DAO would be able to achieve quorum, leading the Council to lower the limit.  While the Council initially intended to change quorum to 3 million, Realms requires that quorum be set at a full-digit percentage of token supply, meaning 10 million is the lowest possible setting.  As the circulating supply of JTO increases and governance becomes more active, the Security Council may consider adjusting quorum in the future.  **** **Liquidity mining ** The Jito Foundation has launched a number of small-scale liquidity mining programs. These programs have tended to last a month or less, and have focused on growing liquidity for JTO, expanding the use of JitoSOL pairs (especially for newly-launched products), and encouraging JitoSOL usage in new products and markets.  You can find a full list of programs launched below: 

Project

Pool Split

Amount In JTO

To

Destination Pool

Date Sent

Date Start

Date Ends

Notes

Raydium

JTO/SOL

80000

NCV2Uo3hfW5LSZXAJe19y6SpC5K98PuQwShCSZgTki3

JVoPtWWDsRcLvQosu5fWc2CaNF6jEtJzbxdPtcEuvZo

12/07/2023

12/07/2023

12/14/2023

Raydium

JTO/SOL

5000

NCV2Uo3hfW5LSZXAJe19y6SpC5K98PuQwShCSZgTki3

JVoPtWWDsRcLvQosu5fWc2CaNF6jEtJzbxdPtcEuvZo

12/15/2023

12/14/2023

12/21/2023

Tapered incentives for second weeks

Orca

JTO/USDC

80000

93MjUKNKxazKmgS3GBX2Gj2BttEjJUyi7NYeyDHdHSc2

93MjUKNKxazKmgS3GBX2Gj2BttEjJUyi7NYeyDHdHSc2

12/07/2023

12/07/2023

12/14/2023

Orca

JTO/USDC

5000

93MjUKNKxazKmgS3GBX2Gj2BttEjJUyi7NYeyDHdHSc2

93MjUKNKxazKmgS3GBX2Gj2BttEjJUyi7NYeyDHdHSc2

12/15/2023

12/14/2023

12/21/2023

Tapered incentives for second weeks

Kamino

JitoSOL/JTO

245000

5TBk9eYiageouQ575xU4RENwnxGjJgEQ7UBy6J91WKYE

8DRToyNBUTR4MxqkKAP49s9z1JhotQWy3rMQKEw1HHdu

12/07/2023

12/07/2023

01/07/2025

Initial 600k allocation -- not all paid out

Kamino

JitoSOL/JTO

50000

5TBk9eYiageouQ575xU4RENwnxGjJgEQ7UBy6J91WKYE

8DRToyNBUTR4MxqkKAP49s9z1JhotQWy3rMQKEw1HHdu

12/07/2023

02/06/2024

03/06/2024

Kamino

JitoSOL/SOL

300000

5TBk9eYiageouQ575xU4RENwnxGjJgEQ7UBy6J91WKYE

HCntzqDU5wXSWjwgLQP5hqh3kLHRYizKtPErvSCyggXd

12/07/2023 and 12/15/2023

12/06/2023

03/06/2024

Kamino

JitoSOL/JUP

20000

5TBk9eYiageouQ575xU4RENwnxGjJgEQ7UBy6J91WKYE

4dPX2rrJgSEeB7sLrM9SdTE9PWzfeMe8Ky5YCfqQCwMD

12/07/2023

02/01/2024

03/01/2024

Meteora

JitoSOL/JUP

20000

JADaUV8kvDpDbJr55wxXJHVaBS3VCj8thZZHjfeuCVLd

2QrWsSWrGvoAqkDC5XSGqjS752RWLaopqAaGrbugSxBL

01/29/2024

02/01/2024

03/01/2024

The Foundation liquidity mining address can be monitored here: [https://app.squads.so/squads/8sjM83a4u2M8YZYshLGKzYxh1VHFfbgtaytwaoEg4bUJ/transactions](https://app.squads.so/squads/8sjM83a4u2M8YZYshLGKzYxh1VHFfbgtaytwaoEg4bUJ/transactions)  **** **Transparency Reports** The Jito Foundation publishes quarterly Transparency Reports to give the DAO community insight into the Foundation’s financial status. You can find these reports below:  [DEC 2023](https://drive.google.com/file/d/15Xh2I8J6sGDNq_Aqtjk0mll-6KmFkD7B/view?usp=sharing) --- # The Jito Governance Token (JTO) JTO is the governance token of the Jito Network, enabling community members to have a direct impact on the protocol's decision-making and future direction. Through JTO, token holders participate in the Jito DAO, which oversees crucial aspects of the network including protocol upgrades, parameter adjustments, and treasury management. Jito's growth within the Solana ecosystem has been substantial. JitoSOL is the largest Liquid Staking Token (LST) on Solana, boasting a Total Value Locked (TVL) of 14m SOL (as of November 2024), while the Jito MEV network of validators running the Jito-Solana client operates over 90% of network-stake weight (as of November 2024) . This article aims to offer a comprehensive understanding of the utility and role of the JTO tokens in governance of the Jito Network. ## **Governance ** JTO enables token holders to make key decisions to shape the future of the Jito Network so that it continues to evolve and thrive in alignment with the needs of those it serves, and of the broader Solana ecosystem. These decisions and initiatives may include: - Setting fees of the JitoSOL stake pool and Jito (Re)staking network. - Updating delegation strategies by controlling parameters of the [StakeNet](https://www.jito.network/blog/a-deep-dive-into-stakenet/) programs - Managing parameters for the Jito TipRouter node consensus network - Managing the [treasury](https://gov.jito.network/dao/Jito/treasury/v2) of JTO tokens held by the DAO and fees generated from JitoSOL and restaking (denominated in JitoSOL) - Contributing to the ongoing development and improvement of Jito’s protocols and products The Jito Foundation is excited for token holders to continue to lead Jito’s growth as they engage in the governance process to steer the direction of theJito Network. ## **Jito Foundation** The Jito Foundation organizes and coordinates decisions from the token holder community. Its mission is aligned with that of the Jito Network:  - Enhance the staking economy through JitoSOL and associated products - Improve the Solana network The Foundation structure amplifies the power of the Jito Network. Token holder decisions will seamlessly transfer from DAO governance to off-chain infrastructure and relationships with strategic contributors (given that many strategic contributors require a counterparty to enter into agreements). The Foundation empowers the Jito Network to operate at greater scale and speed as the network evolves. 10% of the total supply was airdropped and 24.3% was transferred to Realms DAO that is controlled directly by token holders. The remaining 25% was allocated to the Jito Foundation to fund these efforts and lead large-scale strategic relationships. The Foundation is led by two independent Directors (Matt Shaw and Glenn Kennedy), with an independent Supervisor provided by FFP Corporate Services. The Foundation’s DAO administrator is [Webslinger](https://www.webslinger.io/), an advisory firm for leading crypto projects. Token holders have ultimate control over the Foundation with the ability to remove the Supervisor and Directors. Transparency reports are provided on a regular basis by the Foundation. Jito Foundation is governed by its [Constitution](https://www.jito.network/docs/governance/overview/), [Bylaws](https://www.jito.network/docs/governance/bylaws-of-the-jito-foundation/) and [Articles of Association and Memorandum of Association](https://www.jito.network/docs/governance/amended-and-restated-memorandum-of-association/). ## **Allocation Details** The Jito token (JTO) has  a total supply of 1,000,000,000 JTO with the initial circulating supply and float listed below: ![Token Specification and Distribution Summary](https://www.jito.network/omnidocs/governance/images/Token_Specification_and_Distribution_Summary_Chart.png) Jito tokens (JTO) were allocated across the following main categories: ![Token Allocation](https://www.jito.network/omnidocs/governance/images/FINAL_Granular_pie_chart_1.png) ### **Community Growth** 34.3% – 342,857,143 JTO The “Community Growth” token allocation is dedicated to growing the Jito community. The first use was a retrospective airdrop for 10% of total supply to Jito community members as a recognition of their contribution in bootstrapping the network and to facilitate robust governance participation (see additional details below). The remaining tokens (24.3% of the total supply) are controlled by DAO governance on the [Realms platform](https://gov.jito.network/dao/Jito). The use and pace of distribution for these tokens is up to token holder governance. The goal is growing Jito Network’s community and utility. ### **More On The Airdrop** 10% – 100,000,000  The airdrop by the Cayman Foundation consists of 90,000,000 JTO tokens for immediate distribution and an additional 10,000,000 unlocking over the next year, each of which will come from the 342,857,143 tokens allocated to Community Growth. The eligibility for the JTO token airdrop had been determined by a user's contribution to the Jito Network's development and growth over time. This included long-standing JitoSOL holders, users engaging with JitoSOL on various DeFi protocols, Solana validators operating the Jito-Solana MEV client, and searchers actively utilizing Jito Network’s MEV products. The airdrop was backwards-looking and the snapshot for eligible activity was taken on November 25th, 2023.  ### **Ecosystem Development** 25% – 250,000,000 Jito’s network has had a strong start, but the mission to enhance the Solana network and staking economy is far from over. The ecosystem development portion of the token allocation is to fund communities and contributors that help drive the expansion of the premier liquid staking protocol on Solana and related network advancements, such as the innovative StakeNet. StakeNet is designed as a self-sustaining protocol for timeless Solana LSTs, which the Foundation has open-sourced for other platforms to use.  For further details, please see the section on Jito Foundation prior to the distribution section. ### **Investors** 16.2% – 162,142,857 Jito Labs has been fortunate to have the support of prominent investors in the Solana community since its genesis. Their expertise and strategic guidance have been instrumental in the Network’s growth and development since its launch. The tokens allocated to investors unlock over 3 years, with a 1-year cliff. ![investors schedule](https://www.jito.network/omnidocs/governance/images/FINAL_Investors_Supply.png) ### **Core Contributors** 24.5% – 245,000,000 A portion of JTO tokens was allocated to Jito’s founders and current and future employees of early contributors to the ecosystem. These tokens vest and unlock over 3 years, with a 1-year cliff. ![core contributors](https://www.jito.network/omnidocs/governance/images/FINAL_Core_Contributors_Supply.png) ### **Supply** The chart below shows how the circulating supply of JTO tokens will evolve over time: ![circulating supply](https://www.jito.network/omnidocs/governance/images/FINAL_Supply_Schedule.png) ** *Note: the evolution of the JTO circulating supply over time is subject to change as the community makes future decisions on the use of funds and pace of disbursements.* --- Keep up with the latest from Jito Network! For more insights and conversations, join our [Telegram](https://t.me/+csIgnEQMCHhiYjVh), follow us on [X](https://twitter.com/jito_sol), and check out the [blog](https://www.jito.network/blog/) for ongoing updates and product information. --- # Introduction to Stakenet Jito StakeNet is a decentralized Solana stake pool manager, blending Validator History and Steward Programs for secure, transparent validator management and autonomous stake operations. ## Jito Steward Program The Steward Program is an Anchor program designed to manage the staking authority for a SPL Stake Pool. Using on-chain [validator history](https://www.jito.network/docs/stakenet/validator-history/program-overview.md) the steward selects a set of high-performing validators to delegate to, maintains the desired level of stake on those validators over time, and continuously monitors and re-evaluates the validator set at a set cadence. Initially, the validator selection is customized for the JitoSOL stake pool criteria and will be deployed to manage that stake pool. Additionally, the steward surfaces this staking algorithm through variable parameters to be decided by [Jito DAO](https://gov.jito.network/dao/Jito). In turn, this greatly decentralizes the stake pool operations. The core operations of the Steward Program are permissionless such that any cranker can operate the system. However there are some admin abilities that allow for tweaking parameters and system maintenance. ### Table of Contents 1. [Program Overview](https://www.jito.network/docs/stakenet/jito-steward/program-overview.md) 2. [Parameters](https://www.jito.network/docs/stakenet/jito-steward/parameters.md) 3. [StakeNet UI](https://www.jito.network/docs/stakenet/jito-steward/ui.md) (work in progress) 4. Developers - [Steward CLI Guide](https://www.jito.network/docs/stakenet/jito-steward/developers/cli.md) - [Events API](https://www.jito.network/docs/stakenet/jito-steward/developers/api.md) - [Running a Keeper](https://www.jito.network/docs/stakenet/jito-steward/developers/keeper-bot-quick-start.md) 5. Advanced Concepts - [SPL Stake Pool Internals](https://www.jito.network/docs/stakenet/jito-steward/advanced/spl-stake-pool-internals.md) - [Validator States](https://www.jito.network/docs/stakenet/jito-steward/advanced/managing-validator-states.md) 6. [Validator FAQ](https://www.jito.network/docs/stakenet/jito-steward/faq.md) (work in progress) ## Validator History Program This program can store three years of history for every validator on the network. This data currently includes vote credits, commission, MEV commission, validator version, client type, and can be expanded in the future. By providing a transparent and cryptographically verified record of past actions, it becomes possible both for users and on-chain programs to make informed decisions about validator behavior. ### Table of Contents 1. [Program Overview](https://www.jito.network/docs/stakenet/validator-history/program-overview.md) 2. [Key Features & Capabilities](https://www.jito.network/docs/stakenet/validator-history/key-features.md) 3. [Technical Architecture](https://www.jito.network/docs/stakenet/validator-history/technical-architecture.md) 4. [Data Fields Explained](https://www.jito.network/docs/stakenet/validator-history/data-fields.md) 5. [Integration & Composability](https://www.jito.network/docs/stakenet/validator-history/integration.md) 6. [Developers](https://www.jito.network/docs/stakenet/validator-history/developers/api.md) - [Validator History CLI Guide](https://www.jito.network/docs/stakenet/validator-history/developers/cli.md) --- # StakeNet Terminology **Steward Program**: An Anchor program designed to manage the staking authority for a SPL Stake Pool, selecting and managing validators based on performance metrics. **SPL Stake Pool**: A Solana program that allows for the creation of stake pools, enabling users to delegate their stake to multiple validators through a single pool and receive a Liquid Staking Token (LST) representing their stake. **Validator History Program**: A Solana program that maintains historical performance data for validators. It records and stores various metrics over time on-chain. **Delegation**: The amount of stake targeted to a specific validator by the Steward Program. **State Machine**: The core logic of the Steward Program that manages different operational states and transitions between them. **Cycle**: A period of time (currently 10 epochs) in the Steward Program during which validators are selected and delegations are managed. The scores and validator selections are fixed for the duration of a cycle. **Validator Score**: The final score used for delegation eligibility, calculated by multiplying the raw_score by all binary eligibility filters. If any binary criterion fails (returns 0), the validator score becomes 0, making the validator ineligible for delegation. **Raw Score**: A 4-tier hierarchical score (64-bit encoded) that ranks validators based on: (1) inflation commission, (2) MEV commission, (3) validator age, and (4) vote credits performance. This score is calculated before binary eligibility filters are applied and is used for determining unstaking priority and ranking validators. **Rebalancing**: The process of adjusting stake allocations among validators to maintain desired proportions or react to performance changes. **Instant Unstaking**: A process that allows for immediate removal of staked SOL under certain conditions from a validator, bypassing usual rebalancing. **Blacklist**: A list of validators that are excluded from receiving delegations through the Steward Program. **Delinquency**: A state where a validator is not its duties adequately, often measured by missed vote opportunities. In the context of the Steward Program, this is measured by voting less than a specific threshold in a given epoch. **Epoch Credits**: A measure of a validator's performance, representing the number of times it has correctly voted on blocks in a given epoch. Directly impacts validator staking rewards. Also known as Vote Credits. **Commission**: The percentage of rewards that a validator keeps for itself before distributing the remainder to its delegators. **Superminority**: The highest-staked validators in the network who collectively hold more than 33.3% of the stake. --- # StakeNet Governance ## JIP-33 JIP-33 proposes a strategic partnership between Jito Network and Coinbase to integrate JitoSOL into Coinbase's product ecosystem. Key components include mint/burn functionality for SOL-to-JitoSOL conversion in the Coinbase app, USD loan products against JitoSOL collateral, JitoSOL availability on the Base network, and directed stake to Coinbase-operated validators under the JIP-27 framework. Coinbase validators would run the BAM client with relaxed commission restrictions (5% on rewards, 10% on tips). Proposal: [JIP-33 Forum Post](https://forum.jito.network/t/jip-33-a-jito-x-coinbase-collaboration/923) --- ## JIP-28 JIP-28 proposes accelerating BAM (Block Assembly Marketplace) adoption by allocating JitoSOL stake to validators running BAM software. It introduces a tiered delegation schedule that increases BAM stake allocations as network adoption grows, ultimately transitioning to 100% BAM stake once full adoption is reached. This proposal motivated the introduction of the `running_bam_score` binary eligibility criterion in the Steward program. Proposal: [JIP-28 Forum Post](https://forum.jito.network/t/jip-28-accelerate-bam-adoption/904) --- ## JIP-27 JIP-27 introduces directed staking to the JitoSOL stake pool, allowing large JitoSOL holders (initially ≥100k JitoSOL) and whitelisted DeFi protocols to direct their stake to specific validators of their choice. Validators must meet objective eligibility criteria to qualify for directed stake. A protective floor ensures a minimum amount of SOL remains in non-directed, permissionless delegation. Proposal: [JIP-27 Forum Post](https://forum.jito.network/t/jip-27-introduce-directed-staking-to-the-jito-stake-pool/903) --- ## JIP-25 JIP-25 expands and reforms the JitoSOL validator delegation system. Key changes include: expanding the active validator set from 200 to 400, revising the ranking criteria to prioritize commission rate, MEV commission, and validator age (with vote credits as a final tiebreaker), extending the MEV commission reference period from 10 to 30 epochs to reduce gaming, and pausing the priority fee sharing implementation from JIP-16. Proposal: [JIP-25 Forum Post](https://forum.jito.network/t/jip-25-expand-the-validator-set-and-modify-jito-stake-pool-eligibility-and-ranking-criteria/877) --- ## JIP-16 JIP-16 upgrades TipRouter to distribute Solana priority fees (in addition to MEV tips) and adjusts StakeNet to factor in priority fee sharing as a delegation eligibility criterion. It introduces Tip Distribution Account v2 (TDA v2) to handle priority fee collection and distribution, and requires validators to share at least 50% of priority fees to qualify for JitoSOL delegation. The DAO receives 1.5% of distributed priority fees. Proposal: [JIP-16 Forum Post](https://forum.jito.network/t/jip-16-tiprouter-and-stakenet-adjustments-for-priority-fees/640) --- ## JIP-3 JitoSOL was transitioned to management by StakeNet via the JIP-3 proposal. This proposal includes information on the motivation, transition plan, costs, and community discussion. Proposal: [JIP-3 Forum Post](https://forum.jito.network/t/jip-3-transfer-of-jito-stake-pool-management-to-stakenet-protocol-development/309) DAO Vote: [JIP-3 Realms](https://gov.jito.network/dao/Jito/proposal/CTaYLKaPw7gexrjp8gi2aDkG8QJuWzqz6LrySCJoRhyt) --- # Program Overview # Program Overview The Steward Program's main functions include: 1. **Validator Selection and Management**: The program selects validators, monitors their performance, and adjusts stake allocations to maintain optimal performance. 2. **[State Machine](#state-machine)**: A state machine representing the progress throughout a cycle (10-epoch period) for scoring and delegations. 3. **[Adding and Removing Validators](#validator-management)**: Automatically handles the addition and removal of validators based on predefined criteria. 4. **[Admin Abilities](#admin-abilities)**: Allows administrators to update parameters, manage a blacklist, pause/unpause the state machine, and execute passthrough instructions for SPL Stake Pool. ## State Machine The state machine represents the progress throughout a cycle (10-epoch period for scoring and delegations). ### Compute Scores At the start of a 10 epoch cycle ("the cycle"), all validators are scored. The scoring system uses a 4-tier hierarchical ranking combined with binary eligibility criteria. #### Binary Eligibility Criteria All validators must meet the following binary criteria to be eligible for delegation (each is scored as 1.0 if passing, 0.0 if failing): - `mev_commission_score`: If max MEV commission in `mev_commission_range` epochs is less than or equal to threshold, score is 1.0, else 0.0 - `commission_score`: If max commission in `commission_range` epochs is less than or equal to threshold, score is 1.0, else 0.0 - `historical_commission_score`: If any commission within the validator's entire history exceeds the `historical_commission_threshold`, score is 0.0, else 1.0. This effectively bans validators who have performed commission manipulation. - `blacklisted_score`: If validator is blacklisted, score is 0.0, else 1.0 - `superminority_score`: If validator is not in the superminority (top 33.3% by stake), score is 1.0, else 0.0 - `delinquency_score`: If delinquency is not greater than threshold in any epoch within `epoch_credits_range`, score is 1.0, else 0.0 - `running_bam_score`: If validator has been connected to BAM for at least `jito_bam_minimum_epochs` out of the last `jito_bam_window_epochs` epochs, score is 1.0, else 0.0. Epochs with missing BAM data reduce the effective threshold rather than counting as disconnected. - `merkle_root_upload_authority_score`: If validator is using an acceptable Tip Distribution merkle root upload authority (TipRouter or OldJito), score is 1.0, else 0.0 - `priority_fee_commission_score`: If validator's average realized priority fee commission is less than or equal to threshold, score is 1.0, else 0.0 - `priority_fee_merkle_root_upload_authority_score`: If validator is using an acceptable priority fee merkle root upload authority, score is 1.0, else 0.0 > Note: All data comes from the `ValidatorHistory` account for each validator. #### 4-Tier Hierarchical Ranking Validators that pass all binary criteria are ranked using a 4-tier hierarchical scoring system encoded as a 64-bit value: 1. **Inflation Commission** (Tier 1 - Highest Priority, bits 56-63): Lower validator commission is always preferred. This tier uses the maximum commission observed in the `commission_range`, inverted so lower commission = higher score. 2. **MEV Commission** (Tier 2, bits 42-55): Among validators with equal inflation commission, lower MEV commission is preferred. This tier uses the average MEV commission over `mev_commission_range` epochs, inverted so lower commission = higher score. 3. **Validator Age** (Tier 3, bits 25-41): Among validators equal on commissions, older validators (more epochs with non-zero vote credits) are preferred. This rewards validator longevity and reliability. 4. **Vote Credits Ratio** (Tier 4 - Lowest Priority, bits 0-24): Among validators equal on all above tiers, higher performance (vote credits relative to total blocks) is preferred. The 4-tier score ensures that differences in higher-priority tiers always dominate lower-priority tiers. For example, a validator with 1% commission will always rank higher than one with 2% commission, regardless of their MEV commission, age, or performance. #### Final Score Calculation The final score is calculated by multiplying the 4-tier raw score by all binary eligibility factors: ```rust // Calculate 4-tier raw score (encoded as u64) let raw_score = encode_validator_score( commission_max, // Tier 1: Max commission (0-100) mev_commission_avg, // Tier 2: Avg MEV commission (0-10000 bps) validator_age, // Tier 3: Age in epochs vote_credits_avg // Tier 4: Normalized vote credits ); // Apply binary filters let score = raw_score * mev_commission_score * commission_score * historical_commission_score * blacklisted_score * superminority_score * delinquency_score * running_bam_score * merkle_root_upload_authority_score * priority_fee_commission_score * priority_fee_merkle_root_upload_authority_score; ``` If any binary criterion fails (score = 0), the final score becomes zero, making the validator ineligible for delegation. This ensures all validators in the pool meet essential requirements for decentralization, network health, operator quality, and MEV/priority fee sharing. The hierarchical ranking ensures that validators are compared fairly across multiple dimensions, with the most important factors (commissions) taking precedence over secondary factors (age, performance). This creates strong incentives for validators to maintain low commissions while rewarding longevity and performance as tiebreakers. For a detailed breakdown of the formulas used for each score component, see the [Scoring System](https://www.jito.network/docs/stakenet/jito-steward/validators/scoring-system.md) page. Take a look at the implementation in [score.rs](https://github.com/jito-foundation/stakenet/blob/master/programs/steward/src/score.rs) ### Compute Delegations Once all the validators are scored, we need to calculate the stake distribution we will be aiming for during this cycle. The top validators by overall score will become our validator set (the number is configurable via the `num_delegation_validators` parameter, currently set to 400). Each selected validator receives an equal share of the pool (1/400th when 400 validators are selected). If there are fewer eligible validators (having a non-zero score) than the target number, all eligible validators are included in the delegation set. At the end of this step, we have a list of target delegations, representing proportions of the share of the pool, not fixed lamport amounts. ### Idle Once the delegation amounts are set, the Steward waits until we’ve reached the 95% point of the epoch to run the next step. ### Compute Instant Unstake All validators are checked for a set of Instant Unstaking criteria, like commission rugs, delinquency, etc. If they hit the criteria, they are marked for the rest of the cycle. The following criteria are used to determine if a validator should be instantly unstaked: - `delinquency_check`: Checks if validator has missed > `instant_unstake_delinquency_threshold_ratio` of votes this epoch - `commission_check`: Checks if validator has increased commission > `commission_threshold` - `mev_commission_check`: Checks if validator has increased MEV commission > `mev_commission_bps_threshold` - `is_blacklisted`: Checks if validator was added to blacklist blacklisted If any of these criteria are true, we mark the validator for instant unstaking: ```rust let instant_unstake = delinquency_check || commission_check || mev_commission_check || is_blacklisted; ``` Take a look at the implementation in [score.rs](https://github.com/jito-foundation/stakenet/blob/master/programs/steward/src/score.rs#L474) ### Rebalance One instruction is called for each validator, to increase or decrease stake if a validator is not at the target delegation. For each validator, we first check if the target balance is greater or less than the current balance. If the target is less, we attempt to undelegate stake: When undelegating stake, we want to protect against massive unstaking events due to bugs or network anomalies, to preserve yield. There are two considerations with this: There are 3 main reasons we may want to unstake. We want to identify when each of these cases happen, and let some amount of unstaking happen for each case throughout a cycle. - the pool is out of line with the ideal validator set (top N validators by score, configurable) and should be rebalanced, - a validator is marked for instant unstake, or - a validator gets a stake deposit putting it far above the target delegation. We want to run the rebalance step in parallel across all validators, meaning these instructions can be run in any order, but we need to have some notion of the unstaking priority/ordering so the worst validators can be unstaked before the cap is hit. Pre-calculating the balance changes is difficult since balances can change at any time due to user stake deposits and withdrawals, and the total lamports of the pool can change at any time. To address 1: we set a cap for each unstake condition, and track the amount unstaked for that condition per cycle. (scoring_unstake_cap, instant_unstake_cap, stake_deposit_unstake_cap) To address 2: in each instruction, we calculate how much this validator is able to be unstaked in real-time, based on the current balances of all validators, unstaking caps, and which validators would be "ahead" in priority for unstaking before caps are hit. (Lower raw_score = higher unstaking priority). If all the "worse" validators will be unstaked and hit the caps before this one can, no unstaking is done on this validator. For each validator, its active stake balance in lamports is then saved. In the next epoch, any lamports above this can be assumed to be a stake deposit, and can be unstaked. If the target is greater, we attempt to delegate stake: In a similar vein to unstaking, we want to be able to customize the priority of staking so that instructions can be run in any order, but stake is going to better validators given a limited pool reserve. We calculate how much this validator is able to be staked in real time, given the number of validators “ahead” in priority (based on overall score). If all validators who need stake are able to be filled and there is still stake left over in the reserve, this validator gets the stake it needs, either up to the target or until the reserve is empty, whichever is first. If stake was delegated, the balance is updated. Note that because of the 1-epoch delay in cooling down stake that’s unstaked from validators, there will be many instances where the reserve won’t have enough balance to match the stake needs for everyone, but the following epoch, it will (assuming no withdrawals). If we are already at the target, nothing happens. Progress is marked so this validator won’t be adjusted again this epoch. After all validators’ progress is marked “true”, we transition to idle. ### Rest of the cycle After unstaking is done, the state machine moves back into Idle. In next epoch and in the rest of the epochs for the cycle, it repeats these steps: - Compute Instant Unstake - Rebalance - Idle At the start of the next cycle, we move back to Compute Scores, and all those pieces of state are reset to 0. ### Diagram [View in Figma](https://www.figma.com/board/zBcpTOu1zqKIoEnd54sWqH/Steward-Program?node-id=0-1&t=1FK9C2TtNvFEfOU6-1) ![State Machine Diagram](https://www.jito.network/omnidocs/stakenet/images/state-machine-diagram.png) ## Validator Management ### Adding Validators The JitoSOL pool aims to have as many active validators as possible in the pool, meaning they are able to get scored and considered for delegation. This does NOT mean they are guaranteed stake (see the State Machine section above for how validators receive stake). Validators are added permissionlessly if they meet the following criteria: - At least 5 epochs of voting. - Minimum SOL stake of 5000. There are approximately 1300 validators that meet these criteria today, with a capacity for 5000 validators. ### Removing Validators Validators are removed if: - The validator’s vote account closes. - The validator stops voting for 5 epochs, leading to the deactivation of the stake account in the stake pool. ## Admin Abilities There are 3 authorities. `blacklist_authority`, `parameters_authority`, and `admin`. `blacklist_authority` is used to add/remove validators to/from the blacklist to prevent delegation. `parameters_authority` is used to update the parameters, which affects scoring and delegation. `admin` is used for all other perimissioned actions, including updating authorities, pausing the state machine, and executing passthrough instructions for SPL Stake Pool that require the staker as a signer. --- # Validator States # Validator States [Explanation of different validator states and how Steward manages them, in progress...] --- # SPL Stake Pool Internals # SPL Stake Pool: Overview The [SPL Stake Pool program](https://github.com/solana-program/stake-pool) allows users to delegate stake to multiple validators while maintaining liquidity through pool tokens. Thorough documentation of the SPL Stake Pool program can be found [here](https://www.solana-program.com/docs/stake-pool). This is meant to be a quick primer, and the Advanced Concepts section contains nuances relevant to the Steward program. ## Key Accounts 1. **Stake Pool**: Main account holding pool configuration and metadata. 2. **Validator List**: Stores information about all validators in the pool. 3. **Reserve Stake**: Holds undelegated stake for the pool. 4. **Validator Stake Accounts**: Individual stake accounts for each validator. 5. **Transient Stake Accounts**: Temporary accounts used for stake adjustments. 6. **Pool Token Mint**: Mint for the pool's liquidity tokens. ## Authorities 1. **Manager**: Controls pool configuration and fees. 2. **Staker**: Manages validator set and stake distribution. 3. **Withdraw Authority**: Program-derived authority for the pool's stake accounts. 4. **Deposit Authority** (optional): Controls stake deposits into the pool. ## Stake Flow - **Deposit**: Users deposit SOL or existing stake accounts, receiving pool tokens in return. - **Withdrawal**: Users burn pool tokens to withdraw SOL or activated stake accounts. ## Validator Management - **Addition**: Staker adds new validators, creating associated stake accounts. - **Removal**: 1. Staker initiates removal, deactivating the validator's stake. 2. Over subsequent epochs, deactivated stake is merged into the reserve. 3. Validator is removed from the list once all associated stake is reclaimed. ## Epoch Update Process 1. **Update Validator List Balances**: - Merges transient stakes with validator stakes or reserve. - Updates stake balances for each validator. 2. **Update Stake Pool Balance**: - Calculates total pool value. - Applies and distributes fees. 3. **Cleanup Removed Validator Entries**: - Removes fully deactivated validators from the list. ## Interaction with Stake Program The pool uses Solana's Stake program for core staking operations: - Creating and closing stake accounts - Delegating, activating, and deactivating stakes - Splitting and merging stakes - Withdrawing from stake accounts These operations are performed via Cross-Program Invocation (CPI) calls from the Stake Pool program to the Stake program. --- # SPL Stake Pool: Advanced Concepts ## Minimum Lamport Balances Stake accounts in the pool must maintain minimum balances that cover rent and stake minimums: 1. **Rent-Exempt Reserve**: Every stake account must have enough lamports to be rent-exempt (2282880 lamports). 2. **Minimum Delegation**: Solana enforces a minimum delegation amount for stake accounts, which is currently 1 lamport. There is a deactivated feature that will increase this to 1 SOL (1 SOL = 10^9 lamports), but there are no current plans to activate this. spl-stake-pool's own MINIMUM_ACTIVE_STAKE constant is 1_000_000 lamports. The pool uses the `minimum_stake_lamports` function to calculate this: ```rust pub fn minimum_stake_lamports(meta: &Meta, stake_program_minimum_delegation: u64) -> u64 { meta.rent_exempt_reserve .saturating_add(minimum_delegation(stake_program_minimum_delegation)) } pub fn minimum_delegation(stake_program_minimum_delegation: u64) -> u64 { std::cmp::max(stake_program_minimum_delegation, MINIMUM_ACTIVE_STAKE) } ``` This ensures that stake accounts always have enough lamports to remain valid and delegated. You cannot decrease or increase a validator account's stake with fewer lamports than the minimum_delegation, because the transient stake account would not have enough lamports to remain valid. As of August 2024, the minimum lamports for a stake account is 3_282_880 lamports. ## Stake Account Rent Funding When keeping track of all lamports in the pool, it's important to note the rent for stake accounts in the Stake Pool comes from the reserve account. 1. **Validator Addition**: When adding a new validator, the rent for the validator's stake account is funded from the pool's reserve account. ```rust let required_lamports = minimum_stake_lamports(&meta, stake_minimum_delegation); Self::stake_split( stake_pool_info.key, reserve_stake_info.clone(), withdraw_authority_info.clone(), AUTHORITY_WITHDRAW, stake_pool.stake_withdraw_bump_seed, required_lamports, stake_info.clone(), )?; ``` 2. **Transient Stake Accounts**: When creating a transient stake account (used for rebalancing), the rent is funded from the pool's reserve account. ```rust let required_lamports = stake_rent.saturating_add(lamports); Self::stake_split( stake_pool_info.key, reserve_stake_info.clone(), withdraw_authority_info.clone(), AUTHORITY_WITHDRAW, stake_pool.stake_withdraw_bump_seed, required_lamports, transient_stake_account_info.clone(), )?; ``` The Stake Pool always ensures that any stake account it creates or manages has sufficient lamports to remain rent-exempt. ## Validator Removal Process When a validator is removed from the stake pool, the process involves several steps and may take multiple epochs to complete. The exact path depends on the current state of the validator's stake accounts and when the `UpdateValidatorListBalance` instruction is called. ### Initial Removal 1. The `RemoveValidatorFromPool` instruction is called by the stake pool's staker. 2. The validator's `StakeStatus` is changed to `DeactivatingValidator`. 3. The validator's active stake account is deactivated. ### Subsequent Updates The completion of the removal process depends on when `UpdateValidatorListBalance` is called and the state of the validator's stake accounts. This instruction can be called in the same epoch as the removal or in later epochs. #### Scenario 1: No Transient Stake If the validator has no transient stake when removed: 1. First `UpdateValidatorListBalance` call: - If the active stake is fully deactivated (cooldown complete): - The stake is merged into the reserve. - The `StakeStatus` changes to `ReadyForRemoval`. - If the active stake is still cooling down: - No change occurs. - The `StakeStatus` remains `DeactivatingValidator`. 2. Subsequent `UpdateValidatorListBalance` calls: - If the status is still `DeactivatingValidator`: - Check if cooldown is complete and merge into reserve if so. - If the status is `ReadyForRemoval`: - The validator entry is removed from the list. #### Scenario 2: With Transient Stake If the validator has transient stake when removed: 1. First `UpdateValidatorListBalance` call: - The `StakeStatus` changes to `DeactivatingAll`. - Both active and transient stakes begin deactivation (if not already deactivating). 2. Subsequent `UpdateValidatorListBalance` calls: - If transient stake cooldown completes first: - Transient stake is merged into reserve. - `StakeStatus` changes to `DeactivatingValidator`. - If active stake cooldown completes first: - Active stake is merged into reserve. - `StakeStatus` changes to `DeactivatingTransient`. 3. Final `UpdateValidatorListBalance` call: - When both active and transient stakes are fully deactivated and merged: - `StakeStatus` changes to `ReadyForRemoval`. - On the next call after `ReadyForRemoval`: - The validator entry is removed from the list. ### Important Notes - The entire process can take multiple epochs due to Solana's stake cooldown period. - `UpdateValidatorListBalance` must be called regularly to progress the removal process. - Validators in any deactivating state (`DeactivatingValidator`, `DeactivatingAll`, `DeactivatingTransient`) cannot receive new stake. - Withdrawals can still occur from deactivating validator stake accounts, potentially accelerating the removal process. - If a validator is removed and re-added before the removal process completes, the process resets and the validator becomes active again. --- # Parameters # Parameters Live parameters can be seen on-chain at https://jito.network/stakenet/steward/config or via the CLI. | Parameter | Value | Description | | --------------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Scoring Parameters** | | | | `mev_commission_range` | 30 | Number of recent epochs used to evaluate MEV commissions and running Jito for binary eligibility. Also used to calculate average MEV commission for Tier 2 scoring | | `epoch_credits_range` | 30 | Number of recent epochs used to evaluate vote credits performance for Tier 4 scoring and delinquency checks | | `commission_range` | 30 | Number of recent epochs used to evaluate maximum validator commission for Tier 1 scoring and binary eligibility | | `mev_commission_bps_threshold` | 1000 | Maximum allowable MEV commission in mev_commission_range for binary eligibility (stored in basis points, 1000 = 10%) | | `commission_threshold` | 5 | Maximum allowable validator commission in commission_range for binary eligibility (stored in percent) | | `historical_commission_threshold` | 50 | Maximum allowable validator commission across all validator history for binary eligibility (stored in percent) | | `scoring_delinquency_threshold_ratio` | 0.97 | Minimum ratio of slots voted on for each epoch for binary eligibility. Used as proxy for validator reliability. Ratio is epoch_credits / (blocks_produced * TVC_MULTIPLIER) | | `jito_bam_minimum_epochs` | 6 | Minimum number of epochs a validator must have been connected to BAM within the window to qualify for delegation. Must not exceed `jito_bam_window_epochs` | | `jito_bam_window_epochs` | 10 | Window size (in epochs) over which BAM connectivity is evaluated. The checked range is `[(current_epoch - 1) - jito_bam_window_epochs, current_epoch - 1]` inclusive, spanning `jito_bam_window_epochs + 1` epochs. Epochs with missing data reduce the effective threshold rather than counting as disconnected | | | | | | | | | | **Delegation Parameters** | | | | `instant_unstake_delinquency_threshold_ratio` | 0.70 | Same as scoring_delinquency_threshold_ratio but evaluated every epoch for instant unstake | | `num_delegation_validators` | 400 | Number of validators who are eligible for stake (validator set size). Top N validators by score receive equal delegation | | `scoring_unstake_cap_bps` | 750 | Percent of total pool lamports that can be unstaked due to new delegation set (in basis points, 750 = 7.5%) | | `instant_unstake_cap_bps` | 1000 | Percent of total pool lamports that can be unstaked due to instant unstaking (in basis points, 1000 = 10%) | | `stake_deposit_unstake_cap_bps` | 1000 | Percent of total pool lamports that can be unstaked due to stake deposits above target lamports (in basis points, 1000 = 10%) | | | | | | **Priority Fee Parameters** | | | | `priority_fee_lookback_epochs` | 10 | Number of recent epochs to evaluate priority fee distribution for scoring | | `priority_fee_lookback_offset` | 2 | Offset from current epoch when evaluating priority fee history (allows time for data to be uploaded) | | `priority_fee_max_commission_bps` | 10000 | Maximum allowable average realized priority fee commission (in basis points, 10000 = 100%) | | `priority_fee_error_margin_bps` | 500 | Error margin added to max commission threshold to account for rounding and calculation variance (in basis points, 500 = 5%) | | `priority_fee_scoring_start_epoch` | 65535 | Epoch when priority fee scoring becomes active. Set to 65535 (max u16) to disable. Before this epoch, all validators receive score of 1 for priority fee commission check | | | | | | **State Machine Operation Parameters** | | | | `compute_score_slot_range` | 10000 | Scoring window such that the validators are all scored within a similar timeframe (in slots) | | `instant_unstake_epoch_progress` | 0.90 | Point in epoch progress before instant unstake can be computed | | `instant_unstake_inputs_epoch_progress` | 0.50 | Inputs to "Compute Instant Unstake" need to be updated past this point in epoch progress | | `num_epochs_between_scoring` | 10 | Cycle length - Number of epochs to run the Monitor->Rebalance loop | | `minimum_stake_lamports` | 5,000,000,000,000 (5000 SOL) | Minimum number of stake lamports for a validator to be considered for the pool | | `minimum_voting_epochs` | 5 | Minimum number of consecutive epochs a validator has to vote before it can be considered for the pool | --- # Steward API # Steward API ## Events Endpoint This endpoint allows you to retrieve various events related to the Steward program. Events are emitted by the Steward program when certain actions occur, such as when a validator is scored, or when rebalancing takes place. ### Endpoint `GET https://kobe.mainnet.jito.network/api/v1/steward_events` ### Parameters | Parameter | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------- | | vote_account | String | No | Filter events by validator vote account public key | | epoch | Integer | No | Filter events by epoch number | | event_type | String | No | Filter events by type (see Valid Event Types below) | | page | Integer | No | Page number for pagination (default: 1) | | limit | Integer | No | Number of events per page (default: 100, max: 1000) | ### Valid Event Types Most relevant to validators: - `ScoreComponentsV4`: Validator scoring details using the 4-tier hierarchical scoring system. Emitted once every 10 epochs - `InstantUnstakeComponentsV3`: Information about instant unstaking events - `RebalanceEvent`: Details about stake rebalancing operations Updates to overall state: - `StateTransition`: Changes in the Steward program's state machine - `DecreaseComponents`: Included in RebalanceEvent, provides specifics on stake decreases - `AutoRemoveValidatorEvent`: Automatic removal of offline validators from the pool - `AutoAddValidatorEvent`: Automatic addition of new validators to the pool - `EpochMaintenanceEvent`: Epoch maintenance operations ### Example Request: Get a validator's scores `GET https://kobe.mainnet.jito.network/api/v1/steward_events?vote_account=J1to3PQfXidUUhprQWgdKkQAMWPJAEqSJ7amkBDE9qhF&event_type=ScoreComponentsV4` ```json { "events": [ { "signature": "5N3hVRpuqsiXCiChrm3GuaWRfi2zZMYAkx6jnM3YTocAC5RBTsrukk4ghFHeCyZawC7Ca72i7fo8TNg2MsG1zXP7", "event_type": "ScoreComponentsV4", "vote_account": "J1to3PQfXidUUhprQWgdKkQAMWPJAEqSJ7amkBDE9qhF", "timestamp": "2024-08-20T06:18:46Z", "data": { "score": 7260571231234567890, "raw_score": 7260571231234567890, "commission_max": 5, "mev_commission_avg": 800, "validator_age": 1250, "vote_credits_avg": 9650000, "mev_commission_score": 1, "blacklisted_score": 1, "superminority_score": 1, "delinquency_score": 1, "running_jito_score": 1, "commission_score": 1, "historical_commission_score": 1, "merkle_root_upload_authority_score": 1, "priority_fee_commission_score": 1, "priority_fee_merkle_root_upload_authority_score": 1, "details": { "max_mev_commission": 1000, "max_mev_commission_epoch": 658, "superminority_epoch": 65535, "delinquency_ratio": 0.98, "delinquency_epoch": 65535, "max_commission": 5, "max_commission_epoch": 659, "max_historical_commission": 10, "max_historical_commission_epoch": 520, "avg_priority_fee_commission": 450, "max_priority_fee_commission_epoch": 658 } }, "epoch": 659 }, ... ] } ``` **ScoreComponentsV4 Fields:** - `score`: Final score (u64). If 0, validator is ineligible. Otherwise, equals `raw_score` - `raw_score`: 4-tier encoded score before binary filters applied - `commission_max`: Maximum inflation commission observed (0-100, Tier 1 component) - `mev_commission_avg`: Average MEV commission in basis points (0-10000, Tier 2 component) - `validator_age`: Number of epochs with non-zero vote credits (Tier 3 component) - `vote_credits_avg`: Scaled vote credits ratio (Tier 4 component) - Binary eligibility scores (1 = pass, 0 = fail): - `mev_commission_score`: MEV commission check - `commission_score`: Recent commission check - `historical_commission_score`: Historical commission check - `blacklisted_score`: Blacklist check - `superminority_score`: Superminority check - `delinquency_score`: Voting delinquency check - `running_jito_score`: Running Jito MEV client check - `merkle_root_upload_authority_score`: Tip distribution authority check - `priority_fee_commission_score`: Priority fee commission check - `priority_fee_merkle_root_upload_authority_score`: Priority fee authority check - `details`: Additional scoring details for debugging and transparency ### Example Request: See stake movements by epoch `GET https://kobe.mainnet.jito.network/api/v1/steward_events?event_type=RebalanceEvent&epoch=657&limit=2000` ```json { "events": [ { "signature": "64GGjM2QtrKw4SPocR5hmw17Kenf9qBdRRM5KrrM9gkr8XUgyyjXNQkuzfxq3ZhDJgHU8jvhUKxaAfMnnGp85Uss", "event_type": "RebalanceEvent", "vote_account": "7emL18Bnve7wbYE9Az7vYJjikxN6YPU81igf6rVU5FN8", "timestamp": "2024-08-17T20:20:57Z", "data": { "rebalance_type_tag": "Increase", "increase_lamports": 2762842586176, "decrease_components": { "scoring_unstake_lamports": 0, "instant_unstake_lamports": 0, "stake_deposit_unstake_lamports": 0, "total_unstake_lamports": 0 } }, "epoch": 657 }, ... ] } ``` --- # Steward CLI Guide > Commands and operations for Steward management # Accounts | Account | Address | | -------------- | -------------------------------------------- | | Program | Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 | | Steward Config | jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv | | Steward State | 9BAmGVLGxzqct6bkgjWmKSv3BFB6iKYXNBQp8GWG1LDY | | Authority | 9eZbWiHsPRsxLSiHxzg2pkXsAuQMwAjQrda7C7e21Fw6 | # CLI Commands Build CLI binary from `/stakenet` directory: ```bash cargo build -p steward-cli --release ``` ## Permissionless Commands ### View Config Displays all parameters of this Steward configuration. ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 view-config --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv ``` ### View State Displays high level Steward internal operations including current state, total number of validators in the pool, next cycle epoch, etc. ```bash ./target/release/steward-cli --json-rpc-url $(solana config get | grep "RPC URL" | awk '{print $3}') view-state --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv ``` ### View State of Single Validator Displays state of a single Validator. ```bash ./target/release/steward-cli --json-rpc-url $(solana config get | grep "RPC URL" | awk '{print $3}') view-state --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --vote-account J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv ``` Output: ``` Vote Account: J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv Stake Account: 6PAY8LEswawgCGnzB3tKGJBtELUwDpeMfDCiNpCyNt8q Transient Stake Account: C2AurJCKxp5Q8DbaZ84aiSUiKKazqgRVsUiTiihqNYui Steward List Index: 3 Overall Rank: 441 Score: 0 Raw Score: 0 Passing Eligibility Criteria: No Target Delegation Percent: 0.0% Is Instant Unstake: false Is blacklisted: false Validator History Index: 321 Active Lamports: 3398839 (0.00 ◎) Transient Lamports: 0 (0.00 ◎) Steward Internal Lamports: 114590 Status: 🟩 Active Marked for removal: false Marked for immediate removal: false ``` `Vote Account`: Validator's vote account address `Stake Account`: Validator's stake account from this stake pool `Transient Stake Account`: Validator's transient stake account used for activating/deactivating stake `Steward List Index`: Position in the Steward list, 1-1 with spl-stake-pool `ValidatorList` `Overall Rank`: Validator's rank among all validators, indicating staking priority if Target is nonzero (based on score), and unstaking priority if target is zero (based on raw_score) `Passing Eligibility Criteria`: Indicates if validator meets binary eligibility requirements `Score`: Validator's final score (0 if any eligibility criteria failed, otherwise equals raw_score) `Raw Score`: Validator's 4-tier hierarchical score before binary filters applied `Target Delegation Percent`: Share of the stake pool TVL this validator is targeted to receive. Not a guaranteed amount - dependent on staking and unstaking priority. `Is Instant Unstake`: Indicates if this validator should be immediately unstaked `Is blacklisted`: Indicates if validator is blacklisted from the pool `Validator History Index`: Position in the validator history `Active Lamports`: Amount of actively staked lamports `Transient Lamports`: Amount of lamports in transient state `Steward Internal Lamports`: Steward's internal tracking of stake used to detect user deposits `Status`: Validator's `StakeStatus` in the spl-stake-pool `ValidatorList` account `Marked for removal`: Indicates if validator is flagged for removal next epoch `Marked for immediate removal`: Indicates if validator is flagged for immediate removal ### View State of All Validators ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 --json-rpc-url $(solana config get | grep "RPC URL" | awk '{print $3}') view-state --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --verbose ``` ### View Next Index To Remove ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 view-next-index-to-remove --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv ``` ### Auto Remove Validator ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 auto-remove-validator-from-pool --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json --validator-index-to-remove 1397 ``` ### Auto Add Validator ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 auto-add-validator-from-pool --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json --vote-account 4m64H5TbwAGtZVnxaGAVoTSwjZGV8BCLKRPr8agKQv4Z ``` ### Manually Update All Vote Accounts ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 manually-copy-all-vote-accounts --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json --priority-fee 300000 ``` ## Manually Update Vote Account ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 manually-copy-vote-account --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json --validator-index-to-update 1 ``` ### Manually Remove Validator ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 manually-remove-validator --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --authority-keypair-path ../../credentials/stakenet_test.json --validator-index-to-remove 0 ``` ## Remove Bad Validators ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 remove-bad-validators --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Permissionless Cranks ## Crank Epoch Maintenance ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 crank-epoch-maintenance --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Crank Compute Score ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 crank-compute-score --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Crank Compute Delegations ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 crank-compute-delegations --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Crank Idle ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 crank-idle --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Crank Compute Instant Unstake ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 crank-compute-instant-unstake --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Crank Rebalance ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 crank-rebalance --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json ``` ## Crank Steward ```bash ./target/release/steward-cli --json-rpc-url $(solana config get | grep "RPC URL" | awk '{print $3}') crank-steward --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --payer-keypair-path ../../credentials/stakenet_test.json --priority-fee 200000 ``` ## Privileged Commands ### Create Steward ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 init-steward \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config-keypair-path ../../credentials/steward_config.json \ --stake-pool 3DuPtyTAKrxKfHkSPZ5fqCayMcGru1BarAKKTfGDeo2j \ --mev-commission-range 30 \ --epoch-credits-range 30 \ --commission-range 30 \ --mev-commission-bps-threshold 1000 \ --commission-threshold 5 \ --historical-commission-threshold 50 \ --scoring-delinquency-threshold-ratio 0.97 \ --instant-unstake-delinquency-threshold-ratio 0.70 \ --num-delegation-validators 400 \ --scoring-unstake-cap-bps 750 \ --instant-unstake-cap-bps 1000 \ --stake-deposit-unstake-cap-bps 1000 \ --compute-score-slot-range 10000 \ --instant-unstake-epoch-progress 0.90 \ --instant-unstake-inputs-epoch-progress 0.50 \ --num-epochs-between-scoring 10 \ --minimum-stake-lamports 5000000000000 \ --minimum-voting-epochs 5 ``` ### Realloc State ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 realloc-state --authority-keypair-path ../../credentials/stakenet_test.json --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv ``` ### Update Config ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 update-config \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv \ --num-epochs-between-scoring 3 ``` ### Update Authority `blacklist` | `admin` | `parameters` ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 update-authority blacklist \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv \ --new-authority aaaDerwdMyzNkoX1aSoTi3UtFe2W45vh5wCgQNhsjF8 ``` ### Set Staker ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 set-staker \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv ``` ### Revert Staker ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 revert-staker \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv ``` ### Pause ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 pause \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --print-tx ``` ### Resume ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 resume \ --authority-keypair-path ../../credentials/stakenet_test.json \ --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --print-tx ``` ### Reset State ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 reset-state --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --authority-keypair-path ../../credentials/stakenet_test.json ``` ### Add To Blacklist ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 add-to-blacklist --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --authority-keypair-path ../../credentials/stakenet_test.json --validator-history-index-to-blacklist 2168 ``` ### Remove From Blacklist ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 remove-from-blacklist --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --authority-keypair-path ../../credentials/stakenet_test.json --validator-history-index-to-deblacklist 2168 ``` ## Close Steward ```bash ./target/release/steward-cli --program-id Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 close-steward --steward-config jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv --authority-keypair-path ../../credentials/stakenet_test.json ``` --- # Running a Keeper # Keeper Bot Quick-start Below are the steps to configuring and running the Stakenet Keeper Bot. We recommend running it as a docker container. ## Setup ### Credentials In the root directory create a new folder named `credentials` and then populate it with a keypair. This is keypair that signs and pays for all transactions. ```bash mkdir credentials solana-keygen new -o ./credentials/keypair.json ``` ### ENV In the root directory create `.env` file ```bash touch .env ``` Then copy into the `.env` file the contents below. Everything should be set as-is, however you will need to include a `JSON_RPC_URL` that can handle getProgramAccounts calls. ```bash # RPC URL for the cluster JSON_RPC_URL="INCLUDE YOUR RPC URL HERE" # Cluster to specify (mainnet, testnet, devnet) CLUSTER=mainnet # Region to specify for metrics purposes (us-east, eu-west, local, etc.) REGION=local # Gossip entrypoints GOSSIP_ENTRYPOINTS=GOSSIP_ENTRY_1,GOSSIP_ENTRY_2 # Log levels RUST_LOG="info,solana_gossip=error,solana_metrics=info" # Path to keypair used to execute tranasactions KEYPAIR=./credentials/keypair.json # Validator history program ID (Pubkey as base58 string) VALIDATOR_HISTORY_PROGRAM_ID=HistoryJTGbKQD2mRgLZ3XhqHnN811Qpez8X9kCcGHoa # Tip distribution program ID (Pubkey as base58 string) TIP_DISTRIBUTION_PROGRAM_ID=4R3gSG8BpU4t19KYj8CfnbtRpnT8gtk4dvTHxVRwc2r7 # Steward program ID STEWARD_PROGRAM_ID=Stewardf95sJbmtcZsyagb2dg4Mo8eVQho8gpECvLx8 # Steward config account for JitoSOL STEWARD_CONFIG=jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv # Priority Fees in microlamports PRIORITY_FEES=20000 # Retry count TX_RETRY_COUNT=100 # Confirmation time after submission TX_CONFIRMATION_SECONDS=30 # Run flags (true/false) RUN_CLUSTER_HISTORY=true RUN_COPY_VOTE_ACCOUNTS=true RUN_MEV_COMMISSION=true RUN_MEV_EARNED=true RUN_STEWARD=true RUN_EMIT_METRICS=false # Interval to update Validator History Accounts (in seconds) VALIDATOR_HISTORY_INTERVAL=300 # Interval to run steward (in seconds) STEWARD_INTERVAL=301 # Interval to emit metrics (in seconds) METRICS_INTERVAL=60 # For Oracle Authority Only RUN_STAKE_UPLOAD=false RUN_GOSSIP_UPLOAD=false RUN_COPY_IS_BAM_CONNECTED=false # Minimum BAM connection rate (0.0 - 1.0) for a validator to be marked # is_bam_connected. A validator must meet or exceed this rate to qualify. # Required when RUN_COPY_IS_BAM_CONNECTED=true. MIN_BAM_CONNECTION_RATE=0.95 # Run with the startup flag set to true FULL_STARTUP=true # Running with no_pack set to true skips packing the instructions and will cost more NO_PACK=false # Pay for new accounts when necessary PAY_FOR_NEW_ACCOUNTS=false # Max time in minutes to wait after any fire cycle COOL_DOWN_RANGE=20 # Metrics upload influx server (optional) SOLANA_METRICS_CONFIG="" # Minimum activated stake threshold for creating validator history accounts (in lamports) VALIDATOR_HISTORY_MIN_STAKE=500000000000 ``` ## Running Docker image from source Once the setup is complete use the following commands to run/manage the docker container: > Note: We are running `Docker version 24.0.5, build ced0996` ### Start Docker ```bash docker compose --env-file .env up -d --build stakenet-keeper --remove-orphans ``` ### View Logs ```bash docker logs stakenet-keeper -f ``` ### Stop Docker\*\* ```bash docker stop stakenet-keeper; docker rm stakenet-keeper; ``` ## Run from Dockerhub This image is available on Dockerhub at: https://hub.docker.com/r/jitolabs/stakenet-keeper ```bash docker pull jitolabs/stakenet-keeper:latest docker run -d \ --name stakenet-keeper \ --env-file .env \ -v $(pwd)/credentials:/credentials \ --restart on-failure:5 \ jitolabs/stakenet-keeper:latest ``` ## Running as Binary To run the keeper in terminal, build for release and run the program. ### Build for Release ```bash cargo build --release --bin stakenet-keeper ``` ### Run Keeper ```bash RUST_LOG=info ./target/release/stakenet-keeper ``` To see all available parameters run: ```bash RUST_LOG=info ./target/release/stakenet-keeper -h ``` --- # Steward FAQ # Validator Frequently Asked Questions [FAQ in progress] --- # Scoring System > How StakeNet scores validators # Scoring System The Steward program uses a 4-tier hierarchical scoring system combined with binary eligibility criteria to rank validators for stake delegation. This page provides detailed formulas and explanations for each component. ## Overview The scoring system has two main components: 1. **Binary Eligibility Criteria**: Pass/fail checks (score of 1.0 or 0.0) that ensure validators meet minimum requirements 2. **4-Tier Hierarchical Ranking**: A tiered scoring system that ranks eligible validators with commission being most important, followed by age and performance ## Binary Eligibility Criteria All validators must pass ALL of the following binary checks to be eligible for delegation. Each criterion evaluates to 1.0 (pass) or 0.0 (fail). ### MEV Commission Score ``` mev_commission_score = { 1.0 if max(mev_commission[t1, t2]) ≤ mev_commission_bps_threshold 0.0 otherwise } where: t1 = current_epoch - mev_commission_range t2 = current_epoch mev_commission_bps_threshold = 1000 (10%) ``` **Purpose**: Ensures validators don't charge excessive MEV commissions. --- ### Commission Score ``` commission_score = { 1.0 if max(commission[t1, t2]) ≤ commission_threshold 0.0 otherwise } where: t1 = current_epoch - commission_range t2 = current_epoch commission_threshold = 5% ``` **Purpose**: Ensures validators don't charge excessive inflation commissions in recent epochs. --- ### Historical Commission Score ``` historical_commission_score = { 1.0 if max(historical_commission[t1, t2]) ≤ historical_commission_threshold 0.0 otherwise } where: t1 = first_reliable_epoch = 520 t2 = current_epoch historical_commission_threshold = 50% ``` **Purpose**: Bans validators who have performed commission manipulation (rug pulls) at any point in their history. --- ### Running BAM Score ``` running_bam_score = { 1.0 if bam_connected_count >= max(0, jito_bam_minimum_epochs - missed_epochs) 0.0 otherwise } where: window = [(current_epoch - 1) - jito_bam_window_epochs, current_epoch - 1] (inclusive) bam_connected_count = number of epochs in window where is_bam_connected == 1 missed_epochs = number of epochs in window where BAM data was not uploaded (None) ``` **Purpose**: Ensures validators are connected to BAM (Block Assembly Marketplace) with sufficient consistency. Missing data reduces the effective threshold rather than penalizing the validator. --- ### Delinquency Score ``` delinquency_score = { 1.0 if (vote_credits[t] / (total_blocks[t] × TVC_MULTIPLIER)) ≥ scoring_delinquency_threshold_ratio for all t in [t1, t2] 0.0 otherwise } where: t1 = current_epoch - epoch_credits_range t2 = current_epoch - 1 scoring_delinquency_threshold_ratio = 0.97 TVC_MULTIPLIER = 1000 (Turbine Vote Credits multiplier) ``` **Purpose**: Ensures validators maintain high uptime and vote participation. The ratio measures what fraction of possible votes were cast. **Note**: `total_blocks` is the field in ClusterHistory that tracks how many blocks were created by the cluster in a given epoch. This represents the maximum number of vote credits a validator can earn. Vote credits are synonymous with epoch credits. --- ### Blacklisted Score ``` blacklisted_score = { 0.0 if blacklisted in current epoch 1.0 otherwise } ``` **Purpose**: Allows governance to manually exclude validators for security or policy reasons. --- ### Superminority Score ``` superminority_score = { 0.0 if in superminority in current epoch 1.0 otherwise } ``` **Purpose**: Prevents concentration of stake by excluding validators in the top 33.3% of total network stake, promoting decentralization. --- ### Merkle Root Upload Authority Score ``` merkle_root_upload_authority_score = { 1.0 if authority is TipRouter or OldJito 0.0 otherwise (including Unset, DNE, or other values) } ``` **Purpose**: Ensures validators are using an acceptable Tip Distribution merkle root upload authority for MEV distribution. --- ### Priority Fee Commission Score ``` priority_fee_commission_score = { 1.0 if avg_realized_commission[t1, t2] ≤ max_avg_commission OR current_epoch < priority_fee_scoring_start_epoch 0.0 otherwise } where: avg_realized_commission = ceiling(sum(realized_commission[t] for valid t in [t1, t2]) / count(valid t)) realized_commission[t] = ((total_fees[t] - tips[t]) × 10000) / total_fees[t] (in basis points) t1 = current_epoch - priority_fee_commission_range t2 = current_epoch valid t = epochs where priority_fee_merkle_root_upload_authority is not Unset Special cases: - If tips is None, default to 0 (assumes not distributing priority fees, commission = 10000 bps) - If total_fees is None or 0, return 0 bps (no data available yet) - If total_fees is None when tips exists, default to u64::MAX (forces commission to max) ``` **Purpose**: Ensures validators distribute priority fees to stakers and don't keep excessive amounts. Uses ceiling division to be more strict (rounds up commission). --- ### Priority Fee Merkle Root Upload Authority Score ``` priority_fee_merkle_root_upload_authority_score = { 1.0 if authority is TipRouter or OldJito 0.0 otherwise (including Unset, DNE, or other values) } ``` **Purpose**: Ensures validators are using an acceptable authority for priority fee distribution. --- ## 4-Tier Hierarchical Ranking Validators that pass all binary criteria are ranked using a 4-tier system encoded as a 64-bit value. Higher tiers always dominate lower tiers. ### Score Encoding The score is encoded as a u64 with the following bit layout: ``` Bits 56-63 (8 bits): Tier 1 - Inflation Commission (inverted) Bits 42-55 (14 bits): Tier 2 - MEV Commission (inverted) Bits 25-41 (17 bits): Tier 3 - Validator Age Bits 0-24 (25 bits): Tier 4 - Vote Credits Ratio ``` This encoding ensures that when comparing scores as u64 values, differences in higher tiers always dominate lower tiers. ### Tier 1: Inflation Commission (Highest Priority) ``` tier1_score = 100 - min(commission_max, 100) where: commission_max = max(commission[t] for t in [t1, t2]) t1 = current_epoch - commission_range t2 = current_epoch ``` **Range**: 0-100 (8 bits) **Inverted**: Lower commission = higher score **Purpose**: Prioritizes validators with lower inflation commissions. A validator with 0% commission scores 100, while 5% commission scores 95. --- ### Tier 2: MEV Commission ``` tier2_score = 10000 - min(mev_commission_avg, 10000) where: mev_commission_avg = ceiling(sum(mev_commission[t] for valid t in [t1, t2]) / count(valid t)) t1 = current_epoch - mev_commission_range t2 = current_epoch valid t = epochs where mev_commission is not None If no valid epochs exist, default to 10000 (BASIS_POINTS_MAX) ``` **Range**: 0-10000 basis points (14 bits) **Inverted**: Lower commission = higher score **Purpose**: Among validators with equal inflation commission, prefers those with lower MEV commissions. Uses ceiling division to be more strict. --- ### Tier 3: Validator Age ``` tier3_score = min(validator_age, 131071) where: validator_age = count of epochs with non-zero vote credits ``` **Range**: 0-131,071 epochs (17 bits, ~716 years max) **Direct**: Older validators score higher **Purpose**: Among validators equal on commissions, rewards longevity and operational track record. --- ### Tier 4: Vote Credits Ratio ``` tier4_score = min(vote_credits_avg_scaled, 33554431) where: vote_credits_avg_scaled = vote_credits_ratio × VOTE_CREDITS_RATIO_MAX vote_credits_ratio = (sum(vote_credits[t] for t in [t1, t2]) / count[t1, t2]) / (sum(total_blocks[t] for t in [t1, t2]) / count[t1, t2]) / TVC_MULTIPLIER t1 = current_epoch - epoch_credits_range t2 = current_epoch - 1 VOTE_CREDITS_RATIO_MAX = 10,000,000 (for precision) TVC_MULTIPLIER = 1000 (Turbine Vote Credits multiplier) ``` **Range**: 0-33,554,431 (25 bits) **Direct**: Higher performance = higher score **Purpose**: Among validators equal on all other tiers, rewards better performance. This is a relative measure of validator reliability and vote participation, not an exact APY measure. --- ## Final Score Calculation The final score combines the 4-tier raw score with all binary eligibility factors: ```rust // Step 1: Encode 4-tier raw score raw_score = (tier1_score << 56) | (tier2_score << 42) | (tier3_score << 25) | tier4_score // Step 2: Apply binary filters final_score = raw_score × mev_commission_score × commission_score × historical_commission_score × blacklisted_score × superminority_score × delinquency_score × running_bam_score × merkle_root_upload_authority_score × priority_fee_commission_score × priority_fee_merkle_root_upload_authority_score ``` **Result**: If any binary criterion fails (= 0), the final score becomes 0, making the validator ineligible. Otherwise, the final score equals the raw_score, which can be compared directly as a u64 to rank validators hierarchically. --- ## Example Comparison Here's how two validators would be ranked: **Validator A**: 1% commission, 5% MEV commission, 100 epochs old, 0.95 vote ratio **Validator B**: 2% commission, 3% MEV commission, 200 epochs old, 0.98 vote ratio Despite Validator B having better MEV commission, age, and performance, **Validator A ranks higher** because Tier 1 (inflation commission) dominates all other factors. The 1% vs 2% difference in inflation commission overrides all other advantages. --- ## Implementation Reference See the full implementation in [score.rs](https://github.com/jito-foundation/stakenet/blob/master/programs/steward/src/score.rs) in the StakeNet repository. --- # Rebalance System > How StakeNet rebalances among validators # Rebalance System Over time, as people deposit SOL into the reserve, or as validator performance varies, you will want to move stake around. The best way to do this will be through an automated system to collect information about the stake pool and the network, and decide how much stake to allocate to each validator. ## How It Works The [rebalance system](https://github.com/jito-foundation/stakenet/blob/master/programs/steward/src/instructions/rebalance.rs) automatically adjusts stake allocation across validators based on performance and pool conditions. Here's the step-by-step process: 1. **State Transition Check**: Automatically transitions between system states based on current conditions and timing parameters #### State Types - **Idle**: Waiting state, monitors for when to begin operations - **ComputeScores**: Evaluates validator performance metrics - **ComputeDelegations**: Calculates optimal stake distribution - **ComputeInstantUnstake**: Determines validators that need immediate unstaking - **Rebalance**: Executes the actual stake movement operations #### Transition Logic The system uses `maybe_transition()` to check if a state change is needed: - Compares current state before and after transition attempt - Considers current epoch, slot, and epoch progress - Uses configurable parameters like `num_epochs_between_scoring` - Emits `StateTransition` events when state changes occur - Each state has its own transition conditions based on timing and system parameters 2. **State Validation**: Performs comprehensive state checks to ensure system integrity before executing `Rebalance` operations #### State Validation Checks Before executing any rebalance operations, the system performs critical validation through state_checks(): ##### System Status Checks: - **Pause Check**: Ensures the system is not paused (StateMachinePaused error if paused) - **State Verification**: Confirms current state matches expected state (must be Rebalance for rebalance operations) ##### Epoch Synchronization: - **Epoch Alignment**: Verifies current epoch matches the state account's tracked epoch - **Maintenance Complete**: Ensures epoch maintenance has been completed before proceeding ##### Validator List Integrity: - **Removal Queue**: Confirms no validators are pending immediate removal - **List Consistency**: Validates that validator count matches between state tracking and actual validator list - **Mapping Verification**: Ensures 1-to-1 correspondence between pool validators and validator list entries 3. **Validator Verification**: Ensures the target validator exists in the validator list and matches the vote account 4. **Vote Account Validation**: Checks if vote account is valid or if validator needs to be marked for removal 5. **Stake Analysis**: Analyzes current stake account state and calculates active lamports 6. **Rebalance Decision**: Determines the appropriate rebalance action based on: - Current stake pool lamports - Reserve lamports - Active stake lamports - Minimum delegation requirements - Rent requirements #### Rebalance Decision Engine The core rebalance logic processes each validator individually and determines the optimal action based on multiple factors: ##### Pre-Processing Checks - Cycle Validation: Ensures current epoch is within the rebalance cycle - Progress Tracking: Skips validators already processed in this cycle - Removal Status: Bypasses validators marked for deletion or immediate removal - Transient State: Checks if validator has pending transient stake operations ##### Financial Calculations ###### Reserve Management: - Calculates minimum reserve needed for rent across all remaining validators - Determines available reserve lamports after accounting for system requirements - Factors in base costs (minimum delegation + stake rent) for each validator ###### Target vs Current Analysis: - Computes target lamports based on delegation percentages and total pool stake - Compares against current validator stake (minus minimum delegation) - Tracks validator lamport balances to detect stake deposit deltas Target Lamports Calculation The system calculates each validator's target stake allocation using a fractional delegation system: Delegation Structure: Each validator has a `Delegation` with: - **Numerator**: The validator's share portion - **Denominator**: The total shares in the pool Calculation Logic: ``` Target Lamports = (Pool Lamports * Numerator) / Denominator ``` Special Cases: - Zero Allocation (numerator = 0): Target is 0 lamports - Equal Distribution (numerator = 1): Target is pool_lamports / denominator - Proportional Allocation (numerator > 1): Uses 128-bit arithmetic to prevent overflow Key Features: - Precision Loss: Acceptable loss up to `denominator` lamports due to integer division - Overflow Protection: Uses 128-bit intermediate calculations for large values - Immovable Stake: Pool lamports input excludes base costs (minimum delegation + rent) since these cannot be redistributed This fractional system allows for precise percentage-based allocation while maintaining computation efficiency and preventing arithmetic errors. ##### Decision Logic The system determines rebalance type through a three-tier evaluation: ###### Decrease Stake Conditions **Triggers when**: - Current stake exceeds target allocation, OR - Validator is marked for instant unstake - No transient stake operations pending **Unstaking Caps Applied**: - Scoring Unstake Cap: Limits stake reduction based on performance scoring - Instant Unstake Cap: Controls emergency unstaking amounts - Stake Deposit Unstake Cap: Manages withdrawal of recent deposits **Delegation Redistribution**: For instant unstake scenarios, the system automatically redistributes the validator's delegation percentage to other eligible validators by adjusting their denominators. ###### Increase Stake Conditions **Triggers when**: - Current stake is below target allocation - Sufficient reserve lamports available - No transient stake operations pending **No Action** **When current allocation is optimal or constraints prevent changes** ##### State Updates After determining rebalance type, the system updates: - Validator lamport balances to reflect new stake levels - Unstake totals across different categories (scoring, instant, stake deposit) - Delegation percentages for instant unstake redistribution - Progress tracking to mark validator as processed ## Rebalance Types The system supports three types of rebalance operations: ### Increase Stake - When: Validator performance is good and needs more stake - Actions: Moves SOL from reserve to validator's stake account - Parameters: - Target lamports amount - Transient seed Process [`increase_validator_stake`](https://github.com/solana-program/stake-pool/blob/main/program/src/processor.rs#L1497) instruction on `spl-stake-pool` program ### Decrease Stake - When: Validator underperforming or stake needs redistribution - Action: Moves stake back to reserve using transient stake account - Parameters: - Total unstake lamports - Decrease components Process [`decrease_validator_stake_with_reserve`](https://github.com/solana-program/stake-pool/blob/main/program/src/processor.rs#L1180) instruction on `spl-stake-pool` program ### No Action - When: Current stake allocation is optimal - Action: No stake movement required --- # Instant Unstaking > Automated validator removal based on performance and fee criteria All validators are checked for a set of Instant Unstaking criteria, like commission thresholds, delinquency, etc. If they hit the criteria, they are marked for the rest of the cycle. ## Overview The system automatically identifies validators that should be unstaked immediately based on 4 criteria: 1. **Delinquency**: Poor block production performance (based on Timely Vote Credits) 2. **High Commission**: Commission rates above threshold 3. **High MEV Commission**: MEV commission above threshold 4. **Blacklisted**: Validator is on a blacklist ## Example Scenario Let's say we're in epoch 500, and we want to evaluate validator at index 42. ### Initial Setup ```rust // Current state let current_epoch = 500; let epoch_start_slot = 216_000_000; // First slot of epoch 500 let current_slot = 216_100_000; // We're partway through the epoch // Validator we're evaluating let validator_index = 42; let validator_vote_account = "Vote111111111111111111111111111111111111111"; ``` ### Step 1: Instruction Call ```rust // Keeper calls the compute_instant_unstake instruction compute_instant_unstake( ctx: Context, validator_list_index: 42 // Index of validator to evaluate ) ``` ### Step 2: State and Input Validation ```rust // Check we're in the right state assert_eq!(state_account.state.state_tag, StewardStateEnum::ComputeInstantUnstake); // Check we're past the minimum epoch progress (90% through epoch) let epoch_progress = (current_slot - epoch_start_slot) as f64 / slots_in_epoch as f64; assert!(epoch_progress >= 0.90); // instant_unstake_epoch_progress = 90% // Check validator hasn't been processed yet assert!(!state_account.state.progress.get(42)?); // false = not processed // Check validator data is recent enough (50% through epoch minimum) let min_acceptable_slot = epoch_start_slot + (slots_in_epoch as f64 * 0.50).round() as u64; assert!(validator_history.vote_account_last_update_slot >= min_acceptable_slot); assert!(cluster_history.cluster_history_last_update_slot >= min_acceptable_slot); ``` ### Step 3: Instant Unstake Calculation ```rust // Calculate shared values let cluster_history_slot_index = cluster_history_last_update_slot - epoch_start_slot; // = 216_090_000 - 216_000_000 = 90_000 let validator_history_slot_index = vote_account_last_update_slot - epoch_start_slot; // = 216_085_000 - 216_000_000 = 85_000 let total_blocks_latest = 85_000; // Total blocks produced by cluster let epoch_credits_latest = 450; // Credits earned by this validator ``` ### Step 4: Compute Checks #### Delinquency Check ```rust // Calculate rates for cluster and validator let blocks_produced_rate = total_blocks_latest as f64 / cluster_history_slot_index as f64; // = 85_000 / 90_000 = 0.944 blocks per slot let vote_credits_rate = epoch_credits_latest as f64 / validator_history_slot_index as f64; // = 450 / 85_000 = 0.00529 credits per slot // Calculate delinquency ratio using TVC multiplier (16) const TVC_MULTIPLIER: u32 = 16; let delinquency_ratio = vote_credits_rate / (blocks_produced_rate * (TVC_MULTIPLIER as f64)); // = 0.00529 / (0.944 * 16.0) = 0.00529 / 15.104 = 0.00035 let delinquency_check = delinquency_ratio < 0.85; // Vote Credits Delinquency Threshold = 85% // 0.00035 < 0.85 = true (FAIL - validator is severely delinquent) ``` ##### What this means: - Expected: This validator should earn ~15.1 credits/slot if performing optimally - Actual: They're only earning ~0.005 credits/slot - Performance: Only 0.035% of expected perfomance (far below 85% threshold) - Issues: Likey severe downtime, very slow voting, or consistently wrong fork voting #### Commission Check ```rust let commission = validator.history.commission_latest().unwrap_or(100); // COMMISSION_MAX = 100% // = 8 (8% - stored as integer, not basis points) let commission_check = commission > 5; // Commission Threshold = 5% // 8 > 5 = true (FAIL - commission too high) ``` #### MEV Commission Check ```rust let previous_epoch = current_epoch.saturating_sub(1); // = 499 let example_current_epoch = 500; // Get MEV commission for previous and current epoch, take the maximum let mev_commission_range = validator.history.mev_commission_range(previous_epoch, example_current_epoch); // Returns [Some(1000), Some(1200)] for epochs 499 and 500 let mev_commission_bps = mev_commission_range .iter() .filter_map(|&i| i) .max() .unwrap_or(0); // = max(1000, 1200) = 1200 basis points (12.00%) let mev_commission_check = mev_commission_bps > 1000; // MEV Commission Threshold = 10% // 1200 > 1000 = true (FAIL - MEV commission too high) ``` #### Blacklist Check ```rust let is_blacklisted = config.validator_history_blacklist.get(validator_index)?; // = config.validator_history_blacklist.get(42) = false ``` ### Step 5: Final Result ```rust let instant_unstake = delinquency_check || commission_check || mev_commission_check || is_blacklisted; // = true || true || true || false = true // This validator SHOULD be unstaked because: // - Severely delinquent (performance ratio 0.00035 vs 0.85 threshold) // - Commission too high (8% vs 5% threshold) // - High MEV commission (12% vs 10% threshold) ``` ### Step 6: State Update and Event Emission ```rust // Update the state state_account.instant_unstake.set(42, true)?; // Mark for unstaking state_account.progress.set(42, true)?; // Mark as processed // Emit the result event emit!(InstantUnstakeComponentsV2 { instant_unstake: true, delinquency_check: true, // FAIL - 0.00035 << 0.85 threshold commission_check: true, // FAIL - 8% > 5% threshold mev_commission_check: true, // FAIL - 12% > 10% threshold is_blacklisted: false, vote_account: validator_vote_account, epoch: 500, details: InstantUnstakeDetails { epoch_credits_latest: 450, vote_account_last_update_slot: 216_085_000, total_blocks_latest: 85_000, cluster_history_slot_index: 90_000, commission: 8, // 8% (stored as integer) mev_commission: 1200, // 12.00% (in basis points) }, }); ``` ## Key Calculation Details ### Delinquency Formula The delinquency check uses a formula that accounts for the TVC (Timely Vote Credits) multiplier: ```rust delinquency_ratio = vote_credits_rate / (blocks_produced_rate * TVC_MULTIPLIER) ``` Where: - `vote_credits_rate`: validator's credits earned per slot - `blocks_produced_rate`: cluster's blocks produced per slot - `TVC_MULTIPLIER`: 16 (maximum credits per vote under Timely Vote Credits) ### MEV Commission Logic MEV commission checks the maximum commission between the previous and current epoch, ensuring validators can't game the system by temporarily lowering rates. ### Commission Storage Regular commission is stored as an integer percentage (8 = 8%), while MEV commission uses basis points (1200 = 12.00%). ## Example Results for Different Validators Using the actual Steward configuration thresholds: - Delinquency Threshold: 85% (Vote Credits Delinquency Threshold) - Commission Threshold: 5% (Commission Threshold) - MEV Commission Threshold: 10% (MEV Commission Threshold) | Validator | Delinquency | Commission | MEV Commission | Blacklisted | Result | |-----------|-------------|------------|----------------|-------------|---------| | A | ✅ 98% | ✅ 3% | ✅ 8% | ❌ | Keep | | B | ❌ 80% | ✅ 4% | ✅ 9% | ❌ | Unstake | | C | ✅ 90% | ❌ 7% | ✅ 6% | ❌ | Unstake | | D | ✅ 95% | ✅ 4% | ❌ 12% | ❌ | Unstake | | E | ✅ 88% | ✅ 2% | ✅ 5% | ✅ | Unstake | ## Key Points 1. **Timing**: Only runs after 90% progress through the epoch (Instant Unstake Epoch Progress) 2. **Data Freshness**: Requires validator/cluster data updated after 50% epoch progress (Instant Unstake Inputs Epoch Progress) 3. **One Shot**: Each validator is processed only once per cycle 4. **Multiple Criteria**: Any single failure triggers instant unstake 5. **Strict Thresholds**: Commission >5%, MEV Commission >10%, Delinquency <85% 6. **State Management**: Tracks progress and results in persistent state 7. **Event Driven**: Emits detailed events for monitoring and debugging This system helps maintain stake pool health by automatically removing underperforming validators without manual intervention. --- # Steward UI # Steward UI [Detailed description of the Steward UI in progress. For now, check the tooltips on the website and read Program Overview.] --- # Program Overview > On-chain validator data aggregation and historical tracking The Validator History Program is a foundational component of Jito StakeNet that creates an on-chain record of verified Solana validator data, storing up to 512 epochs of history per validator. ## What It Does The program aggregates diverse validator metrics that are typically scattered across different data sources into a single, easily accessible on-chain account. This includes: - **Runtime-accessible data**: validator performance history, validator commission, MEV commission - **Gossip network data**: validator IP addresses, software versions, and client types - **Network position data**: total active stake per validator, stake rank, and superminority status All these fields are consolidated into a single ValidatorHistory account per validator, enabling seamless composition with other on-chain programs while providing extensive historical lookback capabilities. ## Why It Matters Before the Validator History Program, accessing comprehensive validator data required querying multiple disparate sources and APIs. This created friction for: - **Stake pool managers** needing to evaluate validator performance over time - **On-chain programs** requiring historical validator context for decision-making - **Network participants** seeking transparent, verifiable validator metrics By consolidating this data on-chain with a long historical record, the program enables more sophisticated validator selection algorithms and transparent network analysis. ## Role in StakeNet The Validator History Program serves as the data foundation for StakeNet's autonomous operations. The [Jito Steward Program](https://www.jito.network/docs/stakenet/jito-steward/program-overview.md) relies on this historical data to make informed staking decisions, using the comprehensive validator metrics to optimize stake allocation across the network. ## Core Accounts The Validator History Program operates through three main account types: - **Config**: Global configuration and admin authorities for the Validator History Program - **ValidatorHistory**: Tracks historical metadata on-chain for a single validator using a circular buffer structure - **ClusterHistory**: Stores network-wide cluster information and metrics This architecture ensures efficient data storage while maintaining the flexibility needed for complex validator analysis and automated decision-making. --- # Key Features & Capabilities > Data persistence, aggregation, and transparent validator metrics The Validator History Program provides features designed to make validator data accessible, reliable, and actionable. ## Historical Data Persistence **512 Epochs of History**: Each validator's historical data spans up to [512 epochs](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L105), providing approximately 3 years of performance history. **Circular Buffer Architecture**: Data is stored using an efficient [circular buffer](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L107-L114) that automatically manages storage space. As new epochs are added, the oldest data is overwritten, maintaining a consistent account size while preserving the most relevant historical information. ## Comprehensive Data Aggregation Rather than requiring multiple API calls across different data sources, the Validator History Program consolidates all key validator metrics into a single account: **Performance Metrics** - Vote credits and block production history - Skip rates and consensus participation - Historical uptime and reliability scores **Economic Data** - Commission rate changes over time - MEV commission tracking - Stake rewards and distributions **Network Participation** - Gossip network data (IP addresses, ports) - Software version history - Client type **Stake Information** - Total active stake per epoch - Validator ranking within the network - Superminority status tracking ## Single Account Access **Simplified Integration**: Developers can access all validator data through a single ValidatorHistory account, eliminating the complexity of querying multiple data sources. This design enables seamless integration with other on-chain programs. **Composability**: The unified account structure allows other programs, like the Jito Steward Program, to easily incorporate historical validator data into their decision-making algorithms without additional infrastructure. ## On-Chain Verification & Transparency **Verifiable Data**: All validator information is stored on-chain and can be independently verified through standard Solana RPC calls. This transparency builds trust and enables permissionless access to validator performance data. **Immutable History**: Once written to the blockchain, historical data cannot be altered, providing a reliable and tamper-proof record of validator performance over time. ## Automated Data Collection **Epoch-Based Updates**: Data is automatically collected and updated each epoch, ensuring that the historical record stays current without manual intervention. **Multi-Source Integration**: The program seamlessly combines data from Solana's runtime, gossip network, and other verifiable sources into a cohesive historical record. These features work together to create a robust foundation for validator analysis, enabling sophisticated staking strategies and transparent network monitoring across the Solana ecosystem. --- # Technical Architecture > On-chain data structures and stroage architecture The Validator History Program employs technical architecture designed for efficient on-chain storage and retrieval of historical validator data. ## Core Account Structure ### Config Account The [`Config`](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L18) account defines the global configuration of validator history program. - **Admin Management**: Tracks administrative authorities - **Oracle Permissions**: Manages data upload permissions - **Program Integration**: Links to [tip distribution program](https://github.com/jito-foundation/jito-programs/blob/master/mev-programs/programs/tip-distribution/Cargo.toml) - **Counter Tracking**: Monitors total ValidatorHistory accounts ### ValidatorHistory Account The [`ValidatorHistory`](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L359) account serves as the primary data container for each validator. **Key Components:** - **Size**: [65,848 bytes](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L355) per validator account - **Storage Capacity**: Up to 512 epochs of historical data - **Zero-Copy Design**: Implements `bytemuck::{Pod, Zeroable}` traits for efficient memory management - **Unique Identifier**: Each account is indexed and linked to a specific vote account #### Circular Buffer Implementation At the heart of each ValidatorHistory account lies the `CircBuf` - a circular buffer that efficiently manages historical data storage: **Buffer Characteristics:** - **Fixed Size**: 512 entries maximum (`MAX_ITEMS = 512`) - **Wrap-Around Behavior**: Automatically overwrites oldest data when capacity is reached - **Index Tracking**: Maintains current position with `idx` pointer - **Empty State Management**: Tracks buffer state to handle initialization **Memory Efficiency:** The circular buffer prevents account bloat by maintaining a constant size regardless of how much historical data has been collected. When new epochs are added beyond the 512-entry limit, the oldest entries are automatically overwritten. #### Data Structure Design ##### ValidatorHistoryEntry Each epoch's data is stored in a [`ValidatorHistoryEntry`](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L43) struct (128 bytes) containing: **Performance Metrics:** ```rust pub epoch_credits: u32, // Vote credits earned pub commission: u8, // Validator commission percentage pub mev_commission: u16, // MEV commission in basis points pub mev_earned: u32, // MEV rewards (stored as 1/100th SOL) ``` **Validator Information:** ```rust pub ip: [u8; 4], // IPv4 address pub version: ClientVersion, // Software version (major.minor.patch) pub client_type: u8, // Client type ``` **Stake Data:** ```rust pub activated_stake_lamports: u64, // Total active stake pub rank: u32, // Validator rank by stake pub is_superminority: u8, // Superminority status (0/1) ``` **Metadata:** ```rust pub epoch: u16, // Epoch number pub vote_account_last_update_slot: u64, // Last update slot ``` ### ClusterHistory Account The [`ClusterHistory`](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L791) account serves as the primary data for cluster. - **Network Metrics**: Stores cluster-wide statistics - **Block Production**: Tracks total blocks per epoch - **Timestamp Data**: Records epoch start times - **Same Architecture**: Uses identical circular buffer design #### Data Structure Design ##### ClusterHistoryEntry Each epoch's data is stored in a [`ClusterHistoryEntry`](https://github.com/jito-foundation/stakenet/blob/7ea745985c2e31d43d957ac5885e69b328b6f283/programs/validator-history/src/state.rs#L802) struct containing: **Cluster Information** ```rust pub total_blocks: u32, // Total blocks pub epoch: u16, // Epoch number pub epoch_start_timestamp: u64 // Timestamp number ``` ## Memory and Performance Optimizations **Zero-Copy Architecture**: Eliminates runtime memory allocation overhead by using fixed-size structures that can be directly mapped to account data. **Efficient Storage Layout**: C-style struct alignment ensures optimal memory usage and prevents compiler-added padding. **Batch Operations**: Support for bulk updates of historical data without individual transaction overhead. **Normalized Data Access**: Built-in handling for network changes like Timely Vote Credits (TVC) activation. This architecture enables the Validator History Program to provide comprehensive historical data access while maintaining the performance and cost-efficiency required for on-chain operations. --- # Data Fields Explained > Comprehensive breakdown of validator metrics and data sources The Validator History Program tracks diverse validator metrics from multiple sources. Understanding these data fields is essential for effective validator analysis and selection. ## Activated Stake (`activated_stake_lamports`) - **What**: The total amount of active stake delegated to the validator in lamports - **Why it matters**: Primary factor in validator selection algorithms and network influence ## Epoch (`epoch`) - **What**: The Solana epoch number when this data was recorded - **Why it matters**: Provides temporal indexing for historical analysis and trend tracking - **Range**: 16-bit unsigned integer (0-65,535) ## MEV Commission (`mev_commission`) - **What**: Maximum Extractable Value commission rate in basis points - **Why it matters**: Shows validator's MEV sharing policy with delegators ## Epoch Credits (`epoch_credits`) - **What**: Number of successful votes cast by the validator in the current epoch - **Why it matters**: Primary measure of validator performance and consensus participation ## Commission (`commission`) - **What**: Validator's commission rate as a percentage (0-100) - **Why it matters**: Directly affects delegator rewards and validator economics ## Client Type (`client_type`) - **What**: Software client implementation identifier - **Values**: - `0` = Solana Labs - `1` = Jito Labs - `2` = Firedancer - `3` = Agave - `>3` = Other implementations - **Why it matters**: Monitor client diversity - **Collection**: Derived from version information in gossip messages ## Client Version (`version`) - **What**: Software version in major.minor.patch format - **Why it matters**: Track software adoption, compatibility, and network upgrades - **Collection**: From gossip version messages broadcast by validators - **Usage**: Helps monitor network-wide software update progress ## IP Address (`ip`) - **What**: Validator's IPv4 address as a 4-byte array - **Why it matters**: Enables network topology analysis and geographic distribution studies - **Collection**: Extracted from gossip ContactInfo messages ## Superminority Status (`is_superminority`) - **What**: Boolean indicator of superminority membership (0 = false, 1 = true) - **Why it matters**: Critical for network decentralization and security analysis - **Collection**: Calculated based on cumulative stake thresholds - **Definition**: Validators that collectively control >33% of total network stake ## Validator Rank (`rank`) - **What**: Validator's position when ranked by total active stake (1 = highest stake) - **Why it matters**: Shows validator's relative influence and selection probability - **Collection**: Calculated by sorting all validators by stake amount - **Usage**: Lower rank numbers indicate higher stake and network influence ## Last Update Slot (`vote_account_last_update_slot`) - **What**: Most recent slot when the validator's vote account was updated - **Why it matters**: Indicates data freshness for commission and epoch credit information - **Usage**: Helps determine if validator data is current or stale ## MEV Earned (`mev_earned`) - **What**: MEV rewards earned by the validator (stored as 1/100th SOL) - **Why it matters**: Indicates validator's MEV generation capability and additional rewards - **Example**: Value of 150 = 1.50 SOL earned in MEV rewards - **Collection**: Aggregated from tip distribution data ## Is BAM Connected (`is_bam_connected`) - **What**: Whether this validator is connected to BAM (Block Assembly Marketplace) - **Why it matters**: Used to compute the `running_bam_score` score, which checks if a validator has maintained BAM connectivity for at least a minimum number of epochs within a rolling window. Validators that do not meet the threshold are excluded from delegation. - **Example**: A value of 0 = not connected, 1 = connected - **Collection**: Derived from the per-validator BAM connection rate reported by the Kobe API. A validator is marked connected (`1`) when its `bam_connection_rate` meets or exceeds a configurable threshold (`min_bam_connection_rate`, a value between `0.0` and `1.0`, currently `0.90`); otherwise it is `0`. The keeper reads the previous epoch's stats and writes the flag to that epoch's history entry, once per epoch at ~10% epoch progress. - **Usage**: Evaluated over a configurable window (`jito_bam_window_epochs`); validators must be connected for at least `jito_bam_minimum_epochs` out of the window to qualify. Epochs with missing data reduce the effective threshold rather than counting as disconnected. Understanding these data fields enables developers to build sophisticated validator analysis tools, stake pool managers to make informed decisions, and network participants to monitor validator performance transparently. --- # Integration & Composability > Building with validator history data The Validator History Program's unified data structure enables seamless integration with other on-chain programs and off-chain applications, creating a composable foundation for validator analysis and automated decision-making. ## How Other Programs Access Data ### Direct Account Reading On-chain programs can directly read ValidatorHistory accounts using standard Solana account access patterns: ```rust #[derive(Accounts)] pub struct ReadValidatorHistory<'info> { #[account( seeds = [ValidatorHistory::SEED, vote_account.key().as_ref()], seeds::program = validator_history::ID, bump )] pub validator_history_account: AccountLoader<'info, ValidatorHistory>, #[account(owner = vote::program::ID)] pub vote_account: AccountInfo<'info>, } ``` ### Account Discovery Programs can find ValidatorHistory accounts using predictable seed derivation: - **Seed pattern**: `["validator-history", vote_account_pubkey]` - **Program ID**: The Validator History Program ID (`HistoryJTGbKQD2mRgLZ3XhqHnN811Qpez8X9kCcGHoa`) - **Deterministic addresses**: Every vote account has a corresponding ValidatorHistory account ### Data Parsing Best Practices **Circular Buffer Navigation**: ```rust // Access latest validator data let latest_entry = validator_history.history.last(); // Query specific epoch range let epoch_range = validator_history.history.epoch_range(start_epoch, end_epoch); // Check for valid data (non-default values) if entry.commission != u8::MAX { // Process valid commission data } ``` ## Integration Examples ### Jito Steward Program The [Jito Steward Program](https://www.jito.network/docs/stakenet/jito-steward/program-overview.md) serves as the primary example of deep integration with Validator History data: #### Validator Scoring Algorithm: - **Vote Credits Score**: Uses `epoch_credits_range_normalized()` to measure consensus participation over multiple epochs - **Commission Score**: Analyzes `commission_range()` to evaluate commission stability and competitiveness - **MEV Commission Score**: Incorporates `mev_commission_range()` for validators running Jito clients - **Historical Perfomance**: Combines multiple epochs of data for robust scoring rather than single-epoch snapshots #### Eligibility Filtering: - **Superminority Check**: Uses `superminority_latest()` to exclude validators that would concentrate stake - **Perfomance Thresholds**: Filters validators based on minimum epoch credits requirements - **Commission Limits**: Applies maximum commission thresholds from historical data - **Blacklist Management**: Maintains on-chain blacklist of problematic validators #### Stake Allocation Logic: - **Score-Based Ranking**: Ranks eligible validators using composite scores from historical data - **Diversification**: Considers validator geographic and client distribution from gossip data - **Rebalancing**: Uses historical perfomance trends to guide stake reallocation decisions #### Automated Decision Making - **512 Epochs of Context**: Leverages full historical depth for informed validator evaluation - **Transparent Criteria**: All scoring logic is on-chain and auditable - **No External Dependencies**: Entirely self-contained using ValidatorHistory data ## Development Patterns & Best Practices ### Efficient Data Access **Latest Value Queries**: ```rust // Optimized for current state let current_commission = validator_history.history.commission_latest(); let current_stake = validator_history.history.last()?.activated_stake_lamports; ``` **Historical Range Analysis**: ```rust // Efficient range queries with automatic null handling let commission_history = validator_history.history.commission_range( start_epoch, end_epoch ); ``` ## Integration Architecture Patterns ### On-Chain Integration **Direct Program Composition**: - Programs read ValidatorHistory accounts as additional context - Decision-making logic incorporates historical performance - Eliminates dependency on external data sources **State Machine Integration**: - Validator history informs state transitions - Historical context enables sophisticated automation - Transparent, verifiable decision criteria ### Off-Chain Integration **Analytics and Dashboards**: - [Stakenet History Dashboard](https://www.jito.network/stakenet/history/): Interactive validator perfomance monitoring and historical analysis - Real-time validator metrics visualization with 512 epochs of data - Comparative validator analysis and ranking tools - Historical trend analysis across performance dimensions ## Composability Benefits ### Single Source of Truth **Eliminates Data Fragmentation**: - All validator metrics in one standardized location - Consistent data formats across different applications - Reduced integration complexity for developers **Infrastructure Efficiency**: - No need to maintain separate historical databases - Shared data infrastructure across the ecosystem - Lower operational costs for validator analysis tools ### Programmable Transparency **Verifiable Decision Making**: - All historical data is publicly auditable - Algorithm transparency through on-chain logic - Reduced trust requirements for automated systems **Standardized Metrics**: - Common performance indicators across applications - Comparable results between different analysis tools - Network-wide consistency in validator evaluation This composable architecture enables a thriving ecosystem of validator analysis tools, automated stake management systems, and transparent network monitoring applications, all built on a shared foundation of verified historical data. --- # Validator History API # Validator History API ## Validator History Endpoint This endpoint allows you to fetch all validator histories by vote account ### Endpoint `GET https://kobe.mainnet.jito.network/api/v1/validator_history/{vote_account}` ### Parameters | Parameter | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------- | | epoch | Integer | No | Filter validator history entry by epoch number | ### Example Request: Get a validator's scores `GET https://kobe.mainnet.jito.network/api/v1/validator_history/J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv?epoch=861` ```json { "struct_version": 0, "vote_account": "J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv", "index": 321, "last_ip_timestamp": 1760935613523, "last_version_timestamp": 1760935613523, "validator_age": 542, "validator_age_last_updated_epoch": 866, "history": [ { "activated_stake_lamports": 825617784728539, "epoch": 861, "mev_commission": 800, "epoch_credits": 6901581, "commission": 4, "client_type_id": 6, "client_type": "BAM", "version": "2.3.11", "ip": "88.211.250.188", "merkle_root_upload_authority": "TipRouter", "is_superminority": 0, "rank": 97, "vote_account_last_update_slot": 372342468, "mev_earned": 396, "priority_fee_commission": 5000, "priority_fee_tips": 4781931582, "total_priority_fees": 2570378128, "total_leader_slots": 240, "blocks_produced": 240, "block_data_updated_at_slot": 372384000, "priority_fee_merkle_root_upload_authority": "TipRouter" } ] } ``` --- # Validator History CLI Guide > Commands and operations for Validator History management ## Accounts | Account | Address | | ------------------------ | -------------------------------------------- | | Program | HistoryJTGbKQD2mRgLZ3XhqHnN811Qpez8X9kCcGHoa | | Validator History Config | BZP2F1L4FwCaeTPmCmfGiVJAiMFwGawo5mbLj4JFzwEd | ## CLI Commands Build CLI binary from root directory: ```bash cargo build -p validator-history-cli --release ``` ### Configuration Commands #### Initialize Config Creates config account and sets tip distribution program address. ```bash ./target/release/validator-history-cli \ --json-rpc-url 'https://api.mainnet-beta.solana.com' \ init-config \ --keypair-path ~/.config/solana/id.json \ --tip-distribution-program-id '' \ --tip-distribution-authority '' \ --stake-authority '' ``` **Parameters:** - `--keypair-path`: Path to keypair for account creation and transactions - `--tip-distribution-program-id`: Tip distribution program ID (required) - `--tip-distribution-authority`: New tip distribution authority (optional) - `--stake-authority`: New stake authority (optional) #### Initialize Cluster History Creates cluster history account with proper reallocation. ```bash ./target/release/validator-history-cli \ --json-rpc-url 'https://api.mainnet-beta.solana.com' \ init-cluster-history \ --keypair-path ~/.config/solana/id.json ``` ### Data Query Commands #### Cranker Status Displays validator history entries for a specific epoch with summary statistics. ```bash ./target/release/validator-history-cli \ --json-rpc-url '' \ cranker-status \ --epoch 500 ``` **Parameters:** - `--epoch`: Epoch to get status for (optional, defaults to current epoch) **Output includes:** - Commission data - Epoch credits - MEV commission and earnings - Stake amounts - Validator rankings - IP addresses and client information - Summary statistics for all validators #### View Validator History Displays complete history for a single validator across epochs. ```bash ./target/release/validator-history-cli \ --json-rpc-url 'https://api.mainnet-beta.solana.com' \ history 'J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv' \ --start-epoch 450 ``` **Parameters:** - `validator`: Validator vote account address (required), you can find vote account [here](https://www.jito.network/stakenet/history/) - `--start-epoch`: Starting epoch for history display (optional) #### View Cluster History Status Displays cluster-wide block production history. ```bash ./target/release/validator-history-cli \ --json-rpc-url 'https://api.mainnet-beta.solana.com' \ cluster-history-status ``` ### Maintenance Commands #### Backfill Cluster History Backfills cluster history data for a specific epoch. ```bash ./target/release/validator-history-cli \ --json-rpc-url 'https://api.mainnet-beta.solana.com' \ backfill-cluster-history \ --keypair-path ~/.config/solana/id.json \ --epoch 500 \ --blocks-in-epoch 432000 ``` **Parameters:** - `--epoch`: Epoch to backfill (required) - `--blocks-in-epoch`: Number of blocks in the epoch (required) ### Analytics Commands #### Stake Distribution by Country Displays JitoSOL stake distribution by country. ```bash ./target/release/validator-history-cli \ --json-rpc-url \ stake-by-country \ --stake-pool \ --country \ --ip-info-token ``` **Description**: This command analyzes the geographical distribution of JitoSOL stake across validators worldwide. It fetches validator IPs from their history account and determines their countries using IP geolocation. **Parameters:** - `--stake-pool`: The stake pool address to analyze (required) - `--country`: Filter results to show only a specific country (optional) - `--ip-info-token`: API token for IP geolocation service (required) To obtain an IP info token, sign up at https://ipinfo.io ##### View all countries: ```bash ./target/release/validator-history-cli \ --json-rpc-url \ stake-by-country \ --stake-pool 3DuPtyTAKrxKfHkSPZ5fqCayMcGru1BarAKKTfGDeo2j \ --ip-info-token YOUR_IPINFO_TOKEN ``` ##### View specific country: ```bash ./target/release/validator-history-cli \ --json-rpc-url \ stake-by-country \ --stake-pool 3DuPtyTAKrxKfHkSPZ5fqCayMcGru1BarAKKTfGDeo2j \ --country "United States" \ --ip-info-token YOUR_IPINFO_TOKEN ``` --- # Jito Tip Router Jito Tip Router NCN will assume programmatic operations related to the distribution of MEV tips generated from the Jito Tip Distribution protocol every epoch, and, as part of these programmatic operations, will route some portion of all MEV tips collected to the DAO treasury and the NCN network participants. ## Overview Jito Tip Router NCN is handling operation of distribution of MEV tips generated from the Jito Tip Distribution protocol. The system is made of 3 components: - Onchain NCN program - Node Operator Client - Permissionless Cranker ### Onchain NCN Program (Jito Tip Router Program): Onchain NCN program has several components: - Pricing - Switchboard determines the relative weight of assets ( JitoSOL, JTO, ... ) deposited in all the Vaults linked to this Jito Tip Router NCN. - Snapshot - Take snapshots of Operator and Vault per epoch. - Core Logic (Consensus) - Prepare Ballot Box, all votes would be collected here. - Each operator calculate the merkle tree to produce merkle root then cast vote with produced merkle root. - After consensus reached with more than 2/3, cranker can upload the merkle tree of each validator. - Reward Payment ### Node Operator Client - Node operators will compute a `meta merkle root` — a merkle root derived from a new merkle tree containing all validator merkle trees. - Upload `meta merkle root` on-chain. ### Permissionless Cranker - Take snapshots of Operator and Vault per epoch. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/overview.png) *Figure: Overview of the Jito Tip Router* ## Addresses | Network | Program | Address | Version | |---------|------------|----------------------------------------------| --------- | | Mainnet | Tip Router | RouterBmuRBkPUbgEDMtdvTZ75GBdSREZR5uGUxxxpb | 0.0.1 | ## License This project is licensed under the Business Source License 1.1 - see the [LICENSE.md](https://github.com/jito-foundation/jito-tip-router/blob/master/LICENSE-MIT) file for details. --- # Terminology - **MEV (Maximum Extractable Value) Tips**: Tips paid by users participating in a blockspace auction powered by Jito-Solana. - **Jito Tip Router NCN (Node Consensus Network)**: A decentralized network that takes responsibility for programmatically handling the distribution of tips collected by the Tip Distribution Protocol. - **Tip Distribution Protocol**: A mechanism that aggregates SOL, generates a merkle tree and merkle root for distribution, and transfers SOL to the appropriate users/accounts. - **Merkle Root**: A cryptographic representation of a set of data (in this case, validator tips) that is used to verify the integrity of data stored or transmitted in the network. - **Node**: A piece of software running the required protocols as specified by the node consensus network. - **Node Consensus Network (NCN)**: A set of nodes running software for the same network, working together to achieve consensus and provide services. - **Operator**: An entity that manages one or more nodes in the node consensus network. --- # Pricing ## Introduction The Pricing section of the Jito Tip Router defines the mechanisms for managing and updating price data for supported tokens and vaults within the system. Accurate and efficient pricing is critical for ensuring fair and transparent reward distribution across participants. This section introduces key components, such as the `VaultRegistry` and `WeightTable`, which are used to store metadata, pricing information, and asset weights. The pricing architecture leverages oracle feeds, (currently Switchboard), to provide real-time price updates for supported tokens from vaults. Additionally, it includes fallback mechanisms for scenarios where feeds are unavailable, ensuring continuous operation. The system supports permissionless interactions for certain roles, such as Crankers, to initialize and update accounts, making the pricing process both robust and decentralized. This section covers: - **VaultRegistry**: A registry for storing metadata about vaults and their associated tokens, including pricing feeds and backup weights. - **WeightTable**: A mechanism to assign weights to assets each epoch based on their relative value, ensuring dynamic and fair pricing adjustments. The pricing system ensures that all registered vaults and tokens within the Jito Tip Router NCN operate with accurate and transparent price data, fostering trust and efficiency in the ecosystem. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/pricing.png) *Figure: Overview of the Pricing ## VaultRegistry ### Initialize VaultRegistry A Permissionless Cranker initializes the `VaultRegistry` account to store metadata about vaults registered for the Jito Tip Router NCN and information about underlying tokens. While the [Jito Vault Program] stores all on-chain vault information, the Permissionless Cranker manages key details, quotes important data, and uploads it to the `VaultRegistry`. ```rust pub struct VaultRegistry { ... /// The list of supported token ( ST ) mints pub st_mint_list: [StMintEntry; 64], /// The list of vaults pub vault_list: [VaultEntry; 64], } ``` [Jito Vault Program]: https://docs.restaking.jito.network/vault/00_vault_accounts/ ### Register Supported Token Mint (st_mint_list) The Admin registers a supported token mint using the `process_admin_register_st_mint` instruction. This stores relevant information in the `st_mint_list` field of the `VaultRegistry`. Details of each supported token mint include: - **Token Mint Pubkey**: The unique identifier for the token mint. - **Pricing Information**: A custom feed or fixed price if no feed is available. ```rust pub struct StMintEntry { /// The supported token ( ST ) mint st_mint: Pubkey, /// The fee group for the mint ncn_fee_group: NcnFeeGroup, /// The reward multiplier in basis points reward_multiplier_bps: PodU64, /// Either a switchboard feed or a no feed weight must be set /// The switchboard feed for the mint switchboard_feed: Pubkey, /// The weight when no feed is available no_feed_weight: PodU128, } ``` This field enables the storage of an oracle feed for each underlying asset (supported token or ST) along with a backup price. The `reward_multiplier_bps` is used for mints that receive a multiplier on their relative reward amounts (for example, JitoSOL gets 2x the rewards of other LSTs). Initially, the mints permitted for vaults include **LSTs** and **JTO**. Prices will be quoted in SOL. ### Register Vault (vault_list) Permissionless Cranker can register the vault which is associated with Jito Tip Router NCN. Before running `process_register_vault` instruction, both `NcnVaultTicket` and `VaultNcnTicket` accounts must be activated ```rust pub struct VaultEntry { /// The vault account vault: Pubkey, /// The supported token ( ST ) mint of the vault st_mint: Pubkey, /// The index of the vault in respect to the NCN account vault_index: PodU64, /// The slot the vault was registered slot_registered: PodU64, } ``` ## WeightTable ### Initialize Weight Table Permissionless Cranker initializes `WeightTable` account each epoch to store weights for each asset. ```rust pub struct WeightTable { ... /// The weight table table: [WeightEntry; 64], } ``` ### Set weight by Switchboard The weights will be set for each asset via Switchboard feeds through `switchboard_set_weight` instruction. ```rust pub struct WeightEntry { /// Info about the ST mint st_mint_entry: StMintEntry, /// The weight of the ST mint weight: PodU128, /// The slot the weight was set slot_set: PodU64, /// The slot the weight was last updated slot_updated: PodU64, } ``` --- # Snapshot ## Introduction In order to have fixed voting weights for consensus, a snapshot process is done to track the stake balances of all operators, and the composition of assets for each operator for reward payouts later in the epoch. Fees are also stored. This is performed in a top-down approach: 1. Initialize `WeightTable`, finalize it. 2. Initialize `EpochSnapshot`. 3. Initialize `OperatorSnapshot`. 4. Tracks stake weights and stake reward multipliers based on asset type. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/snapshot.png) *Figure: Overview of the Snapshot ## EpochSnapshot ### Initialize & Realloc EpochSnapshot A Permissionless Cranker initializes and reallocs `EpochSnapshot` account to store snapshot which is summary of current epoch. - `fees`: Snapshot of the NCN Fees for the epoch - `operator_count`: The count of operator is associated with Jito Tip Router - `vault_count`: The count of vault is associated with Jito Tip Router (* number of `VaultEntry` stored in `WeightTable` account) - `stake_weights`: The total stake weights for all vault operator delegations ```rust pub struct EpochSnapshot { ... /// Snapshot of the Fees for the epoch fees: Fees, /// Number of operators in the epoch operator_count: PodU64, /// Number of vaults in the epoch vault_count: PodU64, ... /// Tallies the total stake weights for all vault operator delegations stake_weights: StakeWeights, } ``` ## OperatorSnapshot ### Initialize & Realloc OperatorSnapshot A Permissionless Cranker initializes and reallocs`OperatorSnapshot` account each epoch. ```rust pub struct OperatorSnapshot { ... operator: Pubkey, is_active: PodBool, ncn_operator_index: PodU64, operator_index: PodU64, operator_fee_bps: PodU16, vault_operator_delegation_count: PodU64, vault_operator_delegations_registered: PodU64, valid_operator_vault_delegations: PodU64, vault_operator_stake_weight: [VaultOperatorStakeWeight; 64], } ``` --- # Core Logic ## Introduction The Core Logic section of the Jito Tip Router outlines the mechanisms behind the voting and consensus process, which ensures fair and decentralized decision-making. By utilizing a structured voting system and consensus rules, the Jito Tip Router enables operators to securely cast votes and reach agreement on key decisions, such as the selection of a meta merkle root. This section focuses on two main components: 1. **Ballot Box**: A critical account that tracks operator votes, ballot tallies, and consensus progress for each epoch. 2. **Voting and Consensus Mechanism**: The process of casting votes, updating tallies, and reaching a 2/3 consensus based on stake weights. Once consensus is achieved, the `meta_merkle_root` is finalized, and the system facilitates the seamless integration of this result into downstream processes, such as setting the merkle root for validator Tip Distribution Accounts which enables stakers to claim rewards. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/core_logic.png) *Figure: Overview of the Core Logic ## Ballot Box ### Initialize & Realloc BallotBox A Permissionless Cranker initializes and realloc `BallotBox` account each epoch. ```rust pub struct BallotBox { ... /// Slot when this ballot box was created slot_created: PodU64, /// Slot when consensus was reached slot_consensus_reached: PodU64, /// Reserved space reserved: [u8; 128], /// Number of operators that have voted operators_voted: PodU64, /// Number of unique ballots unique_ballots: PodU64, /// The ballot that got at least 66% of votes winning_ballot: Ballot, /// Operator votes operator_votes: [OperatorVote; 256], /// Mapping of ballots votes to stake weight ballot_tallies: [BallotTally; 256], } ``` ## Cast Vote Operators determine their 32-byte meta_merkle_root off-chain. This represents a compressed version of the distribution of all tips to all stakers for the target epoch. They call `cast_vote` instruction with this root, and it is deposited as a `Ballot` into the `BallotBox` account, assuming we are within the valid window of voting. Tallies are stored for each ballot and continuously updated as votes come in, automatically setting the winning ballot once consensus is reached. ```rust pub struct Ballot { /// The merkle root of the meta merkle tree meta_merkle_root: [u8; 32], /// Whether the ballot is initialized is_initialized: PodBool, } pub struct BallotTally { ... /// The ballot being tallied ballot: Ballot, /// Breakdown of all of the stake weights that contribute to the vote stake_weights: StakeWeights, /// The number of votes for this ballot tally: PodU64, } ``` Consensus is defined as 2/3 or greater of the total available stake weight voting for the same meta_merkle_root. Voting is valid as long as: - consensus is not reached. - consensus is reached and we are not more than config.valid_slots_after_voting slots since consensus was first reached. Validators can change their votes up until consensus is reached. ## Set Merkle Root Once a meta merkle root is decided, meaning consensus is reached, each validator’s `TipDistributionAccount` with the merkle_root_upload_authority set to the NcnConfig can have its own merkle_root set. The Cranker client will invoke SetMerkleRoot with the merkle proof, and all the arguments for the Tip Distribution Program UploadMerkleRoot instruction for a given validator. These arguments make up the leaf node of the tree, so the proof is verified against the meta_merkle_root, and a CPI sets the merkle root on the TipDistributionAccount. Claims for that validator and its stakers can now begin. --- # Reward Payment ## Introduction The Reward Payment module in the Jito Tip Router is responsible for distributing rewards generated from tips. It ensures efficient routing and allocation of rewards to all relevant parties, including base reward recipients, operators, and vaults. This section details the routing and distribution process, critical instructions, and key components involved in the reward payment workflow. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/reward_payment.png) *Figure: Overview of the Reward Payment ## Reward Payment Workflow Overview 1. Rewards ( in lamports ) are sent to the PDA of the `BaseRewardReceiver` (Permissionless cranker will claim the rewards). 2. The `route_base_rewards` instruction is called *x* times until `still_routing` becomes `false`. (This is typically only once but may require multiple calls at higher levels of operators and vaults within the network due to CU limitations). 3. Once routing is complete, rewards can be distributed: a. Use `distribute_base_rewards` instruction to allocate to the base reward recipients. (in JitoSOL). b. Use `distribute_ncn_operator_rewards` to send rewards to the next router, specifically the `NcnRewardReceiver` (in lamports), which corresponds to one per operator per NCN fee group. 4. The `route_ncn_rewards` instruction is called *x* times until `still_routing` becomes `false` 5. Once routing is complete, rewards can be distributed: a. Use `distribute_ncn_operator_rewards` to allocate rewards to the operators (in JitoSOL). b. Use `distribute_ncn_vault_rewards` to allocate rewards to the vault (in JitoSOL). This system enables reward distribution (in lamports) at any time after consensus is achieved, regardless of the amount. The most critical instructions in this process are `route_base_rewards` and `route_ncn_rewards`, with particular emphasis on the calculation functions they invoke. It is important to highlight that the router does not consider the specific percentages allocated to each party but rather focuses on their ratios to determine the distribution proportions. ## Step-by-Step Reward Payment Instructions ### 1. Route Base Rewards It handles routing rewards from the `BaseRewardReceiver` to the `BaseRewardRouter` and further processes the allocation of base rewards (DAO, ...) and NCN fee group rewards (Operator). ![alt text](https://www.jito.network/omnidocs/tiprouter/images/route_base_rewards.png) *Figure: Overview of the Route Base Rewards ```rust pub fn route_reward_pool(&mut self, fee: &Fees) -> Result<(), TipRouterError> { let rewards_to_process: u64 = self.reward_pool(); let total_fee_bps = fee.total_fees_bps()?; // Base Fee Group Rewards for group in BaseFeeGroup::all_groups().iter() { let base_fee = fee.base_fee_bps(*group)?; let rewards = Self::calculate_reward_split(base_fee, total_fee_bps, rewards_to_process)?; self.route_from_reward_pool(rewards)?; self.route_to_base_fee_group_rewards(*group, rewards)?; } // NCN Fee Group Rewards for group in NcnFeeGroup::all_groups().iter() { let ncn_group_fee = fee.ncn_fee_bps(*group)?; let rewards = Self::calculate_reward_split(ncn_group_fee, total_fee_bps, rewards_to_process)?; self.route_from_reward_pool(rewards)?; self.route_to_ncn_fee_group_rewards(*group, rewards)?; } // DAO gets any remainder { let leftover_rewards = self.reward_pool(); self.route_from_reward_pool(leftover_rewards)?; self.route_to_base_fee_group_rewards(BaseFeeGroup::dao(), leftover_rewards)?; } Ok(()) } ``` ### 2. Distribute Base Rewards This ensures that all base reward recipients, such as DAO, receive their appropriate share of the rewards generated during the epoch. This instruction integrates with the Solana Stake Pool program to deposit rewards in JitoSOL and utilizes both on-chain accounts and external token accounts to manage distribution efficiently. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/distribute_base_rewards.png) *Figure: Overview of the Distribute Base Rewards ### 3. Distribute NCN Reward Route It handles the distribution of rewards from the `BaseRewardReceiver` to the `NcnRewardReceiver` for a specific NCN fee group and operator. This instruction ensures that rewards are routed accurately to operators within the NCN fee groups (Operator), based on their contributions and stake weights. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/distribute_base_ncn_reward_route.png) *Figure: Overview of the Distribute Base NCN Reward Route ```rust // Get rewards and update state let rewards = { let mut epoch_reward_router_data = base_reward_router.try_borrow_mut_data()?; let base_reward_router_account = BaseRewardRouter::try_from_slice_unchecked_mut(&mut epoch_reward_router_data)?; if base_reward_router_account.still_routing() { msg!("Rewards still routing"); return Err(TipRouterError::RouterStillRouting.into()); } base_reward_router_account .distribute_ncn_fee_group_reward_route(ncn_fee_group, operator.key)? }; // Send rewards ... ``` ### 4. Route NCN Reward Its primary function is to calculate and prepare reward allocations for operators and fee groups, without actually transferring rewards. This instruction is focused on determining how rewards should be distributed by processing operator snapshots, fee group configurations, and available rewards within the system. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/route_ncn_rewards.png) *Figure: Overview of the Route NCN Rewards ```rust ... for vault_operator_delegation_index in starting_vault_operator_delegation_index ..operator_snapshot.vault_operator_stake_weight().len() { let vault_operator_delegation = operator_snapshot.vault_operator_stake_weight() [vault_operator_delegation_index]; // Update iteration state { iterations = iterations .checked_add(1) .ok_or(TipRouterError::ArithmeticOverflow)?; if iterations > max_iterations { msg!( "Reached max iterations, saving state and exiting {}/{}", rewards_to_process, vault_operator_delegation_index ); self.save_routing_state( rewards_to_process, vault_operator_delegation_index, ); return Ok(()); } } let vault = vault_operator_delegation.vault(); let vault_reward_stake_weight = vault_operator_delegation .stake_weights() .ncn_fee_group_stake_weight(vault_ncn_fee_group)?; let operator_reward_stake_weight = operator_stake_weight.ncn_fee_group_stake_weight(vault_ncn_fee_group)?; let vault_reward = Self::calculate_vault_reward( vault_reward_stake_weight, operator_reward_stake_weight, rewards_to_process, )?; self.route_from_reward_pool(vault_reward)?; self.route_to_vault_reward_route(vault, vault_reward)?; } self.reset_routing_state(); } // Operator gets any remainder { let leftover_rewards = self.reward_pool(); self.route_from_reward_pool(leftover_rewards)?; self.route_to_operator_rewards(leftover_rewards)?; } ``` ### 5. Distribute NCN Operator Rewards This instruction ensures that the calculated rewards for each operator within a specific NCN fee group are distributed appropriately. It moves rewards from the NcnRewardReceiver to the operator's associated token account, converting them into a JitoSOL. ![alt text](https://www.jito.network/omnidocs/tiprouter/images/distribute_ncn_operator_rewards.png) *Figure: Overview of the Distribute NCN Operator Rewards ### 6. Distribute NCN Vault Rewards This instruction calculates the rewards for a vault within a particular NCN fee group and operator, transfers the rewards, and integrates them into the stake pool system (e.g., depositing them as JitoSOL). ![alt text](https://www.jito.network/omnidocs/tiprouter/images/distribute_ncn_vault_rewards.png) *Figure: Overview of the Distribute NCN Vault Rewards ## Key Components ### BaseRewardRouter 1. Core Purpose The `BaseRewardRouter` is designed to: - **Manage Rewards**: Keep track of rewards to be distributed across different groups and operators. - **Route Rewards**: Handle the allocation and routing of rewards from a reward pool to various fee groups and operators. - **Support State Persistence**: Save and resume the state of routing operations to handle large computations and ensure continuity. 2. Key Concepts - **Base and NCN Fee Groups**: - Rewards are divided into base fee groups (e.g., protocol and DAO fees) and NCN fee groups (e.g., operator-specific fees). - Each group has specific routing and distribution logic. - **Routing and Distribution**: - **Routing**: Calculates and assigns rewards to the correct pools or routes. - **Distribution**: Transfers rewards from the router to recipients (e.g., operators or vaults). - **Persistence and State Management**: - Supports resuming routing from a saved state to handle large-scale operations within computational limits. ### NcnRewardRouter 1. Core Purpose The NcnRewardRoute is designed to: - Track Operator Rewards: Maintain a record of rewards assigned to an operator across all NCN fee groups. - Enable Reward Updates: Allow incrementing or decrementing rewards based on operations or distributions. - Support Validation and Checks: Provide utility functions to check reward states (e.g., if rewards exist). --- # Node Operator Client ## Solana Epoch Snapshot Once an epoch completes, the operator client takes a snapshot of the Bank from the last existing block of the previous epoch. ## Generate Tip Distribution Merkle Trees and Meta Merkle Root Using the Bank, the client constructs the StakeMetaCollection, which includes details about each validator, their tip distribution account, and the active delegations (stake accounts) on that validator. Based on the StakeMetaCollection, the client generates Merkle trees for each validator, resulting in the GeneratedMerkleTreeCollection. Each tree contains a set of "claimants," which include all the validator's stake accounts, an additional claimant representing the validator’s share of tips (calculated using their mev_commission_bps from the tip distribution account), and a claimant for the fee allocated to the TipRouter. **Details about the `TipRouter` claimant**: - The inclusion of this claimant is the primary difference between the current creation process for `StakeMetaCollection` and `GeneratedMerkleTreeCollection` compared to the prior approach in [`jito-solana/tip-distributor`]. - The amount for the `TipRouter` claimant is calculated by multiplying the validator's total tips by the `TipRouter`'s `NcnConfig.fees_config.total_fees_bps()`, which aggregates the BaseFees and NcnFees. - The `TipRouter` fee represents a percentage of fees assessed on each validator's tips. The program only holds the complete fee once all validators’ `TipRouter` claimants have been claimed. - The fee's destination is a dedicated Program Derived Address (PDA) for each epoch, known as the `BaseRewardReceiver`. Finally, a MetaMerkleTree is created from the `GeneratedMerkleTreeCollection`. [`jito-solana/tip-distributor`]: https://github.com/jito-foundation/jito-programs/tree/master/mev-programs/ ## Cast Vote Once the `meta_merkle_root` is created, the operator submits their vote by calling the cast_vote instruction, provided the BallotBox, EpochSnapshot, and OperatorSnapshot accounts have already been initialized. --- # Permissionless Cranker ## Overview The Tip Router Keeper is a critical component of the Jito Tip Router system that manages epoch-based operations for validators, operators, and vaults. It orchestrates the complete lifecycle of an epoch, from updating vaults, weight setting to reward distribution, ensuring proper consensus and state transitions. ## Architecture ### Core Components 1. **KeeperState** - Manages the state of the keeper across epochs 2. **Epoch Management** - Handles epoch progression and state transitions ### Key Data Structures #### KeeperState The `KeeperState` struct maintains all essential addresses and state information: ```rust pub struct KeeperState { pub epoch: u64, pub ncn: Pubkey, pub vaults: Vec, pub operators: Vec, pub tip_router_config_address: Pubkey, pub vault_registry_address: Pubkey, pub epoch_state_address: Pubkey, // ... additional addresses and state } ``` ## Epoch Lifecycle The keeper follows state machine for each epoch: ### State Progression 1. **SetWeight** - Establishes vault weights for the epoch 2. **Snapshot** - Captures operator and vault snapshots 3. **Vote** - Operators vote on the merkle root 4. **PostVoteCooldown** - Waiting period after voting 5. **Distribute** - Distributes rewards to participants 6. **Close** - Closes epoch accounts and finalizes ### Epoch Progression Logic The keeper uses the `progress_epoch` function to determine when to advance: - **New Epoch Detection**: Automatically progresses when a new epoch begins - **Completion Handling**: Resets to starting epoch when current epoch is complete - **Stall Recovery**: Advances to next epoch when stalls are detected ## Main Loop Operations ### A. Progress Epoch Determines which epoch the keeper should work on based on: - Current epoch - Completion status of epochs - Stall detection ### B. Emit NCN Metrics Collects and emits comprehensive metrics including: - Validator information - Epoch statistics - Ticket states - Account balances ### C. Register Vaults Ensures all vaults are properly registered with the Global Vault Registry before processing begins. ### D. Fetch Keeper State Updates the internal state with current epoch information and account data. ### E. Update Epoch State Synchronizes with on-chain epoch state accounts to maintain consistency. ### F. Create or Complete State - Creates new epoch state if none exists - Detects and handles completed epochs ### G. Crank State Operations Executes state-specific operations based on current epoch state: ```rust match current_state { State::SetWeight => crank_set_weight(handler, state.epoch).await, State::Snapshot => crank_snapshot(handler, state.epoch).await, State::Vote => crank_vote(handler, state.epoch, test_vote).await, State::PostVoteCooldown => crank_post_vote_cooldown(handler, state.epoch).await, State::Distribute => crank_distribute(handler, state.epoch).await, State::Close => crank_close_epoch_accounts(handler, state.epoch).await, } ``` ### H. Emit Epoch Metrics Provides detailed metrics for the current epoch state and progress. ### I. Detect Stall Identifies when the epoch is stuck and needs to progress: - Voting completion - Insufficient rewards for distribution - Other blocking conditions ## Configuration and Deployment ### Operating Modes The keeper supports several operating modes: - **Full Operations** (`run_operations = true`): Complete epoch management - **Metrics Only** (`metrics_only = true`): Only emit metrics without state changes - **Migration Mode** (`run_migration = true`): Special migration operations ## Stall Detection The keeper implements sophisticated stall detection: ### Stall Conditions 1. **Voting States**: During `Vote` and `PostVoteCooldown` states 2. **Low Rewards**: When rewards are below distribution threshold (< 10,000 lamports) 3. **Account Dependencies**: When required accounts are not ready ### Stall Recovery When stalls are detected: - The keeper logs the stall condition - Progresses to the next epoch after timeout - Continues monitoring for resolution --- # Jito (Re)staking > Liquid staking infrastructure for node consensus networks (NCNs). **Jito (Re)staking** is liquid staking infrastructure for decentralized networks called node consensus networks (NCNs) on Solana. It provides a framework for deploying NCNs and staking SPL tokens to them, with flexibility baked in at every level. Altogether, Jito (Re)staking is a coordination protocol for developers to build liquid staking protocols and use the Solana runtime to enforce custom proof of stake protocol for external networks. The protocol coordinates stake and rewards between three main participants: NCNs, Vaults, and Operators. Developers register NCNs with custom rules. Operators perform arbitrary logic defined by the NCN, whether that’s processing data, coordinating tasks, participating in consensus, running models, or verifying offchain inputs. Vaults hold staked SPL tokens, delegate them to Operators, and mint liquid receipt tokens to users, maintaining liquidity and composability in DeFi. NCNs, Operators, and Vaults can define who they interact with and under what conditions. The system consists of two programs: the **Restaking Program** (`RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q`), which acts as an onchain registry for NCNs and Operators, and the **Vault Program** (`Vau1t6sLNxnzB7ZDsef8TLbPLfyZMYXH8WTNqUdm9g8`), which manages tokenized stake through Vault Receipt Tokens (VRTs) between participants. Both of these programs gives developers the flexibility to customize network operations and various administrative authorities, including appointing stake delegators, setting fees, making protocol upgrades, and updating supported tokens. Together, the Restaking program and the Vault Program manage stake delegations across the system. ![img.png](https://www.jito.network/omnidocs/restaking/images/ncn.png) ### Onchain Coordination, Offchain Execution At the core, the protocol is an onchain registry of networks, stakers, and node operators on Solana. The design separates core offchain network services and onchain coordination: - All core activity (computation, validation, data collection, etc.) happens offchain. - All coordination (stake delegation, voting, rewards distributions, penalties) is tracked, maintained, and enforced onchain. This split enables scalability and flexibility for developers while retaining cryptoeconomic guarantees and high performance from Solana’s base layer. It makes it easier to bootstrap distributed networks of economically aligned operators and stakers, without building liquid staking infrastructure from scratch or relying on high emissions. Effectively, this model creates a more efficient and cost effective security model (e.g. one set of staked tokens can secure multiple services) and allows teams to allocate moreresources toward core development. ## Core Components ### Node Consensus Network (NCN) NCNs are a set of node operators and onchain programs that reach consensus on offchain workloads and enforce onchain state transitions. In most cases, NCNs will include their own custom onchain programs to handle proof submissions, verify work, and distribute rewards. Consensus can take place onchain or offchain. For example, oracle networks, DePINs, bridges, DeFi apps, or entire blockchains can deploy an NCN to achieve consensus on an arbitrary result and finalize and distribute rewards, payments, and penalties. NCNs build custom staking mechanisms and use (re)staked assets for economic security, ensuring node operators have an economic commitment to follow protocol and maintain core network operations. ### Vaults Vaults serve as deposit pools that hold SPL tokens (e.g. JitoSOL) and issue liquid vault receipt tokens (VRTs) representing those positions. Vaults opt into supporting specific NCNs and delegate stake to approved operators. Users retain ownership of their stake via liquid VRTs. VRTs accrue rewards that are distributed to the underlying vault and VRT prices are automatically updated as rewards accrue, making it extremely easy for developers to leverage the benefits of liquid staking tokens. Each vault defines key parameters, including how much stake is allocated to each node operator. ### Operators Operators are infrastructure providers that run the offchain services for NCNs and are delegated stake. They opt in to serve specific NCNs and receive stake from approved vaults. Operators have no direct control of the stake, and they are usually rewarded in proportion to the stake they have. Operators can serve multiple NCNs simultaneously, enabling efficient resource usage and shared security. ### The Opt-In Handshake Participation in Jito (Re)staking is governed on-chain by mutual consent: 1. NCNs register onchain and approve operators and vaults to participate in their network 2. Operators opt in to NCNs and must be accepted. 3. Vaults opt in to NCNs and delegate to approved operators. This handshake guarantees that vaults, operators, or NCNs are not forced into any connection. All actively staked links are explicitly approved, creating a modular and flexible system for stake delegation and service coordination. ### Why Jito (Re)staking Matters We built the Jito (Re)staking protocol because there are aspects of Jito Network that can benefit from incremental decentralization. And as the Solana ecosystem continues to mature, we expect other developers will eventually transition to prioritizing resiliency over product iteration speed and seek to build custom decentralized solutions that fit the needs of their protocol. The primary benefits of using the restaking protocol to bootstrap decentralized protocol include: - **Liquid staking functionality**: Stakers maintain liquidity of their staked positions, unlocking more capital efficiency in Solana DeFi. Vaults automatically calculate and update VRT prices and holdings. All rewards accrue to vault instead of each stake account. Liquid staking functionality can integrate with rest of (re)staking protocol (see Maintain Upgradeability) - **Token Utility**: The restaking protocol is completely non-custodial and requires multiple parties to opt-in and coordinate network connections, operations, and rewards distributions, unlocking a path for NCNs to build decentralized networks and install native token utility. - **Fully audited**: Programs are [fully audited](https://github.com/jito-foundation/restaking/tree/master/security_audits) by Certora, Offside, and Ottersec and already secures hundreds of millions of staked assets. - **Maintain upgradeability for outsourcing and decentralizing key protocol functions**: Developers maintain upgradeability for building a network that integrates with VRTs. Examples: Rewards distributions, stake delegations, proof of bandwidth, proof of location, compute verification, prediction markets, auction mechanisms, and more. - **Wide Distribution**: Over 90% of Solana validators run the Jito-Solana client, and JitoSOL is the largest stake pool on Solana. - **Access to professional node operators**: NCNs require different hardware requirements and software competencies. Jito Network is deeply integrated with Solana’s validator ecosystem, which includes a wide range of sophisticated independent operators and institutional operators. This makes it very trivial for NCNs to connect with the industry’s best node operators to participate in their networks, regardless of the underlying network’s hardware and software requirements. - **Access to Jito Network Stakers (JitoSOL)**: Incremental yield to attract economy security from JitoSOL is marginal, and JitoSOL is deeply integrated with the Solana DeFi ecosystem. NCNs can immediately tap into Jito’s network effects without having to attract native stake from scratch. This means, by registering with the Jito (Re)staking framework, bootstrapping and building staked networks is very cost-effective and extremely trivial. - **Capital efficiency**: The same stake can secure multiple services. The same operators can operate multiple services. - **Aligned incentives**: Stakers, operators, and NCN developers all benefit from performance, transparency, and modular security. - **Instant access to Internet Capital Markets**: NCNs have instant access to [Internet Capital Markets](https://multicoin.capital/2025/01/22/the-solana-thesis-internet-capital-markets/). Vaults have the incentive to integrate VRTs across DeFi, creating market structures for native tokens. Jito (Re)staking greatly reduces the friction to launch, or transition existing services into, decentralized protocols with proof of stake security rooted on Solana. ## Key Roles and Responsibilities This section focuses on the organizational roles behind the system. Each persona (whether they’re launching a network, managing stake delegations, running infrastructure, or providing stake) has clearly defined administrative capabilities and responsibilities. This alignment is central to how Jito (Re)staking ensures trust and coordination in a modular, multi-party environment. ### NCN Admin The NCN admin is the team or entity launching and managing the NCN. This could be a protocol team, research group, DAO, or company. **Key responsibilities:** - Register the NCN account, deploy the NCN program(s) including defining consensus, and configure the parameters of the NCN (e.g. accepted tokens and operator quorum) - Approve or remove Operators that serve the network - Launch and finalize epochs (start/close voting periods) - Monitors results, sets fees and manages relationships between operators and vaults - Define slashing logic including slashable behavior and subsequent penalties This role is active and ongoing. Admins aren’t just deployers. They’re stewards of the network’s operation, performance, consensus, and upgrades. ### Vault Admin Vault admins control how users' stake is allocated across NCNs. They manage the vault configuration and oversee delegations. Vaults may be admin-controlled or governed by token holders (e.g. via DAO voting). **Key responsibilities:** - Create and register Vaults that support specific SPL tokens - Opt into selected NCNs and operators and define allocation parameters - Delegate stake to approved Operators - Process reward distributions - Manage warmup/cooldown periods for stake activation and withdrawal Vault admins delegate stake. Their decisions influence which NCNs receive economic security and which Operators can leverage the stake for NCN operations. ### Operators Operators, such as existing Solana validators, run nodes that opt in to run NCN-specific offchain workloads and contribute to onchain protocol. They are rewarded based on performance which can include uptime, correctness, and participation, subject to the NCN. On top of this, they are penalized for underperformance or misconduct Penalties may include losting stake delegations or rewards, or being slashed. **Key responsibilities:** - Opt in to serve one or more NCNs - Accept stake from Vaults and remain compliant to avoid slashing - Run offchain services as specified by each NCN (e.g. compute, validate, read data) - Stay online and responsive throughout each consensus cycle - Participate in voting and contribute to onchain consensus Operators form the execution layer of the network. Because they receive stake from Vaults and are rewarded on a stake-weighted basis, they are economically incentivized to perform correctly and continuously. ### Stakers Stakers are users who deposit JitoSOL and other tokens into Vaults to secure NCNs and earn yield. Their capital is the backbone for NCNs because it provides economic security i.e. an economic incentive to follow protocol. **Key responsibilities:** - Choose which Vault(s) to deposit stake, based on supported NCNs and risk preferences - Receive liquid Vault receipt tokens (VRTs) representing their positions - Earn native staking rewards plus additional restaking yield - Participate in governance (if the Vault allows it) to help steer delegation choices Stakers are the foundation of restaking, they choose where to place their economic security and their deposits give Vaults the power to delegate that economic security to NCNs. ## Lifecycle of a Node Consensus Network (NCN) Once an NCN is initialized, it operates in continuous cycles which are coordinated across three distinct phases: setup, operation, and maintenance. This lifecycle involves initializing the network and its participants, running its offchain tasks, enforcing onchain accountability, and evolving over time based on the demands of the NCN. Each phase involves actions by multiple parties: NCN admins, vault controllers, and node operators. ### Setup Phase: Building the Foundation The setup phase establishes the NCN’s identity, rules, and participants. - **NCN Registration**: The NCN admin initializes an NCN account onchain by calling the restaking program, requiring both the NCN admin key and a base NCN key. This account serves as an entry in the registry and does not store detailed network configurations. Instead, configurations like accepted tokens, slashing conditions, quorum thresholds, and operator requirements are managed separately, typically via the NCN's own onchain program, CLI, or off-chain enforcement logic. - **Vault and Operator Onboarding**: Vaults and Operators must each explicitly opt into the NCN, and the NCN must in turn approve them. Before establishing these relationships, vaults and operators must first register through the **Vault Program** and **Restaking Program**, respectively. Once registered, they can initiate connections to a specific NCN. Once approved by the NCN, the admins should call a warm-up instruction to activate the connections. The warm-up period lasts for one full epoch, not including the current partial epoch. The stake becomes active once all three components initiate and warm up the connections. This opt-in approval process ensures that all active stake delegations are mutual and intentional. - **Stake Delegation**: After the warm-up period, vaults can delegate stake to the operator. Stake becomes active immediately. However, when a user withdraws their stake, it must undergo a cooldown period that lasts for one full NCN-defined epoch. By the completion of this setup phase, the NCN has established its security parameters, approved operators, and activated its initial stake. This foundation sets the stage for the operations phase, and different dynamics come into play. ### Operations Phase: Running the Network Each NCN progresses through consensus cycles, which may be time-bound to epoch lengths or follow a custom logic defined by the NCN admin. Within each cycle, operators perform offchain tasks and submit results, which are validated and finalized onchain. This structure allows NCNs to adopt models ranging from fixed epochs to flexible, event-driven consensus. Key steps for this include: - **NCN Configurations:** The NCN admin registers the NCN through the restaking program and separately configures the associated onchain program and accounts. This may differ from NCN to NCN. For example, here are some configurations from the flagship TipRouter NCN: - `tie_breaker_admin`: The admin authorized to update the tie breaker mechanism or parameters. - `valid_slots_after_consensus`: Number of slots after consensus is reached where votes are still accepted - `epochs_before_stall`: Number of epochs to wait after consensus is reached before epoch accounts can be closed. - `epochs_after_consensus_before_close`: Number of epochs without reaching consensus before the cycle is considered stalled. - **Snapshot**: The NCN admin initiates a new consensus cycle by triggering the snapshot phase, which creates a frozen, point-in-time view of the network's state. During this phase, the system captures and records several critical pieces of information: the current set of active operators, their associated vault delegations, and the weighted stake distribution across the network. For example, the Tip Router NCN handles snapshotting as follows: This snapshot process involves creating an `EpochSnapshot` account to track the total stake weight and participant counts, individual `OperatorSnapshot` accounts for each operator to record their specific delegated stake weights, and a `WeightTable` that freezes the voting weights for each supported token. By locking this configuration at the start of the cycle, the system ensures that all subsequent votes are based on a consistent, immutable view of the network's state, preventing any manipulation of voting power through strategic stake movements or delegation changes during the active voting period. Note: While this applies to the Tip Router and the default Template NCN, other NCNs may define different snapshot mechanisms or parameter names depending on their specific design. - **Offchain Execution**: Operators execute the offchain service and protocol designed by the NCN. Examples include generating ZK proofs, querying external APIs, performing computations, or validating event data. In some cases, this step also involves submitting data of the results onchain or offchain from which it can be read for vote submissions. - **Vote Submission**: Operators cast signed votes for specific results to the NCN’s onchain program. That program is responsible for tallying votes and determining whether consensus has been reached. Once consensus is finalized, it can trigger actions like reward distribution or slashing through the Restaking program. - **Finalization and Rewarding**: Once consensus is reached, the result is sent to another program that invokes a state transition instruction for the NCN i.e. updating accounts, distributing rewards, etc. If successful, rewards are distributed to operators based on stake-weight and other logic that is codified by the NCN. - **Slashing Enforcement (In Current Development)**: When operators fail to meet their obligations, whether through missed votes, invalid data submission, or malicious behavior, their stake is slashed by a designated slasher (set by the NCN) can submit a slashing request. The slashing mechanism ensures that economic incentives remain properly aligned throughout the system. (The slashing program is not currently live). The operation phase is where the network’s value is produced. While all service execution happens offchain, consensus protocol and incentives are preserved onchain, creating a scalable and trust-minimized decentralized protocol. ## Critical Concepts Jito (Re)Staking introduces architectural patterns that enable scalable, secure coordination for independent decentralized services. These include: ### Stake-Weighted Voting and Slashing Consensus in Jito (Re)Staking is driven by submitting onchain votes on offchain execution. Voting power is backed by delegated **onchain** stake. Please note that the slashing functionality is still currently being developed. During each epoch: - Operators perform offchain services (e.g. computation, validation, data retrieval) - They submit signed votes onchain based on their results - These votes are weighted by how much stake they are delegated from vaults - Finalized results require reaching a threshold of weighted agreement - Once slashing is live, NCNs can implement custom slashing logic for missed votes or malicious behavior ### Modular and Permissioned Participation All connections between NCNs, vaults, and operators are explicitly approved by each party—no one is auto-connected. This mutual opt-in model guarantees intentional coordination, while enabling a modular topology: - Operators can serve multiple NCNs - Vaults can allocate and rebalance stake freely - NCNs evolve independently with custom rules and economic structures ### Maintenance Phase: Keeping the Network Healthy At the end of each epoch, administrative and system-level tasks are performed to keep the NCN aligned and efficient. **A brief list includes**: - **Account Cleanup**: To minimize rent costs, temporary accounts like vote records and delegation states are closed at epoch boundaries, reclaiming SOL for reuse. - **Operator and Vault Updates**: The NCN admin can add or remove operators and vaults, and adjust minimum quorum thresholds. In addition, operators and vaults have the ability to opt out or move between NCNs. - **Token Weight and Allocation Adjustments**: NCNs can refresh or rebalance token weights through their own onchain program. Vault admins can update stake allocations across NCNs or shift delegations between operators. - **Dynamic Configuration Changes**: NCN parameters, including reward splits, penalty thresholds, and voting logic, can be revised over time, allowing the network to evolve, upgrade, and adapt to changing usage patterns. This ongoing maintenance ensures the NCN remains flexible and cost-efficient. Administrative actions are coordinated through permissioned onchain records, making changes transparent and auditable. Additional improvements around cross-epoch delegation efficiency are being explored in the development roadmap. ## Addresses | Network | Program | Address | Version | | ------- | --------- | ------------------------------------------- | ------- | | Mainnet | Restaking | RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q | 0.0.5 | | Mainnet | Vault | Vau1t6sLNxnzB7ZDsef8TLbPLfyZMYXH8WTNqUdm9g8 | 0.0.5 | | Testnet | Restaking | RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q | 0.0.5 | | Testnet | Vault | Vau1t6sLNxnzB7ZDsef8TLbPLfyZMYXH8WTNqUdm9g8 | 0.0.5 | | Devnet | Restaking | RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q | 0.0.5 | | Devnet | Vault | Vau1t6sLNxnzB7ZDsef8TLbPLfyZMYXH8WTNqUdm9g8 | 0.0.5 | ## License This project is licensed under the Apache License 2.0 - see the [LICENSE.md](https://github.com/jito-foundation/restaking/blob/master/LICENSE) file for details. --- # Overview > A basic overview of the Jito Restaking architecture. ## Jito Restaking Architecture Overview The Jito (Re)Staking protocol facilitates the relationship between three components: - [NCN](https://www.jito.network/docs/restaking/core-concepts/ncn.md) - [Operator](https://www.jito.network/docs/restaking/core-concepts/operator.md) - [Vault](https://www.jito.network/docs/restaking/core-concepts/vault.md)
Active
Figure 1: Active Relationship State - Visual representation of the three-way relationship between NCN, Operator, and Vault components when all have opted in, resulting in activated stake.
All three components must opt-in to a three-way relationship in order to warm-up and activate a staked relationship. If any of the three components is not "opt-in", there is no stake i.e. the relationship between each component is inactive. Additionally, any component can opt-out of active staked relationships, in which case the protocol will cool down the relationship in the next epoch and deactivate stake. Conversely, relationships can be warmed up.
Inactive
Figure 2: Inactive Relationship State - Visual representation of what happens when one or more components haven't opted in or have opted out, resulting in a deactivated stake.
--- # Vaults > An overview of the Vault component. ## Overview ### The Vault Account: - Serves as the repository for supported token and VRT (Vault Receipt Token). - Tracks the state of tokens deposits, withdrawals, and delegate assets. - Manages a set of administrative roles, responsible for different aspects of vault operations. ### Key functionalities include: - Token Management: Handles deposits, withdrawals, and minting/burning of VRT tokens with fee calculations and slippage protection. - Fee Management: Supports dynamic fee adjustments (deposit, withdrawal, reward) with built-in validation and limits. - Delegation Management: Tracks and manages the delegation of assets to operators, ensuring sufficient reserves for withdrawals. - State Tracking: Maintains a detailed record of vault activity, including cooldowns, ready-to-claim amounts, and delegation states. - Administrative Role Management: Assigns and verifies various admin roles (e.g., delegation admin, fee admin) for secure and efficient operations. ## Key Components ### 1. Vault Structure #### General Information | Field | Type | Description | | --------------------------------- | --------------- | -------------------------------------------------------------------------------------- | | base | Pubkey | The base account used as a PDA seed. | #### Token Information and Accounting | Field | Type | Description | | --------------------------------- | --------------- | -------------------------------------------------------------------------------------- | | vrt_mint | Pubkey | The pubkey of VRT's mint account. | | supported_mint | Pubkey | The pubkey of supported_mint's mint account. | | vrt_supply | u64 | The total number of VRT in circulation. | | tokens_deposited | u64 | The total number of tokens deposited. | | deposit_capacity | u64 | The total number of tokens deposited. | | delegation_state | DelegationState | Rolled-up stake state for all operators in the set. | | additional_asssets_need_unstaking | u64 | The amount of additional assets that need unstaking to fulfill VRT withdrawals. | | vrt_enqueued_for_cooldown_amount | u64 | The amount of VRT tokens in VaultStakerWithdrawalTickets enqueued for cooldown. | | additional_asssets_need_unstaking | u64 | The amount of VRT tokens cooling down. | | vrt_ready_to_claim_amount | u64 | The amount of VRT tokens ready to claim. | #### Admins | Field | Type | Description | | --------------------------------- | --------------- | -------------------------------------------------------------------------------------- | | admin | Pubkey | Vault admin. | | delegation_admin | Pubkey | The delegation admin responsible for adding and removing delegations from operators. | | operator_admin | Pubkey | The operator admin responsible for adding and removing operators. | | ncn_admin | Pubkey | The node consensus network admin responsible for adding and removing support for NCNs. | | slasher_admin | Pubkey | The admin responsible for adding and removing slashers. | | capacity_admin | Pubkey | The admin responsible for setting the capacity. | | fee_admin | Pubkey | The admin responsible for setting the fees. | | delegate_asset_admin | Pubkey | The delegate_admin responsible for delegating assets. | | fee_wallet | Pubkey | Fee wallet account. | | mint_burn_admin | Pubkey | Optional mint signer. | | metadata_admin | Pubkey | Authority to update the vault's metadata. | #### Indexing and Counters | Field | Type | Description | | --------------------------------- | --------------- | -------------------------------------------------------------------------------------- | | vault_index | u64 | The index of the vault in the vault list. | | ncn_count | u64 | Number of VaultNcnTicket accounts tracked by this vault. | | operator_count | u64 | Number of VaultOperatorDelegation accounts tracked by this vault. | | slasher_count | u64 | Number of VaultNcnSlasherTicket accounts tracked by this vault. | | last_fee_change_slot | u64 | The slot of the last fee change. | | last_full_state_update_slot | u64 | The slot of the last time the delegations were updated. | | deposit_fee_bps | u16 | The deposit fee in basis points. | | withdrawal_fee_bps | u16 | The withdrawal fee in basis points. | | next_withdrawal_fee_bps | u16 | The next epoch's withdrawal fee in basis points. | | reward_fee_bps | u16 | Fee for each epoch. | | program_fee_bps | u16 | The program fee in basis points. | | is_paused | bool | Pause flag. | Vault's PDA ```rust use jito_restaking_core::operator::Operator; let program_id = jito_restaking_program::id(); let base_pubkey = pubkey!("base pubkey here"); let vault_pubkey = Vault::find_program_address(&program_id, &base_pubkey).0; ``` --- # Operators > Infrastructure providers that run NCN software and manage delegated assets in the Jito Restaking ecosystem ## What is an Operator? An **Operator** is an entity responsible for running Node Consensus Network (NCN) software and managing delegated assets from vaults. Operators serve as the infrastructure providers in the Jito Restaking ecosystem, executing the actual work required by NCNs while being held accountable through economic incentives and slashing mechanisms. Operators are infrastructure providers that run the offchain services for NCNs and are delegated stake. They opt in to serve specific NCNs and receive stake from approved vaults. Operators have no direct control of the stake and they are usually rewarded in proportion to the stake they have. Operators can serve multiple NCNs simultaneously, enabling efficient resource usage and shared security. ## Key Responsibilities - **NCN Software Execution**: Run and maintain software for various NCNs they opt into - **Asset Management**: Manage delegated assets from vaults with proper security measures - **Fee Collection**: Earn fees (in basis points) for providing services to NCNs - **Slashing Risk**: Accept slashing risk for misbehavior or poor performance - **Offchain Services**: Execute the offchain service and protocol designed by the NCN, including generating ZK proofs, querying external APIs, performing computations, or validating event data - **Vote Submission**: Cast signed votes for specific results to the NCN's onchain program during consensus cycles - **Performance Requirements**: Stay online and responsive throughout each consensus cycle, maintaining uptime, correctness, and participation as required by each NCN ## Operator Account Structure The Operator account stores global metadata and configuration: | Field | Type | Description | |-------|------|-------------| | `base` | Pubkey | Base account used as PDA seed | | `admin` | Pubkey | Primary administrator with full control | | `ncn_admin` | Pubkey | Admin for managing NCN relationships | | `vault_admin` | Pubkey | Admin for managing vault relationships | | `delegate_admin` | Pubkey | Admin for asset delegation operations | | `metadata_admin` | Pubkey | Admin for updating operator metadata | | `voter` | Pubkey | Key used for signing NCN transactions | | `index` | u64 | Unique operator index | | `ncn_count` | u64 | Number of associated NCNs | | `vault_count` | u64 | Number of associated vaults | | `operator_fee_bps` | u16 | Operator fee in basis points | ### Finding Operator PDA ```rust use jito_restaking_core::operator::Operator; let program_id = jito_restaking_program::id(); let base_pubkey = pubkey!("base pubkey here"); let operator_pubkey = Operator::find_program_address(&program_id, &base_pubkey).0; ``` ## Admin Role Separation Operators use role-based access control for security: - **Primary Admin**: Full control over the operator account - **NCN Admin**: Can add/remove NCN support and manage NCN relationships - **Vault Admin**: Can add/remove vault support and manage vault relationships - **Delegate Admin**: Can delegate assets from operator token accounts - **Metadata Admin**: Can update operator metadata and configuration - **Voter**: Can sign transactions for NCN interactions ## Relationship Management Operators participate in a mutual opt-in system where all connections between NCNs, vaults, and operators must be explicitly approved by each party. This ensures no forced connections and creates a modular, flexible system. ### Vault Relationships (OperatorVaultTicket) Operators create **OperatorVaultTickets** to establish relationships with vaults: - Operators opt into vaults they want to receive delegation from - Tickets track the state of the relationship (inactive, warming up, active, cooling down) - Only the operator's `vault_admin` can manage these relationships - This ticket represents the relationship between an Operator and a Vault, created by the Operator to opt in to work with a Vault ### NCN Relationships (NcnOperatorState) Operators participate in **NcnOperatorState** for mutual opt-in with NCNs: - Both the NCN and operator must opt into each other - Enables operators to provide services to specific NCNs - Managed through the operator's `ncn_admin` role - This state represents the mutual opt-in relationship between an NCN and an Operator - The NCN initializes this state, then both NCN and operator can warm-up and cooldown the state to show support for each other ## Operator Operations ### Offchain Execution Operators execute the core work required by NCNs offchain, which may include: - Generating zero-knowledge proofs - Querying external APIs for data feeds - Performing complex computations - Validating event data from external sources - Processing and transforming data according to NCN requirements ### Voting and Consensus - Operators cast signed votes for specific results to the NCN's onchain program - Voting power is weighted by the amount of stake delegated to them from vaults - Votes are submitted onchain during consensus cycles - Finalized results require reaching a threshold of weighted agreement - The NCN program is responsible for tallying votes and determining consensus ### Rewards and Penalties - Operators are rewarded based on performance including uptime, correctness, and participation - Rewards are distributed based on stake-weighted performance - Operators earn fees based on their `operator_fee_bps` setting - Subject to slashing for misbehavior, poor performance, missed votes, invalid data submission, or malicious behavior - Economic incentives ensure operators remain aligned with protocol requirements ## Operator Lifecycle ### 1. Registration and Initialization ```rust // Find operator PDA let operator_pubkey = Operator::find_program_address(&program_id, &base_pubkey).0; ``` The operator registration process involves: - Creating an operator account through the restaking program - Setting initial configuration including operator fee (in basis points) - Establishing admin roles for different operational aspects - Registering with a unique operator index ### 2. Vault Opt-in and Warmup - Create OperatorVaultTicket to signal interest in a vault - Warmup period before relationship becomes active (lasts for one full epoch) - Begin receiving delegated assets from the vault once active - Vault must also opt into the operator for the relationship to activate ### 3. NCN Participation - Opt into NCNs to provide services through NcnOperatorState - Both NCN and operator must mutually opt in - Run required NCN software infrastructure - Participate in consensus cycles through voting - Earn fees based on `operator_fee_bps` setting ### 4. Active Operations - Execute offchain services as specified by each NCN - Submit votes during consensus cycles - Maintain performance standards (uptime, correctness, participation) - Manage delegated assets using `delegate_admin` role - Handle relationship states through appropriate admin roles ### 5. Relationship Management - Use `vault_admin` to manage vault relationships - Use `ncn_admin` to manage NCN relationships - Cooldown periods when opting out of relationships - Ability to serve multiple NCNs simultaneously for resource efficiency ## Economic Model ### Fee Structure - Operators set fees in basis points (`operator_fee_bps`) - Fees are earned for providing services to NCNs - Rewards distributed based on stake-weighted performance - Fee structure incentivizes quality service provision ### Stake Delegation - Operators receive delegated stake from vaults but have no direct control over it - Stake delegation enables voting power in NCN consensus - Operators are economically incentivized through stake-weighted rewards - Risk of slashing provides accountability mechanism ### Multi-NCN Operations - Operators can serve multiple NCNs simultaneously - Enables efficient resource usage and shared security model - Same stake can secure multiple services through different NCNs - Operators benefit from diversified service provision ## Administrative Configuration Operators can configure several variables through the restaking program: - Add and remove support for vaults through OperatorVaultTickets - Add and remove support for NCNs through NcnOperatorState - Change voter keys for NCN transaction signing - Update operator fee structure - Manage admin role assignments - Withdraw funds sent to the operator from rewards, airdrops, and other sources ## Security Considerations ### Role-Based Access Control - Separation of admin responsibilities reduces single point of failure risk - Different keys for different operational aspects enhance security - Primary admin maintains overall control while delegating specific functions ### Slashing Protection - Operators accept slashing risk as part of their service provision - Economic incentives ensure proper behavior and performance - Slashing mechanisms (currently in development) will penalize misbehavior ### Relationship Validation - Mutual opt-in requirements prevent forced connections - Warmup and cooldown periods provide protection against rapid changes - Transparent onchain relationship management ensures accountability --- # NCNs > An overview of the Node Consensus Network (NCN) component. ## Overview A Node Consensus Network (NCN) is a decentralized service or network that reaches onchain consensus on offchain data or workloads. This may include oracles, DePIN services, bridges, co-processors, or new chains. NCNs represent one of the core components in the Jito Restaking ecosystem, alongside Operators and Vaults. It is one of typical NCN design (On-Chain NCN Program), so every NCN does not have to follow this design. ### Key functionalities include: - **Authority Management**: Designate and validate admins for various NCN operations - **Operator and Vault Tracking**: Manage relationships with operators and vaults through mutual opt-in mechanisms - **Consensus Coordination**: Facilitate onchain consensus on offchain execution results - **Reward Distribution**: Calculate and distribute rewards to participating operators, vaults and stakers - **Asset Weight Management**: Define supported tokens and their respective weights in the network ## On-Chain NCN Program Components NCN consists of several key components that work together to provide decentralized services: ### Pricing - Defines supported tokens and their respective weights in the network, determining how different assets are valued within the NCN ecosystem - Manages token weight tables that influence voting power and reward distribution - Controlled by the `weight_table_admin` role ### Snapshot - Captures the current state of Vaults, Operators, and Operator Stake Weights at specific intervals to establish consensus baselines - Creates a frozen, point-in-time view of the network's state for consistent voting - Includes `EpochSnapshot` accounts to track total stake weight and participant counts - Records individual `OperatorSnapshot` accounts for each operator's delegated stake weights ### Core Logic - Implements the fundamental consensus mechanisms that govern how nodes participate and validate output within the network - Handles vote tallying and determines when consensus thresholds are reached - Manages epoch transitions and consensus finalization - Defines slashing conditions and enforcement logic ### Reward Payments - Manages how rewards are calculated and distributed to participating operators, vaults and stakers based on their contributions to the network - Implements stake-weighted reward distribution mechanisms - Handles fee collection and distribution according to NCN-specific logic - Coordinates with the restaking program for reward processing ## Key Components ### 1. NCN Structure The NCN account structure is designed to handle various administrative and operational roles within the network: | Field | Type | Description | | ------------------- | ------ | ---------------------------------------------------- | | base | Pubkey | The base account used as a PDA seed. | | admin | Pubkey | Overall administrator of the NCN. | | operator_admin | Pubkey | Admin responsible for managing operators. | | vault_admin | Pubkey | Admin responsible for managing vaults. | | slasher_admin | Pubkey | Admin responsible for managing slashers. | | delegate_admin | Pubkey | Admin for delegating assets of NCN account. | | metadata_admin | Pubkey | Admin responsible for NCN metadata updates. | | weight_table_admin | Pubkey | Admin for managing asset weight tables. | | ncn_program_admin | Pubkey | Admin for on-chain programs associated with the NCN. | | index | u64 | Index of the NCN account. | | operator_count | u64 | Number of operators registered with the NCN. | | vault_count | u64 | Number of vaults registered with the NCN. | | slasher_count | u64 | Number of slashers registered with the NCN. | ### Finding NCN PDA ```rust use jito_restaking_core::ncn::Ncn; let program_id = jito_restaking_program::id(); let base_pubkey = pubkey!("base pubkey here"); let ncn_pubkey = Ncn::find_program_address(&program_id, &base_pubkey).0; ``` ## Node Operator Client The Node Operator Client represents the core off-chain logic of the NCN. This is where the actual work and computation happens that the NCN is designed to coordinate and secure. Key characteristics: - Runs arbitrary computation as defined by the NCN's specific requirements - Posts data on-chain through custom instructions - Signs transactions using the operator keypair - Executes the offchain services that the NCN was designed to provide ### Sample Node Operator Clients: - [Tip Router Operator Client](https://github.com/jito-foundation/jito-tip-router/blob/master/tip-router-operator-cli/Cargo.toml) - Handles tip routing calculations and submissions - [Solana Merkle Root Uploader](https://github.com/jito-foundation/jito-solana/blob/master/tip-distributor/src/bin/merkle-root-uploader.rs) - Uploads merkle roots for tip distribution - [Stakenet Keeper](https://github.com/jito-foundation/stakenet/blob/master/keepers/stakenet-keeper/src/main.rs) - Manages stakenet operations and state transitions ## Permissionless Cranker For all of the permissionless operations that need to occur on a regular cycle, NCNs require a client that continually executes instructions to maintain network health and progression. Functions include: - Triggering epoch transitions and snapshots - Processing routine maintenance operations - Executing time-sensitive consensus operations - Managing account cleanup and optimization ### Sample Permissionless Cranker: - [Jito Tip Router Keeper](https://github.com/jito-foundation/jito-tip-router/blob/master/cli/src/keeper/mod.rs) - Automated keeper for tip router operations ## NCN Operation Cycle NCNs operate in continuous cycles that involve: 1. **Setup Phase**: Establishing relationships with operators and vaults through mutual opt-in 2. **Snapshot Phase**: Capturing network state for consistent consensus baselines 3. **Execution Phase**: Operators perform offchain work and submit results 4. **Consensus Phase**: Onchain vote tallying and consensus determination 5. **Reward Phase**: Distribution of rewards based on performance and stake weights 6. **Maintenance Phase**: Account cleanup and network parameter updates ## Administrative Roles NCNs use a sophisticated role-based access control system: - **Primary Admin**: Overall control and high-level governance - **Operator Admin**: Manages operator approvals and relationships - **Vault Admin**: Manages vault approvals and delegation relationships - **Slasher Admin**: Manages slashing logic and enforcement - **Delegate Admin**: Handles asset delegation from NCN accounts - **Metadata Admin**: Updates NCN configuration and metadata - **Weight Table Admin**: Manages token weights and pricing parameters - **NCN Program Admin**: Controls associated onchain programs --- # Definitions > A glossary of terms used in Jito Restaking. - **Node Operator (or Operator)**: A specialized party who runs core functionalities for NCNs, such as performing specific offchain computations and participating in consensus - **Node Consensus Network (NCN)**: A set of node operators running software for the same network, working together to achieve consensus and provide services. - **Vault**: A smart contract that securely holds staked assets and delegates them to operators. - **Vault Receipt Token (VRT)**: A tokenized representation of staked assets inside a vault, allowing for liquidity and composability. - **Staking**: The process of collateraliziung assets to support network operations and earn rewards. - **(Re)staking**: The process of staking already-staked assets, such as liquid staking tokens. E.g. Whereas users can “stake” SOL to NCNs, users can “(re)stake” JitoSOL to NCNs. - **Slashing**: A penalty mechanism where a portion of staked assets and/or expected rewards are forfeited if an operator misbehaves or fails to meet performance requirements. - **Delegation**: The act of assigning staked assets to specific operators within the network. - **Multi-Asset Staking**: The ability to stake various types of SPL tokens, not limited to native blockchain tokens. - **Liquid Staking**: A form of staking that provides liquidity to Solana stakers. - **SPL Token**: Solana Program Library Token, a standard for creating and managing tokens on the Solana blockchain. - **Epoch**: A fixed period in the blockchain during which staking rewards are calculated and distributed. --- # Vault Accounts > An overview of the accounts used in the Jito Vault program. ## 1. About the program The vault program manages the vault receipt tokens (VRTs) and associated deposits. The program stores deposited funds and handles the minting and burning of tokenized stake. It also manages the vault's stake in an NCN, including delegation. ## 2. Diagram ![Vault Accounts](https://www.jito.network/omnidocs/restaking/images/vault_accounts.png) ## 3. Accounts All accounts for the vault program are defined in the [jito-vault-core](https://github.com/jito-foundation/restaking/tree/master/vault_core/src) crate. ### 3.1. Config The configuration account is a global account that is used to configure the vault program. It is used to set the restaking program and other program-wide settings. It also keeps track of the number of vaults, fee caps, and other program-wide settings. The number of vaults is used so programs can programmatically iterate through all vaults in the program. ### 3.2. Vault The Vault account is a central component of the vault program, responsible for managing token deposits, VRT minting and burning, and delegation states. It contains several administrative pubkeys and other vault-wide settings. ### 3.3. VaultNcnTicket - VaultNcnTicket is created by the vault to signify support (or lack of) for a given NCN. - VaultNcnTicket is activated through a warmup process. - VaultNcnTicket is deactivated through a cooldown process. - VaultNcnTicket is used to track the state of the vault's support for a given NCN. - Only the Vault ncn_admin pubkey can modify the VaultNcnTicket account. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; Vault[Vault]:::main Ncn[Ncn]:::main VaultNcnTicket[VaultNcnTicket]:::ticket Vault -->|Creates| VaultNcnTicket Vault -.->|Opts in| Ncn ``` ### 3.4. VaultOperatorDelegation - VaultOperatorDelegation account is created by the vault to signify that the vault has delegated its stake to a given operator. - Only the Vault operator_admin pubkey can create the VaultOperatorDelegation account. - The Vault delegation_admin pubkey can modify the VaultOperatorDelegation account. - The VaultOperatorDelegation account is used to track the state of the vault's delegation to a given operator. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; Vault[Vault]:::main Operator[Operator]:::main VaultOperatorDelegation[VaultOperatorDelegation]:::ticket Vault -->|Creates| VaultOperatorDelegation Vault -.->|Opts in| Operator ``` ### 3.5. VaultNcnSlasherTicket - VaultNcnSlasherTicket is created by the vault to signify that the vault has opted-in to a given slasher. - Only the Vault ncn_admin pubkey can modify the VaultNcnSlasherTicket account. - The VaultNcnSlasherTicket account is used to track the state of the vault's opt-in to a given slasher. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; Vault[Vault]:::main NcnVaultSlasherTicket[NcnVaultSlasherTicket]:::ticket Vault -->|Creates| VaultNcnSlasherTicket Vault -.->|Recognizes and copies from| NcnVaultSlasherTicket ``` ### 3.6. VaultNcnSlasherOperatorTicket - VaultNcnSlasherOperatorTicket is created by the vault to track slashings for a given vault, ncn, slasher, operator, epoch pair. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; Vault[Vault]:::main Ncn[Ncn]:::main Slasher[Slasher]:::main Operator[Operator]:::main VaultNcnSlasherOperatorTicket[VaultNcnSlasherOperatorTicket]:::ticket Vault -->|Creates| VaultNcnSlasherOperatorTicket Vault -.->|Tracks slashing for| Ncn Vault -.->|Tracks slashing by| Slasher Vault -.->|Tracks slashing of| Operator ``` ### 3.7. VaultStakerWithdrawalTicket - VaultStakerWithdrawalTicket is created by the vault to track the withdrawal of a given staker. - Stakers create the VaultStakerWithdrawalTicket account when they initiate a withdrawal. ### 3.8. VaultUpdateStateTracker - VaultUpdateStateTracker is created by the vault during epoch updates to aggregate stake information of the `VaultOperatorDelegation` accounts. ## 4. Tracking State State in these programs is spread out across many accounts. To reason about the state of stake at any given time, one can reference the chart below. Assets are considered staked iff: - The NCN has opted-in to the operator - The operator has opted-in to the NCN - The operator has opted-in to the vault - The vault has opted-in to the operator - The vault has opted-in to the NCN - The NCN has opted-in to the vault - The Vault is delegated to that operator ![img.png](https://www.jito.network/omnidocs/restaking/images/staked_venn_diagram.png) --- # Restaking Accounts > An overview of the accounts used in the Jito Restaking program. ## 1. About the program The restaking program acts as a registry for NCNs, operators, and relationships between NCNs, operators, and vaults. It allows users to do the following: - Registers NCN, operators, and their configurations. - Stores relationships between NCN, operators, and vaults. The restaking program does not store any funds; it is purely used as a registry and relationship manager between entities in the system. ## 2. Diagram ![Restaking Accounts](https://www.jito.network/omnidocs/restaking/images/restaking_accounts.png) ## 2. Ncn NCN (Node Consensus Network) are services that provide infrastructure to the network, such as validators, oracles, keepers, bridges, L2s, and other services that require a staking mechanism for security. NCN can be registered through the restaking program. There are several things one can do after registering an NCN: - Add and remove support for operators participating in the NCN operator set. - Add and remove support for vaults - Add and remove support for slashers - Withdraw funds sent to the NCN from rewards, airdrops, and other sources. ## 3. Operator Operators are entities responsible for running NCN software. Operators can register through the restaking program and configure several variables: - Add and remove support for vaults - Add and remove support for NCN - Change voter keys - Withdraw funds sent to the operator from rewards, airdrops, and other sources. ## 4.1. NcnOperatorState This state represents the mutual opt-in relationship between an NCN and an Operator. The NCN initializes this state. Once created, the NCN and operator can both warm-up and cooldown the state to show support for each other. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; NCN[NCN]:::main Operator[Operator]:::main NcnOperatorState[NcnOperatorState]:::ticket NCN -->|Creates| NcnOperatorState NCN -.->|Opts in| Operator Operator -.->|Opts in| NCN Operator -->|Updates| NcnOperatorState ``` ## 4.2. NcnVaultTicket This ticket represents the relationship between an NCN and a Vault. It is created by the NCN to opt in to work with a Vault. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; NCN[NCN]:::main Vault[Vault]:::main NcnVaultTicket[NcnVaultTicket]:::ticket NCN -->|Creates| NcnVaultTicket NCN -.->|Opts in| Vault ``` ## 4.3. OperatorVaultTicket This ticket represents the relationship between an Operator and a Vault. It is created by the Operator to opt in to work with a Vault. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; Operator[Operator]:::main Vault[Vault]:::main OperatorVaultTicket[OperatorVaultTicket]:::ticket Operator -->|Creates| OperatorVaultTicket Operator -.->|Opts in| Vault ``` ## 4.4. NcnVaultSlasherTicket This ticket represents the slashing relationship between an NCN and a Vault. The NCN register slashers. ```mermaid graph TD classDef main fill: #f9f, stroke: #333, stroke-width: 2px; classDef ticket fill: #fff, stroke: #333, stroke-width: 1px; Ncn[Ncn]:::main Vault[Vault]:::main NcnVaultSlasherTicket[NcnVaultSlasherTicket]:::ticket Ncn -->|Creates| NcnVaultSlasherTicket Ncn -.->|Opts in| Vault ``` --- # Introduction > Overview of Node Consensus Networks and the NCN template ## Introduction Node Consensus Networks (NCN) are robust consensus networks built on Solana. They enables network participants to leverage staked assets to agree on critical network decisions. NCNs utilize Jito's restaking infrastructure, allowing operators with delegated tokens to vote on network parameters and states. This tutorial focuses on a [pre-built NCN program](https://github.com/jito-foundation/ncn-template) that serves as a template or base that you can use to create your own NCN program. To help you understand how it works, we will walk through building a simulation test that covers the majority of its setup and functionality. We do not recommend most NCN developers build an NCN from scratch. Rather, we suggest using this prebuilt program as a starting point and customizing it according to your needs. Note: The NCN implementation code is not audited. By following the simulation test setup in this guide, you will gain hands-on experience with the entire NCN lifecycle: initializing vaults and operators using Jito's restaking and vault programs, configuring the NCN program, and executing the full voting process. ### The purpose of NCNs Decentralized networks require reliable mechanisms for participants to reach consensus without central authorities. The NCN addresses this need by: 1. Providing a secure voting framework where influence is proportional to the amount of stake held. 2. Supporting multiple token types with configurable voting weights, allowing flexibility in how voting power is assigned. 3. Creating verifiable and immutable records of consensus decisions on the blockchain. 4. Establishing a solid foundation for network governance and parameter setting. ### NCN components To run an NCN, you need one or more of each of the following three components, which interact with each other: Vaults, Operators, and the NCN Program itself. #### 1. Vaults Vaults are accounts that hold tokens and delegate them to operators. They play a crucial role in the NCN by: 1. Holding the tokens used for staking. 2. Delegating stake (voting power) to chosen operators. 3. Enabling stake-weighted participation in the network's governance. #### 2. Operators Operators are accounts that receive delegated stake from vaults and actively participate in the voting process. Their key functions are: 1. Receiving stake delegations from one or more vaults. 2. Casting votes on behalf of the delegated stake during consensus rounds. 3. Forming the network of active participants who drive the consensus process. #### 3. Keepers Keepers are offchain agents that monitor the network and submit onchain instructions to advance the NCN through its lifecycle. They operate autonomously and are fully permissionless. Their responsibilities include: 1. Monitoring the current onchain state. 2. Executing program instructions to progress through state like voting, post-vote logging and epoch finalization. 3. Emitting metrics or logs to external systems for observability. #### 4. NCN program The NCN Program is the core on-chain component of the system. It's the smart contract that NCN developers build and deploy. Its main responsibilities are: 1. Storing the global configuration parameters for the NCN instance. 2. Maintaining the registry of participating vaults and supported token types. 3. Managing the state for each voting epoch (consensus cycle). ### NCN Lifecycle The Node Consensus Network operates in a well-defined lifecycle that consists of three main phases: 1. **Initial Setup (One-time)**: This phase involves establishing the foundational infrastructure of the NCN. It includes: - Configuring the NCN parameters - Initializing the vault registry - Registering supported token types and assigning weights The initial setup is performed only once when the NCN is first deployed, with occasional administrative updates as needed (such as adjusting token weights or adding new supported tokens). 2. **Snapshotting (Recurring)**: At the beginning of each consensus cycle (epoch), the system captures the current state of all participants: - Creating epoch state and weight tables - Taking snapshots of operator stake weights - Recording vault-operator delegations - Calculating total voting power distribution This phase ensures that voting is based on a consistent, point-in-time view of the network, preventing manipulation during the voting process. 3. **Voting (Recurring)**: After snapshotting is complete, operators can cast their votes: - Operators submit their choices (e.g., weather status) - Votes are weighted according to the operator's stake --- # NCN Components > The three essential components that work together to create a Node Consensus Network ## NCN Components To run an NCN, you need one or more of each of the following three components, which interact with each other: Vaults, Operators, and the NCN Program itself. ### 1. Vaults Vaults are accounts that hold tokens and delegate them to operators. They play a crucial role in the NCN by: 1. Holding the tokens used for staking. 2. Delegating stake (voting power) to chosen operators. 3. Enabling stake-weighted participation in the network's governance. ### 2. Operators Operators are accounts that receive delegated stake from vaults and actively participate in the voting process. Their key functions are: 1. Receiving stake delegations from one or more vaults. 2. Casting votes on behalf of the delegated stake during consensus rounds. 3. Forming the network of active participants who drive the consensus process. ### 3. NCN Program The NCN Program is the core on-chain component of the system. It's the smart contract that NCN developers build and deploy. Its main responsibilities are: 1. Storing the global configuration parameters for the NCN instance. 2. Maintaining the registry of participating vaults and supported token types. 3. Managing the state for each voting epoch (consensus cycle). --- # Getting Started > Getting started with building our sample NCN ## Get to know the program template Our example NCN Program facilitates consensus on a simple "weather status" using a stake-weighted voting mechanism. It operates in distinct time periods called epochs (your NCN's epochs do not have to be equivalent to a Solana epoch). The program uses a weight-based system to determine the influence (voting power) of different operators. Consensus is achieved when votes representing at least 66% of the total participating stake weight agree on the same outcome (ballot). ### Key components The program uses several types of accounts: 1. **Global Accounts**: Initialized once at the start and updated infrequently. - **[`Config`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#config)**: Stores global settings like epoch timing parameters (`epochs_before_stall`, `epochs_after_consensus_before_close`) and voting validity periods (`valid_slots_after_consensus`). - **[`VaultRegistry`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultregistry)**: Manages the list of registered vaults and the different types of stake tokens (mints) the NCN supports. - **[`AccountPayer`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#accountpayer)**: An empty PDA account used to hold SOL temporarily for paying rent during account creation or reallocation. 2. **Per-Consensus Cycle Accounts**: Initialized at the beginning of each epoch and usually closed shortly after the cycle ends. - **[`WeightTable`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#weighttable)**: Stores the specific voting weights assigned to different stake tokens for the current epoch. - **[`EpochState`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus)**: Tracks the status and progress of the current epoch's consensus cycle. - **[`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox)**: Handles the collection and stake-weighted tallying of votes for the current epoch's decision (e.g., weather status). - **[`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot)**: Captures the state of stake delegations at the beginning of the epoch to ensure consistent voting weights throughout the cycle. - **[`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot)**: Records each operator's total stake weight and delegation breakdown for the current epoch. - **[`ConsensusResult`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#consensusresult)**: Stores the final outcome (the winning ballot and associated details) for the completed epoch. - **[`EpochMarker`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochmarker)**: A marker account created when all temporary accounts for an epoch have been successfully closed. 3. **Component Structures**: These are not separate accounts but important data structures used within the accounts above. - **[`Ballot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballot)**: Represents a single potential outcome in the consensus process. - **[`BallotTally`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballottally)**: Aggregates votes and stake weight for a specific ballot. - **[`OperatorVote`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorvote)**: Records a vote cast by a single operator. - **[`VaultOperatorStakeWeight`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultoperatorstakeweight)**: Tracks the weighted stake from a specific vault to an operator. - **[`StMintEntry`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#stmintentry)**: Represents a supported token mint and its voting weight in the VaultRegistry. - **[`VaultEntry`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultentry)**: Represents a registered vault in the VaultRegistry. ### Weather status system The goal of the NCN program is to come to consensus on the weather in Solana Beach. For the purposes of keeping this tutorial simple, our weather statuses are as follows: 1. **Sunny (0)**: Represents clear, sunny weather. 2. **Cloudy (1)**: Represents cloudy weather conditions. 3. **Rainy (2)**: Represents rainy weather conditions. Operators vote on these status values. The program tallies the votes, weighting each vote by the operator's associated stake weight, to determine the final consensus result. Leveraging the final result of this NCN, we can build onchain programs whose behavior is dependent on the weather in Solana Beach. ### Consensus mechanism The consensus process follows these steps: 1. Operators cast votes, choosing a specific weather status (Sunny, Cloudy, or Rainy). 2. Each vote's influence is determined by the operator's total stake weight, calculated from delegations received. 3. Votes are collected and tallied within the `BallotBox` account for the current epoch. 4. Consensus is reached when one weather status receives votes representing ≥66% of the total stake weight participating in that epoch. 5. The final consensus result (winning status, total weight supporting it, etc.) is recorded in the `ConsensusResult` account. ### Onchain program overview The onchain program is written in Rust (without using the Anchor framework) and consists of several instructions that can be called to perform various actions within the NCN. The instruction logic resides in the `/program` directory, while shared core logic is located in the `/core` directory. The instructions are broadly categorized: 1. **Admin Instructions**: These require administrator privileges and are used for initial setup and configuration. - `admin_initialize_config`: Initializes the main `Config` account. - `admin_register_st_mint`: Registers a new type of stake token (ST) the NCN will support. - `admin_set_new_admin`: Transfers administrative control to a new keypair. - `admin_set_parameters`: Updates parameters within the `Config` account. - `admin_set_st_mint`: Updates details for an existing supported token mint (Deprecated/Redundant? Check `admin_register_st_mint` and `admin_set_weight`). - `admin_set_tie_breaker`: Configures the tie-breaking mechanism or authority. - `admin_set_weight`: Sets or updates the voting weight for a specific supported token mint. 2. **Permissionless Keeper Instructions**: These are permissionless instructions, meaning anyone can call them to advance the state of the NCN, typically moving between epoch phases. They ensure the NCN progresses correctly. - `initialize_epoch_state`: Creates the `EpochState` account for a new epoch. - `initialize_vault_registry`: Creates the initial `VaultRegistry` account. - `realloc_vault_registry`: Increases the size of the `VaultRegistry` account, to reach the desired size. Solana has a limitation when it comes to the size of the account that you can allocate in one call, so when you have a larger account, you will need to call realloc on it multiple times to reach the desired size. - `initialize_weight_table`: Creates the `WeightTable` account for an epoch. - `realloc_weight_table`: Increases the size of the `WeightTable` account. - `initialize_epoch_snapshot`: Creates the main `EpochSnapshot` account. - `initialize_operator_snapshot`: Creates an `OperatorSnapshot` account for a specific operator within an epoch. - `set_epoch_weights`: Populates the `WeightTable` with weights from the `VaultRegistry`. - `snapshot_vault_operator_delegation`: Records the weighted stake from a specific vault delegation into the relevant `OperatorSnapshot`. - `initialize_ballot_box`: Creates the `BallotBox` account for voting in an epoch. - `realloc_ballot_box`: Increases the size of the `BallotBox` account. - `register_vault`: Registers a vault (that has already been approved via Jito handshake) with the NCN program's `VaultRegistry`. - `close_epoch_account`: Closes temporary epoch-specific accounts (like `EpochState`, `BallotBox`, etc.) after they are no longer needed, reclaiming rent. 3. **Operator Instruction**: This is the primary action taken by participants during a consensus cycle. - `cast_vote`: Allows an operator (using their admin key) to submit their vote for the current epoch. For more details, you can always check the source code or the API documentation [here](https://github.com/jito-foundation/ncn-template). --- # Building Weather NCN > A hands-on tutorial for building and testing a complete NCN system with voting and consensus ## Build and run the simulation test This section will walk through building a simulation test of our example NCN program. The test represents a comprehensive scenario designed to mimic a complete NCN system. It involves multiple operators, vaults, and different types of tokens. The test covers the entire workflow, from the initial setup of participants and the NCN program itself, through the voting process, and finally to reaching and verifying consensus. It heavily utilizes Jito's restaking and vault infrastructure alongside the custom NCN voting logic. The NCN program used can be found [here](https://github.com/jito-foundation/ncn-template). By creating a simulation test of this NCN, you'll be better prepared to use it as a template or base that you can adapt to create your own NCN program. Just a reminder: we do not recommend most NCN developers build their NCN from scratch. Rather, we suggest using this prebuilt program as a starting point and customizing it according to your needs. The simulation test we'll be creating below can also be found in the [example NCN repository](https://github.com/jito-foundation/ncn-template). However, you'll understand the system better if you write the test along with us, so feel free to clone the repository, delete the test file `./integration_tests/test/ncn_program/simulation_test.rs`, and follow along. This will give you hands-on experience with the entire NCN lifecycle: initializing vaults and operators using Jito's restaking and vault programs, configuring the NCN program, and executing the full voting process. ### Prerequisites Before running the simulation test, ensure you have completed the following setup steps: 1. Build the NCN onchain program using Cargo: `cargo build-sbf --manifest-path program/Cargo.toml --sbf-out-dir integration_tests/tests/fixtures` 2. Ensure you have the correct versions installed: - Solana CLI: 2.2.6 (recommended) - Rust/Cargo: 1.81 or newer ### Building the Simulation Test Let's build the simulation test step by step. #### 1. Create a new file You can start with a blank file. Create a new file named `simulation_test.rs` inside the `integration_tests/tests` folder. Copy and paste the following boilerplate code at the bottom of your test function: ```rust #[cfg(test)] mod tests { use crate::fixtures::{test_builder::TestBuilder, TestResult}; use jito_restaking_core::{config::Config, ncn_vault_ticket::NcnVaultTicket}; use ncn_program_core::{ballot_box::WeatherStatus, constants::WEIGHT}; use solana_sdk::{msg, signature::Keypair, signer::Signer}; #[tokio::test] async fn simulation_test() -> TestResult<()> { // YOUR TEST CODE WILL GO HERE // 2. ENVIRONMENT SETUP // 3. NCN SETUP // 4. OPERATORS AND VAULTS SETUP // 5. NCN PROGRAM CONFIGURATION // 6. Epoch Snapshot and Voting Preparation // 7. VOTING // 8. REWARDS DISTRIBUTION // 9. VERIFICATION // 10. CLEANUP Ok(()) } } ``` Unless otherwise specified, all of the code snippets provided in this guide represent code that should go inside the `simulation_test` test function, in the order provided. Next, you need to make this new test discoverable. Copy and paste the following line into the `integration_tests/tests/mod.rs` file to declare the new module: ```rust // integration_tests/tests/mod.rs mod simulation_test; ``` Now, you can run this specific test using the following command: ```bash SBF_OUT_DIR=integration_tests/tests/fixtures cargo test -p ncn-program-integration-tests --test tests simulation_test ``` This command targets the `ncn-program-integration-tests` package and runs only the `simulation_test` test function. If you want to run all tests in the suite, simply remove the test name filter (`-p ncn-program-integration-tests --test tests simulation_test`) from the command. Currently, the test will pass because it doesn't contain any logic yet. You should see output similar to this: ```bash running 1 test test ncn_program::simulation_test::tests::simulation_test ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 54 filtered out; finished in 0.00s ``` #### 2. Environment Setup The first step within our test function is to set up the testing environment using the `TestBuilder`. Copy and paste the following code at the bottom of your test function: ```rust let mut fixture = TestBuilder::new().await; ``` The `TestBuilder` is a test utility that encapsulates and simplifies the setup process for NCN program testing. It provides: 1. A local test validator environment with pre-loaded programs 2. Clients for interacting with the NCN, Vault, and Restaking programs 3. Helper methods for common operations (creating operators, vaults, advancing clock time) 4. Management of test accounts, keypairs, and token mints This and other utility functions (like `add_operators_to_test_ncn`, `add_vaults_to_test_ncn`) abstract away much of the complex, repetitive setup code, allowing tests to focus on the specific behaviors being verified rather than boilerplate infrastructure. Since we are running this test locally against a test ledger, we need to initialize the Jito Restaking and Vault programs on the ledger. In a real network environment (devnet, mainnet), these programs would already be deployed and configured. Copy and paste the following code at the bottom of your test function: ```rust fixture.initialize_restaking_and_vault_programs().await?; ``` Finally, let's prepare some client objects and configuration variables we'll use throughout the test. Copy and paste the following code at the bottom of your test function: ```rust let ncn_program_client = fixture.ncn_program_client(); let vault_program_client = fixture.vault_client(); let restaking_client = fixture.restaking_program_client(); // Define test parameters const OPERATOR_COUNT: usize = 13; // Number of operators to simulate let mints = vec![ (Keypair::new(), WEIGHT), // Alice: Base weight (Keypair::new(), WEIGHT * 2), // Bob: Double weight (Keypair::new(), WEIGHT * 3), // Charlie: Triple weight (Keypair::new(), WEIGHT * 4), // Dave: Quadruple weight ]; let delegations = [ 1, // Minimum delegation amount (e.g., 1 lamport) 10_000_000_000, // 10 tokens (assuming 9 decimals) 100_000_000_000, // 100 tokens 1_000_000_000_000, // 1,000 tokens 10_000_000_000_000, // 10,000 tokens ]; ``` This code does the following: 1. Gets client handles for interacting with the NCN, Vault, and Restaking programs. 2. Defines `OPERATOR_COUNT` to specify how many operators we'll create. 3. Sets up `mints`: a list of keypairs representing different SPL token mints and their corresponding voting weights. We use different weights to test the stake-weighting mechanism. `WEIGHT` is likely a constant representing the base unit of weight. 4. Defines `delegations`: an array of different token amounts (in lamports, assuming 9 decimals for typical SPL tokens) that vaults will delegate to operators. #### 3. NCN Setup Now, let's create the NCN account using the Jito Restaking program. The `create_test_ncn` helper function handles the necessary instruction calls. Copy and paste the following code at the bottom of your test function: ```rust let mut test_ncn = fixture.create_test_ncn().await?; let ncn_pubkey = test_ncn.ncn_root.ncn_pubkey; ``` This step: - Calls the Jito Restaking program to create a new Node Consensus Network (NCN) account and its associated administrative structures. - Stores the public key (`ncn_pubkey`) of the newly created NCN, which we'll need to interact with it later. If you run the test at this point (`cargo test ... simulation_test`), you should see transaction logs in the output, indicating that the NCN creation instructions were executed successfully. #### 4. Operators and Vaults Setup This phase is crucial for simulating a realistic network. We will create the operators who vote and the vaults that provide the stake (voting power). ##### 4.1 Operator Creation and NCN Connection We'll add the specified number of operators (`OPERATOR_COUNT`) to our NCN using another helper function. Copy and paste the following code at the bottom of your test function: ```rust fixture .add_operators_to_test_ncn(&mut test_ncn, OPERATOR_COUNT, Some(100)) .await?; ``` This `add_operators_to_test_ncn` function performs several actions by calling instructions in the Jito Restaking program: - Creates `OPERATOR_COUNT` (13 in our case) separate operator accounts. - Sets an optional operator fee (here, 100 basis points = 1%). - Establishes a secure, bidirectional "handshake" between each newly created operator and the NCN. The handshake process involves multiple steps: 1. Creating the operator account itself, managed by its unique admin keypair. 2. Initializing the state that tracks the relationship between the NCN and the operator (`do_initialize_ncn_operator_state`). 3. Warming up the connection from the NCN's perspective (`do_ncn_warmup_operator`). 4. Warming up the connection from the operator's perspective (`do_operator_warmup_ncn`). For more information on this, please read the guide [here](https://www.jito.network/docs/restaking/core-concepts/operator.md) This handshake is essential for security. It ensures that operators must explicitly connect to the NCN (and vice-versa) and potentially wait through an activation period before they can participate in voting. ##### 4.2 Vault Creation Next, we create vaults to hold the different types of tokens we defined earlier. We'll distribute them across the token types. Note that you can have more than one vault with the same ST Mint (Support Token Mint). Copy and paste the following code at the bottom of your test function: ```rust // Create vaults associated with different token mints { // Create 3 vaults for Alice (base weight) fixture .add_vaults_to_test_ncn(&mut test_ncn, 3, Some(mints[0].0.insecure_clone())) .await?; // Create 2 vaults for Bob (double weight) fixture .add_vaults_to_test_ncn(&mut test_ncn, 2, Some(mints[1].0.insecure_clone())) .await?; // Create 1 vault for Charlie (triple weight) fixture .add_vaults_to_test_ncn(&mut test_ncn, 1, Some(mints[2].0.insecure_clone())) .await?; // Create 1 vault for Dave (quadruple weight) fixture .add_vaults_to_test_ncn(&mut test_ncn, 1, Some(mints[3].0.insecure_clone())) .await?; } ``` The `add_vaults_to_test_ncn` helper function orchestrates calls to both the Jito Vault and Jito Restaking programs to: - Create a total of 7 vaults (3 + 2 + 1 + 1). - Associate each group of vaults with one of our predefined token mints (`mints[0]`, `mints[1]`, etc.). - Initialize the vault accounts using the Jito Vault program (setting zero fees, which is common for testing). - Mint tokens for the vaults if needed (though here we provide the mints). - Establish bidirectional handshakes "Tickets" between each vault and the NCN using specific Jito Restaking instructions (`do_initialize_ncn_vault_ticket`, `do_warmup_ncn_vault_ticket`). - Establish corresponding handshakes "Tickets" using Jito Vault program instructions (`do_initialize_vault_ncn_ticket`, `do_warmup_vault_ncn_ticket`). - Establish bidirectional handshakes "Tickets" between each new vault and _all_ existing operators using Jito Restaking (`do_initialize_operator_vault_ticket`, `do_warmup_operator_vault_ticket`) and Jito Vault (`do_initialize_vault_operator_delegation`) instructions. Note that `do_initialize_vault_operator_delegation` only sets up the _potential_ for delegation; no actual tokens are delegated yet. - Advance the simulated clock (`fixture.advance_slots`) after handshakes "Tickets" to ensure the relationships become active, simulating the necessary waiting period. Creating vaults with different token types allows us to test how the NCN handles varying voting power based on token weights. ##### 4.3 Delegation Setup This is where vaults actually delegate their tokens (stake) to operators, granting them voting power. We'll iterate through operators and vaults to create delegations. Copy and paste the following code at the bottom of your test function: ```rust // Vaults delegate stake to operators { // Iterate through all operators except the last one for (index, operator_root) in test_ncn .operators .iter() .take(OPERATOR_COUNT - 1) .enumerate() { // Each vault delegates to this operator for vault_root in test_ncn.vaults.iter() { // Cycle through the predefined delegation amounts let delegation_amount = delegations[index % delegations.len()]; if delegation_amount > 0 { // Call the Vault program to add the delegation vault_program_client .do_add_delegation( vault_root, // The vault delegating &operator_root.operator_pubkey, // The operator receiving delegation_amount, // The amount to delegate ) .await .unwrap(); } } } } ``` The delegation process is where voting power is established. Each vault delegates tokens to operators, which determines: 1. How much voting power each operator has 2. How token weights multiply that power 3. The distribution of influence across the network Key aspects of the delegation setup: - Every vault delegates to every operator (except the last one for this example) - Note that vaults can choose whom to delegate to, they don't have to delegate to all operators - Delegation amounts cycle through the `delegations` array to test different scenarios - The last operator intentionally receives zero delegation to test the system's handling of operators without stake - The delegation is performed directly through the vault program using `do_add_delegation` which will call a specific instruction in the vault program to do that Each operator accumulates voting power from all the different delegations they receive. The total voting power for an operator is the sum of the weighted values of each delegation. **Example:** - Vault A (holding Alice, weight W) delegates 100 tokens to Operator X. Power contribution: 100 \* W. - Vault B (holding Bob, weight 2W) delegates 50 tokens to Operator X. Power contribution: 50 _2W = 100_ W. - Operator X's total voting power would be (100 _W) + (50_ 2W) = 200 \* W. This distributed delegation model enables testing complex scenarios where: - Operators have vastly different amounts of influence. - Tokens with higher weights contribute disproportionately more voting power. - The distribution of delegations affects consensus outcomes. The deliberate omission of delegation to the last operator creates a control case to verify that operators with zero stake cannot influence the voting process, which is a critical security feature. You can run the test now and see the output. ##### 4.4 Delegation Architecture and Voting Power Calculation The delegation architecture follows a multiplication relationship: - **Operator Voting Power = Sum of (Delegation Amount × Delegated Token's Weight)** Each operator accumulates voting power from all the different delegations they receive. The total voting power for an operator is the sum of the weighted values of each delegation. **Example:** - Vault A (holding TKN1, weight W) delegates 100 tokens to Operator X. Power contribution: 100 \* W. - Vault B (holding TKN2, weight 2W) delegates 50 tokens to Operator X. Power contribution: 50 _2W = 100_ W. - Operator X's total voting power would be (100 _W) + (50_ 2W) = 200 \* W. This distributed delegation model enables testing complex scenarios where: - Operators have vastly different amounts of influence. - Tokens with higher weights contribute disproportionately more voting power. - The distribution of delegations affects consensus outcomes. The deliberate omission of delegation to the last operator creates a control case to verify that operators with zero stake cannot influence the voting process, which is a critical security feature. You can run the test now and see the output. #### 5. NCN Program Configuration Until now, all the code we've written uses the Jito restaking program and Jito vault program. Now we will start using the example NCN program that you will have to deploy. The NCN Program Configuration phase establishes the on-chain infrastructure necessary for the voting and consensus mechanisms. This includes setting up configuration parameters, creating data structures, and registering the token types and vaults that will participate in the system. ##### 5.1 Program Configuration Initialization First, we initialize the main configuration account for our NCN instance. Copy and paste the following code at the bottom of your test function: ```rust // Initialize the main Config account for the NCN program ncn_program_client .do_initialize_config(test_ncn.ncn_root.ncn_pubkey, &test_ncn.ncn_root.ncn_admin) .await?; ``` This step initializes the core configuration for the NCN program with critical parameters: - **NCN Admin**: The authority that can modify configuration settings, this admin has to be the same admin for the NCN account from Jito restaking program side. - **Epochs Before Stall**: How many epochs before a non-completed consensus cycle is considered stalled (default: 3) - **Epochs After Consensus Before Close**: How long to wait after consensus before closing epoch data (default: 10) - **Valid Slots After Consensus**: How many slots votes are still accepted after consensus is reached (default: 10000) Under the hood, this creates an `NcnConfig` account that stores these parameters and serves as the authoritative configuration for this NCN instance. ##### 5.2 Vault Registry Initialization The vault registry account is a large one, so it is not possible to initialize it in one call due to Solana network limitations. We will have to call the NCN program multiple times to get to the full size. The first call will be an init call to the instruction `admin_initialize_vault_registry`. After that, we will call a realloc instruction `admin_realloc_vault_registry` to increase the size of the account. This will be done in a loop until the account is the correct size. The realloc will take care of assigning the default values to the vault registry account once the desirable size is reached. In our example, we will do that by calling one function `do_full_initialize_vault_registry`. If you want to learn more about this, you can check the [source code](https://github.com/jito-foundation/ncn-template). Copy and paste the following code at the bottom of your test function: ```rust // Initialize the VaultRegistry account (handles potential reallocations) ncn_program_client .do_full_initialize_vault_registry(test_ncn.ncn_root.ncn_pubkey) .await?; ``` The vault registry is a critical data structure that: - Tracks all supported vault accounts - Maintains the list of supported token mints (token types) - Records the weight assigned to each token type - Serves as the source of truth for vault and token configurations Note that this is only initializing the vault registry. The vaults and the supported tokens will be registered in the next steps. Check out the vault registry struct [here](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultregistry) ##### 5.3 Activating Relationships with Time Advancement Next, we advance the simulation clock to ensure that all previously established handshake relationships (NCN-Operator, NCN-Vault, Operator-Vault) become active, as Jito's restaking infrastructure often includes activation periods. Copy and paste the following code at the bottom of your test function: ```rust // Fast-forward time to simulate a full epoch passing // This is needed for all the relationships to get activated let restaking_config_address = Config::find_program_address(&jito_restaking_program::id()).0; let restaking_config = restaking_client .get_config(&restaking_config_address) .await?; let epoch_length = restaking_config.epoch_length(); fixture .warp_slot_incremental(epoch_length * 2) .await .unwrap(); ``` This section: 1. Retrieves the epoch length from the restaking program configuration 2. Advances the simulation time by two full epochs 3. Ensures all handshake relationships between NCN, operators, and vaults become active The time advancement is necessary because Jito's restaking infrastructure uses an activation period for security. This prevents malicious actors from quickly creating and voting with fake operators or vaults by enforcing a waiting period before they can participate. Now it is time to register the supported tokens with the NCN program and assign weights to each mint for voting power calculations. Copy and paste the following code at the bottom of your test function: ```rust // Register each Supported Token (ST) mint and its weight in the NCN's VaultRegistry for (mint, weight) in mints.iter() { ncn_program_client .do_admin_register_st_mint(ncn_pubkey, mint.pubkey(), *weight) .await?; } ``` This step registers each Supported Token (ST) mint with the NCN program and assigns the appropriate weight: - Each token mint (Alice, Bob, Charlie, Dave) is registered with its corresponding weight - The weights determine the voting power multiplier for delegations in that token - Only the NCN admin has the authority to register tokens, ensuring trust in the system - Registration involves updating the vault registry with each token's data - The NCN admin can update the weights of the tokens at any time, which will affect the voting power of the delegations in the next consensus cycle The weight assignment is fundamental to the design, allowing different tokens to have varying influence on the voting process based on their economic significance or other criteria determined by the NCN administrators. It's good to know that in real-life examples, NCNs will probably want to set the token weights based on the token's price or market cap. To do so, you will have to use an oracle to get the price of the token and then set the weight based on that. In this case, you will have to store the feed of the price in this step instead of the weight. ##### 5.5 Vault Registration Registering a vault is a permissionless operation. The reason is the admin has already given permission to the vault to be part of the NCN in the vault registration step earlier, so this step is just to register the vault in the NCN program. Copy and paste the following code at the bottom of your test function: ```rust // Register all the vaults in the ncn program for vault in test_ncn.vaults.iter() { let vault = vault.vault_pubkey; let (ncn_vault_ticket, _, _) = NcnVaultTicket::find_program_address( &jito_restaking_program::id(), &ncn_pubkey, &vault, ); ncn_program_client .do_register_vault(ncn_pubkey, vault, ncn_vault_ticket) .await?; } ``` The final configuration step registers each vault with the NCN program: 1. For each vault created earlier, the system finds its NCN vault ticket PDA (Program Derived Address) 2. The vault is registered in the NCN program's vault registry 3. This creates the association between the vault and its supported token type 4. The registration enables the NCN program to track vault delegations for voting power calculation This registration process establishes the complete set of vaults that can contribute to the voting system, creating a closed ecosystem of verified participants. ##### 5.6 NCN Architecture and Security Considerations ##### 5.5 Architecture Considerations The NCN program configuration establishes a multi-layered security model: 1. **Authentication Layer**: Only the NCN admin can initialize configuration and register tokens 2. **Relationship Layer**: Only vaults and operators with established, active handshakes can participate 3. **Time Security Layer**: Enforced waiting periods prevent quick creation and use of malicious actors 4. **Registry Layer**: All participants must be registered and tracked in on-chain registries This layered approach ensures the integrity of the voting system by validating the identity and relationships of all participants before they can influence the consensus process. The configuration phase completes the preparation of the system's infrastructure, setting the stage for the actual voting mechanics to begin in subsequent phases. #### 6. Epoch Snapshot and Voting Preparation The Epoch Snapshot and Voting Preparation phase is where the system captures the current state of all participants and prepares the infrastructure for voting. This is an essential component of the architecture as it ensures voting is based on a consistent, verifiable snapshot of the network state at a specific moment in time. The upcoming section is a keeper task (with the exception of the voting). This means that it is permissionless and can be done by anyone. ##### 6.1 Epoch State Initialization To begin a new consensus cycle (epoch), we first initialize an `EpochState` account for our NCN, which will track the progress of this epoch. Copy and paste the following code at the bottom of your test function: ```rust // Initialize the epoch state for the current epoch fixture.add_epoch_state_for_test_ncn(&test_ncn).await?; ``` This step initializes the **Epoch State** for the current consensus cycle: - It creates an `EpochState` account tied to the specific NCN and epoch. - This account tracks the progress through each stage of the consensus cycle. - It maintains flags for each phase (weight setting, snapshot taking, voting, closing). - The epoch state provides protection against out-of-sequence operations. - It stores metadata like the current epoch, slot information, and participant counts. Once initialized, the `EpochState` account becomes the authoritative record of where the system is in the voting process, preventing operations from happening out of order or in duplicate. You can take a look at the epoch state struct [here](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus). ##### 6.2 Weight Table Initialization and Population For the current epoch, we initialize a `WeightTable` and populate it by copying the token weights from the `VaultRegistry`, effectively freezing these weights for the duration of this consensus cycle. Copy and paste the following code at the bottom of your test function: ```rust // Initialize the weight table to track voting weights let clock = fixture.clock().await; let epoch = clock.epoch; ncn_program_client .do_full_initialize_weight_table(test_ncn.ncn_root.ncn_pubkey, epoch) .await?; // Take a snapshot of weights for each token mint ncn_program_client .do_set_epoch_weights(test_ncn.ncn_root.ncn_pubkey, epoch) .await?; ``` The weight table mechanism handles the token weights for the current epoch in two stages: 1. **Weight Table Initialization**: - Creates a [`WeightTable`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#weighttable) account for the specific epoch using `do_full_initialize_weight_table`. This may involve multiple calls internally to allocate sufficient space. - Allocates space based on the number of supported tokens registered in the [`VaultRegistry`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultregistry). - Links the table to the NCN and current epoch. - Initializes the table structure with empty entries. 2. **Weight Setting**: - Populates the [`WeightTable`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#weighttable) by calling `do_set_epoch_weights` - Copies the current weights from the [`VaultRegistry`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultregistry) to the epoch-specific `WeightTable`. - "Freezes" these weights for the duration of the consensus cycle. - Updates the [`EpochState`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus) to mark weight setting as complete. - Creates an immutable record of token weights that will be used for voting. This two-step process is critical for the integrity of the system as it: - Creates a permanent record of weights at the time voting begins. - Prevents weight changes during a consensus cycle from affecting ongoing votes. - Allows transparent verification of the weights used for a particular vote. - Enables historical auditing of how weights changed over time. ##### 6.3 Epoch Snapshot Creation We then create an `EpochSnapshot` account to record the overall state for this epoch, such as total operator and vault counts, and to accumulate total stake weight. Copy and paste the following code at the bottom of your test function: ```rust // Take the epoch snapshot fixture.add_epoch_snapshot_to_test_ncn(&test_ncn).await?; ``` The epoch snapshot captures the aggregate state of the entire system: - Creates an [`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot) account for the NCN and epoch. - Records the total number of operators and vaults expected to participate. - Captures the total potential stake weight across all participants (initialized to zero). - Stores important metadata like the snapshot creation slot. - Serves as the reference point for total voting power calculations, acting as the denominator for consensus thresholds. ##### 6.4 Operator Snapshots Next, individual `OperatorSnapshot` accounts are created for each participating operator, capturing their state and expected delegations for the epoch. Copy and paste the following code at the bottom of your test function: ```rust // 2.b. Initialize the operators using the Jito Restaking program, and initiate the // handshake relationship between the NCN <> operators { for _ in 0..OPERATOR_COUNT { // Set operator fee to 100 basis points (1%) let operator_fees_bps: Option = Some(100); // Initialize a new operator account with the specified fee let operator_root = restaking_client .do_initialize_operator(operator_fees_bps) .await?; // Establish bidirectional handshake between NCN and operator: // 1. Initialize the NCN's state tracking (the NCN operator ticket) for this operator restaking_client .do_initialize_ncn_operator_state( &test_ncn.ncn_root, &operator_root.operator_pubkey, ) .await?; // 2. Advance slot to satisfy timing requirements fixture.warp_slot_incremental(1).await.unwrap(); // 3. NCN warms up to operator - creates NCN's half of the handshake restaking_client .do_ncn_warmup_operator(&test_ncn.ncn_root, &operator_root.operator_pubkey) .await?; // 4. Operator warms up to NCN - completes operator's half of the handshake restaking_client .do_operator_warmup_ncn(&operator_root, &test_ncn.ncn_root.ncn_pubkey) .await?; // Add the initialized operator to our test NCN's operator list test_ncn.operators.push(operator_root); } } ``` This step creates an individual snapshot for each operator in the system: - For each operator, it creates an [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot) account linked to the operator, NCN, and epoch. - Records the operator's total delegated stake weight at this moment (initialized to zero). - Captures the expected number of vault delegations for the operator. - Verifies the operator has active handshakes with the NCN. - Validates the operator's eligibility to participate in voting. These snapshots establish each operator's baseline for the current epoch. The actual voting power will be populated in the next step based on individual delegations. This ensures that later delegation changes cannot alter voting weight once the snapshot phase is complete. ##### 6.5 Vault-Operator Delegation Snapshots With operator snapshots ready, we now record the weighted stake from each specific vault-to-operator delegation into the relevant `OperatorSnapshot` and update the total stake in the `EpochSnapshot`. Copy and paste the following code at the bottom of your test function: ```rust // Record all vault-to-operator delegations fixture .add_vault_operator_delegation_snapshots_to_test_ncn(&test_ncn) .await?; ``` This crucial step iterates through each active vault-to-operator delegation and records its contribution to the operator's voting power: - For each valid delegation found in the Jito Vault program: - Retrieves the corresponding token weight from the epoch's [`WeightTable`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#weighttable). - Calculates the weighted stake for that delegation (delegation amount \* token weight). - Updates the relevant [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot) by adding the calculated stake weight. - Stores detailed information about the weighted delegation within the [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot)'s `vault_operator_stake_weight` array. - Increments the total stake weight in the global [`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot). - Creates a [`VaultOperatorDelegationSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#vaultoperatordelegationsnapshot) account for detailed auditing. These granular snapshots serve multiple purposes: - They populate the [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot) accounts with the actual stake weights used for voting. - They update the [`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot) with the total voting power present in the system for this epoch. - They provide detailed audit trails of exactly where each operator's voting power originates. - They enable verification of correct weight calculation for each delegation. - They prevent retroactive manipulation of the voting power distribution. ##### 6.6 Ballot Box Initialization To prepare for voting, we initialize a `BallotBox` account for the current epoch, which will collect and tally all operator votes. Copy and paste the following code at the bottom of your test function: ```rust // Initialize the ballot box for collecting votes fixture.add_ballot_box_to_test_ncn(&test_ncn).await?; ``` The final preparation step creates the ballot box: - Initializes a [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox) account linked to the NCN and epoch using `do_full_initialize_ballot_box`. Similar to the weight table, this may require multiple allocation calls internally. - Creates arrays to track operator votes ([`OperatorVote`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorvote)) and ballot tallies ([`BallotTally`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballottally)). - Sets up the data structures for recording and counting votes. - Prepares the consensus tracking mechanism. - Links the ballot box to the [`EpochState`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus) for progress tracking. The [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox) becomes the central repository where all votes are recorded and tallied during the voting process. It is designed to efficiently track: - Which operators have voted and what they voted for. - The cumulative stake weight behind each voting option (ballot). - The current winning ballot (if any). - Whether consensus has been reached. ##### 6.7 Snapshot Architecture and Security Considerations The snapshot system implements several key architectural principles: 1. **Point-in-Time Consistency**: All snapshots capture the system state relative to the start of the epoch, creating a consistent view based on frozen weights and delegations present at that time. 2. **Immutability**: Once taken and populated, snapshots cannot be modified, ensuring the integrity of the voting weights used. 3. **Layered Verification**: The system enables verification at multiple levels: - Aggregate level (`EpochSnapshot`) - Participant level (`OperatorSnapshot`) - Relationship level (individual weighted delegations within `OperatorSnapshot`, optionally `VaultOperatorDelegationSnapshot`) 4. **Defense Against Time-Based Attacks**: By freezing the state (weights and relevant delegations) before voting begins, the system prevents: - Late stake additions influencing outcomes within the _current_ epoch. - Strategic withdrawals affecting voting power _after_ the snapshot. - Any form of "stake voting power front-running" within the epoch. 5. **Separation of State and Process**: - The state (snapshots, weights) is captured separately from the process (voting). - This clear separation simplifies reasoning about the system. - It enables more effective testing and verification. The comprehensive snapshot approach ensures that voting occurs on a well-defined, verifiable view of the network's state, establishing a solid foundation for the actual voting process to follow. #### 7. Voting Process The Voting Process is the core functionality of the NCN system, where operators express their preferences on the network state (represented by the "weather status" in this simulation). This process leverages the infrastructure and snapshots created in previous steps to ensure secure, verifiable, and stake-weighted consensus. ##### 7.1 Setting the Expected Outcome In our simulation, we'll predefine an expected winning outcome for verification purposes. Copy and paste the following code at the bottom of your test function: ```rust // Define the expected winning weather status let winning_weather_status = WeatherStatus::Sunny as u8; ``` For testing purposes, the system defines an expected outcome (`WeatherStatus::Sunny`). In a production environment, the winning outcome would be determined organically through actual operator votes based on real-world data or criteria. The weather status enum (`Sunny`, `Cloudy`, `Rainy`) serves as a simplified proxy for any on-chain decision that requires consensus. ##### 7.2 Casting Votes from Different Operators Operators now cast their votes. We'll simulate a few operators voting, some for the expected outcome and some against, to test the tallying logic. Copy and paste the following code at the bottom of your test function: ```rust // Cast votes from operators { let epoch = fixture.clock().await.epoch; let first_operator = &test_ncn.operators[0]; let second_operator = &test_ncn.operators[1]; let third_operator = &test_ncn.operators[2]; // First operator votes for Cloudy ncn_program_client .do_cast_vote( ncn_pubkey, first_operator.operator_pubkey, &first_operator.operator_admin, WeatherStatus::Cloudy as u8, epoch, ) .await?; // Second and third operators vote for Sunny (expected winner) ncn_program_client .do_cast_vote( ncn_pubkey, second_operator.operator_pubkey, &second_operator.operator_admin, winning_weather_status, epoch, ) .await?; ncn_program_client .do_cast_vote( ncn_pubkey, third_operator.operator_pubkey, &third_operator.operator_admin, winning_weather_status, epoch, ) .await?; } ``` This section demonstrates the system's ability to handle diverse voting preferences using the `do_cast_vote` helper, which calls the `cast_vote` instruction: - The first operator votes for "Cloudy" (representing a minority view). - The second and third operators vote for "Sunny" (the presumed majority view). - Each `do_cast_vote` call invokes the NCN program with the operator's choice and admin signature. Under the hood, each vote triggers several key operations within the `cast_vote` instruction: - **Verification**: - Verifies the operator admin's signature. - Checks that the operator hasn't already voted in this epoch using the [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox). - Retrieves the operator's [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot) to confirm eligibility and get its total stake weight. - Ensures the [`EpochState`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus) indicates voting is currently allowed. - **Recording**: - Records the vote details (operator, slot, stake weight, ballot choice) in the `operator_votes` array within the [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox). - Marks the operator as having voted. - **Tallying**: - Finds or creates a [`BallotTally`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballottally) for the chosen weather status in the `ballot_tallies` array. - Adds the operator's full stake weight (from the snapshot) to this tally. - Increments the raw vote count for this tally. - **Consensus Check**: - Compares the updated tally's stake weight against the total stake weight recorded in the [`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot). - If the tally now exceeds the consensus threshold (e.g., 66%), it marks consensus as reached in the [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox) and records the current slot. ##### 7.3 Establishing Consensus Through Majority Voting To ensure consensus is reached for our test, the remaining eligible operators will now vote for the predefined winning weather status. Copy and paste the following code at the bottom of your test function: ```rust // All remaining operators vote for Sunny to form a majority for operator_root in test_ncn.operators.iter().take(OPERATOR_COUNT).skip(3) { ncn_program_client .do_cast_vote( ncn_pubkey, operator_root.operator_pubkey, &operator_root.operator_admin, winning_weather_status, epoch, ) .await?; } ``` The consensus mechanism works as follows: - The system maintains a running [`BallotTally`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballottally) for each unique option voted on. - After each vote, it recalculates the total stake weight supporting the voted option. - It compares this stake weight to the total stake weight available in the [`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot). - If an option's stake weight reaches the consensus threshold (e.g., >= 66%), the system: - Marks that `Ballot` as the `winning_ballot` in the [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox). - Records the current `slot` in `slot_consensus_reached`. - Updates the `EpochState`. - Creates a persistent [`ConsensusResult`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#consensusresult) account (discussed in Verification). - Consensus requires a supermajority to ensure decisions have strong, verifiable support across the network's weighted stake. ##### 7.4 Vote Processing Architecture When an operator casts a vote via the `cast_vote` instruction, the system performs several critical operations: - **Authentication**: Verifies the transaction is signed by the correct `operator_admin` keypair associated with the `operator` account. - **Authorization & Preconditions**: Confirms that: - The operator exists, is registered with the NCN, and has an active [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot) for the current `epoch`. - The operator has not already voted in this epoch (checked via [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox)). - The operator has non-zero stake weight in their [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot). - The [`EpochState`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus) confirms that the snapshotting phase is complete and voting is open. - **Vote Recording**: - Locates an empty slot or confirms the operator hasn't voted in the `operator_votes` array within the [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox). - Stores the `operator` pubkey, current `slot`, the operator's total `stake_weights` (from [`OperatorSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#operatorsnapshot)), and the index corresponding to the chosen ballot within the `ballot_tallies` array. - Increments the `operators_voted` counter in the [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox). - **Ballot Processing & Tallying**: - Searches the `ballot_tallies` array for an existing entry matching the `weather_status`. - If found: Adds the operator's `stake_weights` to the `stake_weights` field of the existing [`BallotTally`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballottally) and increments the raw `tally` counter. - If not found: Initializes a new `BallotTally` entry with the `weather_status`, the operator's `stake_weights`, and a `tally` of 1. Increments `unique_ballots`. - **Consensus Calculation & Result Creation**: - Retrieves the total `stake_weights` from the `EpochSnapshot`. - Compares the winning ballot's accumulated `stake_weights` against the total. - If the threshold is met _and_ consensus hasn't already been marked: - Sets the `winning_ballot` field in the `BallotBox`. - Records the current `slot` in `slot_consensus_reached`. - Updates the `EpochState`. - Invokes an instruction (likely via CPI or separate transaction) to create the `ConsensusResult` account, storing the winning status, epoch, weights, and slot. - **Cross-Validation**: Implicitly ensures the vote aligns with the correct `ncn` and `epoch` through the PDAs used for the involved accounts (`BallotBox`, `OperatorSnapshot`, `EpochState`). This multi-layered architecture ensures votes are processed securely, tallied correctly using the snapshotted weights, and that consensus is determined accurately based on stake-weighted participation. ##### 7.5 Security Considerations in the Voting Process The voting process incorporates several key security features: - **Sybil Attack Prevention**: - Voting power is derived directly from snapshotted stake weight, not operator count. - Operators with zero snapshotted stake weight cannot vote, preventing attacks based on creating numerous fake operators. - **Replay Protection**: - The [`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox) tracks which operators have voted (`operator_votes` array). - Attempts by an operator to vote more than once within the same epoch are rejected. - **Time-Bound Voting**: - Votes are only accepted if the [`EpochState`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochaccountstatus) indicates the voting phase is active for the specified `epoch`. - While votes might be accepted slightly after consensus is reached (within `valid_slots_after_consensus`), they won't change the already determined outcome. - **Authority**: Requires `operator_admin` signature. - **Tamper-Proof Tallying**: Uses immutable snapshotted data created _before_ voting began. - **Consistent Threshold**: Calculated based on the total stake weight recorded in the [`EpochSnapshot`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#epochsnapshot), providing a fixed target for the epoch. These security measures ensure the voting process remains resilient against various attack vectors and manipulation attempts, maintaining the integrity of the consensus mechanism. #### 8. Rewards Distribution After consensus is reached, the NCN system can distribute rewards to participants based on their contributions to the consensus process. The rewards system operates through a multi-layered distribution mechanism that allocates rewards to different stakeholders: the Protocol, the NCN itself, operators, and vaults. The reward distribution process consists of three main phases: 1. **Router Initialization**: Setting up the infrastructure for reward routing 2. **NCN Reward Routing and Distributing**: Routing and distributing rewards according to the fee structure to the protocol and the NCN, and to the Operator_Vault couples 3. **Operator Vault Reward Routing and Distributing**: Routing and distributing rewards to operators and their delegated vaults ##### 8.1 Reward Router Initialization Before rewards can be distributed, the system must initialize reward routers that manage the flow of rewards to different participants. Copy and paste the following code at the bottom of your test function: ```rust // Setup reward routers for NCN and operators { let ncn = test_ncn.ncn_root.ncn_pubkey; let clock = fixture.clock().await; let epoch = clock.epoch; ncn_program_client .do_full_initialize_ncn_reward_router(ncn, epoch) .await?; for operator_root in test_ncn.operators.iter() { let operator = operator_root.operator_pubkey; ncn_program_client .do_initialize_operator_vault_reward_router(ncn, operator, epoch) .await?; } } ``` This step creates the infrastructure for reward distribution: - **NCN Reward Router**: A primary router that receives all rewards and distributes them according to the configured fee structure. It manages the overall reward pool and calculates allocations for Protocol, NCN, and operator rewards. - **Operator Vault Reward Routers**: Individual routers for each operator that manage the distribution of rewards to operators and their associated vaults. These handle the final distribution to operators and their delegated vaults. The reward routers implement a hierarchical distribution system: 1. All rewards initially flow into the NCN Reward Router 2. The NCN Reward Router distributes rewards based on fee configurations 3. Operator-specific rewards flow through Operator Vault Reward Routers 4. Finally, rewards reach the ultimate recipients (operators and vault holders) ##### 8.2 NCN Reward Routing and Distribution The first phase of reward distribution involves routing rewards into the NCN system and distributing them according to the configured fee structure. Copy and paste the following code at the bottom of your test function: ```rust // Route rewards into the NCN reward system { let ncn = test_ncn.ncn_root.ncn_pubkey; let epoch = fixture.clock().await.epoch; const REWARD_AMOUNT: u64 = 1_000_000; // Advance the clock to ensure we are in a valid time window for reward distribution. let valid_slots_after_consensus = { let config = ncn_program_client.get_ncn_config(ncn).await?; config.valid_slots_after_consensus() }; fixture .warp_slot_incremental(valid_slots_after_consensus + 1) .await?; // Send rewards to the NCN reward receiver let ncn_reward_receiver = NCNRewardReceiver::find_program_address(&ncn_program::id(), &ncn, epoch).0; fn lamports_to_sol(lamports: u64) -> f64 { lamports as f64 / 1_000_000_000.0 } let sol_rewards = lamports_to_sol(REWARD_AMOUNT); ncn_program_client .airdrop(&ncn_reward_receiver, sol_rewards) .await?; // Route rewards through the NCN reward system ncn_program_client.do_route_ncn_rewards(ncn, epoch).await?; // Should be able to route twice (idempotent operation) ncn_program_client.do_route_ncn_rewards(ncn, epoch).await?; let ncn_reward_router = ncn_program_client.get_ncn_reward_router(ncn, epoch).await?; // Distribute Protocol Rewards (4% of total) { let rewards = ncn_reward_router.protocol_rewards(); if rewards > 0 { let config = ncn_program_client.get_ncn_config(ncn).await?; let protocol_fee_wallet = config.fee_config.protocol_fee_wallet(); let balance_before = { let account = fixture.get_account(protocol_fee_wallet).await?; account.unwrap().lamports }; println!("Distributing {} of Protocol Rewards", rewards); ncn_program_client .do_distribute_protocol_rewards(ncn, epoch) .await?; let balance_after = { let account = fixture.get_account(protocol_fee_wallet).await?; account.unwrap().lamports }; assert_eq!( balance_after, balance_before + rewards, "Protocol fee wallet balance should increase by the rewards amount" ); } } // Distribute NCN Rewards (4% of total) { let rewards = ncn_reward_router.ncn_rewards(); if rewards > 0 { let config = ncn_program_client.get_ncn_config(ncn).await?; let ncn_fee_wallet = config.fee_config.ncn_fee_wallet(); let balance_before = { let account = fixture.get_account(ncn_fee_wallet).await?; account.unwrap().lamports }; println!("Distributing {} of NCN Rewards", rewards); ncn_program_client .do_distribute_ncn_rewards(ncn, epoch) .await?; let balance_after = { let account = fixture.get_account(ncn_fee_wallet).await?; account.unwrap().lamports }; assert_eq!( balance_after, balance_before + rewards, "NCN fee wallet balance should increase by the rewards amount" ); } } // Distribute Operator Vault Rewards (92% of total) { for operator_root in test_ncn.operators.iter() { let operator = operator_root.operator_pubkey; let operator_route = ncn_reward_router.operator_vault_reward_route(&operator); let rewards = operator_route.rewards().unwrap_or(0); if rewards == 0 { continue; } println!("Distribute NCN Reward {}", rewards); ncn_program_client .do_distribute_operator_vault_reward_route(operator, ncn, epoch) .await?; } } } ``` The NCN reward routing process follows these steps: 1. **Timing Validation**: The system waits for the configured `valid_slots_after_consensus` period to ensure proper timing for reward distribution. 2. **Reward Reception**: Rewards are deposited into the NCN Reward Receiver account, which serves as the entry point for all rewards. 3. **Fee Calculation**: The system automatically calculates different fee categories based on the NCN configuration: - **Protocol Fees**: 4% allocated to the Protocol for maintaining the underlying restaking infrastructure - **NCN Fees**: 4% retained by the NCN for operational costs - **Operator Vault Rewards**: 92% allocated to operators and their delegated vaults 4. **Distribution Execution**: Each category of rewards is distributed to its respective recipients: - **Protocol Rewards**: Transferred directly to the configured Protocol fee wallet - **NCN Rewards**: Transferred to the NCN's fee wallet - **Operator Vault Rewards**: Routed to individual Operator Vault Reward Routers for further distribution The distribution is weighted based on the operators' voting participation and stake weights from the consensus process, ensuring that rewards flow proportionally to participants who contributed to achieving consensus. ##### 8.3 Operator Vault Reward Routing The second phase distributes rewards that were allocated to operators and vaults, managing the final distribution to individual participants. Copy and paste the following code at the bottom of your test function: ```rust // Route rewards to operators and their delegated vaults { let ncn = test_ncn.ncn_root.ncn_pubkey; let epoch = fixture.clock().await.epoch; for operator_root in test_ncn.operators.iter() { let operator = operator_root.operator_pubkey; // Route rewards to operator and vaults ncn_program_client .do_route_operator_vault_rewards(ncn, operator, epoch) .await?; // Should be able to route twice (idempotent operation) ncn_program_client .do_route_operator_vault_rewards(ncn, operator, epoch) .await?; let operator_vault_reward_router = ncn_program_client .get_operator_vault_reward_router(operator, ncn, epoch) .await?; // Distribute operator's fee portion let operator_rewards = operator_vault_reward_router.operator_rewards(); if operator_rewards > 0 { ncn_program_client .do_distribute_operator_rewards(operator, ncn, epoch) .await?; } // Distribute rewards to vaults that delegated to this operator for vault_root in test_ncn.vaults.iter() { let vault = vault_root.vault_pubkey; let vault_reward_route = operator_vault_reward_router.vault_reward_route(&vault); if let Ok(vault_reward_route) = vault_reward_route { let vault_rewards = vault_reward_route.rewards(); if vault_rewards > 0 { ncn_program_client .do_distribute_vault_rewards(vault, operator, ncn, epoch) .await?; } } } } } ``` The operator vault reward routing process manages distribution at the most granular level: 1. **Operator Fee Calculation**: Each operator's configured fee (basis points) is calculated and retained by the operator. This fee is deducted from the total rewards allocated to that operator before vault distribution. 2. **Vault Reward Distribution**: The remaining rewards are distributed to vaults that delegated stake to the operator, proportional to their delegation amounts and token weights. 3. **Proportional Allocation**: Rewards are allocated based on: - **Delegation Weight**: Larger delegations receive proportionally more rewards - **Token Weight**: Different token types contribute different weighted values based on the weight table - **Participation**: Only delegations that contributed to the voting process receive rewards 4. **Idempotent Operations**: The routing operations are designed to be idempotent, meaning they can be called multiple times without adverse effects, ensuring reliability in distributed systems. This ensures that the economic incentives align with the security and participation goals of the NCN system. ##### 8.4 Reward Architecture and Considerations The rewards system implements several key architectural principles: 1. **Multi-Tier Distribution**: - **Infrastructure Level**: Protocol receives 4% fees for maintaining the underlying restaking infrastructure - **Network Level**: NCN receives 4% fees for operating the consensus network - **Operator Level**: Operators receive their configured fee percentage for participation and validation services - **Delegator Level**: Vault holders receive proportional rewards for providing stake 2. **Proportional Incentives**: - Rewards are distributed proportionally to stake weight contributions from the epoch snapshot - Higher token weights result in higher reward allocations - Active participation in voting is required to receive rewards - Only operators with valid stake delegations can receive rewards 3. **Configurable Fee Structure**: - Protocol and NCN fees are set at 4% each in the current implementation - Operator fees are individually configurable (e.g., 100 basis points = 1%) - The system supports flexible reward allocation policies through configuration 4. **Economic Security**: - Reward distribution aligns economic incentives with network security - Participants are rewarded for honest behavior and penalized for non-participation - The system creates sustainable incentives for long-term network health - Rewards are only distributed after consensus is reached 5. **Transparency and Auditability**: - All reward distributions are recorded on-chain with detailed routing accounts - The calculation methodology is transparent and verifiable through the reward router accounts - Historical reward data enables analysis of network economics - Balance checks ensure accurate reward distribution 6. **Reliability and Safety**: - Timing constraints ensure rewards are only distributed after consensus finalization - Idempotent operations prevent double-spending or incorrect distributions - Balance verification ensures rewards are correctly transferred to recipients This comprehensive reward system ensures that all participants in the NCN ecosystem are appropriately compensated for their contributions while maintaining the security and integrity of the consensus mechanism. #### 9. Verification The Verification phase validates that the voting process completed successfully and that the expected consensus was achieved. This critical step confirms the integrity of the entire system by examining the on-chain data structures ([`BallotBox`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#ballotbox) and [`ConsensusResult`](https://www.jito.network/docs/restaking/ncn-implementation-overview/core-structs.md#consensusresult)) and verifying they contain the expected results. ##### 9.1 Ballot Box Verification After voting concludes, we first verify the `BallotBox` to ensure it correctly reflects that consensus was reached and identifies the expected winning ballot. Copy and paste the following code at the bottom of your test function: ```rust // Verify the results recorded in the BallotBox { let epoch = fixture.clock().await.epoch; let ballot_box = ncn_program_client.get_ballot_box(ncn_pubkey, epoch).await?; assert!(ballot_box.has_winning_ballot()); assert!(ballot_box.is_consensus_reached()); assert_eq!(ballot_box.get_winning_ballot().unwrap().weather_status(), winning_weather_status); } ``` The first verification step examines the `BallotBox` account for the completed epoch: - **Winning Ballot Check**: - `has_winning_ballot()` confirms that the `winning_ballot` field within the `BallotBox` structure is marked as valid. - **Consensus Status Check**: - **Winning Ballot Check**: - `has_winning_ballot()` confirms that the `winning_ballot` field within the `BallotBox` structure is marked as valid. 2. **Consensus Status Check**: - `is_consensus_reached()` checks if the `slot_consensus_reached` field is greater than zero, indicating the consensus condition was met during the voting process. - **Outcome Verification**: - The test retrieves the `winning_ballot` struct and asserts that its `weather_status` field matches the `winning_weather_status` defined earlier (`WeatherStatus::Sunny`). This confirms the correct outcome was identified based on the stake-weighted tally. Verifying the `BallotBox` ensures the core voting and tallying mechanism functioned correctly during the active epoch. ##### 9.2 Consensus Result Account Verification Next, we verify the permanently stored `ConsensusResult` account to confirm it accurately records the winning outcome, epoch details, and vote weights, consistent with the `BallotBox`. Copy and paste the following code at the bottom of your test function: ```rust // Fetch and verify the consensus_result account { let epoch = fixture.clock().await.epoch; let consensus_result = ncn_program_client .get_consensus_result(ncn_pubkey, epoch) .await?; assert!(consensus_result.is_consensus_reached()); assert_eq!(consensus_result.epoch(), epoch); assert_eq!(consensus_result.weather_status(), winning_weather_status); let ballot_box = ncn_program_client.get_ballot_box(ncn_pubkey, epoch).await?; let winning_ballot_tally = ballot_box.get_winning_ballot_tally().unwrap(); assert_eq!(consensus_result.vote_weight(), winning_ballot_tally.stake_weights().stake_weight() as u64); println!( "✅ Consensus Result Verified - Weather Status: {}, Vote Weight: {}, Total Weight: {}, Recorder: {}", consensus_result.weather_status(), consensus_result.vote_weight(), consensus_result.total_vote_weight(), consensus_result.consensus_recorder() ); } ``` The second verification step examines the `ConsensusResult` account, which serves as the permanent, immutable record of the voting outcome: - **Consensus Result Existence & Fetching**: - The test successfully fetches the `ConsensusResult` account using its PDA derived from the NCN pubkey and epoch. Its existence implies consensus was reached and the account was created. - **Consensus Status Validation**: - **Consensus Result Existence & Fetching**: - The test successfully fetches the `ConsensusResult` account using its PDA derived from the NCN pubkey and epoch. Its existence implies consensus was reached and the account was created. 2. **Consensus Status Validation**: - `is_consensus_reached()` checks an internal flag derived from stored values (like `consensus_slot` > 0), confirming the outcome is officially recognized. - **Metadata Verification**: - Asserts that the `epoch` field matches the current epoch. - Asserts that the `weather_status` matches the expected `winning_weather_status`. - **Cross-Account Consistency Check**: - Fetches the `BallotBox` again. - Retrieves the `BallotTally` corresponding to the winning ballot from the `BallotBox`. - Asserts that the `vote_weight` stored in the `ConsensusResult` exactly matches the `stake_weight` recorded in the winning `BallotTally` within the `BallotBox`. This ensures consistency between the temporary voting record and the permanent result. - **Detailed Reporting**: - Prints key details from the verified `ConsensusResult` account for confirmation. Verifying the `ConsensusResult` confirms that the outcome was durably stored with the correct details and consistent with the voting process itself. ##### 9.3 Architecture of Verification and Result Persistence The verification phase highlights several important architectural features: 1. **Dual Records**: - The system temporarily uses the `BallotBox` during the epoch for active voting and tallying. - Upon reaching consensus, it creates a separate, permanent `ConsensusResult` account. - This redundancy allows for cleanup while preserving the essential outcome. 2. **Separation of Process and Outcome**: - The `BallotBox` (process) can eventually be closed to reclaim rent. - The `ConsensusResult` (outcome) persists indefinitely as the historical record. 3. **Automated Result Creation**: - The `ConsensusResult` account is typically created automatically within the `cast_vote` instruction when the consensus threshold is first met. This ensures timely recording without requiring a separate administrative action. 4. **Result Immutability**: - The `ConsensusResult` account, once created, is designed to be immutable. It stores the outcome based on the state when consensus was reached. 5. **Time and Slot Tracking**: - Both `BallotBox` and `ConsensusResult` store key timing information (`slot_consensus_reached`, `epoch`). This metadata is crucial for auditing and understanding the system's behavior over time. ##### 9.4 Verification Techniques and Best Practices The verification approach demonstrates several best practices: 1. **Multi-Level Verification**: Testing both the ephemeral process account (`BallotBox`) and the persistent outcome account (`ConsensusResult`) provides comprehensive validation. 2. **State Assertions**: Using dedicated helper functions on the deserialized accounts (`has_winning_ballot()`, `is_consensus_reached()`) makes tests more readable and robust against internal representation changes. 3. **Equality Assertions**: Using strict equality (`assert_eq!`) for key outcome data (winning status, epoch, weights) ensures exactness. 4. **Cross-Structure Validation**: Comparing critical values (like `vote_weight`) between the `BallotBox` and `ConsensusResult` confirms data consistency across different parts of the system. 5. **Complete Outcome Validation**: Checking not just the winning choice but also associated metadata (epoch, weights, consensus flags) catches more subtle errors. 6. **Clear Reporting**: Outputting verified data (`println!`) provides immediate feedback during test runs. This rigorous verification ensures the NCN system reliably achieves and records stake-weighted consensus according to its design. #### 10. Cleanup After the core functionality has been tested and verified for a given epoch, the temporary accounts associated with that epoch can be closed to reclaim the SOL locked for rent. The persistent `ConsensusResult` account remains. Copy and paste the following code at the bottom of your test function: ```rust // Close epoch accounts but keep consensus result let epoch_before_closing_account = fixture.clock().await.epoch; fixture.close_epoch_accounts_for_test_ncn(&test_ncn).await?; // Verify that consensus_result account is not closed { let consensus_result = ncn_program_client .get_consensus_result(ncn_pubkey, epoch_before_closing_account) .await?; assert!(consensus_result.is_consensus_reached()); assert_eq!(consensus_result.epoch(), epoch_before_closing_account); } ``` This cleanup process involves: - **Identifying Epoch**: Recording the current epoch (`epoch_before_closing_account`) just before initiating closure. - **Closing Accounts**: Calling `fixture.close_epoch_accounts_for_test_ncn`, which likely iterates through epoch-specific accounts and invokes a `close_epoch_account` instruction for each. - **Verifying Persistence**: After the cleanup function returns, the test attempts to fetch the `ConsensusResult` account for the _same_ `epoch_before_closing_account`. - **Confirming Data**: It asserts that the fetched `ConsensusResult` still exists and retains its key data (`is_consensus_reached`, `epoch`), confirming it was _not_ closed during the cleanup process. This demonstrates a crucial design feature: - **Resource Management**: Temporary accounts are removed, preventing indefinite accumulation of rent-paying accounts. - **Outcome Preservation**: The final, critical outcome (`ConsensusResult`) is preserved as a permanent on-chain record, suitable for historical lookups or use by other programs. This efficient cleanup mechanism allows the NCN system to operate continuously over many epochs without unbounded growth in account storage requirements. Now you can save the file and run the test to see the result. --- # NCN Keeper > Hands-on guide to NCN keeper setup, configuration, and automation ## NCN Keeper Each NCN relies on off-chain agents called keepers. Keepers are essentially permissionless automation agents that execute all necessary on-chain instructions to advance (“crank”) the NCN through its epoch phases. Anyone can run a keeper. There are no special authorities required to keep the NCN operational. By monitoring network state and calling the NCN program’s instructions at certain times, keepers make sure the NCN progresses correctly and remains in sync with Solana’s epoch. This guide provides an overview of how to use the `ncn-program-cli`, a command-line interface for interacting with an NCN program using the [NCN template](https://github.com/jito-foundation/ncn-template). Below, we cover installation, configuration, and step-by-step usage of the CLI, from initial setup through running the NCN keeper to automate state management. ### Installation and Setup Before using the Template NCN Program CLI, ensure you have it installed and configured properly, along with the related Jito (Re)Staking tools: 1. Build and install the NCN Program CLI: If you have the [NCN program template repo](https://github.com/jito-foundation/ncn-template), compile and install the CLI binary. For example, using Cargo: ```bash # Clone the template repo git clone git@github.com:jito-foundation/ncn-template.git cd ncn-template # Build the CLI from the repository (assuming you're in the repo directory) cargo build --release # Install the CLI binary cargo install --path ./cli --bin ncn-program-cli --locked ``` After installation, verify it works by running: ```bash ncn-program-cli --help ``` This should display the general help and list available subcommands. 2. Install Jito (Re)Staking CLI (if not already): The NCN program operates alongside Jito’s restaking program. You may need the Jito (Re)Staking CLI (`jito-restaking-cli`) to manage restaking registry tasks (like registering NCNs, operators, and vaults). Install it using Cargo: ```bash cargo install jito-restaking-cli ``` Confirm it is installed: ```bash jito-restaking-cli --help ``` 3. Configure Environment Variables: The `ncn-program-cli` accepts configuration through command-line options or environment variables. Optionally, to avoid passing flags every time, you can use a `.env` file for convenience: ```bash # NCN Operator & Program CLI Environment Configuration # Copy this file to `.env` and update the values below # --------------- REQUIRED -------------------- # Solana cluster (mainnet, devnet, testnet, or localnet) CLUSTER=devnet # RPC endpoint for your Solana cluster (must support getBlock and transaction history) RPC_URL=https://api.devnet.solana.com # Commitment level for RPC operations (e.g. confirmed or finalized) COMMITMENT=confirmed # On-chain NCN instance address (created by the NCN admin) NCN= # Path to your Solana keypair file (must have admin/operator authority) KEYPAIR_PATH=~/.config/solana/id.json # Operator public key (the account responsible for voting) OPERATOR=BSia35bXHZx69XzCQeMUnWqZJsUwJURVvuUg8Jup2BcP # OpenWeather API key (used by the example weather oracle operator) OPENWEATHER_API_KEY=your_api_key_here # --------------- PROGRAM IDS -------------------- # Use these only if you are deploying custom programs # Otherwise, leave them blank to use defaults # NCN Program ID (default: 7rNw1g2ZUCdTrCyVGZwCJLnbp3ssTRK5mdkH8gm9AKE8) NCN_PROGRAM_ID= # Jito Restaking program (default value) RESTAKING_PROGRAM_ID=RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q # Jito Vault program (default value) VAULT_PROGRAM_ID=Vau1t6sLNxnzB7ZDsef8TLbPLfyZMYXH8WTNqUdm9g8 # --------------- LOGGING -------------------- # Set the Rust log level (e.g., info, debug) RUST_LOG=info ``` These variables will be picked up by the CLI, or you can supply equivalent `--rpc-url`, `--ncn-program-id`, `--ncn`, `--keypair-path`, etc., flags to each command. #### Initializing a New NCN Program Before running the keeper, some setup and initialization steps are required to configure the NCN program and connect it. Below is a typical workflow for initializing a new NCN: 1. Fund the Account Payer: The NCN program will create and maintain several temporary accounts (for snapshots, vote tracking, etc.). The program uses a payer account to pay rent for these accounts. You should fund this payer with some SOL to cover rent and fees. The CLI provides a command to transfer SOL from your keypair to the payer account: ```bash ncn-program-cli admin-fund-account-payer --amount-in-sol 10 ``` This example funds the account payer with 10 SOL. 2. Create the NCN Config: Initialize the NCN program’s global configuration on-chain. This must be done by the NCN’s `ncn_admin`: ```bash ncn-program-cli admin-create-config --tie-breaker-admin ``` This creates the NCN’s config account and sets an admin to resolve tied votes or set consensus manually, if needed. You can also override default consensus parameters with options like `--epochs-before-stall`, `--valid-slots-after-consensus`, etc., but in most cases defaults are fine. Run with `--help` to see all available options. 3. Create the Vault Registry: The Vault Registry is an on-chain account in the NCN program that will list all vaults (stake pools or restaked assets) participating in this particular NCN. Initialize it with: ```bash ncn-program-cli create-vault-registry ``` This sets up an empty VaultRegistry account. 4. Register Supported Tokens: Each vault that will contribute stake must be registered under a supported stake token with a weight. The VaultRegistry tracks supported mints and vaults, allowing the snapshot phase to identify which operators hold stake and calculate their voting power: --- ```bash ncn-program-cli admin-register-st-mint --vault --weight --keypair-path ``` For example, if you want to include a vault with mint `ABC...` at weight 100, you’d put that address and weight. This call authorizes that vault for the NCN. Please note that the vault must have already been approved on the restaking program side via a handshake with this NCN. ### Running the Keeper The `keeper` command automates key tasks for each epoch, including creating epoch state accounts, performing stake snapshots, and handling the voting process. It runs continuously while monitoring the blockchain and executing actions based on the current epoch phase. To start the keeper, run: ```bash ncn-program-cli keeper ``` By default, the keeper checks for actions every 10 minutes, retries on errors after 10 seconds, targets the `testnet` cluster and reports metrics using the `solana_metrics` crate with the `local` region label. Let’s break down the keeper’s workflow step by step. #### 1. Vault Registration After registering the stake mints, you need to create entries in the Vault Registry for any vaults that have opted into the NCN. This is a permissionless crank operation: `ncn-program-cli crank-register-vaults`. `crank_register_vaults` is a function that registers any unregistered vaults that have been approved by the NCN but not added to the registry yet. It will: - Fetch all approved accounts - Retrieve the current vault registry - Identify the missing vaults by comparing approved vaults against already registered ones - Register each missing vault individually Once all eligible vaults are registered, the keeper continues its loop by checking and updating the current epoch state. #### 2. Fetch Epoch State Next, the keeper then reads the current epoch from the Solana cluster using `state.fetch(handler, current_keeper_epoch).await` and fetches the corresponding `EpochState` account from the NCN program. If the account already exists, it loads it into local memory. If the epoch has already been marked as complete, the keeper exits the loop early and waits for the next epoch. #### 3. Update Epoch state - Syncing local state with on-chain epoch data The `update_epoch_state` method ensures the keeper’s in-memory state reflects the latest on-chain data for the current epoch. It performs the following actions: - Checks if the epoch is already completed using `get_is_epoch_completed`. If so, it flags the local state and exits early - Fetches the `EpochState` account - Validates the account data to make sure it is present and of the correct size. - Deserializes the account data into an `EpochState` struct. - Updates the keeper's memory with the deserialized state. - Determines the current phase of the epoch by calling `update_current_state`. This function acts as the gatekeeper. If the epoch is already finished, the keeper skips further processing for that loop iteration. #### 4. Core State Machine Operations At this point in the loop, the keeper enters its core state machine execution phase, where it actively drives the NCN epoch forward based on its current on-chain state. The NCN program defines a set of epoch phases. Each phase requires actions to be executed before the epoch can progress. The keeper reads the current `EpochState`, determines the phase and runs the appropriate handler. The epoch lifecycle states are: 1. `SetWeight` → Establishes voting weight structure for the epoch 2. `Snapshot` → Captures stake distribution across operators 3. `Vote` → This is skipped by the NCN keeper 4. `PostVoteCooldown` → Manages post-consensus waiting period 5. `Distribute` → Distributes rewards to participants based on their contributions 6. `Close` → Cleans up completed epoch accounts Each state represents a distinct phase in the epoch lifecycle and the keeper automatically transitions between states as on-chain conditions are met. These operations are permissionless meaning any keeper can execute them when the appropriate conditions are satisfied. It is important to note that this is an example of an NCN’s lifecycle. NCNs may have different states to crank through. Let's examine each state handler, starting with the weight setup phase: #### `SetWeight` The SetWeight state is the first operational phase of each epoch, responsible for establishing the voting power structure that will be used during consensus. This phase uses the function `crank_set_weight` to set up the foundation for stake-weighted voting by creating and populating the weight table. This function performs two steps: 1. **`create_weight_table`** – Initializes and sizes the `WeightTable` account - Depends on the total number of vaults in the registry - Prepares a data structure to store weights efficiently on-chain 2. **`set_epoch_weights`** – Calculates and stores each vault’s voting weight - Fetches the registered stake mints and their weights - Calculates each vault’s total effective stake based on these weights - Writes the results into the `WeightTable` account Once voting weights are set, the epoch transitions to the Snapshot state, where the current stake distribution across all registered operators is captured. #### `Snapshot` The Snapshot phase records the current stake distribution across all vault-operator pairs for the epoch. This step guarantees a fixed, on-chain snapshot of delegated stake that will be used in the upcoming consensus vote. The `crank_snapshot` function performs several steps: 1. **Retrieve vaults and operators** - Fetches all valid vaults from the `VaultRegistry` - Fetches all registered operators in the NCN 2. **Skips if already finalized** - If the `EpochSnapshot` has already been finalized, the function exits early and moves on the next state 3. **Loop through each operator** - Makes sure an `OperatorSnapshot` exists for the current epoch - Filters vaults that have not yet been recorded in this snapshot 4. **Process vaults** - Calls `full_vault_update()` to update the vault’s state and stake balances - Calls `snapshot_vault_operator_delegation()` to record how much stake the vault has delegated to this operator This snapshot process creates a record of how much stake is delegated from each vault to each operator. It ensures that consensus voting in the next phase is based on accurate stake amounts. #### `Vote` This is skipped by the NCN while waiting for the operator to vote. #### `PostVoteCooldown` The PostVoteCooldown state serves as a buffer between finalizing consensus and performing cleanup. It gives the network time to settle and provides visibility into the outcome of the voting phase. The `crank_post_vote_cooldown` function performs two simple but important steps: 1. **Fetch Result**: Loads the finalized `ConsensusResult` account for the epoch from the chain. 2. **Log Outcome**: Prints the result to the logs for debugging and audit purposes. This phase does **not** submit any transactions or mutate state. It simply confirms that consensus has been reached and prepares the system for the final cleanup phase. Once completed, the epoch transitions to the **Close** state, where all temporary accounts are cleaned up. #### `Distribute` The Distribute state allocates rewards to operators and vaults based on their contributions during the epoch. The `crank_distribute` function performs the following steps: 1. **Distribute NCN Rewards:** Calls `distribute_ncn_rewards` to allocate base rewards tied to consensus participation. 2. **Distribute Protocol Rewards:** Invokes `distribute_jito_rewards` to distribute incentives. 3. **Route NCN Receiver Rewards:** If rewards exist for the reward receiver at the NCN-level, routes them using `route_ncn_rewards`. 4. **Operator Vault Reward Routing:** For each operator, it will set up their reward routing and distributes rewards to associated vaults. 5. **Distribute Operator Rewards:** If an operator has accumulated rewards, it distributes them via `distribute_ncn_operator_rewards`. 6. **Distribute Vault Rewards:** Loops through each vault under the operator and distributes rewards via `distribute_ncn_vault_rewards`. All reward distribution and routing steps are logged. Errors are non-blocking and distribution will be retried in future keeper loops if any step fails. Once completed, the epoch moves to the `Close` state, where the temporary accounts are cleaned up. #### `Close` The **Close** state marks the end of an NCN’s epoch lifecycle. During this phase, the keeper performs a full cleanup by closing all temporary accounts created during the epoch. This will reclaim rent, free up state, and prepare the NCN for the next epoch. The `crank_close_epoch_accounts` function performs the following operations: 1. **Close Ballot Box** – Closes the `BallotBox` account that tracked consensus voting 2. **Close Operator Snapshots** – Iterates through each operator and closes their `OperatorSnapshot` account 3. **Close Epoch Snapshot** – Closes the global `EpochSnapshot` that captured the operator-vault stake mapping 4. **Close Weight Table** – Closes the `WeightTable` account that stored epoch voting weights 5. **Close Epoch State** – Closes the `EpochState` account that tracked progress through the state machine Each closure is attempted independently and any errors are logged. Failures do not block anything. ****The keeper will simply attempt to retry them in subsequent loops. #### 5. Timeout and Heartbeat At the end of each loop, the keeper: - Checks whether the epoch has stalled - If a stall is detected and no actions remain, it waits for the `loop_timeout_ms` duration - Emits a heartbeat metric with the current tick count - Starts the next iteration This ensures the keeper remains responsive during stalled epochs while continuously reporting liveness for monitoring and reward tracking. --- # Operator > Complete guide to running NCN operators and automated consensus voting ## Operator With NCNs, operators are responsible for driving consensus. While each operator can have its own unique logic, it's up to the NCN designer to define that behavior. Operators perform all computation off-chain and submit votes on-chain during specific windows, using stake delegated by vaults. To simplify their responsibilities, the operator process automates the on-chain tasks for registered operators, primarily casting votes, handling post-vote logic, and reporting metrics. It runs continuously and monitors the state of the network and acts when it's the operator’s turn to participate. In this guide, we'll be looking at a template operator that fetches weather data and votes on the result. This process is typically run by the same entity that registered the operator, such as a validator, DAO or data provider participating in the NCN. This guide explains how to configure and run the operator using the `ncn-operator-cli` from the [NCN template](https://github.com/jito-foundation/ncn-template). It breaks down the operator loop, details how votes are cast using real-world weather data and walks through the behavior during different epoch states like `Vote`, `PostVoteCooldown`, and `Close`. ### Installation and Setup Before using the Template Operator CLI, install the necessary binaries: 1. Clone the repo ```bash # Clone the template repo git clone git@github.com:jito-foundation/ncn-template.git cd ncn-template # Build the CLI from the repository (assuming you're in the repo directory) cargo build --release # Install the CLI binary cargo install --path ./cli --bin ncn-operator-cli --locked ``` After installation, verify it works by running: ```bash ncn-operator-cli --help ``` 2. Install Jito (Re)Staking CLI (if not already): The NCN program operates alongside Jito’s restaking program. You may need the Jito (Re)Staking CLI (`jito-restaking-cli`) to manage restaking registry tasks (like registering NCNs, operators, and vaults). Install it using Cargo: ```bash cargo install jito-restaking-cli ``` Confirm it works: ```bash jito-restaking-cli --help ``` 1. Configure Environment Variables: The `ncn-program-cli` accepts configuration through command-line flags or environment variables. Optionally, to avoid passing flags every time, you can use a `.env` file for convenience: ```bash # Operator Environment Configuration # Copy this file to `.env` and update the values below # --------------- REQUIRED -------------------- # Solana cluster (mainnet, devnet, testnet, or localnet) CLUSTER=devnet # Solana RPC endpoint (must support getBlock and transaction history) RPC_URL=https://api.devnet.solana.com # Commitment level for operations (e.g. confirmed or finalized) COMMITMENT=confirmed # Your deployed NCN instance address NCN= # Path to your keypair file (admin/operator authority) KEYPAIR_PATH=~/.config/solana/id.json # Operator public key (the account that votes on-chain) OPERATOR=BSia35bXHZx69XzCQeMUnWqZJsUwJURVvuUg8Jup2BcP # OpenWeather API key for the example oracle operator OPENWEATHER_API_KEY=your_api_key_here # --------------- PROGRAM IDS -------------------- # Leave blank to use defaults unless you have custom deployments NCN_PROGRAM_ID== RESTAKING_PROGRAM_ID=RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q VAULT_PROGRAM_ID=Vau1t6sLNxnzB7ZDsef8TLbPLfyZMYXH8WTNqUdm9g8 # --------------- LOGGING -------------------- # Set log level (info, debug, etc.) RUST_LOG=info ``` These variables will be picked up by the CLI, or you can supply equivalent `--rpc-url`, `--ncn-program-id`, `--ncn`, etc., flags to each command. ### Running the Operator The `run-operator` command automates vote casting and post-vote actions for a registered operator. It runs continuously, monitoring the NCN’s epoch state and executing vote-related instructions when appropriate. It also emits metrics for visibility and debugging. To start the operator, run: ```bash ncn-program-cli run-operator ``` By default, the operator loop checks for actions every 10 minutes, retries on errors after 10 seconds, targets the `testnet` cluster and reports metrics with the `local` region label. Let’s break down the operator’s workflow step by step. #### 1. Epoch Progression Before doing any work, the operator checks whether a new epoch has started by querying the cluster by calling `progress_epoch` if the epoch state is completed. This checks that the operator is aligned with the live on-chain epoch and doesn’t act on stale data. The loop progresses through: - Advancing to a new epoch if the chain has moved forward - Looping back to the start of the same epoch if it's marked complete - Staying on the same epoch if work is still pending --- #### 2. Fetch or Update Operator State The operator maintains an internal `KeeperState` that tracks the current epoch, cached on-chain accounts and the latest `EpochState`. This block loads the latest on-chain data to keep the operator aligned with the current epoch. There are two possible paths here: - **New Epoch Detected**: If the loop has progressed to a new epoch, it calls `state.fetch(...)` which does the following: - Sets the operator’s internal epoch value to the current one - Loads all relevant on-chain accounts - Calls `update_epoch_state(...)` internally to populate the latest `EpochState` - **Same Epoch**: If the epoch hasn’t changed, it will skip the full fetch and just refresh the `EpochState` using `update_epoch_state(...)` This avoids unnecessary on-chain requests and helps keep everything responsive. If either call fails, the operator logs the error and skips the current loop without submitting any vote or metrics. --- #### 3. Check for Valid EpochState After updating its state, the operator then checks if a valid `EpochState` exists. If the `EpochState` is missing or not yet initialized on-chain, the operator will: - Log that the epoch has no associated state - Mark the epoch as completed locally - Skip to the next loop cycle This prevents the operator from crashing or spinning unnecessarily while waiting for the epoch to be initialized. --- #### 4. Core State Machine Operations Once the `EpochState` is loaded, the operator identifies the current phase and reacts based on its role as an operator. Only a subset of phases require action. It will evaluate internal conditions to determine eligibility. If the operator is permitted to vote in the current phase, it proceeds with the voting logic. The epoch lifecycle states are: --- 1. `SetWeight` → Establishes voting weight structure for the epoch. No operator action is needed for this step. 2. `Snapshot` → Captures stake distribution across operators. No operator action is needed for this step. 3. `Vote` → Casts vote 4. `PostVoteCooldown` → Triggers post-vote logic and emits operator metrics. Marks the epoch as completed. 5. `Close` → Cleans up completed epoch accounts #### `SetWeight` This step is skipped by the operator as no action is needed. #### `Snapshot` Again, this step is skipped by the operator. #### `Vote` The `Vote` phase is where the operator performs its most important role: submitting a vote that contributes to the NCN’s consensus process. This phase is only active if the operator has received delegation from at least one vault and has not yet cast a vote for the current epoch. During this phase, the operator: 1. **Loads Required Data** It fetches both the `BallotBox` and the `OperatorSnapshot` (which contains data about the operator’s delegation and voting history). These accounts determine whether the operator is eligible to vote and if they’ve already participated in this round. 2. **Checks Eligibility** Using `can_operator_vote(...)`, it will verify that the operator: - Has been delegated stake for this epoch - Has not already voted - Is listed in the ballot box with an appropriate weight 3. **Casts the Vote** If eligible, the operator calls `operator_crank_vote(...)` to submit the vote on-chain. The actual vote content will be determined by the NCN’s logic. In the default template, it maps mock weather data to a vote value. In real NCNs, this would be replaced with your logic and inputs (e.g. price feeds, validator scores, etc.). 4. **Handles Errors** If voting fails, the operator logs the error, delays for the `--error-timeout-ms` and retries the loop. This prevents spammy retries and gives the network time to recover from short lived failures. 5. **Emits Metrics** Once successful, the operator emits the operator vote metrics using `emit_ncn_metrics_operator_vote(...)`. This helps monitor and track vote activity and operator performance in real time. 6. **Post-Vote Flow** If the operator has already voted or is ineligible: - The operator instead performs a `post_vote` action which typically submits metadata or confirms the final state - It emits corresponding post-vote metrics - Finally, it marks the epoch as complete for this operator and allows the operator to skip this epoch in future iterations --- #### `PostVoteCooldown` This phase is used to report the result of the voting process. The operator: - Loads the `BallotBox` - Checks whether consensus was reached - Logs the outcome of the vote (including weights, operator decisions and winning ballot) - Emits post-vote metrics While no vote is cast, the operator may still submit an on-chain transaction (e.g. metrics or metadata), depending on the implementation. #### `Close` This phase is similar to `PostVoteCooldown`, but is used at the very end of the epoch. The operator once again: - Loads the ballot box and logs the final consensus result - Emits final metrics - Marks the epoch as completed so the operator loop can progress to the next one #### 5. Timeout and Heartbeat At the end of each loop, the operator: - Waits for `-loop-timeout-ms` duration - Emits a heartbeat metric with the current tick count - Starts the loop again This helps avoid overloading the RPC and keeps the operator reporting liveness for monitoring dashboards, alerting systems, and reward eligibility checks. --- # Core Struct Definitions > Complete reference for all data structures used by the NCN program ## Core struct definitions Here are the definitions for the core data structures used by the NCN program, typically found in the `/core/src` directory. Understanding these structures is key to understanding the program's logic. ### Config file: `config.rs` - **Purpose**: Stores global, long-lived configuration parameters for the NCN program instance. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct Config { /// The Pubkey of the associated Jito Restaking NCN account this config belongs to. pub ncn: Pubkey, /// The admin authorized to update the tie breaker mechanism or parameters. pub tie_breaker_admin: Pubkey, /// Number of slots after consensus is reached where votes are still accepted /// (though they won't change the outcome). pub valid_slots_after_consensus: PodU64, /// Number of epochs without reaching consensus before the cycle is considered stalled. pub epochs_before_stall: PodU64, /// Number of epochs to wait after consensus is reached before epoch accounts can be closed. pub epochs_after_consensus_before_close: PodU64, /// The first epoch number for which voting is considered valid. pub starting_valid_epoch: PodU64, /// Bump seed for the PDA pub bump: u8, } ``` - **Explanation**: Holds the associated `ncn`, the `tie_breaker_admin`, and various timing/threshold parameters (`valid_slots_after_consensus`, `epochs_before_stall`, `epochs_after_consensus_before_close`, `starting_valid_epoch`). ### Ballot file: `ballot_box.rs` - **Purpose**: Represents a single potential outcome in the consensus process, specifically a weather status in this example. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod)] #[repr(C)] pub struct Ballot { /// The weather status value weather_status: u8, /// Whether the ballot is valid is_valid: PodBool, } ``` - **Explanation**: Holds the numeric `weather_status` being voted on and a boolean `is_valid` flag to ensure it corresponds to a known status. ### BallotTally file: `ballot_box.rs` - **Purpose**: Aggregates votes and stake weight for a specific `Ballot`. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod)] #[repr(C)] pub struct BallotTally { /// Index of the tally within the ballot_tallies index: PodU16, /// The ballot being tallied ballot: Ballot, /// Breakdown of all of the stake weights that contribute to the vote stake_weights: StakeWeights, /// The number of votes for this ballot tally: PodU64, } ``` - **Explanation**: Tracks which `ballot` this tally is for, its `index` in the main array, the total `stake_weights` supporting it, and the raw `tally` (count) of votes. ### OperatorVote file: `ballot_box.rs` - **Purpose**: Records the vote cast by a single operator within a specific epoch's `BallotBox`. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod)] #[repr(C)] pub struct OperatorVote { /// The operator that cast the vote operator: Pubkey, /// The slot when the operator voted slot_voted: PodU64, /// The stake weights of the operator stake_weights: StakeWeights, /// The index of the ballot in the ballot_tallies array ballot_index: PodU16, } ``` - **Explanation**: Stores the `operator` pubkey, the current `slot`, their `stake_weights`, and the `ballot_index` they voted for. ### BallotBox file: `ballot_box.rs` - **Purpose**: The central account for managing the voting process within a specific epoch. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct BallotBox { /// The Pubkey of the NCN this ballot box is for ncn: Pubkey, /// The epoch this ballot box is for epoch: PodU64, /// Bump seed for the PDA bump: u8, /// Slot when this ballot box was created slot_created: PodU64, /// Slot when consensus was reached slot_consensus_reached: PodU64, /// Number of operators that have voted operators_voted: PodU64, /// Number of unique ballots unique_ballots: PodU64, /// The ballot that got at least 66% of votes winning_ballot: Ballot, /// Operator votes operator_votes: [OperatorVote; MAX_OPERATORS], /// Mapping of ballots votes to stake weight ballot_tallies: [BallotTally; MAX_OPERATORS], } ``` - **Explanation**: Holds metadata (`ncn`, `epoch`, timestamps), vote counts, and arrays for individual operator votes and aggregated tallies. ### ConsensusResult file: `consensus_result.rs` - **Purpose**: A persistent account storing the final, immutable outcome of a consensus cycle for a specific epoch. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct ConsensusResult { /// The Pubkey of the NCN this consensus result is for ncn: Pubkey, /// The epoch this consensus result is for epoch: PodU64, /// The vote weight that supported the winning status vote_weight: PodU64, /// The total vote weight in the ballot box total_vote_weight: PodU64, /// The slot at which consensus was reached consensus_slot: PodU64, /// Bump seed for the PDA bump: u8, /// The winning weather status that reached consensus weather_status: u8, } ``` - **Explanation**: Stores the `ncn`, `epoch`, the winning `weather_status`, and the `consensus_slot`. ### AccountPayer file: `account_payer.rs` - **Purpose**: An empty, uninitialized system account used solely as a Program Derived Address (PDA) to hold SOL temporarily for paying rent during account creation or reallocation within the NCN program. - **Definition**: ```rust pub struct AccountPayer {} ``` - **Explanation**: This is a marker struct with no fields. Its associated functions handle deriving the PDA and performing SOL transfers for rent payments using `invoke_signed`. ### EpochMarker file: `epoch_marker.rs` - **Purpose**: An empty account created as a marker to signify that all temporary accounts associated with a specific NCN epoch have been successfully closed. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct EpochMarker { ncn: Pubkey, epoch: PodU64, slot_closed: PodU64, } ``` - **Explanation**: Contains the `ncn`, the `epoch` that was closed, and the `slot_closed`. Its existence confirms cleanup completion for that epoch. ### EpochSnapshot file: `epoch_snapshot.rs` - **Purpose**: Captures the aggregated state of the NCN system at the beginning of a specific epoch snapshot phase. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct EpochSnapshot { /// The Pubkey of the NCN this snapshot is for ncn: Pubkey, /// The epoch this snapshot is for epoch: PodU64, /// Bump seed for the PDA bump: u8, /// Slot when this EpochSnapshot account was created slot_created: PodU64, /// Slot when the snapshotting process (including all operator delegations) was completed slot_finalized: PodU64, /// Number of operators in the epoch operator_count: PodU64, /// Number of vaults in the epoch vault_count: PodU64, /// Keeps track of the number of completed operator registration through `snapshot_vault_operator_delegation` and `initialize_operator_snapshot` operators_registered: PodU64, /// Keeps track of the number of valid operator vault delegations valid_operator_vault_delegations: PodU64, /// Tallies the total stake weights for all vault operator delegations stake_weights: StakeWeights, } ``` - **Explanation**: Stores metadata (`ncn`, `epoch`, timestamps), counts (`operator_count`, `vault_count`), progress trackers, and the total aggregated `stake_weights` for the epoch. ### OperatorSnapshot file: `epoch_snapshot.rs` - **Purpose**: Captures the state of a single operator for a specific epoch, including their total delegated stake weight and a breakdown of contributions from each vault. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct OperatorSnapshot { operator: Pubkey, ncn: Pubkey, ncn_epoch: PodU64, bump: u8, slot_created: PodU64, slot_finalized: PodU64, is_active: PodBool, ncn_operator_index: PodU64, operator_index: PodU64, operator_fee_bps: PodU16, vault_operator_delegation_count: PodU64, vault_operator_delegations_registered: PodU64, valid_operator_vault_delegations: PodU64, stake_weights: StakeWeights, vault_operator_stake_weight: [VaultOperatorStakeWeight; MAX_VAULTS], } ``` - **Explanation**: Contains operator/NCN identifiers, timestamps, status, indices, `operator_fee_bps`, delegation counts/progress, the operator's total `stake_weights`, and a detailed breakdown in `vault_operator_stake_weight`. ### VaultOperatorStakeWeight file: `epoch_snapshot.rs` - **Purpose**: A helper struct within `OperatorSnapshot` to store the calculated stake weight originating from one specific vault's delegation to that operator. - **Definition**: ```rust #[derive(Debug, Clone, Copy, PartialEq, Eq, Zeroable, Pod)] pub struct VaultOperatorStakeWeight { vault: Pubkey, vault_index: PodU64, stake_weight: StakeWeights, } ``` - **Explanation**: Links a `vault` pubkey and `vault_index` to the specific `stake_weight` derived from its delegation to the parent `OperatorSnapshot`. ### StMintEntry file: `vault_registry.rs` - **Purpose**: Represents a supported token mint within the `VaultRegistry`, storing its address and associated voting weight. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod)] #[repr(C)] pub struct StMintEntry { /// The supported token ( ST ) mint st_mint: Pubkey, // Either a switchboard feed or a weight must be set /// The switchboard feed for the mint reserve_switchboard_feed: [u8; 32], /// The weight weight: PodU128, } ``` - **Explanation**: Stores the `st_mint` address and its assigned voting `weight`. `reserve_switchboard_feed` is unused here. ### VaultEntry file: `vault_registry.rs` - **Purpose**: Represents a registered vault within the `VaultRegistry`. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod)] #[repr(C)] pub struct VaultEntry { /// The vault account vault: Pubkey, /// The supported token ( ST ) mint of the vault st_mint: Pubkey, /// The index of the vault in respect to the NCN account vault_index: PodU64, /// The slot the vault was registered slot_registered: PodU64, } ``` - **Explanation**: Stores the `vault` address, the `st_mint` it holds, its assigned `vault_index`, and the `slot_registered`. ### VaultRegistry file: `vault_registry.rs` - **Purpose**: A global account for the NCN program instance that maintains the list of all supported token mints (`StMintEntry`) and all registered vaults (`VaultEntry`). - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct VaultRegistry { /// The Pubkey of the associated NCN account this registry belongs to. pub ncn: Pubkey, /// Bump seed for the PDA pub bump: u8, /// Array storing entries for each supported token mint pub st_mint_list: [StMintEntry; MAX_ST_MINTS], /// Array storing entries for each vault pub vault_list: [VaultEntry; MAX_VAULTS], } ``` - **Explanation**: Holds the `ncn` identifier, `bump`, and arrays for `st_mint_list` and `vault_list`. ### WeightTable file: `weight_table.rs` - **Purpose**: An epoch-specific account that snapshots the weights of all supported tokens at the beginning of the epoch. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct WeightTable { /// The Pubkey of the associated NCN account this account is for. ncn: Pubkey, /// The epoch this account is for. epoch: PodU64, /// Slot when this WeightTable account was created. slot_created: PodU64, /// Number of vaults in tracked mints at the time of creation vault_count: PodU64, /// Bump seed for the PDA bump: u8, /// A snapshot copy of the relevant vault entries from the VaultRegistry vault_registry: [VaultEntry; MAX_VAULTS], /// The weight table table: [WeightEntry; MAX_ST_MINTS], } ``` - **Explanation**: Contains metadata (`ncn`, `epoch`, `slot_created`, `vault_count`), a snapshot of the `vault_registry`, and the main `table` holding `WeightEntry` structs with the frozen weights for the epoch. ### EpochAccountStatus file: `epoch_state.rs` - **Purpose**: A helper struct within `EpochState` used to track the lifecycle status of various temporary accounts associated with a specific epoch. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, ShankType, Pod)] #[repr(C)] pub struct EpochAccountStatus { /// Status of the main EpochState account itself. epoch_state: u8, /// Status of the WeightTable account for this epoch. weight_table: u8, /// Status of the main EpochSnapshot account for this epoch. epoch_snapshot: u8, /// Status array for each individual OperatorSnapshot account. operator_snapshot: [u8; MAX_OPERATORS], /// Status of the BallotBox account for this epoch. ballot_box: u8, } ``` - **Explanation**: Uses `u8` fields to represent the status of various temporary accounts associated with a specific epoch. ### NCNRewardRouter file: `ncn_reward_router.rs` - **Purpose**: The main entry point for routing rewards from NCNs. This router receives rewards and distributes them according to the fee structure. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct NCNRewardRouter { /// NCN the account is associated with ncn: Pubkey, /// The epoch the account is associated with epoch: PodU64, /// Bump seed for the PDA bump: u8, /// Slot the account was created slot_created: PodU64, /// Total rewards routed (in lamports) - cumulative amount ever processed total_rewards: PodU64, /// Amount of rewards in the reward pool (in lamports) - awaiting distribution reward_pool: PodU64, /// Amount of rewards processed (in lamports) - moved out of reward pool for distribution rewards_processed: PodU64, /// Reserved space for future fields reserved: [u8; 128], /// Last vote index processed during routing (for resuming partial operations) last_vote_index: PodU16, /// Last rewards amount being processed during routing (for resuming partial operations) last_rewards_to_process: PodU64, /// Rewards allocated to the Protocol (ready for distribution) protocol_rewards: PodU64, /// Rewards allocated to the NCN (ready for distribution) ncn_rewards: PodU64, /// Total rewards allocated to operator-vault reward receivers (before individual routing) operator_vault_rewards: PodU64, /// Individual operator reward routes - tracks rewards per operator /// Array size 256 limits the number of operators that can participate in an epoch operator_vault_reward_routes: [OperatorVaultRewardRoute; 256], } ``` - **Explanation**: The router distributes rewards in three tiers: 4% to Protocol, 4% to NCN, and 92% to operator-vault rewards. It supports partial routing through iterations to handle large numbers of operators without hitting transaction limits. ### OperatorVaultRewardRouter file: `operator_vault_reward_router.rs` - **Purpose**: Routes rewards from operators to their associated vaults. This router handles the final stage of reward distribution where operator rewards are further distributed to the vaults they operate. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, AccountDeserialize, ShankAccount)] #[repr(C)] pub struct OperatorVaultRewardRouter { /// The operator the router is associated with operator: Pubkey, /// The NCN the router is associated with ncn: Pubkey, /// The epoch the router is associated with epoch: PodU64, /// The bump seed for the PDA bump: u8, /// The slot the router was created slot_created: PodU64, /// The operator's index within the NCN ncn_operator_index: PodU64, /// The total rewards that have been routed (in lamports) - cumulative amount ever processed total_rewards: PodU64, /// The rewards in the reward pool (in lamports) - awaiting distribution reward_pool: PodU64, /// The rewards that have been processed (in lamports) - moved out of reward pool rewards_processed: PodU64, /// Rewards allocated to the operator (in lamports) - operator's fee portion operator_rewards: PodU64, /// The last rewards amount being processed during routing (for resuming partial operations) last_rewards_to_process: PodU64, /// The last vault operator delegation index processed during routing last_vault_operator_delegation_index: PodU16, /// Individual vault reward routes - tracks rewards per vault (limited to 64 vaults) vault_reward_routes: [VaultRewardRoute; 64], } ``` - **Explanation**: The distribution is based on the operator taking their fee percentage first, then remaining rewards are distributed to vaults proportionally by stake weight. It supports partial routing through iterations to handle large numbers of vaults. ### OperatorVaultRewardRoute file: `ncn_reward_router.rs` - **Purpose**: A component structure within `NCNRewardRouter` that tracks rewards allocated to a specific operator within the reward routing system. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, ShankType)] #[repr(C)] pub struct OperatorVaultRewardRoute { /// The operator pubkey operator: Pubkey, /// Reward amount allocated to this operator rewards: NCNRewardRouterRewards, } ``` - **Explanation**: Stores the mapping between an operator and their allocated reward amount within the NCN reward routing system. ### VaultRewardRoute file: `operator_vault_reward_router.rs` - **Purpose**: A component structure within `OperatorVaultRewardRouter` that tracks rewards allocated to a specific vault within the operator's reward distribution. - **Definition**: ```rust #[derive(Debug, Clone, Copy, Zeroable, Pod, ShankType)] #[repr(C)] pub struct VaultRewardRoute { /// The vault pubkey that will receive rewards vault: Pubkey, /// The amount of rewards allocated to this vault (in lamports) rewards: PodU64, } ``` - **Explanation**: Stores the mapping between a vault and its allocated reward amount within an operator's reward distribution system. --- # CLI Overview > Getting started with jito-restaking-cli ## Installation ### Option 1: Install from crates.io (Recommended) ```bash cargo install jito-restaking-cli ``` ### Option 2: Build from Source ```bash git clone git@github.com:jito-foundation/restaking.git cd restaking cargo build --release cargo install --path ./cli --bin jito-restaking-cli ``` ### Verify Installation ```bash jito-restaking-cli --help ``` ## Quick Start ### 1. Configuration First, set up your configuration. You can use command-line flags or a config file: ```bash # Using command-line flags jito-restaking-cli --rpc-url https://api.mainnet-beta.solana.com \ --signer ~/.config/solana/id.json \ restaking config get # Or create a config file (recommended) # See Configuration guide for details ``` ### 2. Initialize System Components ```bash # Initialize restaking config (one-time setup) jito-restaking-cli restaking config initialize # Initialize vault config (one-time setup) jito-restaking-cli vault config initialize 100 ``` ### 3. Create Your First Vault ```bash # Create a vault jito-restaking-cli vault vault initialize \ J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn \ 100 \ 100 \ 500 \ 9 \ 1000000000 ``` ### 4. Set Up an Operator ```bash # Initialize operator with 5% fee (500 basis points) jito-restaking-cli restaking operator initialize 500 ``` ### 5. Create an NCN ```bash # Initialize NCN jito-restaking-cli restaking ncn initialize \ --path-to-base-keypair ./ncn-keypair.json ``` ## Common Command Patterns ### Global Options Most commands accept these global options: ```bash jito-restaking-cli [GLOBAL_OPTIONS] # Common global options: --rpc-url # Solana RPC endpoint --signer # Your wallet keypair or Ledger --commitment # Transaction commitment level --verbose # Enable detailed output --print-tx # Show transaction instead of executing --print-json # Output in JSON format ``` ### Dry Run Mode Use `--print-tx` to see which instructions without executing: ```bash jito-restaking-cli \ --print-tx vault vault initialize \ J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn \ 100 \ 100 \ 500 \ 9 \ 1000000000 ``` ### JSON Output Use `--print-json` for programmatic access: ```bash jito-restaking-cli --print-json restaking ncn list ``` ## What's Next? Now that you have the CLI installed and understand the basics, explore these guides: 1. **[Vault Operations](https://www.jito.network/docs/restaking/cli/vault.md)** - Create and manage vaults 2. **[Operator Management](https://www.jito.network/docs/restaking/cli/operator.md)** - Set up and run operators 3. **[NCN Operations](https://www.jito.network/docs/restaking/cli/ncn.md)** - Coordinate network consensus ## Getting Help - Use `--help` with any command for detailed usage information - Check the **[CLI Reference](https://www.jito.network/docs/restaking/cli/reference.md)** for complete command documentation ```bash # Get help for specific commands jito-restaking-cli --help jito-restaking-cli vault --help jito-restaking-cli vault vault initialize --help ``` --- # NCN Operations > Learn how to interact with the NCN account Node Consensus Networks (NCNs) coordinate validation services between operators and vaults in the Jito (Re)staking ecosystem. NCNs manage which operators can participate in validation and which vaults can delegate stake to the network. ## Basic NCN Operations ### Creating an NCN ```bash # Generate keypair for your NCN solana-keygen new --outfile ./my-ncn-keypair.json # Initialize the NCN jito-restaking-cli restaking ncn initialize \ --path-to-base-keypair ./my-ncn-keypair.json ``` ### Viewing NCN Information ```bash # Get NCN details jito-restaking-cli restaking ncn get # List all NCNs jito-restaking-cli restaking ncn list # JSON output for programmatic access jito-restaking-cli --print-json restaking ncn get ``` ## Managing Operators ### Adding Operators to Your NCN Operators must go through a two-step process to join an NCN: ```bash # Step 1: Initialize the relationship jito-restaking-cli restaking ncn initialize-ncn-operator-state \ # Step 2: Start the warmup period jito-restaking-cli restaking ncn ncn-warmup-operator \ ``` ### Monitoring Operators ```bash # View all operators in your NCN jito-restaking-cli restaking ncn list-ncn-operator-state # Check operator status and warmup progress jito-restaking-cli --print-json restaking ncn list-ncn-operator-state ``` ### Removing Operators ```bash # Initiate operator removal (cooldown period) jito-restaking-cli restaking ncn ncn-cooldown-operator \ ``` ## Managing Vault Connections ### Connecting Vaults to Your NCN Vaults provide the staked tokens that operators use for validation: ```bash # Step 1: Create the vault ticket jito-restaking-cli restaking ncn initialize-ncn-vault-ticket \ # Step 2: Activate the connection jito-restaking-cli restaking ncn warmup-ncn-vault-ticket \ ``` ### Vault Relationship Benefits **For the NCN:** - Access to delegated stake for validation - Diversified funding sources - Reduced dependency on single vault **For Vaults:** - Access to professional validation services - Diversified staking opportunities - Enhanced yield potential ### Monitoring Vault Connections ```bash # View all connected vaults jito-restaking-cli restaking ncn list-ncn-vault-ticket # Check vault connection status jito-restaking-cli --print-json restaking ncn list-ncn-vault-ticket ``` ### Removing Vault Connections ```bash # Disconnect a vault (cooldown period) jito-restaking-cli restaking ncn cooldown-ncn-vault-ticket \ ``` ## Delegation and Token Management ### Setting Up Token Delegation NCNs can manage token delegation: ```bash # Create delegated token account jito-restaking-cli restaking ncn ncn-delegate-token-account \ \ \ \ --should-create-token-account ``` **Common delegation scenarios:** - **Operator rewards** - Distributing earned fees to operators - **Network incentives** - Managing token incentives for participants - **Governance tokens** - Coordinating voting across operators - **Reserve funds** - Managing emergency or development funds ## Administrative Operations ### Setting Up Admin Roles Distribute administrative responsibilities across your team: ```bash # Set operator admin (manages operator relationships) jito-restaking-cli restaking ncn ncn-set-secondary-admin \ --set-operator-admin \ # Set vault admin (manages vault connections) jito-restaking-cli restaking ncn ncn-set-secondary-admin \ --set-vault-admin \ # Set multiple roles for one admin jito-restaking-cli restaking ncn ncn-set-secondary-admin \ --set-slasher-admin \ --set-delegate-admin \ ``` ### Transferring Ownership ```bash # Transfer primary admin rights jito-restaking-cli restaking ncn ncn-set-admin \ --old-admin-keypair ./current-admin.json \ --new-admin-keypair ./new-admin.json \ ``` **When to transfer ownership:** - Organizational changes - Security key rotation - Decentralization initiatives - Emergency situations ## NCN Governance Patterns ### Democratic Governance Distribute control across multiple admins: ```bash # Operations team manages day-to-day operations jito-restaking-cli restaking ncn ncn-set-secondary-admin \ --set-operator-admin \ --set-vault-admin \ # Security team handles slashing and emergencies jito-restaking-cli restaking ncn ncn-set-secondary-admin \ --set-slasher-admin \ # Community representatives manage metadata and governance jito-restaking-cli restaking ncn ncn-set-secondary-admin \ --set-metadata-admin \ --set-weight-table-admin \ ``` ## Quick Reference | Task | Command | |------|---------| | Create NCN | `restaking ncn initialize --path-to-base-keypair ` | | View NCN | `restaking ncn get ` | | Add operator | `initialize-ncn-operator-state` → `ncn-warmup-operator` | | Add vault | `initialize-ncn-vault-ticket` → `warmup-ncn-vault-ticket` | | Set admin role | `restaking ncn ncn-set-secondary-admin --set--admin` | | Transfer ownership | `restaking ncn ncn-set-admin --old-admin-keypair --new-admin-keypair` | | List operators | `restaking ncn list-ncn-operator-state ` | | List vaults | `restaking ncn list-ncn-vault-ticket ` | --- # Operator Operations > Learn how to interact with the Operator account Operators provide professional validation services across multiple networks using delegated tokens from vaults. They earn fees for their services and can participate in multiple NCNs simultaneously. ## Basic Operator Operations ### Creating an Operator ```bash # Initialize operator with 5% fee (500 basis points) jito-restaking-cli restaking operator initialize 500 # The command will output your operator pubkey - save this! # Example output: "Operator initialized: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgHRv" ``` ### Viewing Operator Information ```bash # Get operator details jito-restaking-cli restaking operator get # List all operators (market research) jito-restaking-cli restaking operator list # JSON output for automation jito-restaking-cli --print-json restaking operator get ``` ### Updating Operator Fees ```bash # Update to 4% fee (400 basis points) jito-restaking-cli restaking operator operator-set-fees \ 400 # Best practice: announce fee changes in advance to delegators ``` ## Managing Vault Relationships ### Connecting to Vaults Operators must establish relationships with vaults to receive delegations: ```bash # Step 1: Initialize the relationship jito-restaking-cli restaking operator initialize-operator-vault-ticket \ # Step 2: Activate the relationship (warmup period) jito-restaking-cli restaking operator warmup-operator-vault-ticket \ ``` ### Removing Vault Connections ```bash # Initiate cooldown (gradual disconnection) jito-restaking-cli restaking operator cooldown-operator-vault-ticket \ ``` ## Joining NCN Networks ### Joining an NCN ```bash # Request to join an NCN (operator-initiated) jito-restaking-cli restaking operator operator-warmup-ncn \ # Note: NCN must also approve the relationship from their side ``` ### Monitoring NCN Participation ```bash # View all NCN participations jito-restaking-cli restaking operator list-ncn-operator-state # Check participation status jito-restaking-cli --print-json restaking operator list-ncn-operator-state | \ jq '.[] | {ncn: .ncn, status: .status, warmup_complete: .warmup_complete}' ``` ### Leaving an NCN ```bash # Initiate departure from NCN jito-restaking-cli restaking operator operator-cooldown-ncn \ ``` ## Token Delegation Management ### Setting Up Token Accounts Operators can manage delegated token accounts for various purposes: ```bash # Create delegated token account jito-restaking-cli restaking operator operator-delegate-token-account \ \ \ \ --should-create-token-account ``` ## Administrative Management ### Setting Up Admin Roles Distribute operational responsibilities across your team: ```bash # Set NCN admin (manages NCN relationships) jito-restaking-cli restaking operator operator-set-secondary-admin \ --set-ncn-admin \ # Set vault admin (manages vault relationships) jito-restaking-cli restaking operator operator-set-secondary-admin \ --set-vault-admin \ # Set voter admin (handles governance) jito-restaking-cli restaking operator operator-set-secondary-admin \ --set-voter-admin \ # Set multiple roles for operational efficiency jito-restaking-cli restaking operator operator-set-secondary-admin \ --set-delegate-admin \ --set-metadata-admin \ ``` **Admin Role Descriptions:** | Role | Responsibilities | Use Case | |------|-----------------|----------| | `ncn-admin` | NCN relationship management | Business development team | | `vault-admin` | Vault connection management | Partnership team | | `voter-admin` | Governance participation | Strategy team | | `delegate-admin` | Token delegation operations | Operations team | | `metadata-admin` | Operator information updates | Marketing team | ### Transferring Ownership ```bash # Transfer primary ownership jito-restaking-cli restaking operator operator-set-admin \ --old-admin-keypair ./current-admin.json \ --new-admin-keypair ./new-admin.json \ ``` **When to transfer ownership:** - Organizational restructuring - Security key rotation schedule - Succession planning - Emergency situations ## Quick Reference | Task | Command | |------|---------| | Initialize operator | `restaking operator initialize ` | | Update fees | `restaking operator operator-set-fees ` | | Connect to vault | `initialize-operator-vault-ticket` → `warmup-operator-vault-ticket` | | Join NCN | `restaking operator operator-warmup-ncn ` | | Set admin roles | `restaking operator operator-set-secondary-admin --set--admin` | | View operator | `restaking operator get ` | | List vault connections | `restaking operator list-operator-vault-ticket ` | | List NCN participations | `restaking operator list-ncn-operator-state ` | --- # Vault Operations > Overview of vault program operations The vault commands manage the core functionality of restaking vaults, including global configuration, vault creation and management, user operations, and administrative functions. Vaults are the primary interface for users to participate in restaking and earn rewards. ## Command Structure All vault commands follow this pattern: ```bash jito-restaking-cli vault [OPTIONS] ``` Where: - **COMPONENT**: `config` or `vault` - **ACTION**: Specific operation to perform - **OPTIONS**: Command-specific parameters ## Core Components ### 1. Global Configuration Management System-wide configuration for all vaults: ```bash # View global configuration jito-restaking-cli vault config get # Update global settings (admin only) jito-restaking-cli vault config set-program-fee jito-restaking-cli vault config set-program-fee-wallet jito-restaking-cli vault config set-admin ``` **When to use:** Initial system setup, global fee adjustments, administrative changes. ### 2. Individual Vault Operations Creating and managing specific vaults: ```bash # Create a new vault jito-restaking-cli vault vault initialize # View vault details jito-restaking-cli vault vault get # List all vaults jito-restaking-cli vault vault list ``` **When to use:** Creating investment products, managing vault portfolios, user research. ## Global Configuration Global configuration affects all vaults in the system and is typically managed by the protocol administrators. ### Configuration Management ```bash # View current global settings jito-restaking-cli vault config get # Update program fee (affects all vaults) jito-restaking-cli vault config set-program-fee 150 # 1.5% # Change fee collection wallet jito-restaking-cli vault config set-program-fee-wallet # Transfer global admin rights jito-restaking-cli vault config set-admin ``` **Global configuration controls:** - **Program fees** - Base fee collected from all vault operations - **Fee wallet** - Where program fees are deposited - **Global admin** - Who can modify system-wide settings ## Vault Creation and Management ### Creating Vaults Vaults are created for specific tokens with defined fee structures: ```bash # Create JitoSOL restaking vault jito-restaking-cli vault vault initialize \ J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn \ 50 \ 50 \ 300 \ 9 \ 1000000000 # Create USDC restaking vault jito-restaking-cli vault vault initialize \ EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v \ 25 \ 25 \ 200 \ 6 \ 1000000 # Create custom token vault jito-restaking-cli vault vault initialize \ \ \ \ \ \ ``` **Parameter explanation:** - **Token mint** - The SPL token that can be deposited - **Deposit fee** - Fee charged on deposits (basis points) - **Withdrawal fee** - Fee charged on withdrawals (basis points) - **Reward fee** - Fee taken from earned rewards (basis points) - **Decimals** - Number of decimal places for the token - **Initial amount** - Bootstrap liquidity amount ### Vault Configuration ```bash # Set deposit capacity limit jito-restaking-cli vault vault set-capacity # Update fee structure jito-restaking-cli vault vault set-fees \ --deposit-fee-bps 75 \ --withdrawal-fee-bps 75 \ --reward-fee-bps 400 \ # Pause/resume vault operations jito-restaking-cli vault vault set-is-paused --set-pause jito-restaking-cli vault vault set-is-paused # Resume ``` ### Token Metadata Management ```bash # Create VRT token metadata jito-restaking-cli vault vault create-token-metadata \ \ "Jito SOL Vault Token" \ "jitoSOL-VRT" \ "https://metadata.example.com/vault.json" # Update existing metadata jito-restaking-cli vault vault update-token-metadata \ \ "Updated Vault Name" \ "NEW-VRT" \ "https://new-metadata-url.com/vault.json" ``` ## User Operations ### Deposits (Minting VRT) Users deposit tokens and receive Vault Receipt Tokens (VRT): ```bash # Deposit tokens and mint VRT jito-restaking-cli vault vault mint-vrt \ \ \ # Example: Deposit 10 SOL, expect at least 9.9 VRT jito-restaking-cli vault vault mint-vrt \ \ 10000000000 \ 9900000000 ``` **Slippage protection:** - `MIN_AMOUNT_OUT` protects against unfavorable exchange rates - Accounts for deposit fees and current vault exchange rate - Transaction fails if minimum output not achievable ### Withdrawals Two-step withdrawal process for security: ```bash # Step 1: Enqueue withdrawal (burns VRT, creates ticket) jito-restaking-cli vault vault enqueue-withdrawal \ \ # Step 2: Complete withdrawal after cooldown period jito-restaking-cli vault vault burn-withdrawal-ticket \ ``` ### Withdrawal Ticket Management ```bash # Check withdrawal ticket status jito-restaking-cli vault vault get-withdrawal-ticket \ \ # Transfer withdrawal ticket to another user jito-restaking-cli vault vault change-withdrawal-ticket-owner \ --old-ticket-owner-keypair ./current-owner.json \ \ ``` ## Delegation Management ### Operator Delegation Vaults delegate tokens to operators for validation services: ```bash # Initialize delegation relationship jito-restaking-cli vault vault initialize-operator-delegation \ \ # Delegate tokens to operator jito-restaking-cli vault vault delegate-to-operator \ \ \ # Reduce delegation (cooldown period) jito-restaking-cli vault vault cooldown-operator-delegation \ \ \ ``` ### Delegation Monitoring ```bash # View all operator delegations jito-restaking-cli vault vault get-operator-delegations # View specific operator delegation jito-restaking-cli vault vault get-operator-delegation \ \ ``` ## NCN Integration ### Vault-NCN Relationships Connect vaults to Node Consensus Networks for coordinated validation: ```bash # Initialize vault-NCN relationship jito-restaking-cli vault vault initialize-vault-ncn-ticket \ \ # Activate the relationship jito-restaking-cli vault vault warmup-vault-ncn-ticket \ \ # Deactivate the relationship jito-restaking-cli vault vault cooldown-vault-ncn-ticket \ \ ``` **Benefits of NCN integration:** - Coordinated delegation strategies across operators - Enhanced security through network coordination - Optimized reward distribution mechanisms - Shared governance and decision-making ## Vault Update Cycles ### Managing Update Cycles Vault update cycles synchronize state changes and reward distribution: ```bash # Start an update cycle jito-restaking-cli vault vault initialize-vault-update-state-tracker \ # Process each operator in the update jito-restaking-cli vault vault crank-vault-update-state-tracker \ \ # Complete the update cycle jito-restaking-cli vault vault close-vault-update-state-tracker \ ``` ### Update Cycle Monitoring ```bash # Check update cycle status jito-restaking-cli vault vault get-vault-update-state-tracker # Monitor progress with JSON output jito-restaking-cli --print-json vault vault get-vault-update-state-tracker ``` **Update cycle purposes:** - Synchronize delegation changes across operators - Distribute earned rewards to depositors - Update vault exchange rates and balances - Process any pending state transitions ## Administrative Operations ### Admin Role Management ```bash # Transfer primary vault ownership jito-restaking-cli vault vault set-admin \ --old-admin-keypair ./current-admin.json \ --new-admin-keypair ./new-admin.json \ # Set specialized admin roles jito-restaking-cli vault vault set-secondary-admin \ --set-delegation-admin \ jito-restaking-cli vault vault set-secondary-admin \ --set-operator-admin \ # Set multiple roles at once jito-restaking-cli vault vault set-secondary-admin \ --set-fee-admin \ --set-capacity-admin \ --set-metadata-admin \ ``` **Available admin roles:** - `--set-delegation-admin` - Manage delegation operations - `--set-operator-admin` - Manage operator relationships - `--set-ncn-admin` - Manage NCN connections - `--set-slasher-admin` - Handle slashing operations - `--set-capacity-admin` - Manage deposit limits - `--set-fee-wallet` - Change fee collection address - `--set-mint-burn-admin` - Manage VRT minting/burning - `--set-delegate-asset-admin` - Manage asset delegation - `--set-fee-admin` - Update fee structures - `--set-metadata-admin` - Manage token metadata ### Advanced Token Operations ```bash # Update vault balance calculations jito-restaking-cli vault vault update-vault-balance # Delegate token account control jito-restaking-cli vault vault delegate-token-account \ \ \ \ # Transfer tokens via delegated authority jito-restaking-cli vault vault delegated-token-transfer \ \ \ ``` ## Monitoring and Information ### Vault Information Retrieval ```bash # Basic vault information jito-restaking-cli vault vault get # Detailed JSON output for automation jito-restaking-cli --print-json vault vault get # List all vaults in the system jito-restaking-cli vault vault list # Enhanced JSON output with reserved space details jito-restaking-cli --print-json-with-reserves vault vault get ``` ## Quick Reference | Category | Command | |----------|---------| | **Global Config** | | | Initialize system | `vault config initialize ` | | View config | `vault config get` | | Update fee | `vault config set-program-fee ` | | **Vault Management** | | | Create vault | `vault vault initialize ` | | View vault | `vault vault get ` | | Set capacity | `vault vault set-capacity ` | | Update fees | `vault vault set-fees ` | | **User Operations** | | | Deposit | `vault vault mint-vrt ` | | Start withdrawal | `vault vault enqueue-withdrawal ` | | Complete withdrawal | `vault vault burn-withdrawal-ticket ` | | **Delegation** | | | Delegate to operator | `vault vault delegate-to-operator ` | | View delegations | `vault vault get-operator-delegations ` | | **NCN Integration** | | | Connect to NCN | `vault vault initialize-vault-ncn-ticket` → `warmup-vault-ncn-ticket` | | **Maintenance** | | | Update balance | `vault vault update-vault-balance ` | | Start update cycle | `vault vault initialize-vault-update-state-tracker ` | --- # CLI Usage > Command-Line Reference for jito-restaking-cli # Command-Line Help for `jito-restaking-cli` This document contains the help content for the `jito-restaking-cli` command-line program. ### `jito-restaking-cli` A CLI for managing restaking and vault operations **Usage:** `jito-restaking-cli [OPTIONS] [COMMAND]` ###### **Subcommands:** * `restaking` — Restaking program commands * `vault` — Vault program commands ###### **Options:** * `--config-file ` — Path to the configuration file * `--rpc-url ` — RPC URL to use * `--commitment ` — Commitment level * `--restaking-program-id ` — Restaking program ID * `--vault-program-id ` — Vault program ID * `--signer ` — Filepath or URL to a keypair * `--verbose` — Verbose mode * `--print-tx` — This will print out the raw TX instead of running it Default value: `false` * `--print-json` — This will print out account information in JSON format Default value: `false` * `--print-json-with-reserves` — This will print out account information in JSON format with reserved space Default value: `false` ### `jito-restaking-cli restaking` Restaking program commands **Usage:** `jito-restaking-cli restaking ` ###### **Subcommands:** * `config` — Initialize, get, and set the config struct * `ncn` — * `operator` — ### `jito-restaking-cli restaking config` Initialize, get, and set the config struct **Usage:** `jito-restaking-cli restaking config ` ###### **Subcommands:** * `initialize` — Initialize the config * `get` — Get the config * `set-admin` — Set the config admin ### `jito-restaking-cli restaking config initialize` Initialize the config **Usage:** `jito-restaking-cli restaking config initialize` ### `jito-restaking-cli restaking config get` Get the config **Usage:** `jito-restaking-cli restaking config get` ### `jito-restaking-cli restaking config set-admin` Set the config admin **Usage:** `jito-restaking-cli restaking config set-admin ` ###### **Arguments:** * `` — The new admin's pubkey ### `jito-restaking-cli restaking ncn` **Usage:** `jito-restaking-cli restaking ncn ` ###### **Subcommands:** * `initialize` — Initialize NCN * `initialize-ncn-operator-state` — Initialize NCN Operator State * `ncn-warmup-operator` — Warmup NCN Operator State * `ncn-cooldown-operator` — NCN Cooldown Operator State * `initialize-ncn-vault-ticket` — Initialize NCN Vault Ticket * `warmup-ncn-vault-ticket` — Warmup NCN Vault Ticket * `cooldown-ncn-vault-ticket` — Cooldown NCN Vault Ticket * `ncn-delegate-token-account` — NCN Delegate Token Account * `get` — Get NCN * `list` — List all NCNs * `list-ncn-operator-state` — List All Ncn Operator State for a NCN * `list-ncn-vault-ticket` — List All Ncn Vault Ticket for a NCN * `ncn-set-admin` — Set NCN Admin * `ncn-set-secondary-admin` — Set NCN Secondary Admin ### `jito-restaking-cli restaking ncn initialize` Initialize NCN **Usage:** `jito-restaking-cli restaking ncn initialize [OPTIONS]` ###### **Options:** * `--path-to-base-keypair ` ### `jito-restaking-cli restaking ncn initialize-ncn-operator-state` Initialize NCN Operator State **Usage:** `jito-restaking-cli restaking ncn initialize-ncn-operator-state ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking ncn ncn-warmup-operator` Warmup NCN Operator State **Usage:** `jito-restaking-cli restaking ncn ncn-warmup-operator ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking ncn ncn-cooldown-operator` NCN Cooldown Operator State **Usage:** `jito-restaking-cli restaking ncn ncn-cooldown-operator ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking ncn initialize-ncn-vault-ticket` Initialize NCN Vault Ticket **Usage:** `jito-restaking-cli restaking ncn initialize-ncn-vault-ticket ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking ncn warmup-ncn-vault-ticket` Warmup NCN Vault Ticket **Usage:** `jito-restaking-cli restaking ncn warmup-ncn-vault-ticket ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking ncn cooldown-ncn-vault-ticket` Cooldown NCN Vault Ticket **Usage:** `jito-restaking-cli restaking ncn cooldown-ncn-vault-ticket ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking ncn ncn-delegate-token-account` NCN Delegate Token Account **Usage:** `jito-restaking-cli restaking ncn ncn-delegate-token-account [OPTIONS] ` ###### **Arguments:** * `` * `` * `` ###### **Options:** * `--should-create-token-account` ### `jito-restaking-cli restaking ncn get` Get NCN **Usage:** `jito-restaking-cli restaking ncn get ` ###### **Arguments:** * `` ### `jito-restaking-cli restaking ncn list` List all NCNs **Usage:** `jito-restaking-cli restaking ncn list` ### `jito-restaking-cli restaking ncn list-ncn-operator-state` List All Ncn Operator State for a NCN **Usage:** `jito-restaking-cli restaking ncn list-ncn-operator-state ` ###### **Arguments:** * `` ### `jito-restaking-cli restaking ncn list-ncn-vault-ticket` List All Ncn Vault Ticket for a NCN **Usage:** `jito-restaking-cli restaking ncn list-ncn-vault-ticket ` ###### **Arguments:** * `` ### `jito-restaking-cli restaking ncn ncn-set-admin` Set NCN Admin **Usage:** `jito-restaking-cli restaking ncn ncn-set-admin --old-admin-keypair --new-admin-keypair ` ###### **Arguments:** * `` — The NCN pubkey ###### **Options:** * `--old-admin-keypair ` — Filepath or URL to a keypair of old admin * `--new-admin-keypair ` — Filepath or URL to a keypair of new admin ### `jito-restaking-cli restaking ncn ncn-set-secondary-admin` Set NCN Secondary Admin **Usage:** `jito-restaking-cli restaking ncn ncn-set-secondary-admin [OPTIONS] ` ###### **Arguments:** * `` — The NCN pubkey * `` — The new admin pubkey ###### **Options:** * `--set-operator-admin` — Set operator_admin * `--set-vault-admin` — Set vault_admin * `--set-slasher-admin` — Set slasher_admin * `--set-delegate-admin` — Set delegate_admin * `--set-metadata-admin` — Set metadata_admin * `--set-weight-table-admin` — Set weight_table_admin * `--set-ncn-program-admin` — Set ncn_program_admin ### `jito-restaking-cli restaking operator` **Usage:** `jito-restaking-cli restaking operator ` ###### **Subcommands:** * `initialize` — Initialize Operator * `initialize-operator-vault-ticket` — Initialize Operator Vault Ticket * `warmup-operator-vault-ticket` — Warmup Operator Vault Ticket * `cooldown-operator-vault-ticket` — Cooldown Operator Vault Ticket * `operator-warmup-ncn` — Operator Warmup NCN * `operator-cooldown-ncn` — Operator Cooldown NCN * `operator-set-admin` — Operator Set Admin * `operator-set-secondary-admin` — Operator Set Secondary Admin * `operator-set-fees` — Sets the operator fee * `operator-delegate-token-account` — Operator Delegate Token Account * `get` — Get operator * `list` — List all operators * `list-operator-vault-ticket` — List Operator Vault Ticket for an Operator * `list-ncn-operator-state` — List All Ncn Operator State for a Operator ### `jito-restaking-cli restaking operator initialize` Initialize Operator **Usage:** `jito-restaking-cli restaking operator initialize ` ###### **Arguments:** * `` ### `jito-restaking-cli restaking operator initialize-operator-vault-ticket` Initialize Operator Vault Ticket **Usage:** `jito-restaking-cli restaking operator initialize-operator-vault-ticket ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking operator warmup-operator-vault-ticket` Warmup Operator Vault Ticket **Usage:** `jito-restaking-cli restaking operator warmup-operator-vault-ticket ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking operator cooldown-operator-vault-ticket` Cooldown Operator Vault Ticket **Usage:** `jito-restaking-cli restaking operator cooldown-operator-vault-ticket ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking operator operator-warmup-ncn` Operator Warmup NCN **Usage:** `jito-restaking-cli restaking operator operator-warmup-ncn ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking operator operator-cooldown-ncn` Operator Cooldown NCN **Usage:** `jito-restaking-cli restaking operator operator-cooldown-ncn ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking operator operator-set-admin` Operator Set Admin **Usage:** `jito-restaking-cli restaking operator operator-set-admin --old-admin-keypair --new-admin-keypair ` ###### **Arguments:** * `` — The Operator pubkey ###### **Options:** * `--old-admin-keypair ` — Filepath or URL to a keypair of old admin * `--new-admin-keypair ` — Filepath or URL to a keypair of new admin ### `jito-restaking-cli restaking operator operator-set-secondary-admin` Operator Set Secondary Admin **Usage:** `jito-restaking-cli restaking operator operator-set-secondary-admin [OPTIONS] ` ###### **Arguments:** * `` * `` ###### **Options:** * `--set-ncn-admin` * `--set-vault-admin` * `--set-voter-admin` * `--set-delegate-admin` * `--set-metadata-admin` ### `jito-restaking-cli restaking operator operator-set-fees` Sets the operator fee **Usage:** `jito-restaking-cli restaking operator operator-set-fees ` ###### **Arguments:** * `` * `` ### `jito-restaking-cli restaking operator operator-delegate-token-account` Operator Delegate Token Account **Usage:** `jito-restaking-cli restaking operator operator-delegate-token-account [OPTIONS] ` ###### **Arguments:** * `` * `` * `` ###### **Options:** * `--should-create-token-account` ### `jito-restaking-cli restaking operator get` Get operator **Usage:** `jito-restaking-cli restaking operator get ` ###### **Arguments:** * `` ### `jito-restaking-cli restaking operator list` List all operators **Usage:** `jito-restaking-cli restaking operator list` ### `jito-restaking-cli restaking operator list-operator-vault-ticket` List Operator Vault Ticket for an Operator **Usage:** `jito-restaking-cli restaking operator list-operator-vault-ticket ` ###### **Arguments:** * `` ### `jito-restaking-cli restaking operator list-ncn-operator-state` List All Ncn Operator State for a Operator **Usage:** `jito-restaking-cli restaking operator list-ncn-operator-state ` ###### **Arguments:** * `` ### `jito-restaking-cli vault` Vault program commands **Usage:** `jito-restaking-cli vault ` ###### **Subcommands:** * `config` — * `vault` — Vault commands ### `jito-restaking-cli vault config` **Usage:** `jito-restaking-cli vault config ` ###### **Subcommands:** * `initialize` — Creates global config (can only be done once) * `get` — Fetches global config * `set-admin` — Set the config admin * `set-program-fee` — Set the program fee * `set-program-fee-wallet` — Set the program fee wallet ### `jito-restaking-cli vault config initialize` Creates global config (can only be done once) **Usage:** `jito-restaking-cli vault config initialize ` ###### **Arguments:** * `` — The program fee in basis points * `` — The program fee wallet pubkey ### `jito-restaking-cli vault config get` Fetches global config **Usage:** `jito-restaking-cli vault config get` ### `jito-restaking-cli vault config set-admin` Set the config admin **Usage:** `jito-restaking-cli vault config set-admin ` ###### **Arguments:** * `` — The new admin's pubkey ### `jito-restaking-cli vault config set-program-fee` Set the program fee **Usage:** `jito-restaking-cli vault config set-program-fee ` ###### **Arguments:** * `` — The program fee ### `jito-restaking-cli vault config set-program-fee-wallet` Set the program fee wallet **Usage:** `jito-restaking-cli vault config set-program-fee-wallet ` ###### **Arguments:** * `` — The program fee wallet ### `jito-restaking-cli vault vault` Vault commands **Usage:** `jito-restaking-cli vault vault ` ###### **Subcommands:** * `initialize` — Creates a new vault * `create-token-metadata` — Creates token metadata for the vault's LRT token * `update-token-metadata` — * `initialize-vault-update-state-tracker` — Starts the vault update cycle * `crank-vault-update-state-tracker` — Cranks the vault update state tracker, needs to be run per operator * `close-vault-update-state-tracker` — Ends the vault update cycle * `mint-vrt` — Mints VRT tokens * `initialize-operator-delegation` — Sets up the delegations for an operator * `delegate-to-operator` — Delegates tokens to an operator * `cooldown-operator-delegation` — Cooldown delegation for an operator * `initialize-vault-ncn-ticket` — Initialize Vault NCN Ticket * `warmup-vault-ncn-ticket` — Warmup Vault NCN Ticket * `cooldown-vault-ncn-ticket` — Cooldown Vault NCN Ticket * `enqueue-withdrawal` — Starts the withdrawal process * `change-withdrawal-ticket-owner` — Change withdrawal ticket owner * `burn-withdrawal-ticket` — Burns the withdrawal ticket, ending the withdrawal process * `get-vault-update-state-tracker` — Gets the update state tracker for a vault * `get-operator-delegations` — Gets the operator delegations for a vault * `get-operator-delegation` — Gets the operator delegation for a vault * `get-withdrawal-ticket` — * `get` — Gets a vault * `list` — List all vaults * `set-admin` — Set Admin * `set-capacity` — Sets the deposit capacity in the vault * `set-fees` — Sets the fees in the vault * `set-is-paused` — Sets the vault's pause state * `set-secondary-admin` — Set Secondary Admin * `update-vault-balance` — Update Vault Balance * `delegate-token-account` — Delegate a token account * `delegated-token-transfer` — Transfer a token account ### `jito-restaking-cli vault vault initialize` Creates a new vault **Usage:** `jito-restaking-cli vault vault initialize [VRT_MINT_ADDRESS_FILE_PATH]` ###### **Arguments:** * `` — The token which is allowed to be deposited into the vault * `` — The deposit fee in bips * `` — The withdrawal fee in bips * `` — The reward fee in bips * `` — The decimals of the token * `` — The amount of tokens to initialize the vault with ( in the smallest unit ) * `` — The file path of VRT mint address ### `jito-restaking-cli vault vault create-token-metadata` Creates token metadata for the vault's LRT token **Usage:** `jito-restaking-cli vault vault create-token-metadata ` ###### **Arguments:** * `` — The vault pubkey * `` — The name of the token * `` — The symbol of the token * `` — The URI for the token metadata ### `jito-restaking-cli vault vault update-token-metadata` **Usage:** `jito-restaking-cli vault vault update-token-metadata ` ###### **Arguments:** * `` — The vault pubkey * `` — The name of the token * `` — The symbol of the token * `` — The URI for the token metadata ### `jito-restaking-cli vault vault initialize-vault-update-state-tracker` Starts the vault update cycle **Usage:** `jito-restaking-cli vault vault initialize-vault-update-state-tracker ` ###### **Arguments:** * `` — Vault account ### `jito-restaking-cli vault vault crank-vault-update-state-tracker` Cranks the vault update state tracker, needs to be run per operator **Usage:** `jito-restaking-cli vault vault crank-vault-update-state-tracker ` ###### **Arguments:** * `` — Vault account * `` — Operator account ### `jito-restaking-cli vault vault close-vault-update-state-tracker` Ends the vault update cycle **Usage:** `jito-restaking-cli vault vault close-vault-update-state-tracker [NCN_EPOCH]` ###### **Arguments:** * `` — Vault account * `` — Optional NCN epoch to close ### `jito-restaking-cli vault vault mint-vrt` Mints VRT tokens **Usage:** `jito-restaking-cli vault vault mint-vrt ` ###### **Arguments:** * `` — Vault account * `` — Amount to deposit * `` — Minimum amount of VRT to mint ### `jito-restaking-cli vault vault initialize-operator-delegation` Sets up the delegations for an operator **Usage:** `jito-restaking-cli vault vault initialize-operator-delegation ` ###### **Arguments:** * `` — Vault account * `` — Operator account ### `jito-restaking-cli vault vault delegate-to-operator` Delegates tokens to an operator **Usage:** `jito-restaking-cli vault vault delegate-to-operator ` ###### **Arguments:** * `` — Vault account * `` — Operator account * `` — Amount to delegate ### `jito-restaking-cli vault vault cooldown-operator-delegation` Cooldown delegation for an operator **Usage:** `jito-restaking-cli vault vault cooldown-operator-delegation ` ###### **Arguments:** * `` — Vault account * `` — Operator account * `` — Amount to cooldown ### `jito-restaking-cli vault vault initialize-vault-ncn-ticket` Initialize Vault NCN Ticket **Usage:** `jito-restaking-cli vault vault initialize-vault-ncn-ticket ` ###### **Arguments:** * `` — Vault account * `` — NCN account ### `jito-restaking-cli vault vault warmup-vault-ncn-ticket` Warmup Vault NCN Ticket **Usage:** `jito-restaking-cli vault vault warmup-vault-ncn-ticket ` ###### **Arguments:** * `` — Vault account * `` — NCN account ### `jito-restaking-cli vault vault cooldown-vault-ncn-ticket` Cooldown Vault NCN Ticket **Usage:** `jito-restaking-cli vault vault cooldown-vault-ncn-ticket ` ###### **Arguments:** * `` — Vault account * `` — NCN account ### `jito-restaking-cli vault vault enqueue-withdrawal` Starts the withdrawal process **Usage:** `jito-restaking-cli vault vault enqueue-withdrawal ` ###### **Arguments:** * `` — Vault account * `` — Amount to withdraw ### `jito-restaking-cli vault vault change-withdrawal-ticket-owner` Change withdrawal ticket owner **Usage:** `jito-restaking-cli vault vault change-withdrawal-ticket-owner --old-ticket-owner-keypair ` ###### **Arguments:** * `` — The vault pubkey * `` — The new ticket owner pubkey ###### **Options:** * `--old-ticket-owner-keypair ` — The old ticket owner keypair ### `jito-restaking-cli vault vault burn-withdrawal-ticket` Burns the withdrawal ticket, ending the withdrawal process **Usage:** `jito-restaking-cli vault vault burn-withdrawal-ticket ` ###### **Arguments:** * `` — Vault account ### `jito-restaking-cli vault vault get-vault-update-state-tracker` Gets the update state tracker for a vault **Usage:** `jito-restaking-cli vault vault get-vault-update-state-tracker ` ###### **Arguments:** * `` — Vault account ### `jito-restaking-cli vault vault get-operator-delegations` Gets the operator delegations for a vault **Usage:** `jito-restaking-cli vault vault get-operator-delegations ` ###### **Arguments:** * `` — Vault account ### `jito-restaking-cli vault vault get-operator-delegation` Gets the operator delegation for a vault **Usage:** `jito-restaking-cli vault vault get-operator-delegation ` ###### **Arguments:** * `` — Vault account * `` — Operator account ### `jito-restaking-cli vault vault get-withdrawal-ticket` **Usage:** `jito-restaking-cli vault vault get-withdrawal-ticket [STAKER]` ###### **Arguments:** * `` — Vault account * `` — Staker account ### `jito-restaking-cli vault vault get` Gets a vault **Usage:** `jito-restaking-cli vault vault get ` ###### **Arguments:** * `` — The vault pubkey ### `jito-restaking-cli vault vault list` List all vaults **Usage:** `jito-restaking-cli vault vault list` ### `jito-restaking-cli vault vault set-admin` Set Admin **Usage:** `jito-restaking-cli vault vault set-admin --old-admin-keypair --new-admin-keypair ` ###### **Arguments:** * `` — The Vault pubkey ###### **Options:** * `--old-admin-keypair ` — Filepath or URL to a keypair of old admin * `--new-admin-keypair ` — Filepath or URL to a keypair of new admin ### `jito-restaking-cli vault vault set-capacity` Sets the deposit capacity in the vault **Usage:** `jito-restaking-cli vault vault set-capacity ` ###### **Arguments:** * `` — The vault pubkey * `` — The new capacity ### `jito-restaking-cli vault vault set-fees` Sets the fees in the vault **Usage:** `jito-restaking-cli vault vault set-fees [OPTIONS] ` ###### **Arguments:** * `` — The vault pubkey ###### **Options:** * `--deposit-fee-bps ` — The deposit fee BPS * `--withdrawal-fee-bps ` — The withdrawal fee BPS * `--reward-fee-bps ` — The reward fee BPS ### `jito-restaking-cli vault vault set-is-paused` Sets the vault's pause state **Usage:** `jito-restaking-cli vault vault set-is-paused [OPTIONS] ` ###### **Arguments:** * `` — The vault pubkey ###### **Options:** * `--set-pause` — Set pause ### `jito-restaking-cli vault vault set-secondary-admin` Set Secondary Admin **Usage:** `jito-restaking-cli vault vault set-secondary-admin [OPTIONS] ` ###### **Arguments:** * `` — The vault pubkey * `` — The new admin pubkey ###### **Options:** * `--set-delegation-admin` — Set delegation_admin * `--set-operator-admin` — Set operator_admin * `--set-ncn-admin` — Set ncn_admin * `--set-slasher-admin` — Set slasher_admin * `--set-capacity-admin` — Set capacity_admin * `--set-fee-wallet` — Set fee_wallet * `--set-mint-burn-admin` — Set mint_burn_admin * `--set-delegate-asset-admin` — Set delegate_asset_admin * `--set-fee-admin` — Set fee_admin * `--set-metadata-admin` — Set metadata_admin ### `jito-restaking-cli vault vault update-vault-balance` Update Vault Balance **Usage:** `jito-restaking-cli vault vault update-vault-balance ` ###### **Arguments:** * `` — The vault pubkey ### `jito-restaking-cli vault vault delegate-token-account` Delegate a token account **Usage:** `jito-restaking-cli vault vault delegate-token-account ` ###### **Arguments:** * `` — The vault pubkey * `` — The delegate account * `` — The token mint * `` — The token account ### `jito-restaking-cli vault vault delegated-token-transfer` Transfer a token account **Usage:** `jito-restaking-cli vault vault delegated-token-transfer ` ###### **Arguments:** * `` — The token account * `` — The recipient pubkey * `` — The amount to transfer
This document was generated automatically by clap-markdown. --- # Rust Client > Learn how to use the Jito Restaking Rust client. Powered by [Codama](https://github.com/codama-idl/codama), there are Rust clients code `jito-restaking-client` and `jito-vault-client`. Install like below: ```toml [dependencies] jito-restaking-client = { git = "https://github.com/jito-foundation/restaking.git", branch = "master" } jito-vault-client = { git = "https://github.com/jito-foundation/restaking.git", branch = "master" } ``` ## Jito Restaking Client Through `jito-restaking-client`, you can handle the operation of NCN and Operator such as registering, making relationship with Vault. **Example**: Initializing NCN: ```rust fn initialize_ncn(restaking_program_id: &Pubkey, rpc_client: &RpcClient, keypair: &Keypair) { let base = Keypair::new(); let ncn = Ncn::find_program_address(restaking_program_id, &base.pubkey()).0; let mut ix_builder = InitializeNcnBuilder::new(); let ix = ix_builder .config(Config::find_program_address(restaking_program_id).0) .ncn(ncn) .admin(keypair.pubkey()) .base(base.pubkey()) .instruction(); let blockhash = rpc_client.get_latest_blockhash().unwrap(); let tx = Transaction::new_signed_with_payer( &[ix], Some(&keypair.pubkey()), &[keypair, &base], blockhash, ); let result = rpc_client.send_and_confirm_transaction(&tx).unwrap(); println!("{:?}", result); } ``` Initializing Operator: ```rust fn initialize_operator(restaking_program_id: &Pubkey, rpc_client: &RpcClient, keypair: &Keypair) { let base = Keypair::new(); let operator = Operator::find_program_address(restaking_program_id, &base.pubkey()).0; let mut ix_builder = InitializeOperatorBuilder::new(); let ix = ix_builder .config(Config::find_program_address(restaking_program_id).0) .operator(operator) .admin(keypair.pubkey()) .base(base.pubkey()) .operator_fee_bps(1_000) .instruction(); let blockhash = rpc_client.get_latest_blockhash().unwrap(); let tx = Transaction::new_signed_with_payer( &[ix], Some(&keypair.pubkey()), &[keypair, &base], blockhash, ); let result = rpc_client.send_and_confirm_transaction(&tx).unwrap(); println!("{:?}", result); } ``` ## Jito Vault Client Through `jito-vault-client`, you can handle the operation of Vault such as minting VRT, withdrawing. **Example**: Initializing Vault: ```rust fn initialize_vault( vault_program_id: &Pubkey, rpc_client: &RpcClient, keypair: &Keypair, ) -> (Pubkey, Pubkey) { let base = Keypair::new(); let vault = Vault::find_program_address(vault_program_id, &base.pubkey()).0; let vrt_mint = Keypair::new(); let token_mint = pubkey!("HSkJ5428nHAvWsWA1AjeFuh79STnuUMvs4APoyAZXbkK"); let mut ix_builder = InitializeVaultBuilder::new(); let ix = ix_builder .config(Config::find_program_address(vault_program_id).0) .vault(vault) .vrt_mint(vrt_mint.pubkey()) .token_mint(token_mint) .admin(keypair.pubkey()) .base(base.pubkey()) .deposit_fee_bps(1_000) .withdrawal_fee_bps(1_000) .reward_fee_bps(1_000) .decimals(9) .instruction(); let blockhash = rpc_client.get_latest_blockhash().unwrap(); let tx = Transaction::new_signed_with_payer( &[ix], Some(&keypair.pubkey()), &[keypair, &base, &vrt_mint], blockhash, ); let result = rpc_client.send_and_confirm_transaction(&tx).unwrap(); println!("{:?}", result); (vault, vrt_mint.pubkey()) } ``` Create Token Metadata: ```rust fn create_token_metadata(rpc_client: &RpcClient, keypair: &Keypair, pubkeys: (Pubkey, Pubkey)) { let inline_mpl_token_metadata_id = pubkey!("metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s"); let metadata = Pubkey::find_program_address( &[ b"metadata", inline_mpl_token_metadata_id.as_ref(), pubkeys.1.as_ref(), ], &inline_mpl_token_metadata_id, ) .0; let mut ix_builder = CreateTokenMetadataBuilder::new(); let ix = ix_builder .vault(pubkeys.0) .admin(keypair.pubkey()) .vrt_mint(pubkeys.1) .payer(keypair.pubkey()) .metadata(metadata) .name(String::from("Hello")) .symbol(String::from("HLO")) .uri(String::from("https://...")) .instruction(); let blockhash = rpc_client.get_latest_blockhash().unwrap(); let tx = Transaction::new_signed_with_payer(&[ix], Some(&keypair.pubkey()), &[keypair], blockhash); let result = rpc_client.send_and_confirm_transaction(&tx).unwrap(); println!("{:?}", result); } ``` --- # TypeScript Client > Learn how to use the Jito Restaking TypeScript client. Install like below: ```bash yarn add @jito-foundation/restaking-sdk yarn add @jito-foundation/vault-sdk ``` ## Jito Restaking Client Through `@jito-foundation/restaking-sdk`, you can handle the operation of NCN and Operator such as registering, making relationship with Vault. **Example**: Initializing NCN: ```ts import { address, generateKeyPairSigner, getProgramDerivedAddress, getAddressEncoder, addSignersToTransactionMessage, createTransaction, createSignerFromKeyPair, createSolanaClient, createKeyPairFromBytes } from "gill"; import { getInitializeNcnInstruction } from "@jito-foundation/restaking-sdk"; import { resolve } from "node:path"; import { homedir } from "node:os"; import { readFileSync } from "node:fs"; const cluster = "devnet"; const restakingProgramPubkey = address("RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q"); const configPubkey = address("4vvKh3Ws4vGzgXRVdo8SdL4jePXDvCqKVmi21BCBGwvn"); const { rpc, sendAndConfirmTransaction } = createSolanaClient({ urlOrMoniker: cluster, }); const keypairFilePath = "~/.config/solana/id.json"; const resolvedKeypairPath = resolve(keypairFilePath.replace("~", homedir())); const keypair = await createKeyPairFromBytes( Uint8Array.from(JSON.parse(readFileSync(resolvedKeypairPath, "utf8"))), ); const adminKeypair = await createSignerFromKeyPair(keypair); const baseKeypair = await generateKeyPairSigner(); const addressEncoder = getAddressEncoder(); const [ncnPubkey, bumpSeed] = await getProgramDerivedAddress({ programAddress: restakingProgramPubkey, seeds: [ Buffer.from("ncn"), addressEncoder.encode(baseKeypair.address) ] }); const input = { config: configPubkey, ncn: ncnPubkey, admin: adminKeypair, base: baseKeypair, }; const instruction = getInitializeNcnInstruction(input); const { value: latestBlockhash } = await rpc.getLatestBlockhash().send(); const transaction = createTransaction({ feePayer: adminKeypair, instructions: [instruction], latestBlockhash, version: "legacy" }); const signedTransaction = addSignersToTransactionMessage([adminKeypair, baseKeypair], transaction); try { const signature = await sendAndConfirmTransaction(signedTransaction); console.log("Transaction confirmed!", signature); } catch (err) { console.error("Unable to send and confirm the transaction"); console.error(err); } ``` Initializing Operator: ```ts import { address, generateKeyPairSigner, getProgramDerivedAddress, getAddressEncoder, addSignersToTransactionMessage, createTransaction, createSignerFromKeyPair, createSolanaClient, createKeyPairFromBytes } from "gill"; import { getInitializeNcnInstruction, getInitializeOperatorInstruction, InitializeOperatorInput } from "@jito-foundation/restaking-sdk"; import { resolve } from "node:path"; import { homedir } from "node:os"; import { readFileSync } from "node:fs"; const cluster = "devnet"; const restakingProgramPubkey = address("RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q"); const configPubkey = address("4vvKh3Ws4vGzgXRVdo8SdL4jePXDvCqKVmi21BCBGwvn"); const { rpc, sendAndConfirmTransaction } = createSolanaClient({ urlOrMoniker: cluster, }); const keypairFilePath = "~/.config/solana/id.json"; const resolvedKeypairPath = resolve(keypairFilePath.replace("~", homedir())); const keypair = await createKeyPairFromBytes( Uint8Array.from(JSON.parse(readFileSync(resolvedKeypairPath, "utf8"))), ); const adminKeypair = await createSignerFromKeyPair(keypair); const baseKeypair = await generateKeyPairSigner(); const addressEncoder = getAddressEncoder(); const [operatorPubkey, bumpSeed] = await getProgramDerivedAddress({ programAddress: restakingProgramPubkey, seeds: [ Buffer.from("operator"), addressEncoder.encode(baseKeypair.address) ] }); const input: InitializeOperatorInput = { config: configPubkey, operator: operatorPubkey, admin: adminKeypair, base: baseKeypair, operatorFeeBps: 1000, }; const instruction = getInitializeOperatorInstruction(input); const { value: latestBlockhash } = await rpc.getLatestBlockhash().send(); const transaction = createTransaction({ feePayer: adminKeypair, instructions: [instruction], latestBlockhash, version: "legacy" }); const signedTransaction = addSignersToTransactionMessage([adminKeypair, baseKeypair], transaction); try { const signature = await sendAndConfirmTransaction(signedTransaction); console.log("Transaction confirmed!", signature); } catch (err) { console.error("Unable to send and confirm the transaction"); console.error(err); } ``` ## Jito Vault Client Through `@jito-foundation/vault-sdk`, you can handle the operation of Vault such as minting VRT, withdrawing. **Example**: Initializing Vault: ```ts import { address, generateKeyPairSigner, getProgramDerivedAddress, getAddressEncoder, addSignersToTransactionMessage, createTransaction, createSignerFromKeyPair, createSolanaClient, createKeyPairFromBytes } from "gill"; import { resolve } from "node:path"; import { homedir } from "node:os"; import { readFileSync } from "node:fs"; import { getInitializeVaultInstruction, InitializeVaultInput } from "@jito-foundation/vault-sdk"; import { CreateAssociatedTokenIdempotentInput, getAssociatedTokenAccountAddress, getCreateAssociatedTokenIdempotentInstruction } from "gill/programs/token"; const cluster = "devnet"; const vaultProgramPubkey = address("3bw2Y3np6zzckFMxcwmk8X8GALS8apHsQX1NXz8ifNbG"); const { rpc, sendAndConfirmTransaction } = createSolanaClient({ urlOrMoniker: cluster, }); const keypairFilePath = "~/.config/solana/id.json"; const resolvedKeypairPath = resolve(keypairFilePath.replace("~", homedir())); const keypair = await createKeyPairFromBytes( Uint8Array.from(JSON.parse(readFileSync(resolvedKeypairPath, "utf8"))), ); const adminKeypair = await createSignerFromKeyPair(keypair); console.log("Admin: ", adminKeypair.address); const baseKeypair = await generateKeyPairSigner(); console.log("Base: ", baseKeypair.address); const vrtMintKeypair = await generateKeyPairSigner(); console.log("VRT Mint Keypair Address: ", vrtMintKeypair.address); const stMintPubkey = address("2oVqm2u7e2M6NQX8nk6drCqFHe7fi6qpkuqpmZh5ssiJ"); const addressEncoder = getAddressEncoder(); const [configPubkey] = await getProgramDerivedAddress({ programAddress: vaultProgramPubkey, seeds: [ Buffer.from("config"), ] }); const [vaultPubkey] = await getProgramDerivedAddress({ programAddress: vaultProgramPubkey, seeds: [ Buffer.from("vault"), addressEncoder.encode(baseKeypair.address) ] }); const adminStTokenAccount = await getAssociatedTokenAccountAddress(stMintPubkey, adminKeypair); const vaultStTokenAccount = await getAssociatedTokenAccountAddress(stMintPubkey, vaultPubkey); const [burnVaultPubkey] = await getProgramDerivedAddress({ programAddress: vaultProgramPubkey, seeds: [ Buffer.from("burn_vault"), addressEncoder.encode(baseKeypair.address), ] }); const burnVaultVrtTokenAccount = await getAssociatedTokenAccountAddress(vrtMintKeypair.address, burnVaultPubkey); const input: InitializeVaultInput = { config: configPubkey, vault: vaultPubkey, vrtMint: vrtMintKeypair, stMint: stMintPubkey, adminStTokenAccount, vaultStTokenAccount, burnVault: burnVaultPubkey, burnVaultVrtTokenAccount, admin: adminKeypair, base: baseKeypair, associatedTokenProgram: address("ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL"), depositFeeBps: 1000, withdrawalFeeBps: 1000, rewardFeeBps: 1000, decimals: 9, initializeTokenAmount: 1000, }; const instruction = getInitializeVaultInstruction(input, {programAddress: vaultProgramPubkey}); const adminAssociatedTokenInput: CreateAssociatedTokenIdempotentInput = { mint: stMintPubkey, owner: adminKeypair.address, payer: adminKeypair, ata: adminStTokenAccount, tokenProgram: address("TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA") }; const admin_st_token_account_ix = getCreateAssociatedTokenIdempotentInstruction(adminAssociatedTokenInput); const vaultAssociatedTokenInput: CreateAssociatedTokenIdempotentInput = { mint: stMintPubkey, owner: vaultPubkey, payer: adminKeypair, ata: vaultStTokenAccount, tokenProgram: address("TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA") }; const vault_st_token_account_ix = getCreateAssociatedTokenIdempotentInstruction(vaultAssociatedTokenInput); const { value: latestBlockhash } = await rpc.getLatestBlockhash().send(); const transaction = createTransaction({ feePayer: adminKeypair, instructions: [admin_st_token_account_ix, vault_st_token_account_ix, instruction], latestBlockhash, version: "legacy" }); const signedTransaction = addSignersToTransactionMessage([adminKeypair, baseKeypair, vrtMintKeypair], transaction); try { const signature = await sendAndConfirmTransaction(signedTransaction); console.log("Transaction confirmed!", signature); } catch (err) { console.error("Unable to send and confirm the transaction"); console.error(err); } ```