Jito NCN and VRT mechanics: building Node Consensus Networks on Jito restaking

The restaking overview explains the pitch: stake SOL once, earn Solana staking yield plus extra yield from opt-in services. This article is for the operator and protocol side — the teams building those services, registering as operators, and trying to understand what "slashable restaked SOL" actually means in code.

Jito's restaking system introduces two primitives that underpin everything: Node Consensus Networks (NCNs) — the opt-in services themselves — and Vault Receipt Tokens (VRTs) — the tokenised claim on restaked assets. Neither concept maps cleanly to existing Solana patterns, so they are worth understanding from the account up.

The three-actor model

Jito restaking separates concerns across three roles. Every NCN involves all three.

• Stakers deposit SOL or LSTs (jitoSOL, mSOL, bSOL, etc.) into a Jito vault. They receive VRT tokens back representing their share. They earn base staking yield plus NCN fee distributions. Their assets are at risk of slashing if an operator they are delegated to misbehaves.
• Operators run the off-chain software for one or more NCNs. They register on-chain, opt into specific NCNs, receive delegated restaked SOL as economic backing, and earn a cut of NCN fees. They are the slashable party — bad behaviour costs them delegated stake.
• NCN developers deploy the on-chain program that defines what the service does, what counts as misbehaviour, and how rewards are distributed. They register the NCN, set slashing parameters, and maintain the slashing oracle.

The key insight is that trust flows from stakers → operators → NCN. Stakers choose which vaults and therefore which operators to back. Operators choose which NCNs to participate in. NCN developers attract operators by offering competitive fee splits and realistic slashing conditions.

What is an NCN?

A Node Consensus Network is any protocol that needs a decentralised set of operators with real economic stake behind their commitments. The restaking layer provides the stake; the NCN developer provides the consensus logic. Canonical examples:

• Oracle networks — operators attest to off-chain price data. Incorrect attestations are slashable.
• Bridge relayers — operators sign cross-chain messages. Double-signing or signing invalid messages is slashable.
• Sequencers — operators order transactions for an L2. Censorship or equivocation is slashable.
• Task schedulers / keepers — operators execute time-sensitive on-chain actions. Failure to act (or acting incorrectly) is slashable.
• MEV / tip router — Jito's own tip router NCN routes validator tips through the restaking layer, distributing them to stakers.

What distinguishes an NCN from a regular protocol is the slashable stake. Anyone can run a keeper bot. Running one as an NCN operator means you have skin in the game — operators who misbehave lose delegated SOL, giving stakers a reason to care about operator quality.

Vault Receipt Tokens (VRTs)

When you deposit SOL into a Jito vault, you do not get jitoSOL back. You get a VRT — a vault-specific SPL token whose supply represents total shares in that vault.

VRT price is determined by the vault's total assets divided by total VRT supply:

VRT price = vault.tokens_deposited / vrt_mint.supply

On deposit:
  vrt_to_mint = deposit_amount * vrt_mint.supply / vault.tokens_deposited

On withdrawal:
  sol_to_return = vrt_amount * vault.tokens_deposited / vrt_mint.supply

Price increases monotonically as staking rewards accrue (assuming no slashing). A slashing event reduces vault.tokens_deposited without burning VRTs, so each VRT becomes worth less SOL — that is the mechanism by which stakers bear slashing risk.

VRTs are composable SPL tokens. They can be transferred, used as collateral in lending protocols, or listed on DEXes, while the underlying SOL continues staking. This is the yield-bearing token primitive that makes restaking interesting for DeFi.

On-chain account layout

The Jito restaking program (jito-foundation/restaking) uses a small set of PDAs to track relationships between actors. The critical ones:

// The NCN itself — registered by the NCN developer
pub struct Ncn {
    pub admin: Pubkey,          // who can update NCN config
    pub operator_admin: Pubkey, // who approves operator registrations
    pub vault_admin: Pubkey,    // who approves vault delegations
    pub slasher_admin: Pubkey,  // who can add slashers
    pub delegate_admin: Pubkey,
    pub metadata: Pubkey,       // optional metadata account
    pub index: u64,             // global NCN index
    pub operator_count: u64,
    pub vault_count: u64,
    pub slasher_count: u64,
    pub bump: u8,
}

