DEV Community: Carlos Prada

I Built a Token of Which I Have Full Control

Carlos Prada — Mon, 01 Jun 2026 17:28:26 +0000

What Is This About?

Recently I was doing the #100DaysOfSolana challenge and I created a token that has a permanent delegate account.

What is that, you might ask?

As the Solana Token Extensions paper describes it: "Allows specifying a permanent account delegate for a mint. This delegate has unlimited delegate privileges over any account for that mint, which means that it can burn or transfer any amount of tokens."

This means the account that is a permanent delegate has full control over that token (transfer and burn) without the approval of the owner's account.

Is It Hard to Create?

Nope. Here is how you can do it if you have the Solana CLI installed:

spl-token create-token --enable-permanent-delegate --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

spl-token is part of the Solana CLI
create-token is the command that initiates the token creation
--enable-permanent-delegate is the flag that activates the Token Extension on the token
--program-id specifies the Token-2022 Program to create your token (if the flag is not passed, the token will be initiated with another token program that does not support extensions) That's it — your token is live. You can give it to people, seize it, or even burn it without any approval other than yours.

Pros

Good for companies that wish to have full control and must seize assets if legal infringements have been made.

Cons

The token is really not yours. Even if it is in your wallet, someone else can do whatever they want with it. And that's scary.

How Can You Check If a Token Has a Permanent Delegate?

Go to the Solana Explorer and search the mint address of the token you want to look up. You will see a Token Extensions row at the bottom. If it says Permanent Delegate your token can be transferred or burned by another account: the permanent delegate account.

As you can see in the picture below:

So next time you transact with tokens, don't forget to look for what extensions it has — it might be some useful information for you. Here is the Token-2022 Extension Guide if you want to do your own research.

See you soon for more posts about my developer journey!

A Guide to the Solana Token Extensions I Used Over the Last 3 Days

Carlos Prada — Wed, 27 May 2026 01:25:55 +0000

Token Extensions are behaviours embedded directly into a token, enforced at the program level at creation time. You can set transfer fees, make transfers confidential, or disable token transfers altogether — all baked in, no extra contracts needed.

A Bit of Context

I have been doing the 100 Days of Solana challenge, where every day a new challenge teaches you something new about the Solana blockchain from a developer's perspective.

I started knowing nothing. Today I can spin up accounts, explain how Solana accounts are encoded at the byte level, make transfers, and create my own tokens with custom extensions. Here's what the last few days looked like.

What I Built

Day 29 — Token-2022 From Scratch

This was the big one. Using nothing but the spl-token CLI, I:

Initialised a token with the Token-2022 program
Added a transfer fee (200bps, as you can see in the terminal output below)
Attached on-chain metadata — name, symbol, and URI — so the token is human-readable
Created an Associated Token Account (ATA), the address that holds a specific token instead of SOL
Minted tokens into it
Transferred tokens to another wallet
Collected the transfer fees accumulated from those transactions Here's what the final mint looked like on the terminal:

Everything — fee config, metadata pointer, withdrawal authority — living directly on the mint account. No separate contract, no external registry.

Days 30 & 31 — Slower, but Necessary

Funny enough, the exercises on days 30 and 31 were less technically advanced than what I had already built on day 29. The day 32 challenge turned out to be essentially a more structured version of day 29.

That said, I don't regret it at all. Days 30 and 31 walked me slowly through each concept individually — transfer fees, metadata, ATAs — one at a time. Everything was extremely pertinent. Sometimes slowing down is how you actually understand what you already did.

Day 33 — Soulbound Tokens

On day 33 I built a token that cannot be transferred. Ever.

These are called soulbound tokens — and because they can never move between wallets, they must be minted directly into the ATA of the final intended owner. The token is bound to that address forever.

"What's the point of a token you can't send to anyone?"

More than you'd think. Their use cases include:

🎓 Credentials — proof you completed a course or passed a certification
🏅 Badges — on-chain achievements tied to a specific wallet
🪪 Membership proofs — non-sellable, non-transferable access rights The restriction is enforced at the Token-2022 program level. There is no workaround — any transfer instruction on a non-transferable mint will always fail.

What Surprised Me

While going through the multiple token creation challenges, I dug into the Solana Token Extensions Technical Paper and discovered something that genuinely caught my attention: confidential transfers.

