What is Jito?

Learn what Jito is, how JitoSOL works on Solana, and how Jito combines liquid staking with MEV capture through its validator infrastructure.

Cube ExplainersMar 30, 2026
Summarize this blog post with:
What is Jito? hero image

Introduction

Jito is a Solana staking protocol built around two ideas that are usually discussed separately: liquid staking and MEV capture. Most staking products ask a simple question: how can users delegate tokens and keep them productive? Jito asks a harder one: if validators on Solana can earn not just base staking rewards but also extra value from transaction ordering, can that value be captured more systematically and shared with stakers?

That is the reason Jito stands out. At the user level, it offers JitoSOL, a liquid staking token representing staked SOL. At the infrastructure level, it is tied to Jito-Solana, Jito’s fork of the Solana validator client, which is explicitly described as an MEV-focused Solana client. The product is useful because it tries to combine three things that often pull in different directions: staking yield, on-chain liquidity, and better access to block-level revenue.

To understand Jito, it helps to start with the problem it is solving. Ordinary staking locks SOL and pays staking rewards, but locked SOL cannot be used elsewhere in DeFi. Ordinary liquid staking fixes that by issuing a transferable token against staked SOL, but it still leaves open the question of whether validators are earning all the value available to them. Jito’s answer is that some of that missing value sits in MEV, and that a staking product can be designed to route part of it back to users.

How does JitoSOL provide liquid staking for SOL?

OptionLiquidityYield sourcesYield accrualBest for
JitoSOLHigh transferableStaking + MEVPrice appreciationDeFi users and treasuries
Native stakingLockedStaking onlyStake rewardsPassive stakers
Standard liquid stakingHigh transferableStaking onlyPrice appreciationLiquidity seekers
Figure 453.1: JitoSOL vs native staking vs liquid staking

At the surface, Jito looks familiar to anyone who has seen liquid staking before. A user deposits SOL into the protocol and receives JitoSOL in return. That token is the user-facing representation of their position in a pooled set of staked SOL, and because it is transferable, it can circulate through wallets, trading venues, and DeFi applications instead of remaining locked in native stake accounts.

The useful mental model is this: JitoSOL is not meant to be a separate economic asset with its own independent purpose. It is a claim on staked SOL in a pool, and its value proposition comes from the rewards flowing into that pool. A third-party description of Jito Staked SOL captures the intended behavior clearly: it tracks SOL while accruing staking and MEV rewards, with yield reflected in the token’s price rather than through separate balance increases. That means a holder is typically looking for appreciation relative to SOL over time, not because JitoSOL is supposed to detach from SOL, but because it represents SOL plus accrued rewards.

This design is attractive to users who do not want to choose between staking and liquidity. A long-term SOL holder can remain exposed to Solana, continue earning staking-related return, and still use the liquid token elsewhere. That makes Jito naturally appealing to DeFi users, treasuries, and anyone trying to avoid the all-or-nothing tradeoff of native staking.

But if Jito were only a liquid staking token, it would be easier to describe and less distinctive. The more important part is where the extra yield is supposed to come from.

Why does Jito capture MEV and how does it boost staking yield?

The crucial idea behind Jito is that block production can generate value beyond ordinary staking rewards. In crypto this is usually discussed as MEV, short for maximal extractable value: the extra value available from deciding which transactions to include, in what order, and under what conditions.

On Solana, that value does not appear in the same way it does on every other chain, because the execution model is different. Still, the underlying economic fact remains: control over blockspace can be monetized. Jito’s approach, according to a security audit of its MEV validator system, is to modify validator software so that searchers can effectively bid for inclusion of transaction bundles. The point is not just to let validators capture more revenue. It is to create a more explicit market around that revenue and then connect it back to stakers.

An analogy helps here. You can think of an ordinary validator as a business that earns its standard service fee, while a Jito-enabled validator is trying to run a side auction for especially valuable requests. That analogy explains the revenue logic, but it fails in one important way: block production is not an ordinary business process. It is constrained by consensus, transaction validity, timing, and network-level fairness. If the auction mechanism is poorly designed, it can harm liveness or create incentives for spam and manipulation.

That tension is why Jito is both a staking protocol and an infrastructure project. The extra yield is not magic. It depends on software, routing, and market design working correctly under the rules of Solana.

How do Jito’s validator, relayer, and bundle systems work together?

ComponentRoleTrust / checksMain riskBenefit
RelayerForwards bundles to TPUOff-chain validationAuth spoofing / DoSFaster bundle submission
Block engineSelects and auctions bundlesExternal service (audit out‑of‑scope)Centralized source riskMarket for MEV bids
BundlesAtomic transaction packageValidator executes atomicallySpam via failing bundlesEnables multi-step arbitrage
Modified validatorProduces blocks, captures MEVRuns bundle/path checksSkipped votes, liveness issuesPasses MEV to stakers
Figure 453.2: Jito-Solana architecture components