// Ticket created when an operator opts into an NCN
pub struct OperatorNcnTicket {
    pub operator: Pubkey,
    pub ncn: Pubkey,
    pub index: u64,
    pub state: SlotToggle,  // warming up / active / cooling down
    pub bump: u8,
}

// Ticket created when an NCN approves an operator
pub struct NcnOperatorState {
    pub ncn: Pubkey,
    pub operator: Pubkey,
    pub ncn_opt_in_state: SlotToggle,
    pub operator_opt_in_state: SlotToggle,
    pub bump: u8,
}

// Ticket linking a vault to an NCN
pub struct VaultNcnTicket {
    pub vault: Pubkey,
    pub ncn: Pubkey,
    pub slasher: Pubkey,
    pub index: u64,
    pub state: SlotToggle,
    pub bump: u8,
}

// Tracks how much of a vault's assets are delegated to an operator
pub struct VaultOperatorDelegation {
    pub vault: Pubkey,
    pub operator: Pubkey,
    pub delegation_state: DelegationState,
    pub last_update_slot: u64,
    pub bump: u8,
}

The SlotToggle type is a warm-up / cool-down mechanism: opt-in and opt-out are not instant. There is a configurable epoch delay before a new operator becomes active in an NCN, preventing stake from materialising and dematerialising within the same epoch.

NCN lifecycle: from registration to rewards

Step 1 — register the NCN

The NCN developer calls initialize_ncn on the restaking program. This creates the NCN account (a PDA) and sets the admin keypairs. At this point no operators exist and no stake is delegated.

import { Connection, Keypair, PublicKey } from "@solana/web3.js";
import { RestakingClient } from "@jito-foundation/restaking-sdk";

const connection = new Connection("https://api.mainnet-beta.solana.com");
const admin = Keypair.fromSecretKey(/* your keypair */);
const client = new RestakingClient(connection, admin);

// Register a new NCN
const { ncnPubkey, tx } = await client.initializeNcn({
  admin: admin.publicKey,
  operatorAdmin: admin.publicKey,  // can be a separate keypair
  vaultAdmin: admin.publicKey,
  slasherAdmin: admin.publicKey,
});

await client.sendAndConfirm(tx);
console.log("NCN registered:", ncnPubkey.toBase58());

Step 2 — operator registration

Operators first register globally (one initialize_operator call, creates their Operator account). Then they opt into your specific NCN with operator_warmup_ncn. The NCN side confirms with ncn_warmup_operator. Both sides must opt in — neither can be forced.

// Operator side: opt into the NCN
await client.operatorWarmupNcn({
  operator: operatorKeypair.publicKey,
  ncn: ncnPubkey,
});

// NCN admin side: approve the operator
await client.ncnWarmupOperator({
  ncn: ncnPubkey,
  operator: operatorKeypair.publicKey,
  ncnAdmin: admin,
});

// After one epoch, NcnOperatorState.operator_opt_in_state becomes Active
// The operator is now live in the NCN and eligible for delegations

Step 3 — vault delegation

Vaults (controlled by vault admins or configured with auto-delegation) delegate restaked assets to operators. The vault admin calls add_delegation, specifying how much of the vault's assets back each operator. Delegations are expressed as a proportion of the vault's total deposits.

For the NCN to see a vault's stake, there must also be a VaultNcnTicket — the vault opts into the NCN, and the NCN approves the vault (same two-sided handshake as operator registration). Only then does the vault's delegated stake count toward the operator's weight in the NCN.

Step 4 — slashing conditions

Slashing is where NCN design gets hard. The restaking program itself does not know what your NCN's rules are — that is your responsibility. You register a slasher: a program (or a privileged keypair for simpler designs) that is authorised to call slash on the restaking program.

