Jito Restaking and NCNs: How Operator Access Actually Works

Executive summary

Two programs and what they store

Jito Restaking is built from two onchain programs with a clean separation of duties. The restaking program is a registry: it records NCNs, operators, and the relationships between NCNs, operators, and vaults. The official documentation is explicit that it stores no funds. The vault program is where value actually sits — it holds deposited SPL tokens and mints vault receipt tokens against them.

That split matters when reading any restaking dashboard. A relationship existing in the registry says nothing about whether stake has moved. The two questions are answered by two different programs, and most confusion in this ecosystem comes from conflating them.

The protocol separates offchain execution from onchain coordination: computation, validation, and data collection happen offchain, while delegation, voting, rewards, and penalties are tracked onchain.

The four participants

Four roles interact, and each has a defined boundary. The column that usually gets skipped is the last one: what each participant cannot do. Those limits are what make the access question answerable.

The opt-in handshake and who starts it

The official documentation states the rule plainly: NCNs register onchain and approve operators and vaults, operators opt in to NCNs and must be accepted, and vaults opt in to NCNs and delegate to approved operators. No party is auto-connected.

One detail is easy to miss and changes the practical picture. The relationship between an NCN and an operator lives in anNcnOperatorStateaccount, and the documentation says the NCN initializes that account. Once it exists, both sides can warm up and cool down their own side of it. An operator therefore cannot unilaterally create a pending application onchain. Until an NCN admin acts, there is no record to opt into.

Registration is permissionless. The relationship is not, and the operator is not the party that can start it.

Warmup, cooldown, and what active means

Connections do not activate on the instruction that creates them. The documentation describes a warm-up period lasting one full epoch, not counting the current partial epoch, and stake becomes active only once all three components have initiated and warmed up their connections. Withdrawals run the other way through a cooldown lasting one full NCN-defined epoch.

Onchain, each side of a relationship is a slot toggle holding aslot_addedand aslot_removedvalue. A side counts as opted in when its added slot is the more recent of the two. This is why a relationship account existing is not the same as a relationship being live, and why the counts in the next section separate the two.

Three layers of access

Discussions about “joining restaking” usually collapse several distinct gates into one question. Separating them makes the situation legible, and each layer can be measured independently.

The layers are cumulative. Clearing the first costs a transaction; clearing the last depends on decisions made by NCN admins and vault admins that are not published as criteria.

What exists on mainnet today

The following counts come from querying the two programs directly and, separately, from Jito’s own published stats page on the same day. Two of the three headline figures agree exactly, which is a useful check on both methods. The third does not, and the gap is informative rather than a defect.

Breaking the 54 relationship accounts down by state gives the clearest single view of where applications stall. 40 were mutually active. 6 had the NCN side opted in while the operator side had cooled down. 5 had the operator side opted in while the NCN side had not, or no longer, opted in. 3 had both sides cooled down. Those 5 are the visible shape of the approval gate.

Concentration is high. TipRouter and Switchboard together accounted for 22 of the 40 mutually active relationships. Six of the 16 registered NCNs had no mutually active operator at all. Among operators, the highest number of NCN relationships held by any single account was two.

Reported ecosystem totals on the same day: $14.1M TVL in USD, 39,416 depositors, and 1.37% of JitoSOL restaked. These are Jito’s published figures, not independent valuations.

Named NCNs and their status

NCN accounts do not carry names onchain. The mapping below comes from the official NCN directory, which links three of its entries to their onchain addresses; the active operator counts are measured from the relationship accounts at those addresses. The four remaining entries are published as forthcoming and have no address on that page.

TipRouter is the reference implementation and the largest by operator count. It exists to decentralize MEV tip distribution, with a documented allocation of 3% of tips to the Jito DAO treasury and NCN participants. Its operator client and permissionless keeper are published, which makes it the most practical starting point for understanding what running an NCN workload involves.

Nine additional NCN accounts exist onchain beyond the seven listed publicly. They are not attributed here because no first-party source names them, and guessing at ownership from address patterns is not evidence.

The operator set

The official operator directory lists 22 operators. The pattern in the join dates is the most informative column on the page: 21 of the 22 show Jan 31, 2025, and one shows Nov 4, 2025. That is the signature of a curated founding cohort with a single subsequent addition, not a rolling intake.

The delegation column is equally direct. Six operators showed any delegation at all; the remaining sixteen showed none, including several with seven or eight vault connections. Being listed, being connected, and being delegated to are three different states.

Spot checks against the onchain registry matched the directory exactly for the operators that publish an address — vault counts of eight, seven, and four for three separate operators lined up with their onchain vault counters. Nine of the 22 entries link to a placeholder rather than an address and showed zero vault connections.

Vaults and restaked value

