Agave: what it is and why Solana's validator got renamed

If you've run a Solana node in the last two years you've typed agave-validator and maybe wondered where the name came from. Agave is the validator client that still produces most of Solana's blocks — and it's not a new client at all. It's the original Solana Labs validator, renamed and handed to a new steward. This is the short version of what happened and why it matters.

What Agave is

Agave is the Rust validator client maintained by Anza, the engineering company spun out of Solana Labs in early 2024. It is the direct continuation of the codebase that lived at solana-labs/solana for Solana's entire history up to that point — the same runtime, the same consensus, the same JSON-RPC. It now lives at anza-xyz/agave.

Crucially, Agave remains the reference implementation for Solana's consensus and runtime semantics. When people ask "how does Solana actually behave here," the answer is usually "whatever Agave does." Every other client is measured against it.

Why the rename happened

It was an organisational decision, not a technical fork. Through 2024, Solana's development split across three entities:

• Solana Foundation — stewards the network, delegation programs, ecosystem.
• Solana Labs — the original company; stepped back from day-to-day validator client maintenance.
• Anza — a new company formed by core protocol engineers, which took over the validator client.

Renaming the client from "the Solana validator" to Agave made an important point explicit: the protocol is not the same thing as any one implementation of it. A network where the client is literally called "Solana" quietly implies there's only one correct client. Calling it Agave — one client among several — is part of the same client-diversity push that produced Firedancer and Sig.

What actually changed

For node operators the changes were mostly cosmetic, but real:

• Repo. solana-labs/solana → anza-xyz/agave.
• Binaries. The validator binary became agave-validator. Several tools kept the solana- prefix for compatibility (the solana CLI is still solana), so you live with a mix of agave-* and solana-* commands.
• Release line. The v1.18 series was the last under the old name; the v2.x line shipped as Agave.

What did not change: the on-chain protocol, the RPC interface, account formats, transaction semantics. No app had to change anything. A rename of the implementation is invisible from the API.

Where Agave sits in the client landscape

Agave is the trunk that the production ecosystem grows from:

• Jito-Solana is a fork of Agave with the Jito Block Engine baked in. Because MEV revenue is real money, the large majority of staked SOL runs Jito-Solana — which means the large majority of stake runs Agave-derived code.
• Frankendancer bolts Firedancer's C networking stack onto Agave's runtime and consensus — still Agave underneath for the parts that decide validity.
• Firedancer (full) and Sig are the genuine independents — ground-up rewrites in C and Zig with no shared code. They're what real client diversity finally looks like, and they exist precisely so that an Agave consensus bug can't halt the whole network.

So vanilla Agave runs a relatively small slice of stake directly, but as the base of Jito-Solana and Frankendancer it's underneath most of the network. For the full breakdown of who runs what, see the validator client landscape.

Does this affect you?

If you build apps: no. Same RPC, same semantics. The rename is trivia you'll see in logs and changelogs.

If you run a validator: you're running Agave (or a fork of it) and you should track anza-xyz/agave releases, not the archived solana-labs/solana repo. Expect agave-* binary names and a mix of old and new command prefixes.

If you're just learning Solana: "Agave" and "the Solana Labs validator" refer to the same lineage. When older docs say one and newer docs say the other, they mean the same client.

References

• anza-xyz/agave
• anza.xyz
• jito-foundation/jito-solana