A slash call specifies:

• The NCN being slashed for
• The operator being slashed
• The vault to slash (the specific delegation to reduce)
• The amount to slash (in lamports / token units)

The restaking program reduces VaultOperatorDelegation.delegation_state and vault.tokens_deposited, which depresses the VRT price proportionally. Slashed funds can be directed to a penalty treasury or burned depending on your NCN config.

The hard part is the slashing oracle: you need a program or committee that can make a credible, on-chain-verifiable determination that an operator misbehaved. For oracle networks this might be comparing signed attestations. For sequencers it might be fraud proofs. The restaking layer takes no position — it just enforces the slash once called.

The rewards flow

NCN fee distribution is not handled by the restaking program — it is handled by the NCN program itself. The typical pattern:

1. Service users pay fees into the NCN program (or fees are captured from the service the NCN provides — e.g. MEV tips, oracle fees).
2. The NCN program distributes a cut to operators (e.g. 10% of fees), proportional to their active delegated stake weight.
3. Operators optionally pass through a portion to their stakers — but this is at operator discretion unless your NCN program enforces it.
4. The vault accumulates rewards which raise the VRT price, benefiting all VRT holders proportionally.

Jito's tip router NCN is the reference implementation for this flow: MEV tips from validators flow through the NCN, are split between the Jito DAO, operators, and stakers, and the distribution is enforced on-chain. The jito-tip-router repo is worth reading as a production NCN example.

Building an NCN: what you actually need

In rough order of complexity:

1. The NCN program

Write an Anchor (or native Rust) program that implements your service logic. This is separate from the restaking program — you are building on top of it, not modifying it. Your program will hold fee accounts, implement your consensus logic, and contain the slasher instruction that calls into the restaking program CPI.

use anchor_lang::prelude::*;
use jito_restaking_sdk::cpi as restaking_cpi;

#[program]
pub mod my_ncn {
    use super::*;

    // Called by your slashing oracle when an operator misbehaves
    pub fn slash_operator(
        ctx: Context<SlashOperator>,
        amount: u64,
    ) -> Result<()> {
        // Verify the slash condition (your oracle logic)
        require!(
            ctx.accounts.slash_proof.is_valid(),
            MyNcnError::InvalidSlashProof
        );

        // CPI into the Jito restaking program
        restaking_cpi::slash(
            CpiContext::new_with_signer(
                ctx.accounts.restaking_program.to_account_info(),
                restaking_cpi::Slash {
                    config: ctx.accounts.restaking_config.to_account_info(),
                    ncn: ctx.accounts.ncn.to_account_info(),
                    operator: ctx.accounts.operator.to_account_info(),
                    vault: ctx.accounts.vault.to_account_info(),
                    ncn_operator_state: ctx.accounts.ncn_operator_state.to_account_info(),
                    vault_ncn_ticket: ctx.accounts.vault_ncn_ticket.to_account_info(),
                    vault_operator_delegation: ctx.accounts.vault_operator_delegation.to_account_info(),
                    slasher_admin: ctx.accounts.slasher_admin.to_account_info(),
                    vault_slasher_ticket: ctx.accounts.vault_slasher_ticket.to_account_info(),
                    ncn_vault_slasher_ticket: ctx.accounts.ncn_vault_slasher_ticket.to_account_info(),
                    vault_program: ctx.accounts.vault_program.to_account_info(),
                },
                &[/* slasher signer seeds */],
            ),
            amount,
        )?;

        emit!(OperatorSlashed {
            operator: ctx.accounts.operator.key(),
            amount,
            slot: Clock::get()?.slot,
        });

        Ok(())
    }
}

2. Admin keypairs and multisig

The NCN admin roles (operator admin, vault admin, slasher admin) should be a Squads multisig in production — not a hot wallet. Operator and vault approvals are gated by these keys, so compromise of the admin means an attacker could whitelist malicious operators or vaults.

3. Operator onboarding docs