The primary infrastructure component visible in the evidence is Jito-Solana, which Jito describes as its fork of the Solana validator. This matters because liquid staking protocols ultimately depend on where delegated stake is sent, and in Jito’s case the protocol is closely tied to validators running software designed to participate in MEV capture.

The audited architecture gives a clearer picture of the mechanism. In that design, a relayer sits in front of the modified validator and acts like the validator’s TPU-facing entry point, forwarding transactions onward and also communicating with a block engine. Searchers submit bundles, meaning groups of transactions that should be processed together. The validator software had been modified to process these bundles in a dedicated path, where if one transaction in a bundle fails, the full bundle is rolled back.

A concrete example makes the flow easier to see. Imagine a searcher sees an arbitrage opportunity that only works if several trades happen in sequence. Sending those trades one by one is risky, because another participant may intervene after the first step. With Jito’s bundle model, the searcher can submit the transactions as a package and bid for inclusion. The relayer forwards the package, the system evaluates it, and if the validator producing the block accepts the winning bundle, the sequence can execute atomically from the searcher’s perspective. The validator then captures the associated payment or tip for that block opportunity.

That mechanism is why Jito can plausibly offer more than baseline staking yield. If validators using Jito’s infrastructure earn more from block production, then a staking product delegating into that environment can potentially pass some of that value on to users through JitoSOL’s exchange rate versus SOL.

How do users deposit SOL and use JitoSOL in practice?

From a user’s perspective, the complexity above is mostly hidden. The practical action is simple: deposit SOL, receive JitoSOL, and then hold or use JitoSOL elsewhere. The reason this simplicity matters is that the protocol is designed for users who want outcomes, not validator operations. They do not need to run the MEV client, evaluate bundles, or interact with relayers. They need a tokenized staking position that can fit into normal Solana portfolio management.

That said, Jito is especially well-suited to users who understand that “yield” here has two inputs, not one. Part comes from ordinary Solana staking economics. Part is intended to come from MEV-related revenue captured by the validator and market infrastructure. A user who only wants the simplest possible staking setup may not care about that distinction. A user who is already active in Solana DeFi, by contrast, may find it central: the product tries to turn otherwise inaccessible validator-side revenue into something reflected in a liquid token they can hold and deploy.

What are the risks and trade-offs of Jito’s MEV-based staking?

AreaBenefitMain riskMitigation
Operational complexityAccess to extra MEV yieldSoftware bugs and ops burdenAudits and release controls
Incentive alignmentShare MEV with stakersSpam from failing bundlesEconomic penalties or fees
Governance curationCurated validator qualityCentralization and opaque bansDAO veto and appeals window
Availability & spamAtomic bundle executionDoS and liveness harmRelayer auth and penalties
Figure 453.3: Jito trade-offs: benefits, risks, mitigations

Jito’s strengths and its risks come from the same place. Because it reaches into validator behavior and transaction ordering, it inherits operational and incentive complexity that a plain stake pool would not.

The security audit illustrates this clearly. It found that some checks had initially been offloaded away from the validator in ways that could create correctness problems, including the risk of invalid transactions causing blocks not to be voted on. It also identified an incentive issue in bundle handling: if a failing bundle rolls back the associated bribe payment as well, then submitters may face too little cost for spamming bad bundles. These are not cosmetic issues. They show that once staking yield depends on an auction and bundle system, protocol design has to align technical validity and economic incentives very carefully.

There is also a governance dimension. Jito’s forum materials show that the protocol has built increasingly explicit mechanisms for deciding which validators should receive stake from the JitoSOL pool. StakeNet is described in governance materials as an on-chain program that cycles validators into and out of the Jito stake pool according to governed criteria. More recent proposals establish committee- and rule-based blacklisting for validators engaged in behaviors Jito considers harmful, including malicious MEV activity and, in a separate proposal, intentionally lagging block production.

This matters for users because delegation is not purely passive. Jito is not saying, “stake is distributed neutrally and forever.” It is saying, in effect, that the quality of the validator set affects the value and legitimacy of the product, so the pool may exclude validators that violate the protocol’s standards. That can be a feature for users who want a curated validator set aligned with Jito’s view of network health. It can also be a trade-off, because curation introduces governance power, judgment calls, committee design questions, and the possibility of false positives or opaque enforcement.

Who should use JitoSOL; intended users and use cases

