NCN Cookbook
  • Jito Restaking

    • Jito Restaking Repository
    • Jito Restaking Documentation
    • Jito Restaking CLI
  • Jito Restaking

    • Jito Restaking Repository
    • Jito Restaking Documentation
    • Jito Restaking CLI
  • Introduction

    • Intro to Jito Restaking
    • NCN Overview
  • Core Concepts

    • Overview
    • NCN
    • Operator
    • Vault
  • Getting Started

    • Installation
    • Rust Client
    • TypeScript Client
    • Python Client
  • Integrating with Jito Restaking

    • Restaking Program
    • Vault Program
  • Building NCN

    • NCN Design
    • Pricing
    • Snapshot
    • Core Logic
    • Rewards Payment
  • References

    • Overview of Real-World Projects
    • Jito Tip Router Program
  • Developer Resources

    • Learning & Core Resources for Jito Restaking

Jito Tip Router Program

Overview

Current Process

  • Each validator has a unique tip distribution account, owned by the Jito Tip Distribution Program, where SOL is collected for a given epoch.
  • At the end of the epoch, an off-chain process takes place which produces a merkle tree and merkle root for each validator’s tip distribution account.
    • Validators can run this process themselves or delegate it to another party.
    • The merkle tree is intended to distribute any SOL in the account to the validator based on their MEV commission rate. Remaining funds are sent to stakers’ stake accounts pro-rata.
  • After the merkle root has been uploaded, merkle proofs are uploaded on-chain and the program will transfer SOL from the tip distribution account to the validator’s vote account and stake accounts.

Problem

  • Merkle root upload authority is permissioned with opt-in from each Jito-Solana validator. This mechanism creates a single point of potential failure with adverse impacts on network stakeholders and lacks transparency on the calculation.

Solution

The TipRouter NCN will leverage Jito (Re)staking to empower a set of node operators to come to consensus on the correct merkle root for tip distribution.

The mechanism of the TipRouter NCN is detailed below:

  • Validators can delegate the merkle root upload authority to a program derived address owned by the NCN, giving it permission to upload merkle roots.
  • After the epoch rollover, node operators will compute a 'meta merkle root' — a merkle root derived from a new merkle tree containing all validator merkle trees — and upload it on-chain. This change reduces the number of votes required, as operators now vote on the meta merkle root instead of casting individual votes for each validator.

Tips

Inside of Stake Meta:

  • validator_vote_account: The account representing the validator's voting authority.
  • validator_node_pubkey: The public key of the validator node.
  • maybe_tip_distribution_meta: Metadata related to tip distribution, if applicable.
    • merkle_root_upload_authority: The authority responsible for uploading the merkle root.
    • tip_distribution_pubkey: The public key owned by the Jito Tip Distribution Program.
    • total_tips: The total amount of tips in the TipDistributionAccount
    • validator_fee_bps: The validator's cut of tips from TipDistributionAccount, calculated from the on-chain commission fee bps.
  • delegations: Delegations to this validator.
    • stake_account_pubkey: The public key of the stake account.
    • staker_pubkey: The public key of the staker.
    • withdrawer_pubkey: The public key authorized to withdraw from the stake account.
    • lamports_delegated: Lamports delegated by the stake account
  • total_delegated: The total amount of delegations to the validator.
  • commission: The validator's delegation commission rate as a percentage between 0-100.
  • After each vote, consensus of node operators will be checked. After ⅔ of stake agrees on a merkle root for a given validator, a cross program invocation will take place to upload the merkle root to the validator’s tip distribution account.
  • Operators can change their vote until consensus is reached, then they can not change their vote. Once consensus is reached, any operators who have not voted have a fixed window of slots to submit their vote in order to be eligible for rewards.

NCN Program

Following the NCN design section, Jito Tip Router consists of:

  • Pricing
  • Snapshot
  • Core Logic
  • Reward Payment

Pricing

Permissionless Cranker:

Prepare several accounts like TrackedMints and WeightTable.

  • Initialize TrackedMints account
  • Register Mint
  • Initialize WeightTable account

NCN Admin:

NCN admin update weight of supported token on Tip Router NCN.

  • Update WeightTable account

Snapshots (Operator + Vault)

Take snapshots of Operator and Vault per epoch.

Permissionless Cranker:

Aggregate all information of operators and vaults associated with NCN

  • Initialize EpochSnapshot account
  • Initiazize OperatorSnapshot account

Core Logic (Consensus)

Permissionless Cranker:

Prepare Ballot Box, all votes would be collected here.

  • Initialize Ballot Box

After consensus reached with more than 2/3, cranker can upload the merkle tree of each validator.

  • Set Merkle Root

Operator:

Each operator calculate the merkle tree to produce merkle root then cast vote with produced merkle root.

  • Cast Vote

Reward Payment

IN PROGRESS

References

  • JIP-8: Adopt TipRouter NCN (Protocol Development)
  • Jito Tip Router Repo
Last Updated:
Contributors: Aoi Kurokawa
Prev
Overview of Real-World Projects