The Solana (SOL) network faced a threat that could have compromised user funds, but resolved it quietly.  

The detected vulnerabilities were corrected privately, which generated discomfort among participants in this ecosystem due to the lack of transparency and its impact on decentralization, according to SolanaFloor, a site specialized in the Solana ecosystem. 

Despite the "anger" of the Solana community, it is important to highlight that these types of findings, which could compromise the network, are usually kept secret so that a hacker does not discover the error and exploit it. 

The core of the problem

In mid-April, critical flaws were identified in two key programs, Token-2022 and ZK ElGamal Proof, which would have allowed attackers to mint unlimited tokens or drain user wallets.  

However, these errors were later revealed on May 2, when the Solana Foundation published a post-mortem report, in which it explained the problem surrounding the ZK ElGamal Proof.  

This program, based on zero-knowledge cryptography, allows you to verify that a wallet has a correct balance without revealing its contents. It uses ElGamal encryption, a mathematical technique that ensures the privacy of sensitive data.

The flaw lay in a flawed implementation of the Fiat-Shamir transformation, a method that converts private cryptographic proofs into public ones using a hash. In this case, essential components were omitted from the hash, allowing the creation of fake proofs that the system accepted as valid . If exploited, this would have allowed an attacker to manipulate transactions or generate unlimited tokens. 

For its part, Token-2022 is a token standard on Solana that introduces features like custom transaction rules, dynamic fees, and interest-bearing tokens. Compatible with the original SPL system, which defines how tokens and protocols operate on the network, Token-2022 would offer greater flexibility to developers. However, its vulnerability also left funds exposed to potential mass theft. 

On April 18, just two days after identifying the flaw, the network's main validators, according to SolanaFloor, adopted two corrective patches. This process, however, was carried out without public notification to users or open discussion, sparking criticism.  According to the same source, this "private" update generated great unrest in the community and revealed a worrying centralization. 

Voices of concern

On May 7, the developer of BasePumpFun (a platform for issuing tokens on Ethereum Layer 2 Base) known on X as The Smart Ape, expressed his concern: “They admitted they were extremely close to an exploit that would have allowed unlimited tokens to be minted and stolen from any wallet. It could have been the end of Solana .  ”

He added that while no attacks exploiting the vulnerability were reported, the fix was handled "behind closed doors, without community voting or transparency." He believes the reliance on a small group of validators raises serious concerns about Solana's decentralization. 

According to data shared by The Smart Ape, four major Solana validators control nearly 80% of staked SOL, facilitating unilateral decisions and reinforcing complaints about staker centralization. These validators include decentralized finance (DeFi) platforms and exchange staking pools, such as Jito, Binance Staking, Marinade, and Jupiter. 

Chart of the platforms with the largest amounts of SOL staked. Source: X.

However, reviewing data from Solana's block explorers, both Solscan and Solana Beach offer different figures than those presented by The Smart Ape regarding validators. According to those two sites, out of the 1,300 existing validators, platforms such as Helius, Binance Staking, Galaxy and Coinbase are the ones that hold the largest percentages of SOL staking, with each of them representing between 2% and 3% of the total SOL in stake . 

Differences in validator counts between Solana explorers are common due to the dynamic nature of the networks. Each explorer uses different methods to track active nodes, such as polling frequency or criteria for considering a validator "online," leading to small discrepancies in the reported numbers. 

Thus, the lack of communication prior to the patch and the release of the report only after the problem was resolved fueled criticism. For many, this episode calls into question the balance between efficiency and openness in a network that presents itself as decentralized, while it is also true that reporting what happened before it was resolved would have been risky.