DEV Community: Anika Jha

🦇 The longest day of the year. The worst day to be a vampire. Race through June-inspired worlds, dodge sunlight, solve puzzles, and find your missing coffin before sunset in this whimsical browser adventure. ☀️ One day. ⚰️ One coffin. One very tired 🦇 .

Anika Jha — Fri, 19 Jun 2026 13:29:32 +0000

June Solstice Game Jam Submission

Anika Jha

Jun 18

Long Day, Tiny Vampire

#devchallenge #gamechallenge #gamedev #junesolsticegamejam

3 min read

Long Day, Tiny Vampire

Anika Jha — Thu, 18 Jun 2026 04:59:13 +0000

This is a submission for the June Solstice Game Jam

One day. One coffin. One very tired vampire.

Link for gameplay

(long-day-tiny-vampire)

What I Built

The longest day of the year.
The worst day to be a vampire.

🦇☀️⚰️

Long Day, Tiny Vampire is a browser game about a tiny vampire whose coffin gets accidentally shipped away during a series of June celebrations.

Now he's stuck outside on the June Solstice, desperately trying to get home before sunset.

Along the way, you'll:

🍣 Hide beneath giant sushi trays on International Sushi Day

🩴 Launch yourself across beaches during National Flip-Flop Day

🌈 Cross rainbow pathways created by music at a Pride Parade

🔐 Solve cryptic puzzles in an Alan Turing-inspired garden

☀️ Survive the Longest Afternoon, where shadows almost disappear

The goal? Get home. Try not to become ash.

Video Demo

Code

Built as a browser game so anyone can play instantly.
Check out the GitHub Repository

How I Built It

I wanted every level to feel like a completely different celebration rather than repeating the same platforming mechanics over and over.

Instead of designing five levels with the same gameplay, I built five different puzzle experiences connected by a single survival mechanic: sunlight.

The central system is the Dynamic Shadow System.

As the day progresses, the position of the sun changes, and shadows become smaller and smaller. Safe zones literally shrink as the player moves closer to the harshest part of the day. By the time players reach The Longest Afternoon, finding shade becomes a puzzle of its own.

Each celebration introduces a different style of interaction:

Sushi Day focuses on timing and moving shadows.
Flip-Flop Day uses physics-based traversal.
Pride Parade introduces chromesthesia-inspired puzzles where music paints the world with colour.
Turing's Garden focuses on pattern recognition and codebreaking.
The Longest Afternoon becomes a resource management challenge where every patch of shade matters.

To reinforce the feeling of a journey, I added several narrative systems:

Postcards left behind by the missing coffin.
Time-based dialogue from Nox and the Sun.
Solstice Memories hidden throughout the world.
Optional secret routes and alternate paths.

One of the biggest design goals was making the player feel the passage of time.

The game begins at sunrise.

The game ends at sunset.

Everything in between is a race against the longest day of the year.

Prize Category

Best Ode to Alan Turing

One of the game's major locations is Turing's Garden, a puzzle-filled maze inspired by Alan Turing's work in logic, cryptography, problem solving and Butterflies.

Players solve pattern-based challenges, decode encrypted notes, and uncover a hidden ending that celebrates curiosity, imagination, and the importance of being yourself.

Rather than treating Turing as a historical footnote, I wanted his influence to feel woven into the experience itself.

A hidden Alan Turing ending for players who collect every encrypted note!!

Best Google AI Usage

Google AI was used throughout the ideation and design process to explore gameplay concepts, refine puzzle ideas, shape narrative elements, and iterate on level design.

The game evolved from a simple "vampire versus sunlight" concept into a journey through June celebrations, blending storytelling, puzzle mechanics, and emotional progression into a cohesive experience.

Transfer Fees, Metadata, and Soulbound Tokens: My First Real Token Experiments on Solana

Anika Jha — Mon, 25 May 2026 08:45:14 +0000

Coming from a Web2 background, I thought tokens were basically just “crypto coins.”

After building on Solana for the past few days, I realised they’re closer to programmable economic systems.

In a single week, I created:

fungible tokens
tokens with on-chain metadata
protocol-level transfer fees
non-transferable “soulbound” tokens

And the craziest part?

Most of it required zero smart contract code.

Creating My First Token

The first time this clicked was when I ran:

spl-token create-token

That one command created a real token mint on Solana devnet.

Then I minted supply into my wallet:

spl-token mint <MINT_ADDRESS> 1000

At that moment, I had effectively created my own on-chain currency.

Not a database entry.
Not a mock project.
An actual blockchain asset.

Metadata Made Tokens Feel Real

Without metadata, tokens are just unreadable addresses.

Using Token-2022, I added:

a token name
symbol
metadata URI

spl-token initialize-metadata \
<MINT_ADDRESS> \
"ReinforceCoin" \
"RFC" \
"https://example.com/metadata.json"

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

Transfer Fees Were the Coolest Part

Then I experimented with transfer fees.

