# jito-solana: Jito's MEV enabled fork of the Solana validator

> jito-solana is a Rust fork of the Solana validator maintained by the Jito Foundation, with bundle handling, a tip router snapshot service and jito-protos added to the upstream workspace, published as separate mainnet and testnet release tags. It suits operators who want to run a validator with Jito's MEV stack built in, but it is a full validator rather than a library, the debug build is explicitly not fit for a cluster, and the release line sits at 4.x with a beta ahead of it.

**jito-foundation/jito-solana** — Jito Foundation MEV Solana Client

- Repository: https://github.com/jito-foundation/jito-solana
- Stars: 762 · Forks: 424
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jito-foundation-jito-solana

## A validator fork, not a bot and not a library

jito-solana is described in one line: this repository contains Jito's fork of the Solana validator. The project is written in Rust, licensed under Apache-2.0, and published from a master branch with a build badge pointing at Buildkite.

That framing settles the scope immediately. This is a complete validator client, the software that participates in consensus on Solana, with Jito's changes folded in. It is not a trading bot, not a bundle submitter you point at a public RPC, and not a Rust crate you add to your own project. If you want to run a validator that speaks Jito's protocol, you build this and run the resulting binary.

The build output is named for Agave, which is visible in the instructions for granting XDP capabilities, where the binary path is a placeholder for the agave-validator-binary. The README recommends the Jito Gitbook for detailed instructions on building and running Jito-Solana, and points at the Anza documentation for the upstream parts.

The repository layout makes the scale obvious. The Cargo workspace lists well over a hundred members, including the core validator pieces such as `core/`, `ledger/`, `banks-server/`, `banks-client/`, `accounts-db/`, `poh/`, `gossip/`, `runtime/`-side programs under `programs/`, and the client, cli, faucet and keygen tools. Alongside those upstream crates sit the Jito additions: `bundle/`, `jito-protos/`, and `jito-tip-router-snapshot-service/`.

The release tags are the other structural fact. The listed releases are v4.3.2-jito labelled Mainnet, v4.3.1-jito also labelled Mainnet, and v4.4.0-beta.1-jito labelled Testnet. So mainnet and testnet are versioned and published as separate lines, and a beta for the next version exists alongside the current stable mainnet one.

## Building from source with a pinned toolchain and system packages

The build instructions are four steps, and the first is installing Rust.

```bash
$ curl https://sh.rustup.rs -sSf | sh
$ source $HOME/.cargo/env
$ rustup component add rustfmt
```

The rustfmt component is added explicitly because the repository formats its code with it. A `rust-toolchain.toml` file pins a specific rust version and makes cargo commands run with that version, and the README notes that cargo will install the correct version automatically if it is not already present, so a mismatched local toolchain is not something you have to solve by hand.

The system dependencies are listed per distribution. On Linux you may need libssl-dev, pkg-config, zlib1g-dev and protobuf, and on Ubuntu the package list is explicit:

```bash
$ sudo apt-get update
$ sudo apt-get install libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang cmake make libprotobuf-dev protobuf-compiler libclang-dev
```

Fedora gets its own list with openssl-devel, systemd-devel, zlib-devel, protobuf-devel, protobuf-compiler, perl-core and clang-devel. The presence of llvm, clang, cmake and the protobuf compiler is the tell that this is not a plain library build, since the Solana runtime compiles BPF programs and needs the LLVM toolchain for that.

Then the source and the build:

```bash
$ git clone https://github.com/jito-foundation/jito-solana.git
$ cd jito-solana
```

```bash
$ ./cargo build
```

The build note attached to that last command is the one that catches people out. It says this builds a debug version that is not suitable for running a testnet or mainnet validator, and points to the Anza install guide for the instructions to build a release version for test and production use. A validator is a machine that has to keep up with block times, so a debug build is not a starting point, it is a mistake.

## XDP transmit needs capabilities the binary does not have by default

One step is specific to this fork and is easy to miss, because it is about Linux kernel networking rather than Rust.

XDP transmit is enabled on Linux by default and requires extra capabilities. After building, the capabilities have to be granted to the validator binary:

```bash
$ sudo setcap 'cap_net_admin,cap_net_raw+eip' <path-to-agave-validator-binary>
```

