Overview
Solana is a programmable Layer 1 network. SOL is used for transaction fees and staking. Its account and program model differs from Ethereum’s, so an instruction, token account and wallet address should not be assumed to work like an ERC-20 transfer.
Mechanisms
Solana uses proof of stake; proof of history helps establish ordering rather than replacing all consensus duties. Transactions can include multiple instructions, and fees depend on the relevant transaction and priority settings. A displayed fast response should still be interpreted using the network’s commitment levels and the application’s acceptance policy.
Risks and interpretation
Operational risks include validator and client dependencies, RPC availability, program authority and token-specific controls. Check the exact token mint and network before transferring. Staking returns depend on changing network parameters and operator performance; they are separate from changes in SOL’s price and do not guarantee a positive return in euros.
- 01Accounts and programs
- 02Instructions
- 03Atomic execution
- 04Confirmation and fees
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
A Solana transaction groups instructions, with accounts and signatures authorizing the requested operations. Instructions execute atomically: if an instruction fails, the transaction’s state changes are reverted, while fees may still be charged. Separate this execution outcome from confirmation. Before signing, inspect the program invoked and the accounts it may affect.
Put the mechanism into context
A fictional transaction contains two instructions. The first would update a token account; the second fails during execution. Someone claims the first change is permanently retained because it ran first. Draw the transaction boundary around both instructions.
Apply it in the workshop →What this mechanism does not guarantee
Operational risks include validator and client dependencies, RPC availability, program authority and token-specific controls. Check the exact token mint and network before transferring. Staking returns depend on changing network parameters and operator performance; they are separate from changes in SOL’s price and do not guarantee a positive return in euros.
Worked case: identify the token, not its name
A fictional wallet shows two tokens with the same display name but different mint identifiers. The receiving service supports only one. Matching the display name is insufficient; the team must establish the exact supported mint and destination requirements. It must also distinguish the SOL used for fees from the amount transferred in the other token.
Your analysis checklist
Review the mint, relevant account, instructions, authority settings and observed confirmation level. Explain why a familiar logo cannot replace these checks.