Posts

This is Part 2 of the Solana Authorities series. In Part 1 we covered the authority pattern itself: what authorities are, how they differ from ownership, and what None means. Now we go deep on the two authorities every SPL token has. Disabling the mint authority does not disable the freeze authority. A token with a “renounced” mint can still have every holder locked out of their tokens. These are two independent fields in a single 82-byte account, and checking only one of them is not enough. ...

This is Part 1 of the Solana Authorities series. If you work with tokens, NFTs, staking, or governance on Solana, this series maps every authority field you will encounter, what each one controls, and what happens when you hand it off or burn it. The problem Every Solana intro tutorial mentions “the mint authority” once, in passing, when teaching spl-token create-token. Almost no tutorial explains: That the mint has a separate freeze authority that can disable transfers for any holder. That Token-2022 added roughly a dozen additional authority slots through extensions, several of which can move user funds without consent. That stake accounts have two authorities (stake and withdraw), and losing the withdraw authority is permanent loss of principal, not just rewards. That Metaplex metadata has its own update authority that controls how wallets and marketplaces render an NFT, independent of who holds it. That governance programs (SPL Governance, Squads, Realms) are themselves just programs that hold authorities on behalf of a DAO, and the security model collapses to whatever those programs enforce. Most rugs, freezes, and operational mistakes on Solana trace back to one of these fields being misunderstood. ...

This is Part 6 of the Solana Program Lifecycle series. In Part 5 we covered the upgrade authority lifecycle, from a single keypair through Squads multisig and SPL Governance to the irreversible --final flag. Now we step back and look at the whole pipeline: how a program moves from a file on your laptop to live bytecode on mainnet. The short answer: it is more than solana program deploy. The deploy command is the last step, not the whole thing. Developers who skip straight to mainnet tend to discover this when a partial buffer upload stalls at 3 AM, or when a CPI that worked perfectly in local testing silently fails because the account it needed never existed outside mainnet. ...

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. ...

1. Introduction Sui is a Layer-1 blockchain that uses an object-centric model to process transactions in parallel, enabling high throughput and instant finality while providing native primitives for building decentralized applications. Developers choose Sui for several compelling reasons: Parallel execution - Transactions don’t wait in a single-file line, resulting in faster confirmation times Consumer-ready features - zkLogin (sign in with Google/Apple) and zkSend (share crypto via link) lower barriers to entry Move programming language - A secure, resource-oriented language designed specifically for blockchain development Built for scale - Optimized for data-heavy applications like gaming, NFTs, DeFi, and social apps This guide walks you through setting up the complete Sui development environment on your local machine. By the end, you’ll have the Sui CLI installed, a local network running, and the essential developer tools configured to start building Move smart contracts and decentralized applications on Sui. ...

Install Required Tools 1 2 3 4 apt install \ wpasupplicant \ wireless-tools \ --no-install-recommends Identify your wireless interface First, let’s figure out your wireless interface name using 1 ip link You’ll see output like this: 1 2 3 4 5 6 7 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP mode DEFAULT group default qlen 1000 link/ether 98:fa:9b:31:a4:h6 brd ff:ff:ff:ff:ff:ff altname enp0s31f6 3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether d0:ab:d5:11:4r:5c brd ff:ff:ff:ff:ff:ff Look for the line that starts with something like wl???? — that’s your wireless interface. In this example, it’s wlp2s0. Make a note of it, you’ll use it in the next steps. ...