For XDP zero-copy mode, enabled with the `--xdp-zero-copy` flag, the capability set is larger:

```bash
$ sudo setcap 'cap_net_admin,cap_net_raw,cap_bpf,cap_perfmon+eip' <path-to-agave-validator-binary>
```

The difference between the two lines is the extra `cap_bpf` and `cap_perfmon`, which are what allow the zero-copy path to run eBPF programs and read performance counters. If you grant only the first set and then start the validator with `--xdp-zero-copy`, the process will lack the permissions it needs, so the setcap call has to match the mode you intend to run.

This is a real operational detail rather than a footnote, because setcap attaches the capabilities to the file on disk. Replace the binary with a fresh build and the attributes are gone, so a rebuild in a deployment pipeline has to reapply setcap. It is also a Linux-only step, which is consistent with a validator that has to sustain a high rate of packet transmission.

The README does not describe how XDP is used for the Jito side of things, so what the capabilities are for in the MEV path specifically is not something the documentation spells out.

## Tests, benchmarks and the argument for unit test coverage

The test suite runs through nextest rather than plain cargo test:

```bash
$ ./cargo nextest run --profile ci  --cargo-profile ci --config-file .config/nextest.toml
```

The `--profile ci` and `--cargo-profile ci` pair plus the nextest config file mean the same profile is applied to the test runner and to the compile, which is how a workspace this size keeps CI builds consistent. The nextest binary comes from the `.config/` directory in the repository, alongside the rest of the CI configuration.

Benchmarks need a different toolchain. The README says to install the nightly build of rustc first, because `cargo bench` requires unstable features only available in the nightly build:

```bash
$ rustup install nightly
```

```bash
$ cargo +nightly bench
```

Coverage has its own script, and the output is opened in a browser:

```bash
$ scripts/coverage.sh
$ open target/cov/lcov-local/index.html
```

The long section on coverage is the most unusual part of the README, and it explains the philosophy rather than the tooling. The argument is that coverage is a developer productivity metric rather than a quality metric, and that a unit test encodes a problem the codebase solves. The suggested experiment is concrete: if you do not understand why a line of code exists, delete it and run the unit tests, and the nearest failing test should tell you what problem the code was solving. If no test fails, you are invited to open a pull request asking what problem the code solves. If a test does fail and you can think of a better way to solve the same problem, that pull request is wanted too.

There is also a local testnet path, with instructions in the Anza docs on running a benchmark cluster, and a remote development cluster option: `devnet`, described as a stable public cluster for development at devnet.solana.com that runs 24/7.

## The Jito crates in a workspace of upstream Solana crates

The interesting engineering question in this repository is what Jito changed, and the workspace listing gives the clearest answer available without reading the diffs.

Three crate names are not part of upstream Solana: `bundle/`, `jito-protos/` and `jito-tip-router-snapshot-service/`. The rest of the workspace is the standard Solana validator, and it is a very large standard validator, with members such as `core/`, `ledger/`, `accounts-db/`, `poh/`, `bloom/`, `bucket_map/`, `cost-model/`, `feature-set/`, `io-uring/`, `quic-client/`, `cost-model/`, `precompiles/`, `merkle-tree/`, and the runtime programs under `programs/` including `bpf_loader`, `system`, `vote`, `compute-budget`, `ed25519-tests` and the zero knowledge ElGamal and token proof programs.

The `bundle/` crate is the core of the MEV addition. A bundle is a group of transactions that are submitted together and are meant to land atomically or not at all, which is the mechanism MEV strategies are built on. `jito-protos/` holds the protocol definitions, and the tip router snapshot service is the component that serves the tip accounts, which is the piece that tells searchers where to send their tips.

The `jito-tip-router-snapshot-service/` name is a little revealing about the design. A snapshot service suggests the tip set is periodically published and served as a snapshot rather than negotiated per request, which is a different model from a live auction. The README does not describe the protocol in detail, and the project documentation is in a Gitbook rather than in the repository, so the specifics of the MEV flow live outside the code.

The workspace also contains `geyser-plugin-host/` and `geyser-plugin-manager/`, the Geyser plugin interface used for external data feeds, and `banking-stage-ingress-types/` and `banks-server/`, which are the parts of the pipeline where transaction ingress happens. The Jito changes to a validator are most likely concentrated in the ingress path, which is where bundles would arrive.