The best way to understand who Jito is for is to ask what problem its design assumes you have. If your problem is simply, “I want to stake SOL in the most minimal way possible,” Jito may be more elaborate than necessary. If your problem is, “I want my SOL to remain liquid, I want staking exposure, and I want access to a product designed to capture more of Solana’s validator-side economics,” then Jito makes immediate sense.

That is why the protocol tends to appeal most to users already living inside Solana’s financial layer. They want an asset that can move through DeFi while still representing a yield-bearing staking position. They are also more likely to care that Jito’s product is built around a specific thesis: that MEV should not simply leak away or accrue only to a narrow set of operators, but can be organized into a market and shared through a staking wrapper.

Conclusion

Jito is best understood as a liquid staking protocol on Solana that tries to turn validator-side MEV into user-facing staking yield. The visible token is JitoSOL, but the deeper product is the machinery behind it: a modified validator client, bundle-based blockspace auctions, and a governed system for deciding which validators belong in the pool.

The short version to remember is this: Jito lets users hold a liquid claim on staked SOL while aiming to earn not just ordinary staking rewards, but also a share of MEV-related revenue. That promise is what makes it useful; and what makes its design more ambitious, and more complex, than a standard staking token.

Frequently Asked Questions

How does Jito capture MEV and pass that value to JitoSOL holders?
Jito captures MEV by running a modified Solana validator client (Jito‑Solana) plus a relayer and block‑engine that accept paid "bundles" from searchers; validators bid to include those bundles and capture tips/payments, and the protocol routes some of that block‑level revenue back to the pooled stake so JitoSOL accrues value relative to SOL. This flow (relayer → block engine → bundle path → validator) and the intent to share MEV with stakers is described in the article and reflected in the audited architecture notes.
Does holding JitoSOL carry more risk than ordinary staking?
Yes - compared with a plain stake pool, Jito adds operational and incentive complexity because it depends on modified validator behavior and an auction/bundle market; the article highlights risks to liveness and incentive alignment, and the security audit flagged specific correctness and spam‑incentive issues that increase protocol risk relative to simple staking. These trade‑offs are intrinsic to trying to monetize and share validator‑side MEV.
Is JitoSOL redeemable 1:1 for SOL at any time, or can its price diverge from SOL?
JitoSOL is a transferable claim on pooled staked SOL and is designed to reflect staking plus MEV yield through its exchange rate versus SOL rather than by increasing underlying balances; that means it tracks SOL plus accrued rewards but is not presented as an immutable 1:1 redeemable peg, and Jito has published a price‑stability analysis (PDF) whose substantive conclusions are not available from the evidence fetched here. In short, JitoSOL represents staked SOL with yield reflected in price, but deviations from SOL can occur and the project's detailed peg analysis is in a separate document.
Who is Jito intended for - when should I choose Jito over simple staking?
Jito is aimed at users who want both liquidity and staking exposure plus potential access to validator‑side economics, so it suits DeFi users, treasuries, and anyone who wants a liquid, yield-bearing SOL claim; by contrast, someone seeking the simplest possible native stake setup may find Jito’s MEV and governance complexity unnecessary. The article frames this as the intended product fit.
How does Jito choose which validators receive stake and what governance risks should delegators expect?
Validator selection for the Jito stake pool is governed rather than purely passive: the project describes StakeNet as an on-chain program to cycle validators in and out and governance proposals (e.g., forum posts and JIPs) establish blacklisting and committee‑based enforcement; forum evidence also shows a Blacklist/BOC process, concerns about single‑source detection data, and limited appeals, so governance power and transparency trade‑offs are material for delegators. Users should expect curation and governance decisions to affect which validators receive Jito stake.
Does Jito’s MEV system create censorship or fairness problems for the Solana network?
The MEV bundle mechanism can create censorship, liveness, spam, and incentive‑alignment risks if poorly designed because it changes transaction ordering incentives and introduces bundle failure/rollback dynamics; the article warns these risks exist and the audit specifically called out a spam incentive for failing bundles and noted that the block engine was out of scope for the review, leaving some risks unassessed. Jito has proposed technical fixes and governance controls but some mitigations were described as planned rather than fully validated in production.
What operational and security issues did the Jito MEV audit find?
The Jito MEV audit identified multiple issues including: some checks being offloaded from the validator (risking correctness), a spam incentive because failing bundles could roll back bribe payments, the block engine being out‑of‑scope for the audit, and a relayer authentication fix that could create a DoS vector for IPv6‑bound relayers; the audit dates and these specific caveats are recorded in the published report summary. Jito acknowledged some issues and indicated planned fixes, but the audit also left unresolved questions about deployment and whether economic penalties for failing bundles would be implemented.

Related reading

Keep exploring

Your Trades, Your Crypto