Lightspeed Newsletter: A peek into Solana’s core governance
Every blockchain has a means of governance, but when it comes to upgrading Solana, the means are perhaps less widely-known
Kolonko/Shutterstock modified by Blockworks
Today, enjoy the Lightspeed newsletter on Blockworks.co. Tomorrow, get the news delivered directly to your inbox. Subscribe to the Lightspeed newsletter.
Howdy!
To all of our US readers: Happy 4th of July, ‘Murica, may freedom ring, etc.
And since today is dedicated to celebrating government, it seems apropos to talk a bit about governance:
Who governs Solana?
Every blockchain has a means of governance — that is, a way for humans to decide how its software should be upgraded.
Bitcoin has its core developers and Bitcoin Improvement Proposals, and Ethereum has something similar. The means of upgrading Solana are perhaps a bit less widely-known.
When I put out the bat signal for Solana people to explain how governance works on the network, I immediately got ratio’ed by Ore developer Hardhat Chad, who wrote: “Toly proposes stuff and then Trent says no” — referring to Solana co-founder Anatoly Yakovenko and @trent.sol, the self-described “chief curmudgeon” of Anza, which is the developer shop building Solana’s primary client.
When Trent doesn’t say no, the process works something like this: Someone proposes a Solana Improvement Document (SIMD), then validators vote using voting tokens based on their share of staked solana. If the vote passes, client developers implement and create the change.
(I should add: Multiple people I asked said that Yakovenko is not very involved in governance directly, though he does advise core contributors.)
A client is an implementation of a blockchain’s software. Solana’s main client is currently Agave, Arcium CTO Nicolas Schapeler told me.
Agave is a fork of the original validator software created by Solana Labs. It is maintained by Anza, which was founded by a group of Solana Labs core developers and executives. Anza was announced in January. Jito also offers its Jito-Solana client, meaning Solana has two widely used clients.
After client developers make changes, validators turn the proposal into reality by upgrading to the new client version. Since this process runs partly through Anza, Agave’s importance to Solana’s development could become a problem if Anza were to go rogue.
“When more clients are live, the guarantee that client devs do exactly as SIMDs say is much higher, as validators will opt to switch to a competing client if they don’t. Even though this hasn’t been a problem so far, it is a good guarantee to have in place — just in case,” Schapeler said in an email. If validators were to dissent from a client upgrade, they could choose to not upgrade the client or to fork the source repository to remove the change, he said.
More clients are expected to go live on Solana in the future — most notably the Jump-created Firedancer.
The strength of Solana’s governance model depends on validators’ ability to opt out of code changes they don’t like, the anonymous professionally-managed validator operator @nodedruid told me in a direct message.
“Validators watch SIMDs and code changes closely, and in the past have intervened with opinions changing the course of Anza’s (previously Labs’) validator client code,” @nodedruid said, adding: “Things will become more formalized around a ‘Solana spec’ when you have multiple teams with live clients; Firedancer, Zig, etc.”
In a governance context, validators can perhaps be thought of as elected representatives (in a proportional representation system, for any Netherlands fans out there): solana stakers can delegate their stake to the validators whom they choose, and those validators’ voting power is based on how much stake they gather.
One Solana participant I spoke to wants to see this change: “In the end state, we at Chainflow feel that validators AND delegators would vote,” Chainflow founder Chris Remus told me, explaining that he wants to see voting include more stakeholders.
This would perhaps be helpful in cases where validators vote on issues that affect themselves — like the recent SIMD-0096, where validators voted to route 100% of priority fees to themselves, rather than burning half, in an effort to cut down on side deals.
“[I]f the core devs didn’t think SIMD-0096 was workable, they would have loudly advocated against it,” Solana Foundation head of strategy Austin Federa told me, adding that “validator weighted governance has downsides, but so does token holder governance.”
— Jack Kubinec
One Good DM
A message from Rex St. John, developer relations at Anza:
Get the news in your inbox. Explore Blockworks newsletters:
- The Breakdown: Decoding crypto and the markets. Daily.
- 0xResearch: Alpha in your inbox. Think like an analyst.