I created a token with a built-in 2% fee:

spl-token create-token \
--transfer-fee-basis-points 200

When I transferred 100 tokens, the recipient only received 98.

The remaining 2 tokens were automatically withheld by the protocol itself.

No backend.
No middleware.
No custom logic.

The blockchain enforced the economics.

That was the moment tokenomics finally made sense to me.

Soulbound Tokens Felt Like the Future

The most interesting experiment was creating a non-transferable token:

spl-token create-token \
--enable-non-transferable

I tried transferring it to another wallet.

The transaction failed instantly.

Not because my app blocked it —
because the token program itself rejected the transfer.

That immediately made me think about:

certificates
university credentials
attendance badges
KYC verification
reputation systems

All enforced directly on-chain.

What Surprised Me Most

The hardest part wasn’t the commands.

It was understanding Solana’s account model:

wallet addresses
mint accounts
token accounts
associated token accounts

I kept confusing them constantly.

But once that mental model clicked, the entire ecosystem started making sense.

Final Thoughts

Before this, blockchain development felt abstract.

Now it feels surprisingly practical.

I’m starting to see Solana less as “crypto” and more as infrastructure for programmable ownership, incentives, and identity.

And honestly?

Watching token economies work directly from the terminal was way more fun than I expected.

Why Solana’s Account Model Broke My Web2 Brain

Anika Jha — Tue, 19 May 2026 14:23:39 +0000

If you come from Web2, Solana’s account model feels weird at first.
You expect databases, backend servers, and application state living somewhere behind an API.

Instead, Solana gives you one core idea:

Everything is an account.

Wallets are accounts.
Programs are accounts.
Token balances live in accounts.
Even smart contract state is stored in accounts.

Unlike Ethereum, which separates wallets and contracts, Solana uses one flat account model for everything.

A Solana account has five main fields:

lamports → the SOL balance (1 SOL = 1 billion lamports)
data → raw bytes storing account state
owner → the program allowed to modify the account
executable → whether the account is runnable program code
rent_epoch → deprecated field related to rent collection

The biggest mental shift for me was understanding that:

Programs do not store their own state.

On Solana, programs are mostly stateless.
The executable code lives in one account, while separate data accounts store application state.

Coming from Web2, the best analogy I found is a filesystem:

Programs = executable binaries
Data accounts = files/databases
System Program = operating system kernel
Public keys = file paths

Programs simply read and write to accounts they are given access to.

Another interesting rule: only the owner program can modify an account’s data or debit lamports from it. But anyone can send lamports to an account. That ownership model is much simpler and stricter than traditional backend permission systems.

I also found Solana’s rent model surprisingly elegant. Accounts must maintain a minimum SOL balance proportional to their data size to remain on-chain. Instead of hiding storage costs behind infrastructure bills, Solana exposes them directly at the protocol level.

The coolest part is realizing how transparent the system is.
Using Solana Explorer or RPC calls, you can inspect accounts, transactions, balances, program interactions, and state changes in real time.

At some point it stopped feeling like “using a blockchain” and started feeling like debugging a distributed operating system.

Why Solana Transactions Feel More Like Database Commits Than API Calls

Anika Jha — Sat, 09 May 2026 14:35:25 +0000

The first time I sent a Solana transaction, I expected it to behave like a normal API request:

Send request → wait → success/failure.

But after debugging failed transactions on devnet, inspecting logs in Solana Explorer, and manually tracking confirmations, I realised Solana transactions behave much more like database commits than HTTP calls.

That mental model shift finally made blockchain development click for me.

A Solana Transaction Is More Than a Request

A transaction contains:

signatures (authorization)
instructions (operations)
account keys (state involved)
a recent blockhash (replay protection)

Unlike a typical API request handled by one server, every validator in the network verifies and executes the transaction independently before agreeing on the final state change.

That’s a completely different architecture from most Web2 systems.

Failed Transactions Taught Me the Most

What surprised me most was that failed transactions still exist on-chain.

Even when a transfer fails, the transaction can still:

have a signature
consume compute units
generate logs
charge fees

I intentionally triggered failed transactions on devnet and inspected them in Solana Explorer. Seeing execution traces and program logs for a failed transfer felt less like debugging an API request and more like analysing a distributed database operation.

Solana Transactions Are Atomic

This was another huge difference.

In Web2 systems, partial failures happen all the time. One service succeeds, another fails, and retries happen later.

On Solana, transactions are atomic:

Either every instruction succeeds
or the entire transaction rolls back

But validators still charge fees because the network still processes the workload.

That behaviour reminded me much more of SQL transaction commits than REST APIs.

Final Takeaway

The biggest challenge in learning Solana wasn’t the SDK or RPC calls.

It was changing how I think about state changes.

Once I stopped viewing transactions as API requests and started viewing them as signed, atomic, distributed state transitions, everything started making more sense.

And honestly, that shift is what makes blockchain development interesting in the first place.

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