Operators will want to know: what software to run, what hardware specs are required, what the slashing conditions are (precisely — not vaguely), and what the expected fee split is. No operator will risk delegated SOL on ambiguous slashing terms.

4. The slashing oracle — the hard part

Your slashing oracle needs to be trustworthy. Options in ascending order of decentralisation:

• Centralised oracle: a committee keypair (or multisig) calls slash after off-chain adjudication. Simple, fast, but requires trusting the committee. Fine for v1.
• On-chain fraud proofs: operators submit signed attestations on-chain, a verifier program checks for equivocation or invalid data, and slash is callable by anyone with proof. Harder to build but fully trustless.
• ZK proofs: the slash condition is expressed as a ZK circuit. Anyone can generate a proof of misbehaviour and call slash. The gold standard, rarely done in practice for v1.

Reading delegation state from a client

To query how much stake an operator has across all vaults for your NCN:

import { Connection, PublicKey } from "@solana/web3.js";
import {
  RestakingClient,
  VaultOperatorDelegation,
  findVaultOperatorDelegationAddress,
} from "@jito-foundation/restaking-sdk";

const connection = new Connection("https://api.mainnet-beta.solana.com");
const ncnPubkey = new PublicKey("YOUR_NCN_ADDRESS");
const operatorPubkey = new PublicKey("OPERATOR_ADDRESS");

// Fetch all vaults that have opted into this NCN
const client = new RestakingClient(connection);
const vaultNcnTickets = await client.getVaultNcnTicketsByNcn(ncnPubkey);

let totalDelegated = 0n;

for (const ticket of vaultNcnTickets) {
  if (!ticket.account.state.isActive()) continue;

  const [delegationPda] = findVaultOperatorDelegationAddress(
    ticket.account.vault,
    operatorPubkey,
    client.programId
  );

  const delegation = await VaultOperatorDelegation.fetch(
    connection,
    delegationPda
  );

  if (delegation) {
    totalDelegated += delegation.delegationState.stakedAmount;
  }
}

console.log("Total delegated stake for operator:", totalDelegated.toString(), "lamports");

NCNs in production

As of mid-2026, the most visible NCN is Jito's own tip router. It routes MEV tips from the block engine through the restaking layer, distributing them proportionally to stakers in participating vaults. The tip router NCN was the proving ground for the restaking architecture — studying its source is the fastest path to understanding how a production NCN is built.

Beyond Jito's internal use, oracle networks and bridge operators are the next cohort. The incentive is straightforward: if you are already running an oracle or relayer, adding restaked-SOL backing makes your service more credible to protocols that want slashable commitments, and gives you access to Jito's staker distribution for fee sharing.

The jito-restaking-program repo

The canonical source is github.com/jito-foundation/restaking. Key files to study:

• restaking_core/src/ncn.rs — the NCN account definition and all its methods
• restaking_core/src/operator_ncn_ticket.rs and ncn_operator_state.rs — the two-sided opt-in accounts
• restaking_program/src/processor/ — every instruction handler; reading these is faster than reading docs
• vault_core/src/vault.rs — the vault account with VRT minting/burning logic
• clients/rust/ — the generated Rust client you CPI from your NCN program

The jito-tip-router repo shows an NCN program in production — specifically how to collect fees, distribute them to operators weighted by delegation, and handle epoch snapshots of stake weight.

Summary

Jito restaking is not a product you integrate — it is an infrastructure primitive you build on top of. The restaking program handles stake accounting, VRT minting, and enforcing slashes. You build the NCN program that defines what your service does and what merits a slash.

The minimum viable NCN is: register the NCN on-chain, onboard a few operators with a multisig-gated slasher, and distribute fees from your service to operators proportional to their delegation. The hard work is making slashing conditions precise enough that operators will accept them and stakers will trust them.

For the staker side and a broader overview of the restaking landscape, see Restaking on Solana. For the MEV context that motivates much of this infrastructure, see Jito Block Engine demystified.