## Against upstream Agave and against running Jito as a separate service

The comparison worth making is between forking the validator and running Jito as a sidecar.

The sidecar approach means running an unmodified upstream validator and pointing your own tooling at it, with a separate service handling bundles and tips. The difference in approach is where the MEV logic lives. In a fork, the bundle path is inside the transaction ingress code, so a bundle is handled by the same process that participates in consensus, with no extra network hop and no separate process to keep alive. In a sidecar, the bundle service has to talk to the validator over the network, which adds a hop and a failure mode, but leaves the validator untouched.

The cost of the fork approach is upgrade pain, and this repository makes that visible. Every upstream Solana release has to be merged in, and the release tags show the consequence: the version numbers track the upstream validator version with a `-jito` suffix, and the pace is roughly one tagged build every few days, v4.3.1 on 2026-10-14 and v4.3.2 on 2026-10-16, with a 4.4.0 beta on 2026-10-15. That is a fork taking upstream changes continuously.

The third option is not running a validator at all, which is the honest baseline. If you are a user of Solana rather than an operator, none of this is your concern, and the question you care about is whether the Jito validator on the network handles your transactions well.

The repository's own tooling reflects the fork's complexity. There is a `RELEASE.md` describing the release process, a `CHANGELOG.md`, a `CONTRIBUTING.md`, an `AGENTS.md`, a `clippy.toml` and a `deny.toml` for dependency licence checking, a `.rumdl.toml` for markdown linting, a `Cargo.lock` committed for a workspace this size, and a `release.sh` script in the tree. A `SECURITY.md` is present as well, and the CHANGELOG and CONTRIBUTING files are the places to look for how a release is put together and how a change gets accepted.

## Conclusion

Adopt jito-solana if you intend to run a Solana validator with Jito's MEV machinery included rather than bolting a separate tip router on top of an upstream client, and follow the Anza install guide for the release build rather than the debug one. Do not adopt it for anything other than validator operation, since it is a whole client rather than a library, and check first which release line you want, because mainnet and testnet tags are published separately and a 4.4.0 beta exists alongside the 4.3.2 mainnet release.

## FAQ

### What is jito-solana?

It is Jito Foundation's fork of the Solana validator, written in Rust and licensed under Apache-2.0. The repository adds a `bundle/` crate, `jito-protos/` and `jito-tip-router-snapshot-service/` to the upstream Solana workspace.

### How do I build jito-solana from source?

Install Rust with rustup, add the rustfmt component, install the listed system packages, clone the repository, and run `./cargo build`. The README warns that this produces a debug build that is not suitable for running a testnet or mainnet validator.

### What capabilities does the validator binary need for XDP transmit?

On Linux you grant `cap_net_admin,cap_net_raw+eip` with setcap on the validator binary. For XDP zero-copy mode with the `--xdp-zero-copy` flag you also need `cap_bpf` and `cap_perfmon`.

### How do I run the jito-solana test suite?

Run `./cargo nextest run --profile ci --cargo-profile ci --config-file .config/nextest.toml`, which applies the ci profile to both the test runner and the compile using the nextest config in the repository.

### How are mainnet and testnet releases of jito-solana named?

They are published as separate lines with a `-jito` suffix, for example v4.3.2-jito labelled Mainnet and v4.4.0-beta.1-jito labelled Testnet. The release process is described in RELEASE.md in the repository.

### Is jito-solana still being maintained?

The repository is not archived and the last push was on 2026-10-20. Recent tags include v4.3.2-jito from 2026-10-16, v4.3.1-jito from 2026-10-14 and v4.4.0-beta.1-jito from 2026-10-15, under an Apache-2.0 licence.

## Sources

- [Issues](https://github.com/jito-foundation/jito-solana/issues)
- [jito-foundation/jito-solana on GitHub](https://github.com/jito-foundation/jito-solana)
- [License: Apache-2.0](https://github.com/jito-foundation/jito-solana/blob/master/LICENSE)
- [README](https://github.com/jito-foundation/jito-solana/blob/master/README.md)
- [Releases](https://github.com/jito-foundation/jito-solana/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jito-foundation-jito-solana