DEV Community: Hala Kabir

How I Built a Counter Program in Anchor and Learned to Trust My Tests -Hala Kabir

Hala Kabir — Sun, 21 Jun 2026 21:38:47 +0000

Nothing exposes fuzzy understanding faster than trying to explain your own code. Over the last few days of the #100DaysOfSolana challenge, I’ve been building, testing, and intentionally breaking a decentralized counter program using the Anchor framework.

When you're writing smart contracts on Solana, a green test suite feels great—but it can also hide silent assumptions. Today, I want to pull back the curtain on how my first Anchor program works and show exactly how I broke it on purpose to prove my test suite actually does real work.

The Entry Point: Solana's Guard Rails

The biggest paradigm shift when moving from Web2 to Solana development is how state is handled. In Solana, programs (smart contracts) are stateless; all data lives inside external accounts. To create an account, Anchor uses an accounts validation struct. Here is how my Initialize struct is laid out:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = authority, space = 8 + 32 + 8)]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

This struct functions as our security guard before the main logic ever runs. The #[account(...)] macro tells Anchor to initialize a brand-new counter account, forces the transaction authority to pay the SOL storage rent, and allocates exactly enough memory space (8 bytes for the Anchor discriminator, 32 bytes for the public key, and 8 bytes for our data number).

Short Handlers and Iron-Clad Access Control

Because the accounts struct handles the heavy lifting of security and allocation, our actual instruction handlers inside the pub mod can be beautifully short and concise.

The ctx.accounts object lets us confidently unpack the validated accounts. But initialization is only half the battle. What stops a malicious actor from modifying someone else's state? This is where access control shines in our Increment instruction:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut, has_one = authority)]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

By adding has_one = authority, Anchor automatically enforces a strict on-chain check: the key signing this transaction must match the public key permanently stored inside the counter.authority field. If it doesn't, execution completely halts.

Proving the Tests Earn Their Keep

To make sure this logic holds up, I wrote a test suite tracking both the happy path and critical failure states using an integrated test runner:

it("Initializes then increments successfully", async () => {
  await program.methods.initialize().accounts({...}).signers([...]).rpc();
  await program.methods.increment().accounts({...}).signers([...]).rpc();

  const account = await program.account.counter.fetch(counterKeypair.publicKey);
  if (account.count.toNumber() !== 1) {
    throw new Error("Assertion Failed!");
  }
});

Why this test exists: If the runtime environment introduces a regression where state transitions fail silently or data math corrupts, this test will instantly trip.

it("Increment fails when the wrong authority signs", async () => {
  try {
    await program.methods.increment().accounts({ authority: authorityB.publicKey }).signers([authorityB]).rpc();
    throw new Error("The transaction should have failed!");
  } catch (err) {
    console.log("Caught expected authority error!");
  }
});

Why this test exists: This isolates our access control constraint, ensuring an unauthorized user cannot maliciously modify accounts they do not own.

The Turning Point: Mutation Testing

The real magic happened when I ran a manual mutation test pass—planting bugs on purpose to see if my test suite was genuinely "load-bearing."

I intentionally went into src/lib.rs and broke the core arithmetic logic by updating the step increment from 1 to 2:

counter.count = counter.count.checked_add(2).ok_or(ProgramError::Custom(0))?;

When I compiled and ran the suite, the happy path test caught it red-handed. The test framework threw a glaring red flag because it expected a value of 1 but received a 2 directly from the account state.

This taught me a massive lesson: you can't just trust a green checkmark because your tutorial said it's correct. You only truly trust your tests when you have physically watched them break for the exact right reasons.

If I had another week to build on this, my next step would be implementing dynamic PDA (Program Derived Address) counters so users could spin up unique, deterministically mapped counter states linked exclusively to their wallets.

Anchor Test failing on 0 !== 1 despite increment method being called in Solana Playground- Hala Kabir

Hala Kabir — Sat, 20 Jun 2026 20:11:32 +0000

@niranjannlc @walletguy @ajdroi & @matthewrevell pleasee help an young develpoer..

