Jonas Hahn

@redacted_noah the IDL situation is indeed unsatisfying… I started to build an IDL history for the projects I cover myself to solve this. Can still work nicely if you run it automated and potentially even let Claude create issues/ PRs if an IDL change would break something (on my side)

Hey @jacobvcreech foundation should run an indexer that watches the metadata program an indexes the history of each IDL, including all versions. It should then expose a service that (1) gives me the current IDL for a program given a major version (so two majors can be active at the same time) and (2) gives me a history of every IDL change for a program between two timestamps, so I can make changes as I index. With Streamingfast + Claude you could probably vibecode this in a day.

As requested, all my current complaints in no particular order: 1. Uploaded IDL on-chain management is a mess. It has no versioning history, and when IDLs have breaking changes (like anchor 0.30+) all old clients currently looking at the on-chain IDL break. Why can't I lock a client to an IDL major version? Why is every IDL producer slightly different? Anchor, shank, etc should all produce the same thing. Published IDLs are wonderful in that I can add an account that's referenced by a has_one or PDA without breaking existing TS clients. But they need proper versioning. 2. Related to 1, since there's no IDL history, parsing historic transactions on Solana is impossible. Contract endpoints change, IDLs change, there's no history of it. 3. Read layer. The read layer sucks. You can do a lot to structure your program code to optimize for point-queries using PDAs as a kind of index. Like a crappy redis. But the second you need to do list queries ("get me all governance proposals with this tag") you're hosed. gPA is a terrible thing to use. That means you need an indexer! 4. Indexers. I have spent literal years wrestling with indexing on Solana, trying to get it so you catch every anchor record and insert it into postgres. *Finally* I have a solution that works, thanks to @streamingfastio. But even one stream is ~$500/month. Not really accessible to a dev trying things out in their spare time. Fine for Helium. 5. Transaction sending and landing. This is arguably the ONE thing a blockchain should be good at. Why am I talking to like 5-10 different people to find the optimum way to restructure my tx builder+sender every 3 weeks? Prio fees, stake weight QoS, compute limits, jito, lookup tables, transaction vs VersionedTransaction (the most ugly interface ever in both ts and rust). There's just so much to unpack here. Wrap it all up and throw it in a black box I don't ever have to look at again. Please. 6. Anchor performance. Anchor hogs a bunch of memory, newest versions init_if_needed almost always causes it to blow the heap. It also uses a bunch of CUs. It's the most used framework for smart contracts, let's pour all the resources we have into making it better. Native solana code is seriously so ugly to read it's a security hazard. There's no reason anchor, which is all pretty macros, can't be made to be just as fast. 7. CPI call depth limit. It's arbitrary, and low. Sometimes for composability you need more. CPIs are also super expensive. @blockiosaurus has some nice posts on why composability is a lie. 8. Tx size limits. This is actually the least of my problems, I can almost always find a way to work around this. 9. Rent is TOO DAMN HIGH. Sol is mooning, so rent is getting crazy high. I work for a company with funding, so it's not an issue for me. But if I were trying to do Solana in my spare time, $3000 to deploy a smart contract is ridiculous. 10. cNFTs continue to cause issues. If you need to mint a cNFT, then do something with that cNFT, you need to wait for the cNFT to be indexed so you can get its proof so you can construct the subsequent transaction _doing_ something with that cNFT. Huge headache. I wish Core NFTs had existed when we migrated helium, I would have used those instead. 11. Errors. Solana errors are notoriously unhelpful. #L277" target="_blank" rel="nofollow noopener">github.com/anza-xyz/agave…. This entire list should tell you which account the error came from. This is actively being worked on by Solana devrel. 12. Wallets. Of the top 3 wallets (Phantom, Solflare, Backpack) none of them are open source. One is source available, but usually pretty out of date. Wtf. 13. Rust clients suck. Using things like anchor from typescript are a breeze, because there's dynamic account resolution of has_one's and PDAs. Every time I have to use rust, it's like going back to the stone age. 14. Explorers suck. Why am I still using explorer.solana.com? Because it's the only one that consistently doesn't have broken IDL parsing, and has all the information that I need, and works with localnet devnet and mainnet. But it's notably missing things like seeing all txs on a program and filtering by instruction type. 15. The base RPC spec is missing tons of functionality. For one, it sucks at priority fees. Second, it's missing read level functionality enterprise web apps usually make use of, like incremental updates. I shouldn't need to waste data refetching accounts if they haven't changed. But there's no way to say "getMultipleAccounts that have changed past block x" 16. Dependency hell. ALWAYS with the dependency hell. Semver is never followed, especially on rust clients. So upgrading dependencies is always a nightmare. 17. Error handling when you turn off preflight checks is horrendous. Often times, if you've messed up the tx (too large, don't have enough sol, etc) it'll just hang forever. Hanging forever has to be the least desirable outcome for anything. 18. No ability to easily run txs at a specified time/on a schedule without deploying your own workers/crons. RIP clockwork (dw, I'm building a solution to this) I'm sure there's more, but my build finished to it's back to work. This is just top of mind.

@SolPlay_jonas @solana_devs @solana And kora also serves as a x402 facilator too 😇🙌🏻

You can now pay @solana gas fees in any SPL token using Kora! Full video below 👇

As someone who works with custom rpcs, I hated having to type it in every time in the explorer so I wrote a save customs clusters feature and got it merged into the explorer - you can now save to local storage your clusters, whether it's @Helius RPCs or @magicblock endpoints!