By default, everything on the Solana blockchain is publicly visible — balances, transaction amounts, wallet addresses. Confidential transfers use zero-knowledge proofs to encrypt transaction amounts on-chain, making them verifiable without being readable.

This opens doors for business-critical use cases that simply weren't possible before on a public chain — payroll, private treasury movements, B2B settlements. The infrastructure is already there. It just needs to be used.

What's Next

I'll keep learning something new about Solana development every single day. I'll sporadically post write-ups like this one so you can follow along with what I'm discovering on the journey.

Follow me if you want to see more. The deeper we go, the more interesting it gets.

# Day 24: In Solana, Everything is an Account

Carlos Prada — Sat, 23 May 2026 01:09:54 +0000

On Solana there is just... accounts. One model. Everything is an account — your wallet, a deployed program, a token mint, a user's token balance. All of them live in the same flat key-value store where the key is a 32-byte address and the value is the account data.

It sounds simple. It's actually a pretty elegant design decision with a lot of implications.

The Filesystem Analogy

Here's the mental model that clicked for me: think of Solana like a filesystem.
Every account is a file. Each account (file) has:

metadata:
- owner
- permissions
- size
contents:
- the actual data

Program accounts are executable files. Data accounts are the documents those programs read from and write to. And the System Program? That's the OS kernel — it handles creating new files and transferring ownership.

The Five Fields Every Account Has

No matter what an account represents, it always has the same five fields:

lamports — the SOL balance. 1 SOL = 1,000,000,000 lamports.
data — a raw byte array. This is where all state lives.
owner — the program that controls this account and can modify its data.
executable — a boolean. If true, this account contains a deployed program.
rent_epoch — deprecated. You'll see it set to u64::MAX on all modern accounts.

The ownership rule is the key security primitive: only the owner program can modify an account's data or debit its lamports. Anyone can credit lamports to any writable account. Simple, but powerful.

Programs Don't Store Their Own State

This is the one that surprises every Web2 developer: Solana programs are stateless.

A program's executable bytecode lives in one account. Any data that program needs lives in entirely separate accounts. The program just reads and writes those accounts at runtime. It's the difference between a web server (the program) and a database (the data accounts) — they're separate things.

Reading a Real Account On-Chain

To make this concrete, I fetched the Wrapped SOL mint account — one of the most fundamental accounts on Solana mainnet. Here's how I pulled the raw data using @solana/kit:

import { createSolanaRpc, address, getBase64Encoder, getBase16Decoder } from "@solana/kit";
import { getMintDecoder } from "@solana-program/token";

const rpc = createSolanaRpc("https://api.mainnet-beta.solana.com");
const mintAddress = address("So11111111111111111111111111111111111111112");

const { value: accountInfo } = await rpc
  .getAccountInfo(mintAddress, { encoding: "base64" })
  .send();

const dataBytes = getBase64Encoder().encode(accountInfo.data[0]);

The account data comes back as base64. Once decoded into raw bytes, I ran it through two decode paths — the Token Program codec, and a manual byte-level read using DataView:

// Codec approach
const mint = getMintDecoder().decode(dataBytes);

// Manual byte-level approach
const view = new DataView(dataBytes.buffer, dataBytes.byteOffset, dataBytes.byteLength);
const supply = view.getBigUint64(36, true);  // bytes 36–43, little-endian
const decimals = view.getUint8(44);          // byte 44

Both approaches confirmed the same thing — here's what the terminal showed:

Supply is 0 (wSOL is minted on demand), decimals is 9, and both mint and freeze authorities are null — meaning no one can mint more or freeze transfers. The account is fully decentralized.

Rent Exemption

One last thing: every account must hold a minimum lamport balance proportional to its data size. This keeps the validator state from bloating with abandoned accounts. For a zero-data account it's roughly 0.00089 SOL. Using the Solana CLI You can calculate exact amounts with:

solana rent <data-size-in-bytes>

If an account drops below this threshold, it gets purged. So whenever you create an account in a program, you're responsible for funding it past the rent-exempt minimum.

Key Takeaway

Solana's account model is the foundation for everything else — PDAs, token accounts, program-derived state. Once you internalize that all state lives in accounts, programs are stateless, and ownership = write permission, the rest of the ecosystem starts to make a lot more sense.

This post is part of my 100 Days of Solana series. Follow along as I go from zero to deployed program. Github Repo

Day 20 of 100-Days-of-Solana: Solana transactions look complicated? Here's a breakdown.