Hi everyone, I am running into a persistent issue on Solana Playground where my Anchor integration test is failing with an AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 0 !== 1.

My smart contract includes a functional increment instruction, and my anchor.test.ts file correctly initializes the account and immediately calls the increment instruction right after. The code looks like this:

describe("counter", () => {
  it("Increments", async () => {
    const provider = anchor.AnchorProvider.env();
    anchor.setProvider(provider);
    const program = anchor.workspace.Counter;
    const keypair = anchor.web3.Keypair.generate();

    await program.methods.initialize().accounts({ counter: keypair.publicKey, authority: provider.wallet.publicKey }).signers([keypair]).rpc();
    await program.methods.increment().accounts({ counter: keypair.publicKey, authority: provider.wallet.publicKey }).rpc();

    const state = await program.account.counter.fetch(keypair.publicKey);
    assert.strictEqual(state.count.toNumber(), 1);
  });
});

What I've tried:

Re-building and re-deploying the contract successfully on Testnet.
Hard-refreshing the playground browser environment.
Running test directly via the playground terminal console.

Despite the successful deployment and complete test script execution, the fetched state counter remains 0. Is there a known state-caching or deployment-sync quirk within Solana Playground that prevents the transaction from reflecting on the account state during test runner execution? Any help would be greatly appreciated!

Three Token-2022 Mints in One Week: Fees, Yield, and Soul-Bound Tokens -Hala Kabir

Hala Kabir — Sat, 13 Jun 2026 20:53:34 +0000

If you are coming from a Web2 background, adding custom behavior to a digital asset usually means writing complex application middleware, hacking core database schemas, or riskily altering base-layer logic. On Solana, things are completely different. Token-2022—the upgraded SPL (Solana Program Library) token standard—introduces Token Extensions.

Think of extensions as secure, native, plug-and-play middleware built directly into the blockchain's core layout. Instead of rewriting or auditing custom smart contracts, developers can opt into complex behaviors like native transaction taxes, automatic dynamic yield displays, or permanent transfer locks right at the mint's creation.

This past week, during my 100 Days of Solana challenge, I went into the trenches with Token-2022 to ship three distinct mints on devnet. Here is the exact breakdown of what I built, the terminal history behind them, and when you should reach for these extensions in production.

1. The Revenue Driver: Transfer Fees

The Extension

Extension Used: TransferFeeConfig
Devnet Mint Address: HPjCRBKC2nhWwrK8ZoZtv6cdTXv3pbHP6b9ndgqvXtDG
Solana Explorer Link: View on Solana Explorer

The Command
To spin up a token that automatically skims a 1% fee on every single wallet-to-wallet transfer (capped at a maximum of 5,000 whole tokens), I ran this in my terminal on Day 50:

# Create Token-2022 mint with a 1% transfer fee (100 basis points) and a cap of 5,000 tokens
spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 9 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 5000000000000

Gotcha Warning: The --transfer-fee-maximum-fee flag expects the amount in base units (lamports-equivalent for tokens). Because I set --decimals 9, I had to multiply my desired 5,000 token cap by 10 9 (5000000000000)so it didn't *accidentally * cap my fees at a tiny fraction of a token!

When to Reach for It
This extension lets you hardcode business economics directly into the asset. You would use this to build sustainable creator royalties on community tokens, automate a continuous protocol revenue skim on stablecoins, or fund a decentralized autonomous organization (DAO) treasury directly through user transaction volume without relying on third-party marketplace compliance.

2. The Multi-Extension Heavyweight: Hybrid Interest-Bearing & Fee Mint

The Extension
Extensions Combined: InterestBearingConfig + TransferFeeConfig
Devnet Mint Address: F1Xf67zwZnZzBjQ18fHtaEfJ6yzq6iGatNWvT9n5BgcJ
Solana Explorer Link: View on Solana Explorer

