Solana

This is Part 5 of the Solana Program Lifecycle series. In Part 4 we walked through the deploy and upgrade flows: the Buffer account, the chunked writes, and the activation step that copies bytecode into the ProgramData account. Every upgrade instruction checks one thing before it proceeds: who is allowed to do this. That one thing is the upgrade_authority_address field: 33 bytes in the ProgramData account that control who can replace the program’s bytecode. This post traces the full lifecycle of that field, from the keypair that deployed the program to the irreversible --final flag that writes None and freezes the program forever. ...

This is Part 4 of the Solana Program Lifecycle series. In Part 3 we saw that a program is two accounts: a 36-byte Program Account that points to a ProgramData Account holding the actual bytecode. Now we look at how those two accounts get created and replaced. The short version: there is a third account involved. A temporary one. It exists only during the deploy or upgrade, and if anything goes wrong, it can sit on chain holding your SOL until you reclaim it. ...

This is Part 3 of the Solana Program Lifecycle series. In Part 1 we covered the account model. In Part 2 we covered compute units. Now let’s look at something most developers never think about until something breaks: how programs actually live onchain. Because here’s the thing: a Solana program isn’t one account. It’s two. And the relationship between them is what makes upgrades possible without breaking everything that depends on the program. ...

This is Part 2 of the Solana Program Lifecycle series. In Part 1 we covered how accounts work. Now comes the thing that will break our code if we ignore it: compute units. Solana transactions don’t warn you when you’re close to the compute limit. They just fail. Users lose the fees. No refund. The first time many developers discover this is when mainnet starts rejecting transactions that worked fine on devnet. ...

This is Part 1 of the Solana Program Lifecycle series. If you’re new to Solana development, start here. These concepts come up in everything you’ll build. 1. The Account Model Everything on Solana is an account. Programs, user data, tokens, even the ledger state, all stored in accounts. There’s no database engine, no relational tables. Just accounts in a flat key-value map where each key is a 32-byte address and each value is an account. ...