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.

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?
| Option | Liquidity | Yield sources | Yield accrual | Best for |
|---|---|---|---|---|
| JitoSOL | High transferable | Staking + MEV | Price appreciation | DeFi users and treasuries |
| Native staking | Locked | Staking only | Stake rewards | Passive stakers |
| Standard liquid staking | High transferable | Staking only | Price appreciation | Liquidity seekers |
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?
| Component | Role | Trust / checks | Main risk | Benefit |
|---|---|---|---|---|
| Relayer | Forwards bundles to TPU | Off-chain validation | Auth spoofing / DoS | Faster bundle submission |
| Block engine | Selects and auctions bundles | External service (audit out‑of‑scope) | Centralized source risk | Market for MEV bids |
| Bundles | Atomic transaction package | Validator executes atomically | Spam via failing bundles | Enables multi-step arbitrage |
| Modified validator | Produces blocks, captures MEV | Runs bundle/path checks | Skipped votes, liveness issues | Passes MEV to stakers |
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?
| Area | Benefit | Main risk | Mitigation |
|---|---|---|---|
| Operational complexity | Access to extra MEV yield | Software bugs and ops burden | Audits and release controls |
| Incentive alignment | Share MEV with stakers | Spam from failing bundles | Economic penalties or fees |
| Governance curation | Curated validator quality | Centralization and opaque bans | DAO veto and appeals window |
| Availability & spam | Atomic bundle execution | DoS and liveness harm | Relayer auth and penalties |
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
Related reading