The Architecture (client.ts)
On Day 52, I wanted to see how far I could push Token-2022 by stacking extensions together. Instead of running basic CLI commands, I wrote a custom programmatic script in TypeScript (client.ts) to initialize a single Hybrid Mint that accumulates interest while simultaneously enforcing transfer fees.

The script successfully executed the entire transaction lifecycle on Devnet:

Created the hybrid mint address and associated token accounts.
Took an initial UI snapshot showing exactly 1000000tokens.
Paused script execution for 15 seconds to allow on-chain interest to compound natively.
Logged a post-pause UI balance increase to 1000000.237667 entirely from holding!
Transferred 1,000 tokens to a recipient wallet, automatically holding back the transfer fee.
Ran aFEE SWEEPcommand to harvest the withheld fees back to the primary wallet authority.

The Hard Truth About Native Yield

Here is the subtle architectural distinction that will save future readers hours of debugging: The interest-bearing extension does not mint new supply or change your underlying raw balance state. Instead, it modifies the displayed UI amount across wallets and block explorers using an on-chain timestamp formula relative to network time. The raw amount inside your token account remains exactly the same, but the network calculates and updates what the user sees in real-time. It’s perfect for visual, UI-driven yield tracking without the inflation or gas overhead of continuous minting transactions.

3. The Unbreakable Link: Non-Transferable (Soulbound) Tokens

The Extension

Extension Used: NonTransferable
Devnet Mint Address: HZUuPaia9C4aHZ3W9sp31sM56FF6pYK8dPYwbgwbWhtK
Solana Explorer Link: View on Solana Explorer

The Command
Finally, on Day 54, I built a token designed to act as a permanent badge of honor that absolutely** refuses to leave the wallet it’s delivered to:**

# Initialize a soul-bound mint that locks tokens permanently to the recipient
spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 0 \
  --enable-non-transferable

The Reality of Runtime Rejection

To ensure the validator network was strictly locking down this asset, I intentionally forced a standard spl-token transfer to a secondary wallet. The runtime didn't just quietly ignore it—it shut down the simulation instantly. M*y terminal logged this exact raw program failure:*

Error: Client error: Faulty transaction: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x12

