Uploaded IDL on-chain management is a mess.
IDLs lack versioning history, causing breaking changes when updates occur (e.g., Anchor 0.30+). This breaks old clients, and there's no way to lock a client to a major IDL version. Additionally, different producers like Anchor and Shank generate slightly different outputs. Proper versioning is needed.
No IDL history for parsing historic transactions.
Since IDLs change over time and there’s no history, it’s impossible to reliably parse past transactions. Contract endpoints evolve, making historical analysis difficult.
Read layer inefficiency.
Solana's read layer lacks effective indexing for list queries. PDAs work well for point queries but are inefficient for searching related data (e.g., "get all governance proposals with this tag"). This necessitates external indexers.
Indexers are expensive.
Catching every Anchor record and inserting it into a database (e.g., PostgreSQL) is challenging. Solutions exist (e.g., @streamingfastio), but even a single stream costs ~$500/month, making it inaccessible for small developers.
Transaction sending and landing complexities.
Optimizing transactions is a constant challenge—priority fees, stake-weight QoS, compute limits, Jito, lookup tables, and VersionedTransaction interfaces are all cumbersome. A simple, unified solution is needed.
Anchor performance issues.
Anchor consumes excessive memory and compute units. init_if_needed frequently causes heap overflows. Solana’s native code is difficult to read, but Anchor should be optimized rather than forcing devs to use raw Solana code.
CPI call depth limit is restrictive.
The current limit is low and can hinder composability. Additionally, CPI calls are expensive, making certain use cases inefficient. (@blockiosaurus has insightful posts on this.)
Transaction size limits are inconvenient but manageable.
While tx size restrictions are an issue, workarounds usually exist, making this a lower-priority concern.
Rent costs are becoming prohibitive.
As SOL prices rise, on-chain rent becomes increasingly expensive. Deploying a smart contract can cost ~$3,000, which is unaffordable for individual developers.
cNFT indexing delays.
cNFTs require waiting for indexing before they can be used in subsequent transactions. This delay complicates workflows, making Core NFTs a better alternative in hindsight.
Unhelpful error messages.
Solana’s error messages often lack clarity, failing to specify which account caused an issue. Improvements are in progress (GitHub link).
Wallets lack open-source transparency.
The top wallets (Phantom, Solflare, Backpack) are either closed-source or outdated in their source availability.
Rust clients are cumbersome.
TypeScript benefits from dynamic account resolution for has_one and PDAs, but Rust lacks this, making development slower and more painful.
Explorers are inadequate.
Solana Explorer is the most reliable option but lacks features like filtering by instruction type or listing all transactions for a program.
RPC spec lacks critical features.
Priority fees are poorly handled, and incremental updates (e.g., “get accounts modified after block X”) are missing. Refetching unchanged data wastes bandwidth.
Dependency management is a nightmare.
Rust dependencies often don’t follow SemVer, making upgrades unpredictable and painful.
Poor error handling when preflight checks are off.
If a transaction fails due to size or insufficient SOL, it often just hangs instead of returning an error message.
No native transaction scheduling.
Running transactions at specific times requires deploying custom workers or cron jobs. Clockwork was a partial solution, but it's gone. A new alternative is needed.
Passkey Wallet Infrastructure The upcoming secp256r1 precompile (Solana 2.2) enables biometric authentication and passkey-based wallets. Potential use cases: