Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
An Ethereum project usually deploys many contracts (factory, pool, governance, etc.). A Solana project usually deploys one program that handles many instruction variants. This design forces tight modularity within a single binary and a different upgrade model — programs are upgradable via BPF Loader Upgradeable, not by deploying new contracts.
A Solana program with multiple instructions.
solana program show <PROGRAM_ID> — note the upgrade authority and the program data account.use anchor_lang::prelude::*;
declare_id!("MyD3F1ProgramAddressHere11111111111111111111");
#[program]
pub mod my_defi {
use super::*;
pub fn initialize_pool(ctx: Context<InitPool>) -> Result<()> { /* ... */ Ok(()) }
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> { /* ... */ Ok(()) }
pub fn withdraw(ctx: Context<Withdraw>, shares: u64) -> Result<()> { /* ... */ Ok(()) }
pub fn swap(ctx: Context<Swap>, amount_in: u64, min_out: u64) -> Result<()> { /* ... */ Ok(()) }
pub fn liquidate(ctx: Context<Liquidate>) -> Result<()> { /* ... */ Ok(()) }
}
// Each instruction is dispatched by an 8-byte discriminator (sha256("global:method_name"))
// Programs are upgraded by re-uploading the binary; upgrade authority must sign.
// No proxy patterns needed — upgrade is built into the BPF loader.
#[derive(Accounts)]
pub struct InitPool<'info> { /* accounts */ }
#[derive(Accounts)]
pub struct Deposit<'info> { /* accounts */ }
// ... etc