Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
On Ethereum, every new deployment creates a new contract address with its own storage. Deploy two copies of ERC-20 and you have two separate token contracts. On Solana, the program is immutable code — one deployment, one program ID — and the state (mints, accounts, balances) lives in separate accounts that the program operates on. The SPL Token program at address TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA is the ONLY token program; every SPL token on Solana uses that same program. This changes everything about upgrade paths, protocol composability, and who owns which accounts.
A token on Ethereum is its own contract. A token on Solana is a Mint account owned by the shared SPL Token program. 'Creating a new token' on Solana means creating a new Mint account — no new program is deployed. This is why CPIs (cross-program invocations) work so cleanly: every token mint and every token account has the same interface because it's the same program reading them.
# Compare deployment patterns:
# Ethereum (Solidity):
forge create src/MyToken.sol:MyToken # deploys a new contract
# Returns: contract at 0xABC... with its own bytecode + its own storage
# Solana:
spl-token create-token # creates a Mint account
# Returns: mint at 7XyZ... held by the SPL Token program
# No new program bytecode deployed. Ever.
# Second token on Solana:
spl-token create-token # another Mint account
# Same program (TokenkegQ...). Different mint account. That's it.spl-token create-token on devnet (solana config set --url devnet). Note the mint address. Run it again — you get a different mint address, but TokenkegQ... is the owner of both. Inspect with solana account <mint-addr>.declare_id!) and why upgrading a program in place (with the upgrade authority) is possible whereas in Solidity every upgrade creates a new address.