This video presents a comprehensive 4-phase roadmap for becoming a Solana developer: Phase 1 covers client-side Solana development including understanding the Bitcoin white paper, Solana's ED25519 cryptography, account model with PDAs, transaction structure, and wallet adapters; Phase 2 focuses on Rust programming fundamentals including data types, memory management, and package management; Phase 3 addresses smart contracts (programs) using native Rust and frameworks like Anchor and Pinocchio; Phase 4 covers advanced topics including multisig/MPC for secure wealth management, Solana indexing via Geyser plugin, and building liquidator bots for arbitrage opportunities.
Complete Solana and Rust Roadmap 2025: Developer Guide
Added:Over the past 6 months, students and working professionals alike have probably made 250K from Solana grant. We have personally given out 10K US in our web 3 cohort. We have had one person who converted yesterday for a 100K offer in a Solana company. 30% of referrals in super 30 were a Solana company. My biggest offer was from a Solana company.
And we're now starting a Solana validator at 100x school. Hopefully by this time, you know, I'm very closely connected to web 3 blockchains and specifically the Solana ecosystem. I'm also doing the superdev fellowship from July where we'll be selecting a lot of folk to learn Solana development and the top 20 would receive a $2,500 grant each. The link to the fellowship is in the description. This video I wanted to talk through if you want to get into the Solana ecosystem. Um if you want to build your own company, win a hackathon, get a grant, get a job or apply for the fellowship, what is a standard road map for someone who hopefully knows development already. So there's a mild prerequisite to this video. If you've done a little bit of web development, DSA uh dev, then a lot of things that I say in this video might make sense. If not then maybe come back to this video later whenever you're looking for a Solana and a Rust road map. With that I've broken this down into four parts.
Client side Solana Rust for Solana development programs on Solana and some web 2 plus web 3 topics. Let's dive deeper into all four of these sections and understand as a beginner what are the topics you need to tackle sequentially to learn Solana development. Let's get right into it.
We'll kick things off by reading just the Bitcoin white paper. Um it's decent orientation into getting into blockchains. You don't necessarily have to dive directly into Solana. The Solana white paper is a little challenging. So would not recommend reading that. The Bitcoin white paper is fairly easy. Um in fact at this point I would urge you to try building a version of the Bitcoin blockchain yourself. A milder version where there is, you know, no complicated consensus. Um fairly simple block processing, transaction parsing and block mining. In fact, I'll link in the description a small RFC that I created in the beginning of the cohort and a project that a user built using that specific RFC. After you understand what blockchains are, try to read a bit about what is Solana, how is it different from Bitcoin and Ethereum. Um, maybe first understand the difference between Bitcoin and Ethereum, then understand the difference between Ethereum and Solana. Um, next up, um, spend some time on cryptography. Um, you don't have to dive too deep. Um, the important parts over here are going to be public key cryptography and over there specifically, you need to understand the ED25519 curve. The ECDSA curve is only relevant for Bitcoin and Ethereum. Uh, so you can skip this one. But ED25519 which is you know one specific curve to do public key cryptography on Solana which means you understand what public key cryptography is you understand what are public keys private keys what is signature what is verification then focus purely on ED25519 and you know you don't need to understand the algorithm you don't need to understand what the curve looks like you just need to know this is a specific way to create a public and a private key on Solana what is a private key something you keep safe what is a public key you share with the world for example if I open my phantom wallet here this is my public key that you can see 9 cgs but my private key I've kept with myself. I won't share it on the video. Um if I do share it, then you'll be able to pull out these $64 from my account. Next up, try to create a wallet on Solana and airdrop yourself some Solana. Um you can do that. Air drop yourself some Solana. Um preferably buy some Solana on Binance or Coinb um and have a wallet like I have over here where you have some Solana, let's say 0.2 Solana, um in a public key whose private key you own. then understand the concept of ownership or owners and u authorities um on Solana. For example, if you look at this specific wallet of mine and if I go to explorer.solana.com, if I paste the public key, you'll see it has a few fields over here. The address, how much Solana I have, allocated data size, which is something you need to learn about, assigned program ID on what is also known as the owner, which says system program here, and executable, no.
So, what is this assigned program ID?
And there's this other concept of authorities which isn't relevant for this address but generally what is a mint authority, what is an upgrade authority, what is a freeze authority, what is a revoke authority. Learn about these auxiliary addresses that exist for a lot of addresses on Solana. Next up read about the accounts model on Solana.
I've kept this in bold because this is actually fairly important probably the most important topic until this point probably the most hard to digest as well. You need to understand how data is stored on the Solana blockchain. You need to understand the concept of data counts, PDAs and specifically in PDAs, there are two big use cases that PDAs have. Something called program signing and determinism. These three things you need to understand well uh before you proceed at all. Um if you don't understand the data model on Solana and if you're not able to digest PDAs um then there's no point proceeding further because most programs on Sana are going to use a PDA. Then feel free to spend some time on program accounts and program data accounts and that's pretty much it. take a breather at this point and you know ensure you already understand the data model on Salana because it's very different from the web two data model and also from the Ethereum data model. Next up, transaction structure and instruction formats. At this point, understand how do you interact with the blockchain. For example, what happens when I actually try to send someone Solana? If I click on send, select Solana, select a random address and try to pay them 0.1 soul. If I click on next and click on send, what exactly is happening? How is a transaction created? What is a transaction? What is an instruction? Um, how many instructions can you shove in a specific transaction? How many accounts can you shove in an instruction? Are all important interview questions to know the answers for. Generally, not super important, but these nuances can be asked in an interview. also not the worst thing in the world to know what the transaction format looks like. What are the headers, the bytes, what are the three types of transactions that exist on Salana? V 0 legacy transactions, version transactions, vo transactions, and what's the difference between them.
Next up, um spend some time here.
Transaction inputs on Solana. When I go over here and click a few buttons and try to send someone Solana, things feel fairly simple, but under the hood, they're not. If I click on send over here, I'm actually sending a very complex object to the Solana blockchain through what's called an RPC. So you first need to understand what an RPC is and then need to understand what exactly do I send to the Solana blockchain. That is exactly what I mean when I say transaction inputs on Solana. I'm not going to dive deeper into this but yeah read about it. Um the whenever you're sending a transaction to Solana, you're sending a fairly complex object. It's not as simple as calling a function um or you know calling an API endpoint. The format looks fairly weird and the reason it looks very weird is because that specific format is what makes Solana fast. So again a very popular interview question is what makes Solana fast or paralyzable? And the answer is the way the transactions inputs are sent. Um, more specifically, how the accounts are sent in the input. Um, now what this means is something you have to Google after the video. Then spend some time on wallet adapters. Fairly simple stuff.
It's basically a UI library that makes it easy to connect with wallets. For example, if I go to jup.ag, which is a dex aggregator or, you know, just a place where I can go connect my wallet and convert, you know, let's say 0.1 Solana into USDC. Um, when I click on swap, how does this popup come up? How does my wallet ask me to approve the specific transaction? How does this website connect to my wallet? And the answer is through wallet adapters.
Jupiter has their own. Anza has one as well. There are a bunch of, you know, other popular wallet adapters that you can use. You don't have to build one yourself. They have very simple APIs.
Creating a DAP like this isn't too hard based on those APIs. Ideals and reading contracts, official clients versus um passing data for yourself. Um long story short, contracts are very hard to read, very hard to understand. A lot of times not published by the developers and hence um you have to reverse engineer them um yourself. A lot of times they don't have official clients. So what do I mean when I say official clients? For example, you know, Metapplex client for example um this specific library that you see Metaflex Foundation/JS is a JavaScript SDK for interacting with the Metaplex program. So there's a program on the Sana blockchain. There's a very simple JavaScript library where you can call functions to interact with it. A lot of times these libraries don't exist and you have to create them yourself for the specific contract that you're trying to interact with. How do you do that?
How do you reverse engineer the contract? How do you write the clients?
Bosch which is a popular serialization deserialization framework specifically in blockchains the one that Solana uses and hence you need to spend some time on Bosch and understand how can you serialize and deserialize specific data types uh because this is the library used by Solana to actually store data on the blockchain in terms of bytes. So how do you convert you know JSON to bytes or an object to bytes? spend some time on wash and lastly try to build a memecoin marketplace. I think this this is a project that covers all corners when it comes to client side. That means reading a lot of data from the blockchain. That means interacting with contracts that you don't know how they look like. So, you know, figuring out the program inputs, the IDL and creating a client for it, interacting with it. Um, if you can create one end to end, for example, Dex screener is a popular deck on Solana. Sorry, not a DEX, a way to see the currently available meme coins, a way to follow their prices, a way to actually buy. For example, this is a whatever a VA coin which you can see is you know going up a little bit. So creating indexing all of this data somewhere letting the users buy. For example, I can buy some VA coin by you know connecting my wallet. Um and you know I don't have to deploy the final program. It's deployed already. I just need to interact with it. I need to create the client for it. And of course the website the front end reading the data letting the user see all the currently available meme coins hopefully from a specific marketplace like uh pump and and going from there. All of this is client side. You don't need to write any contract. You just need to write front end. Um, and you need to find the specific programs on the Solana blockchain. Figure out how to interact with that. That's section number one.
Um, I speedrun through it because I want to keep the video under 15 minutes. I think people lose context after that. If you need specific ideas or you know discussions or more depth into any one of these, um, let me know in the comments. Although we have a cohort as well where we have covered all these topics in fair depth. Cool. Next up is Rust. I'm just going to speedrun through these. These are very simple concepts you need to know for any language. And that includes data types, variables, loops, functions, strcts, enums, pattern matching. Here is where you know you start to get into the Rust ecosystem.
Package management similar to npm. What is the equivalent on Rust specifically?
There are three packages you need to get comfortable with. Um the Solana program package um Solana SDK and Bosch. Um Bosch we've already done JavaScript as well. BJS we have to do the same thing over here. Slowly we'll talk about a few more packages or what are called traits um in Rust that we need to spend our time on. But if you're able to understand these three, the functions that exist over here, import them and use them. You're good to go. Mutability, memory management, referencing and borrowing, options, errors and error handling, lifetime trades, genics, and macros. Um, I think everything from here to here, basically everything minus macros is already covered in the two 4-hour Rust boot camps that I have. So, I think to just sprint through this section, um, go through the two Rust videos that I have and you're good to go. This is not enough Rust to create web two programs. You need to understand multi-threading and how to write async programs on Rust. you need to understand how can you you know create a TCP listener or a HTTP server and connect to a database so on and so forth. These are all things you don't need for the blockchain and hence we're not learning them here but if you want to become a standard Rust developer or create web two applications there there are more topics needed that are missing over here. Moving on um the third section which is smart contracts or what are called programs on Solana. Smart contracts was a concept popularized by Ethereum but Solana calls them programs.
Um there's a hard prerequisite at this point. You should understand the data model on Solana well. You should understand the transaction inputs that you send to a contract. Well, that means you need to understand point number six and point number seven fairly well uh before you start to write a contract or go through a video that takes you through uh how to write your first smart contract or program on uh Solana because um it looks very different especially if you're coming from the Ethereum world.
If you've only written EVM contracts, um it's a little hard to digest what the inputs look like for a Solana program.
So make sure you're done with the prerequisites, you understand them well and then start to write native contracts in Rust. When we say native contracts, we mean how contracts were sort of supposed to be written on Solana. You can write native contracts in Rust and in C. They're a little hard to write.
They're a little more verbose. They require a developer to write some extra code or you know a lot of checks themselves which is where some more complicated frameworks to write but easy frameworks to use as a developer come into the picture. Two of them being Anchor and Pinocchio. Um Anker is the more OG one. um although it's slightly less optimized when it comes to both space and the amount of compute you're using, the amount of gas that you're paying. Hence, recently came another framework called Pinocchio which I think is created by the Anza guys as well which is not as developer friendly as Ankor but is much more uh optimized when it comes to speed and uh the amount of compute units that you're using. So for now feel free to just stick to native contracts. Try to write these contracts.
Uh these are the only contracts you need to practice before an interview. Um if you are going to sit in a sola interview very high probability they're not going to ask you any contract other than these. Amongst these contracts make sure you've practiced them too many times because most probably the interview is going to look like they're going to give you a half written contract and you're supposed to add some functionality to it. So if you understand these contracts well if you've practiced them four five times if you've written tests for them if you understand testdriven development and can write tests either in Rust or JavaScript and then create the contract that's the most optimal thing that you can do in an interview. And as I said, most probably they're not going to ask you any contract outside of these in your final interview. So get fairly comfortable with these in native. Then try to write the same in ankor and you will see how easy your life becomes because anchor handles a lot of things for you and then move on to write the same contracts in Pinocchio and try to compare performance here and here.
Pinocchio is still new. I don't know if it's audited probably is um but it's fairly experimental. You don't have to use Pinocchio for most contracts. It doesn't matter if you know if the compute usage is a little higher if you're taking more space. But I think eventually since there is more development that is happening on Pinocchio, this might become the norm.
So it's always good to stay ahead of everyone. That covers programs. There is no end to this. Honestly, you can write more and more complicated programs. You can go through some native programs on Solana. By native programs, I mean the one that come bundled with the Solana runtime. If you can read them, if you can understand them, if you can write tests for them, that means you're in a great spot. When it comes to smart contract writing or program writing, there are less jobs in u writing smart contracts because companies don't write them very often. Um but they're very high paying jobs and they're usually in either auditing companies or consulting companies. That's the section on smart contracts. Finally, let's move to the fourth section which is a lot of actionable things that you do as a Solana engineer but they are less related to Solana more related to some web two cryptography or you know some standard web two systems or distributed systems some standard web two systems that you might have built in the past.
Number one multisig not a Solana specific concept. It's sort of present in all blockchains. Um, as the name suggests, it's a way for multiple signers to sort of um, execute transactions on an account. It It's a way to make sure if you have a lot of wealth, if you have a very big wallet, which you want to keep very safe, how can you not have a single private key, but sort of delegate the signing to multiple owners and only if three out of five owners or four out of five owners actually sign the transaction is when the transaction goes through. There are popular contracts on Solana that already exist. For example, the governance contract, there are multi6 that already exist on Solana, for example, realms and squads. So you can read through these contracts. A lot of times you are reusing these contracts for internal systems for the company. For example, if you have a company where you're managing a lot of wealth, you don't want to keep that wealth in a wallet that just has a single private key. You probably want to keep it in a multi-IG or you want to do what's written in step number two, which is multi-party communication and threshold signing schemes. This is the more ideal way to do not just wealth management, but also wealth dispersal.
Um if you have a very fat wallet um let's say that has $200 million from which you need to keep dispensing Sona every few minutes every few seconds then multisigs are not the ideal approach to do it you still have the same problem a very fat wallet but multisig are not the ideal solution for it because they'll be slower and they'll be more gas consuming and hence comes another approach where you can still not have a single private key for a public key you can still have multiple people sort of owning it but you minimize the number of transactions that you're doing to finally dispense the transaction if you did not get this part just ignore um but you know take this as a jargon for eventually Google it. What is the difference between a multisig and an MPC? Binance has a good blog on it. I'll link it in the description. These two are topics you need to know. If your company is eventually going to hold a lot of wealth, that means it could be a crypto gateway. It could be a centralized exchange. It could be a wealth management company. It could be a company where you're holding users assets for whatever reason. You need to make sure you hold them in not a normal wallet but in a multiig or in an MPC.
Next up, um this is an auxiliary topic that I put. Um a lot of volumes on Solana right now are on Telegram bots.
Um so it's not the worst idea in the world to understand how can you build telegram bots, how can you make them faster? Indexing the blockchain. Um there are two jargon I'm going to throw at you here. One of them is newer called Yeno Stone and the other one is the Geyser plug-in which is the old and popular way to index the Solana blockchain. Indexing the blockchain basically means creating a copy of the blockchain and it's fairly easy to do on Ethereum because Ethereum only has you know some 100 transactions every 12 seconds. A single block comes up every 12 seconds, it has 100 to 200 transactions. So you can just keep pulling the blockchain slowly from a a NodeJS process for that matter and you know copy everything in memory or in a postress database. Um that is not true for Salana. Solana has you know extremely high transactions per second.
So you can't keep pulling the blockchain you will fall behind very quickly. You sort of have to sit in a validator and push out events from there for the addresses that you're interested to index. So if you want to index for example you know all of your users wallets um you can tell that to a sana validator. Um you can run a small plug-in over there. You can tell the plug-in if anything changes in one of these addresses um send that to a Kafka Q and then you can subscribe to the Kafka Q to listen on what is happening on the blockchain on those specific addresses and store it in a post database store it in memory wherever you want to. Indexing the SA blockchain is hard. Indexing Ethereum is fairly easy.
Why? TPS is different. Any blockchain that has extremely high transactions per second, you will not be able to pull it.
You'll also need more space to store the data because there is more data. So you need to figure out how do you filter out the data? What data you need? What data you not need? Running an RPC running a validator. As I said, we are starting a validator. Now, running it is easy.
Finding stake for it is harder. So, don't pick up this challenge unless you are an incumbent or if you have a lot of Salana because if you don't have enough Solana to stake, your validator will not be profitable. You'll end up losing money. That might happen for us as well because we won't have enough stake initially. Um when you start a validator or a minor if you want to call it the easier challenge is bringing up a machine you know finding a machine that has enough bandwidth and compute. The harder challenge is finding stake um and finding people who can stake the SANA with you. If you're not able to get enough stake, uh your validator will not be profitable. You'll end up losing money and you can lose up to 30 soul a month. That's around $5,000 a month if you don't have enough stake. Lastly, um building liquidators/ the bot/balancing bots. This would require 0.5 as a prerequisites. You need to be running a validator to be able to do this to do these attacks. And these are not really attacks. These are more, you know, um arbituruing opportunities. You need to know when a specific pool is imbalanced.
Now, I'm throwing a few words here. What is a pool? I have a video on it. Top right. Go to it. uh you'll understand what an AMM is, what a pool is. Um but long story short, in blockchains, the pricing of a specific asset doesn't change very quickly and hence what might happen is the price of SA might go to $200, but it's still $190 on a decentralized exchange. Rebalancing it basically means making sure you push it up to $200 and also make some money in the middle. To be able to do that, you need to be really fast because there's a fair amount of competition here. It's basically free money, but at the same time, you need to first there's some barrier to entry here. You need to understand how you can run validators.
You also need to understand how you can reverse engineer a few of these decks.
uh figure out their APIs and you know be able to build on top of them. It's also risky if someone else has a rebalance before you you're screwed so on and so forth. So you need to make sure you're up for the risk. You can run a validator. You can reverse engineer popular contracts on Salana and you're also ready to you know be another competitor in this field. That's a Solana road map. Um hopefully it was insightful. A lot of this might have gone up your head. If it did I do apologize. A more detailed sort of curriculum is in our web 3 cohort if you want to go through it. Um no pressure there. There are a lot of videos on YouTube. There are a lot of creators on uh YouTube that will also cover some of these topics at the very least. And of course, there's code on GitHub where I've learned this from as well. You can go there and learn these things as well.
If you feel like you've done 70 80% of this, um then feel free to apply for the fellowship. It's fairly competitive. Uh but at the same time, the initial lot of people will be high. Eventually, the people that actually get the $2,500 grant might be lesser. But in the worst case, you can try to get in the bigger lot of people that are at least starting the fellowship. With that, we'll end it.
I'll see you guys in the next one.
Bye-bye.
Up Next

Solana Development With Anchor: A Complete Introduction
@chainlink
7.1K views•2022-04-24

Torrent File Format & Bencoding: A Technical Deep Dive
@AsliEngineering
12.5K views•2022-08-08

Operational Security Essentials: A Guide for Hacktivists (OPSEC)
@hitbsecconf
157.4K views•2012-11-26

Understanding Ethereum: A Comprehensive Beginner's Overview
@99Bitcoins
3.1M views•2018-06-26
Related Study Plans & Knowledge Roadmaps
Structured learning paths in Blockchain & Crypto






















![Solana Developer Bootcamp 2026: Learn Blockchain and Full-Stack Crypto Development [Full Course]](https://i.ytimg.com/vi_webp/2pcm7ICRJKU/maxresdefault.webp)