Carlos Prada — Fri, 15 May 2026 23:02:56 +0000

Context

When using a high-level library like @solana/kit, sending SOL looks like this :

But what happens under the hood? Bear with me—I'm just a newbie trying to understand this—but here is how a raw transaction is actually structured.

🧠 Core Content: Understanding a Solana Transaction

At the highest level, a Solana transaction consists of just two things: Signatures and the Message.

1. Signatures

A compact-encoded array of 64-byte Ed25519 signatures.

💡 In human terms: Every account that needs to approve the transaction must sign the serialized message with its private key. It’s the network's way of verifying that the transaction was explicitly authorized by the required accounts.

2. The Message

The message contains the actual logic, broken down into four sub-levels:

Sub-level 1. Header: Metadata specifying the total required signers, read-only signers, and read-only non-signers. It acts as a checklist for the runtime to validate the transaction.

Sub-level 2. Account Keys: An array of all account addresses required by the instructions.

Sub-level 3. Recent Blockhash: A timestamp-like value. If it is older than the 150 most recent blocks, the validators will reject the transaction.

Sub-level 4. Instructions: The actual commands for programs to execute (e.g., Move X amount of SOL from Account 1 to Account 2).

🔍 The Raw JSON Structure:

🤔 What is {"version": 0}?

Solana transactions have a strict size limit of 1232 bytes. Because public keys are 32 bytes each, listing too many accounts will break this limit.

To fix this, Solana introduced two versions:

Legacy: Standard transactions limited by how many raw addresses you can fit.

v0: A version that introduces Address Lookup Tables (ALTs).

An ALT is an account on the blockchain that stores a list of addresses. Instead of passing full 32-byte addresses, you include the ALT address in your Account keys ("staticAccounts" in the JSON above) and reference the other addresses using a tiny 1-byte index. Note: Addresses inside an ALT cannot act as signers.

🎯 Takeaway

It is great to see what consistency can do. I went from knowing nothing on Day 1 to being able to somewhat explain transactions on a blockchain—one of the most complicated pieces of software to wrap your mind around—by Day 20. Let's go! 🚀

100 Days of Solana: Week 2

Carlos Prada — Sat, 09 May 2026 16:24:42 +0000

Two weeks into the #100DaysOfSolana challenge, and I’m finding that the most valuable part of this journey isn't just the code I'm writing, but the perspective I'm gaining.

From User to Developer: My Backstory

I’ve been a user of the Solana ecosystem since 2021—long before I ever typed my first line of code. In fact, Solana is one of the main reasons I started programming in the first place.

The ease of use and the near-instant transaction settlement were phenomenal then, and they still are today. It sparked a genuine curiosity that shifted me from just using the tech to wanting to build with it.

The `@solana/kit`

Coming into the second week, one of my biggest takeaways has been working with the @solana/kit. Knowing that a whole kit is written to implement blockchain functionality easily is a game-changer for someone coming from a web dev background. It makes the integration feel intuitive rather than overwhelming.

Why Slow and Steady Wins the Race

The format of this challenge—taking things slow and guided from a web developer's perspective—has been incredibly beneficial for my understanding of real-world implementation.

When you first start with Solana, the temptation is to jump straight in with:
npm create solana-dapp@latest

While that tool is powerful, it’s often too much in one go. For a learner, it generates a massive boilerplate that can hide the underlying logic. Plus, managing the multiple vulnerabilities that often come from installing a whole premade project with heavy dependencies can be a major distraction.

Looking Ahead

I am genuinely grateful for this specific format. It allows me to build a solid foundation without getting lost in the noise of complex scaffolding.

I’m excited to keep learning and pushing forward until I can create something entirely my own utilizing blockchain technology.

See you all in Week 3! 🚀

From Script to Browser: Migrating My First Custom Solana Keypair

Carlos Prada — Mon, 04 May 2026 01:17:53 +0000

What I Did

I used a simple JavaScript script and the @solana/kit library to programmatically generate a new keypair, saved the secret key to a local .json file, and then wrote a second script to extract that seed so I could manually import it into my Phantom wallet extension for devnet testing.

What Surprised Me

The biggest shift from Web2 was realizing that my "identity" is just a cryptographic string of numbers; once I had that secret key, I could "teleport" my wallet from a raw JSON file on my hard drive directly into a browser extension instantly—no passwords or recovery emails required.

What’s Next

