Forem: Anika Jha

From Skeptic to Builder: My First Two Weeks with Solana

Anika Jha — Sun, 03 May 2026 09:37:24 +0000

Coming into Solana, I expected blockchain development to feel abstract and overly complicated. I assumed everything would revolve around tokens, wallets, and buzzwords that sounded impressive but didn’t translate well into actual engineering. Week 2 changed that perspective completely.

The biggest shift happened when I started reading on-chain data directly. Querying a wallet balance through RPC and fetching recent transactions felt surprisingly familiar. It reminded me of calling APIs in traditional development, except the source of truth wasn’t a private backend server; it was a public network anyone could inspect. That was probably the first moment blockchain started to feel real to me.

Another concept that clicked was Solana’s account model. At first, hearing “everything is an account” sounded vague. But comparing it to databases helped a lot. Wallets, programs, and stored state all exist as accounts with owners, permissions, and data. Instead of rows in tables controlled by one company, the data lives on a distributed ledger. Once I looked at it through that lens, it became much easier to understand.

I was also surprised by how developer-friendly some of the tooling felt. Using JavaScript to connect to devnet, fetch balances, and build a small browser dashboard made Solana feel less intimidating. It wasn’t some unreachable ecosystem; it was something I could interact with using tools I already know.

What’s still confusing? Smart contracts/program architecture at scale, Program Derived Addresses, and how advanced apps structure state efficiently. I understand the basics now, but I know there’s another layer of depth ahead.

What I want to learn next is the write side of blockchain development: sending transactions, interacting with programs, and eventually building full dApps.

Two weeks in, my biggest takeaway is this: blockchain stopped feeling like hype and started feeling like infrastructure.

No Logins, No Passwords: How Identity Actually Works on Solana

Anika Jha — Sun, 26 Apr 2026 16:25:34 +0000

If you’re coming from Web2, identity typically refers to usernames, email addresses, and passwords stored in a database. You sign up, log in, and a platform tells the system who you are.

On Solana (and blockchains in general), that model doesn’t exist.

There are no usernames.
There are no accounts owned by platforms.
There is no central authority verifying identity.

Instead,

your identity is your keypair.

Identity = A Digital Signature

The way this clicked for me was thinking about real-world signatures.

When you sign a document:
Anyone can see your signature
But only you can create it

That’s what proves you authorised something.

Solana works the same way, just digitally.

Your private key = your ability to sign
Your public key = what others use to verify that signature

You don’t log into Solana.
You sign things, and the network verifies that signature.

No Usernames, Just Public Keys

Instead of usernames, you get something like this:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5

This public key:

Is globally unique
Doesn’t require registration
Isn’t stored in someone else’s database You generate it locally, and from that moment on:

That key represents you everywhere on-chain.
No one issues it.
No one can take it away.

In Web2:

Platforms control your account
They can lock you out

On Solana:

Only your private key can authorise actions
No company sits in the middle

Ownership is cryptographic, not permission-based.

But there’s a tradeoff:
Lose your key → lose access
No recovery.

Every Action Is a Signature

When you:

Send SOL
Interact with a program

You’re doing one thing: Signing a transaction
The network verifies it and executes the action.
No sessions. No cookies. Just signatures.

How Apps Recognise You

Instead of “Sign in,” dApps use:
“Connect Wallet”
They read your public key and use that as your identity.
If needed, you sign a message to prove ownership.

Final Thought

The biggest shift is this:
In Web2, platforms give you identity.
In Solana, you own it.

Your wallet isn’t just a tool.
It’s your identity and your ability to prove it.

gh-excavate: Unearthing Code with GitHub Copilot

Anika Jha — Sat, 07 Feb 2026 17:16:59 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Stuck with an unknown repository at 2 AM?
Accidentally deleted production code and trying to figure out what it even did?
Inherited a codebase with zero documentation?

We’ve all been there.

I built gh-excavate — an AI-powered GitHub CLI extension designed for code archaeology.

It’s a terminal-native assistant that helps you understand not just what code does, but why it exists.

Instead of manually browsing commits, scanning files, and piecing together context, you run a single command and gh-excavate digs through the repository for you.

It can:

Analyse a repository or folder to explain its purpose, architecture, and risks
Trace the life of a file from creation to deletion
Detect likely dead or forgotten code
Help investigate “why does this exist?” moments
Work on both local paths and remote GitHub repositories

The CLI handles the structure.
Git handles the history.
GitHub Copilot is the brain and soul of the operation, aka the reasoning engine.

Copilot synthesises context, interprets intent, and transforms raw code and git history into human-level explanations directly in the terminal.

gh-excavate doesn’t just read code.It interprets it.

Demo

Repository:
[gh-excavate](https://github.com/Anika-Jha/gh-excavate)

gh-excavate is a GitHub CLI extension. Once installed, it runs directly inside your terminal.

Installation

Verification

Commands

Example runs

My Experience with GitHub Copilot CLI

GitHub Copilot CLI fundamentally changed how I approached building this project.

Instead of relying on brittle heuristics and heavy parsing logic alone, I focused on designing meaningful prompts, extracting the right context from Git history, and structuring the CLI intelligently — while Copilot handled deeper reasoning.

Copilot became:

The interpretation engine
The architectural analyst
The technical historian
The context synthesiser

gh-excavate gathers the evidence — commit logs, file history, structural context. Copilot CLI connects the dots.

The most important realisation during development was this: the real problem isn’t accessing code — it’s understanding intent. Git tells you what changed. Copilot helps reason about why.

Working directly in the terminal with Copilot felt natural and developer-native. I could validate Git commands, reason about edge cases like file deletions, and refine workflows without leaving the CLI.

This project isn’t just about automation.
It’s about augmenting developer cognition.

Because when you're lost in a codebase, you don’t need autocomplete.

You need understanding.

Code ages. Context fades.
gh-excavate helps bring it back.

** When the git log gets cryptic, and production is on fire — excavate. Because “Who wrote this?” is not a strategy.**
**