Ten vaults are surfaced in the official interface out of 35 registered onchain. Value is concentrated in the top two: the largest vault alone accounted for a majority of reported TVL, and the top three for the large majority of it. Several listed vaults held negligible or zero deposits.

TVL figures are as displayed by the official interface on the status-checked date and are denominated in USD at that moment’s pricing. They are not independently verified, and token decimals for the less common underlying mints were not confirmed, so no derived per-token totals are published here.

Operator economics and fees

Each operator account carries anoperator_fee_bpsfield expressed in basis points. Across the 75 registered operator accounts the median was 500 basis points, with values ranging from 0 to 2000. Rewards are described as stake-weighted and subject to each NCN’s own distribution logic, so the fee field sets a rate rather than a return.

Two structural points shape the economics. Operators receive delegated stake but hold no direct control over it. And an operator can serve multiple NCNs simultaneously, which is the capital-efficiency argument for the whole model — though in practice no measured operator held more than two NCN relationships.

No revenue, yield, or profitability estimate is published here. Operator income depends on NCN-specific reward logic, delegated stake, and running costs that are not visible onchain.

Slashing status and audits

Slashing is central to how restaking is usually described, so its current status deserves stating plainly. The official documentation describes slashing enforcement as in development and states that the slashing program is not currently live. The account structures for slasher roles and slasher tickets exist, and NCNs can define slashing conditions, but the enforcement path is documented as forthcoming.

This cuts both ways. It lowers the immediate downside for an operator today, and it means any risk model built on slashing-adjusted returns is modelling something that is not yet enforced. Both readings should be revisited when the program ships.

The programs themselves have published audit reports in the repository from Ottersec, Certora (two reports), and Offside, dated across late 2024. Audit coverage is a statement about reviewed code at a point in time, not a guarantee of safety, and it does not extend to any individual NCN’s own program.

A common category error

A recurring mistake in restaking discussions is treating vault brands as networks. Names such as kySOL, kyJTO, fragSOL, fragJTO, ezSOL, ezJTO, bzSOL, rstSOL, dmSOL, and LovePIPE are vault receipt tokens issued by vaults. They are not NCNs, and opting into them is a different action with a different counterparty.

The distinction is practical, not pedantic. A vault decides which operators receive its stake. An NCN decides which operators are allowed to serve the network at all. An operator seeking work needs the NCN gate first; an operator seeking stake needs the vault decision second. Naming the wrong counterparty means approaching the wrong party.

How to reproduce these measurements

Every count in this article can be re-derived from a public RPC endpoint without an API key, an indexer, or a paid data provider. The method is to filter program accounts by size, because each account type in these programs has a fixed length that can be computed from the published struct definitions.

Querying the registry

# Count NCN accounts registered with the restaking program
curl -s https://api.mainnet-beta.solana.com \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getProgramAccounts",
    "params": [
      "RestkWeAVL8fRGgzhfeoqFhsqKRchg6aa1XrcH96z4Q",
      { "encoding": "base64", "filters": [{ "dataSize": 592 }] }
    ]
  }'

# Swap dataSize for 520 to list Operator accounts,
# or 440 to list NcnOperatorState relationship accounts.

Reading the relationship state

Field offsets are little-endian and derived from the generated client structs in the program repository. The opt-in test is the part worth getting right: a relationship account existing proves only that an NCN opened a record.

Operator account layout (520 bytes, little-endian)
  0    discriminator      u64
  8    base               Pubkey
  40   admin              Pubkey
  72   ncn_admin          Pubkey
  104  vault_admin        Pubkey
  136  delegate_admin     Pubkey
  168  metadata_admin     Pubkey
  200  voter              Pubkey
  232  index              u64
  240  ncn_count          u64
  248  vault_count        u64
  256  operator_fee_bps   u16

NcnOperatorState layout (440 bytes)
  0    discriminator      u64
  8    ncn                Pubkey
  40   operator           Pubkey
  72   index              u64
  80   ncn_opt_in_state   SlotToggle   (slot_added u64, slot_removed u64)
  128  operator_opt_in_state SlotToggle

A side is opted in when its slot_added is greater than its
slot_removed. A relationship is mutually active only when this
holds for both sides.

Public RPC endpoints rate-limit or disable getProgramAccounts inconsistently, and account layouts change between program versions. Re-derive the sizes from the current structs rather than trusting the table above indefinitely. For related verification workflows, see the Stake Pool Reviewer Kit and Validator Tools.

Risks and what this research does not claim

Sources and methodology

Sources are grouped by evidence type. Official documentation and the Apache-2.0 program repository carry the most weight for structural claims. The official interface is the only source used for entity names, status labels, and published totals. Onchain counts were measured independently and are reported alongside the official figures rather than replacing them.

Verify current state directly before reuse: Jito ecosystem stats, NCN directory, operator directory, and the protocol documentation.

Continue reading