Now that I’ve mastered the "manual" side of key management, I’m looking forward to building a small frontend that allows users to connect their own wallets and sign transactions via the Wallet Adapter.

Note on Security:

While this was an incredible learning experience to see how keypairs actually function, remember that storing unencrypted private keys in a .json file is high-risk! This wallet is strictly for devnet experimentation.

100DaysOfSolana @solana_devs

The Identity Crisis How blockchain improves your life

Carlos Prada — Sat, 02 May 2026 15:48:37 +0000

We’ve all worried that someone could steal our identity just by getting a hand on our personal info. Honestly? That threat isn't going away. Social engineering is a menace to society, especially in a world where information moves at the speed of a click.
Blockchain offers a fix to some of these problems. I say some because no solution is perfect, especially for an issue this messy. But by using specific mechanisms on the Solana blockchain, we can shrink the surface area of what can go wrong.

It limits the attack vectors to one. There—you can stop reading now if you want.

Why Web2 is Getting Weird

Still here? Good. Let's talk about how keypairs make life easier. Have you tried to log into anything lately? It’s a mess.

Input your password.

“Wait, please provide a 2FA code.”
“Now approve the sign-in from your phone.”
“But I don’t have my phone on me!”
“Too bad. Access denied.”

And don’t even get me started on the mountain of paperwork banks and governments want just so you can use your own money. Cryptographic keypair authentication is just... easier.

The "Mom" Test

You’ve seen this technology in action. It’s what lets your mom access her Google or Apple account with a thumbprint or a face scan. You don’t have to hunt for the password she lost (the one she swears she
told you, but definitely didn't).

The mechanism is simple:
Public Key: A code you share with the world. It says, "Hey, this is me!"
Private Key: A code you share with no one. It’s the mathematical proof that says, "It really is me, and here’s the signature to prove it."

Boom. That’s it. You don't need to be a "big brain" cryptographer to use it; you just need to know how it's stored.

The Big Tech Trap vs. The Solana Way

This is where Solana shines. In the "Passkey" world of Big Tech, your private keys are often synced to the cloud. That means a massive corporation technically holds the keys to your kingdom. For a Netflix account? Fine. For your house title or your life savings? Maybe you don't want a cloud company in the middle of that.

On Solana, you are the absolute owner of that private key.

True Custody: You can write your key on a piece of paper and lock it in a safe. It becomes physically impossible to impersonate you unless someone literally steals that paper.
Censorship Resistant: Big Tech can block, censor, or ban you from their "secure" systems whenever they feel like it. Solana is ideology-agnostic. The blockchain doesn't care who you are; if the signature is valid, the gate opens.

One Key to Rule Them All

We need to unify protocols for ease of use, but decentralize the processing for security. Solana provides the high throughput and scalability to actually make this dream a reality for millions of people.

So, next time you use one of those "magic" keypair methods, ask yourself: Who really owns this key, and how is it being processed?

DEV Community: Carlos Prada

I Built a Token of Which I Have Full Control

What Is This About?

Is It Hard to Create?

Pros

Cons

How Can You Check If a Token Has a Permanent Delegate?

A Guide to the Solana Token Extensions I Used Over the Last 3 Days

A Bit of Context

What I Built

Day 29 — Token-2022 From Scratch

Days 30 & 31 — Slower, but Necessary

Day 33 — Soulbound Tokens

What Surprised Me

What's Next

# Day 24: In Solana, Everything is an Account

The Filesystem Analogy

The Five Fields Every Account Has

Programs Don't Store Their Own State

Reading a Real Account On-Chain

Rent Exemption

Key Takeaway

Day 20 of 100-Days-of-Solana: Solana transactions look complicated? Here's a breakdown.

Context

🧠 Core Content: Understanding a Solana Transaction

1. Signatures

2. The Message

🔍 The Raw JSON Structure:

🤔 What is {"version": 0}?

🎯 Takeaway

100 Days of Solana: Week 2

From User to Developer: My Backstory

The @solana/kit

Why Slow and Steady Wins the Race

Looking Ahead

From Script to Browser: Migrating My First Custom Solana Keypair

What I Did

What Surprised Me

What’s Next

Note on Security:

100DaysOfSolana @solana_devs

The Identity Crisis How blockchain improves your life

Why Web2 is Getting Weird

The "Mom" Test

The Big Tech Trap vs. The Solana Way

One Key to Rule Them All

The `@solana/kit`