Seeing custom program error: 0x12 (the hex representation of the Token-2022 program's native CannotTransferNonTransferableToken error) proved that this constraint is absolute. It is enforced natively at the protocol level, making it completely impossible for bad actors or unaligned UIs to bypass the transfer restriction.

Final Reflection

_What surprised me most about this arc was how beautifully clean the development flow is. If you tried to combine transfer fees, UI-driven interest modifiers, and soulbound transfer locks in an EVM environment, you’d be stuck writing, testing, and auditing hundreds of lines of custom Solidity code. Token-2022 shifts the paradigm entirely: complex, production-grade token mechanics are now treated as simple initialization configurations or clean TypeScript extension vectors rather than high-stakes custom software engineering.

By standardizing these patterns directly within the network, Solana makes it incredibly safe and straightforward to combine these primitives for real-world assets, institutional compliance tokens, and tamper-proof digital credentials._

#Have a coderfull day!

Needing Help for Missing 100 Days of Solana challenge -Hala Kabir

Hala Kabir — Mon, 08 Jun 2026 16:20:21 +0000

@niranjannlc & @matthewrevell please can you help or ask somone for help ....

Hi everyone,

I need some help regarding the 100 Days of Solana challenge.

I completed Day 46 and Day 47, but the next email I received was Day 50. I didn't receive any emails for the days in between. I also remember something similar happening earlier where I never received Day 35.

Could someone please check if they received:

Day 48
Day 49

If you did receive them, could you let me know whether those days actually exist in the email sequence?

And if possible, would you be willing to share the challenge links or forward the exact emails to me? I don't want to miss any lessons or fall behind because of missing emails.

Thanks a lot for any help!

Testers Needed For My First Google Playstore App -Hala Kabir

Hala Kabir — Wed, 03 Jun 2026 00:45:50 +0000

@janvinsha @niranjannlc @matthewrevell @sammie_ @rieljdev I will apriciate it soo much.....

🚀 EcoQuantum Solution Beta Testing

Step 1: Join our testing group
Join the group Here

Step 2: Become a beta tester
Download here

Step 3: Install the app from Play Store and test it.

Share Screen shot too after downloading
Please keep the app installed for 14 days and share feedback spent 2 mins daily on app 💚.

If any Problem please tag me in a post @halakabir234hub please, coment your problem or Email Me halakabir234@gmail.com

#Have A coderfull Day

Building Production-Ready DAO Platforms: Lessons from Reviewing a Full-Stack Web3 Application By Hala Kabir

Hala Kabir — Tue, 02 Jun 2026 22:29:35 +0000

The blockchain industry has evolved far beyond simple token transfers and NFT marketplaces. Modern decentralized applications increasingly require sophisticated architectures that combine frontend experiences, backend services, databases, and smart contract interactions.

Recently, I reviewed a DAO-style Web3 platform built using Next.js, Node.js, MongoDB, and blockchain integrations. The experience reinforced several important lessons about what it takes to build production-ready decentralized applications.

Why DAO Platforms Are Technically Challenging

At first glance, a DAO appears straightforward:

* Users connect a wallet
* Members create proposals
* Token holders vote
* Smart contracts execute outcomes

However, production systems are significantly more complex.

A complete DAO platform must coordinate multiple layers:

Frontend Layer

The user interface is responsible for:

* Wallet connection
* Transaction signing
* Governance dashboards
* Proposal management
* Voting interfaces

Frameworks such as Next.js provide a strong foundation for building responsive and scalable user experiences.

Backend Layer

Many newcomers assume DAO platforms are entirely on-chain.

In reality, backend systems often handle:

* Proposal metadata
* Analytics
* Notifications
* Caching
* User activity tracking
* Search functionality

Node.js remains a popular choice due to its flexibility and strong ecosystem.

Blockchain Layer

The blockchain serves as the source of truth for:

* Proposal creation
* Voting outcomes
* Treasury actions
* Governance execution

This layer introduces unique challenges related to transaction reliability, gas optimization, and security.

The Importance of On-Chain and Off-Chain Synchronization

One of the most critical architectural concerns is maintaining consistency between blockchain state and application state.

A common pattern involves:

Smart contracts emit events.
Backend services listen to those events.
Database records are updated.
Frontend applications display synchronized information.

Without proper synchronization mechanisms, users may encounter:

* Incorrect vote counts
* Stale governance data
* Delayed proposal updates
* Inconsistent treasury information

This is often where mature Web3 systems distinguish themselves from early-stage prototypes.

Wallet UX Matters More Than Most Teams Expect

Many Web3 projects focus heavily on protocol design while underestimating user experience.

A governance platform can have excellent smart contracts and still fail if users experience:

* Confusing transaction prompts
* Failed signatures
* Unclear voting confirmations
* Slow state updates

Improving wallet interactions directly improves trust and adoption.

Technical Risks Every DAO Team Should Monitor

Several risks consistently appear across DAO implementations:

1. Synchronization Failures

Blockchain events must be processed reliably to avoid inconsistent state.

2. Governance Abuse

Voting systems should protect against manipulation and proposal spam.

3. Backend Reliability

Even decentralized systems depend on reliable APIs, databases, and monitoring.

4. Security

Treasury management, permissions, and contract execution require continuous review.

What I Would Prioritize in an MVP

For an early-stage DAO platform, I would prioritize:

Stable wallet integration
Reliable proposal creation workflows
Accurate voting mechanisms
Event synchronization infrastructure
Monitoring and observability

These features establish trust before scaling into more advanced governance capabilities.

Final Thoughts

Web3 engineering is increasingly becoming a systems engineering discipline.

Success no longer depends solely on writing smart contracts. Teams must build reliable interactions between frontend applications, backend services, databases, and blockchain infrastructure.

The future of DAO platforms will belong to teams that can balance decentralization, usability, security, and operational excellence.

As I continue exploring DAO infrastructure, Solana development, and full-stack Web3 architecture, I'm excited by the opportunities that lie ahead for builders who can bridge these worlds effectively.

Beyond Basic Mints: Building Multi-Extension & Revocable Tokens on Solana 🚀-Hala Kabir

Hala Kabir — Tue, 02 Jun 2026 07:27:03 +0000

@niranjannlc

Hey developers! 👋

Last week, I dove into basic token mints, metadata, and simple transfer fees. But this week, I went into the deeper waters of Solana token development. If you are still writing complex off-chain logic to control how your tokens behave, you are missing out on the power of Token Extensions (Token-2022).

I just spent the last few days building and deploying advanced multi-extension tokens and testing revocable credential lifecycles on the Solana devnet. Here is a breakdown of what I built, how it works, and why it changes the game for on-chain assets.

🛠️ The Architecture: Multi-Extension Tokens

When you use the Token Extensions Program, you aren't limited to just one modification. You can layer extensions on top of each other at the moment of creation. For my latest build, I initialized a token mint that combines protocol-level economic rules with strict transfer parameters.

Instead of writing custom smart contract logic to intercept a transfer, check a condition, and deduct a fee, the Solana runtime handles it automatically at the account level.

Here is a look at how you set up a mint with multiple extensions using the TypeScript SDK:

TypeScript
import {
  Connection,
  Keypair,
  SystemProgram,
  Transaction,
  sendAndConfirmTransaction,
  TOKEN_2022_PROGRAM_ID,
  getMintLen,
  ExtensionType,
  createInitializeMintInstruction
} from '@solana/web3.js';

// Define the extensions we want to bundle together
const extensions = [
  ExtensionType.TransferFeeConfig,
  ExtensionType.MetadataPointer
];

// Calculate the exact space needed for this specific combination
const mintLen = getMintLen(extensions);

🔐 The Holy Grail: Revocable Credential Lifecycles

One of the coolest use cases I experimented with is the Revocable Credential Lifecycle. Imagine issuing a digital certification, a license, or an identity token that a user owns, but an authority needs the ability to revoke if necessary.

By combining Non-Transferable tokens (ensuring the user can't sell or trade their identity) with a Permanent Delegate, the issuing authority retains the ultimate power to burn or claw back the token if the credential expires or becomes invalid.

When you test this on-chain, the blockchain itself rejects any standard user transfer attempts with a hard TRANSFER FAILED error, yet the designated delegate key can execute administrative actions seamlessly.

🔥 What I Learned & What Clicked

Space Calculation Matters: You can't just allocate a random buffer size for Token-2022 mints. Because extensions vary in size, you must use getMintLen([ExtensionType]) to calculate the exact byte size before creating the account account.
Protocol > Off-Chain: Enforcing compliance and fees at the protocol level means absolute security. No one can bypass your transfer fees by interacting with a different liquidity pool or decentralized exchange; the rules are baked into the token's DNA.

🚀 What's Next?

Now that I have multi-extensions and credential lifecycles successfully running on the devnet, my next move is plugging these advanced tokens into custom Anchor programs to see how they behave when interacting with complex on-chain logic.

If you're still building on the original SPL token standard, it’s time to upgrade. Check out the official Solana Token Extensions Documentation and start shipping!

#Have a coderfull day

Needing Help for Missing 100 Days of Solana challenge -Hala Kabir

Hala Kabir — Mon, 01 Jun 2026 12:27:42 +0000

@niranjannlc please can you help or ask somone for help ....

Hi everyone,

I need some help regarding the 100 Days of Solana challenge.

I completed Day 39 and Day 40, but the next email I received was Day 43. I didn't receive any emails for the days in between. I also remember something similar happening earlier where I never received Day 35.

Could someone please check if they received:

* Day 35
* Day 41
* Day 42

If you did receive them, could you let me know whether those days actually exist in the email sequence?

And if possible, would you be willing to share the challenge links or forward the exact emails to me? I don't want to miss any lessons or fall behind because of missing emails.

Thanks a lot for any help!

Understanding Hermes Agent: Why Agentic AI Is More Than Just a Chatbot

Hala Kabir — Sun, 31 May 2026 19:19:04 +0000

Artificial intelligence has advanced rapidly over the last few years, but many AI systems still operate as simple chat interfaces. They can answer questions, generate text, and assist with tasks, yet they often stop at a single response.

This is where agentic AI becomes interesting.

Hermes Agent is an open-source agent framework designed to go beyond traditional chatbot interactions. Instead of only responding to prompts, it can plan tasks, use tools, and work through multiple steps before producing an answer.

What Makes Hermes Agent Different?

One of the biggest differences between a standard chatbot and an AI agent is the ability to take action.

A traditional chatbot might answer:

"What is the current gold price?"

An agent, however, can follow a process:

Retrieve information from a tool or data source.
Analyze the information.
Compare findings with additional context.
Generate a useful summary.

This approach allows the AI to solve more complex problems rather than simply responding with a single generated answer.

The Power of Multi-Step Reasoning

Many real-world tasks cannot be completed in one step.

Research, software development, data analysis, and automation often require a sequence of actions. Hermes Agent is designed with this idea in mind.

Instead of jumping directly to an answer, the agent can break a larger goal into smaller tasks and work through them logically. This creates a workflow that feels much closer to how humans approach problem-solving.

Why Tool Use Matters

Tool use is one of the most important capabilities in modern AI agents.

Without tools, an AI model is limited to the information available within the model itself. With tools, the agent can interact with external systems, retrieve information, and perform actions that would otherwise be impossible.

This capability significantly expands the types of problems an agent can help solve.

Why Open Source Is Important

Another aspect that makes Hermes Agent compelling is its open-source nature.

Developers can inspect how the system works, customize workflows, integrate new tools, and run the agent on their own infrastructure. This level of transparency and flexibility is important as AI systems become increasingly capable.

Open-source development also encourages experimentation and innovation by allowing the community to contribute improvements and new ideas.

My Take

What excites me most about Hermes Agent is not its ability to answer questions. Many AI systems can already do that.

The more interesting shift is toward AI systems that can reason through tasks, use tools effectively, and execute workflows. As AI continues to evolve, I believe these agentic capabilities will become increasingly important.

Hermes Agent represents an interesting step in that direction by combining planning, tool use, and multi-step reasoning within an open-source framework that developers can explore and build upon.

Whether you are interested in AI research, automation, or building intelligent applications, Hermes Agent is a project worth paying attention to.

From Basic Tokens to Soulbound Assets: What I Learned Building on Solana Token-2022 -Hala Kabir

Hala Kabir — Mon, 25 May 2026 21:33:02 +0000

From Basic Tokens to Soulbound Assets: What I Learned Building on Solana Token-2022

Over the past few days, I went from knowing almost nothing about Solana tokens to building Token-2022 assets with metadata, transfer fee mechanics, and even non-transferable “soulbound” tokens.

Coming from a more Web2 mindset, one of the biggest realizations for me was this:

On Solana, token behavior is enforced directly by the blockchain protocol itself not just by application code.

That completely changed how I think about digital assets.

Starting With a Simple Token

My journey started with creating a basic token mint on Solana devnet.

At first, it felt similar to creating records in a database:

create a mint
create token accounts
mint supply
transfer between wallets

But after experimenting more deeply, I realized Solana tokens are much more programmable than I expected.

Using the Token-2022 program, I could attach rules and behavior directly to the token itself.

Adding Metadata to Tokens

One of the first things I learned was that a token without metadata is basically just an address.

Adding metadata gave the token:

a name
a symbol
a metadata URI

Example:

const mint = await createMint(
  connection,
  payer,
  payer.publicKey,
  null,
  9,
  undefined,
  undefined,
  TOKEN_2022_PROGRAM_ID
);

This made the token feel more like a real product instead of raw blockchain data.

Understanding Transfer Fees

The next concept I explored was transfer fees.

In Web2 systems, fee logic is usually handled by:

backend servers
payment processors
APIs

But with Token-2022, fee behavior can be attached directly to the token design itself.

I simulated a 2% transfer fee model where:

sending 100 tokens
resulted in the recipient receiving 98
while 2 tokens were treated as fees

That was the moment I started understanding how blockchain protocols can enforce economic rules at the asset level.

The Most Interesting Part: Soulbound Tokens

The most fascinating experiment for me was creating non-transferable tokens.

These are sometimes called “soulbound” tokens.

Instead of behaving like currency, they behave more like:

certificates
badges
credentials
identity proofs

I created a Token-2022 mint and intentionally simulated a failed transfer attempt.

TRANSFER FAILED
Reason: Token is NON-TRANSFERABLE
Blockchain rejected transfer attempt

At first this seemed strange because most blockchain discussions focus heavily on trading and transfers.

But then it clicked:

Not every digital asset should be tradable.

A university certificate, event attendance badge, or verified identity token only has meaning if it stays attached to the original wallet.

That is where non-transferable tokens become powerful.

What Surprised Me Most

The biggest surprise was how much token behavior can be enforced at the protocol level.

In Web2:

platforms enforce rules in backend code

On Solana:

the blockchain itself can enforce those rules

That changes the trust model completely.

Another thing that surprised me was how quickly tooling differences appear between environments. Some Token-2022 CLI commands were unavailable in Solana Playground, so I had to adapt by using TypeScript implementations instead.

That debugging process honestly taught me a lot more than just following tutorials.

Key Concepts I Learned

Over these exercises, I learned:

how token mints work
how token accounts hold balances
how metadata gives identity to assets
how transfer fee systems operate
how Token-2022 extends the original SPL token standard
how non-transferable tokens can represent credentials instead of currency

Why Token-2022 Matters

Before this challenge, I thought tokens were mostly about cryptocurrencies.

Now I see them more as programmable digital assets.

A token can represent:

money
reputation
access
memberships
achievements
credentials

And Solana’s Token-2022 program gives developers much more flexibility in designing those systems.

What’s Next

I want to continue exploring:

advanced Token Extensions
NFTs and compressed NFTs
on-chain identity systems
Solana program development
real-world Web3 applications

This challenge gave me a much deeper appreciation for how blockchain systems can move beyond speculation and become infrastructure for digital ownership and identity.

                      # Have a Coderfull Day

The Biggest Google I/O 2026 Announcement Wasn’t a Model -Hala Kabir

Hala Kabir — Sun, 24 May 2026 18:59:02 +0000

When people talk about Google I/O 2026, most conversations will probably focus on Gemini’s newest models and multimodal AI capabilities.

But after watching the developer keynote, I think the most important announcement was something bigger than a model release.

It was Google’s vision for agent-first development through Antigravity.

More than any individual demo, the keynote showed a shift in how software may be built in the future: developers increasingly defining goals and workflows while intelligent agents handle execution.

From AI Assistants to AI Agents

One line from the keynote stood out to me:

“The big shift is our move towards agents, from AI that simply assists you to agents that help you get stuff done.”

That idea appeared throughout the entire presentation.

For the past few years, most AI tools for developers have worked like enhanced assistants:

autocomplete,
debugging help,
code suggestions,
or documentation summaries.

Google’s demos at I/O 2026 felt different.

Instead of simply helping developers write code faster, Antigravity focused on agents that can:

execute workflows,
manage tasks,
coordinate tools,
provision environments,
and operate with increasing autonomy.

That distinction matters.

The keynote wasn’t just about AI-generated code. It was about software workflows becoming agent-driven.

Antigravity Was the Real Star of the Show

The most interesting part of the keynote for me was how everything connected back to Antigravity.

Google introduced:

managed agents,
dynamic subagents,
scheduled tasks,
sandboxed execution environments,
Android integrations,
terminal workflows,
and tooling built specifically for AI-native development.

What stood out most was that Google positioned Antigravity not as a chatbot, but as infrastructure for orchestrating intelligent systems.

That feels like a major shift.

Managed Agents Solve a Real Problem

One of the smartest announcements was managed agents inside the Gemini API.

Building AI agent systems normally requires developers to handle:

orchestration,
execution environments,
scaling,
security,
and infrastructure management.

Google’s approach simplifies this dramatically:

one API call gives developers both the agent and the execution environment.

The Stitch demo showed this clearly. Their agent connected to a GitHub repository, analyzed the codebase, and automatically generated a design system file.

Not just text generation.

Actual development workflow automation.

And importantly, Google emphasized that developers can focus on building experiences instead of managing infrastructure complexity.

“Markdown Is the Hottest Programming Language”

One of the most memorable moments came when Logan Kilpatrick joked:

“Honestly, it feels like the hottest new programming language is Markdown.”

It was funny, but also surprisingly accurate.

Many of the workflows shown in the keynote relied on defining:

instructions,
tools,
skills,
and orchestration logic

through Markdown-based configurations.

That changes the role of developers.

Instead of manually implementing every process step-by-step, developers increasingly define intent, constraints, and capabilities while agents coordinate execution.

In many ways, developers are becoming orchestrators of intelligent systems rather than only writers of low-level implementation logic.

AI Studio Is Becoming a Real Development Platform

Another major takeaway was how quickly Google AI Studio is evolving.

The keynote demonstrated:

app generation,
Cloud Run deployment,
Android app creation,
Firebase integration,
Google Workspace integrations,
and Play Store publishing.

At this point, AI Studio feels much closer to an AI-native development environment than a simple experimentation playground.

The Android demos especially stood out to me. Seeing Kotlin Android apps generated, previewed, tested, and prepared for publishing through agent workflows felt like a preview of how development may look in the near future.

What excites me most is not replacing developers.

It’s reducing friction.

A huge amount of software development time is spent on:

setup,
configuration,
repetitive debugging,
deployment steps,
and environment management.

If agents can reliably reduce that overhead, developers can spend more time focusing on:

architecture,
user experience,
product thinking,
and solving meaningful problems.

The Web Announcements Were Quietly Important

The Chrome and web platform demos may end up being some of the most underrated announcements from the keynote.

Features like:

WebMCP,
Modern Web Guidance,
and Chrome DevTools for agents

suggest that Google is preparing the web itself for AI-native interaction.

The idea that websites can expose structured capabilities directly to browser agents feels like the early foundation of an “agentic web.”

One detail I found especially interesting was the emphasis on accessibility metadata and semantic structure. As browser agents become more capable, accessibility may become even more important because agents rely heavily on structured understanding of interfaces.

That’s a fascinating shift.

Final Thoughts

Google I/O 2026 showcased impressive AI models and polished demos, but I think the deeper story was about the evolution of software development itself.

The keynote presented a future where:

agents collaborate,
workflows become autonomous,
environments provision themselves,
and developers focus more on defining outcomes than manually implementing every step.

We are moving from:

“How do I build this?”

to:

“How do I define what I want built?”

And I think Google Antigravity may end up being one of the most important steps toward that future.

This article was written after watching the Google I/O 2026 developer keynote and reflecting on the direction of agent-first development.

--> By Hala Kabir

🚀 Looking for Android Beta Testers – EcoQuantum Solution 🌍💚 Hello DEV Community!

Hala Kabir — Sun, 24 May 2026 04:36:58 +0000

We recently launched the beta version of EcoQuantum Solution, a youth-led AI & sustainability platform focused on climate awareness, smart technology, and social impact.

We are currently looking for Android beta testers who can help us by:
✅ Testing app performance
✅ Reporting bugs or crashes
✅ Giving honest UX feedback
✅ Suggesting improvements before wider rollout

If you’re interested in supporting an early-stage mission-driven startup, feel free to comment or DM your Gmail address for access to our Google Play closed testing track.

Your feedback can help us improve the app and create better technology for humanity. 🌱✨

Android #BetaTesting #GooglePlay #AI #ClimateTech #Startup #DEVCommunity #EcoQuantumSolution