Forem: Prasiddh Naik

BharatZero

Prasiddh Naik — Fri, 08 May 2026 12:34:30 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

BharatZero is an India-focused legislative explorer that aggregates parliamentary data spanning 1947 to the present into a unified, searchable platform. The app solves a critical transparency problem: India's legislative information is scattered across dozens of government portals (Sansad, PRS Legislative Research, Parliament Digital Library, Data.gov.in), hidden in PDFs, and nearly impossible to navigate comprehensively.

BharatZero brings it all together:

4,708 bill records from three different official sources
7,253 timeline events tracking parliamentary activity
2,560 sitting days with chronological browsing
Prime Minister term filtering—see what legislation passed during any PM's tenure
Complete source attribution for data provenance

The platform features eight sections: Overview, Houses (with Lok Sabha power charts), Timeline, Bills, Committees, Debates, Acts, and Sources. Every record shows exactly where it came from—critical for democratic transparency.

Demo

bharatzero.vercel.app

Code

prasiddhnaik / Bharat0

BharatZero

BharatZero is an India-focused legislative explorer for bills, Acts, Parliament timelines, House power, Prime Minister terms, and official source coverage. It is built as a Vite/React frontend with a small Node API server, Prisma, and PostgreSQL/Neon.

The current app is no longer just a static prototype. It uses generated legislative datasets plus a Prisma-backed repository path for runtime data.

Current Coverage

Generated local datasets currently include:

4,708 Bill records
7,268 Bill action records
7,253 timeline events
2,560 sitting days
217 Act records
15 Prime Minister profile records
16 Lok Sabha power snapshots

Main source families:

Sansad legislation data, as of 2026-04-25
PRS historical bill data, 1992-2019
Parliament Digital Library bill/proceeding data, 1947-2003
Curated Prime Minister profile data from PM India
Curated Lok Sabha power snapshots from ECI/IPU-style election summaries

The PDL sync now covers older Prime Ministers, including Nehru, Shastri, Nanda, and Indira Gandhi-era windows where source records exist.

…

View on GitHub

How I Used Gemma 4

I chose Gemma 4 31B Dense (gemma-4-31b-it) via the Gemini/OpenAI-compatible API for bill analysis generation. Legislative bills are dense, technical documents—often 50+ pages of legal language. Citizens, journalists, and researchers need accessible summaries, but manual summarization doesn't scale across 4,700+ bills.

BharatZero uses Gemma 4 to generate plain-language summaries, economic impact analysis, key provisions extraction, and social implications analysis. The model handles the bilingual nature of Indian legislation seamlessly—bill titles and summaries work in both English and Hindi contexts without separate model tuning.

Analysis is expensive, so BharatZero implements a persistent cache layer. Once a bill is analyzed, results are stored in PostgreSQL. Subsequent requests serve cached results instantly.

Why Gemma 4 31B Dense was the right fit:

Long context: Bills are lengthy documents; Gemma 4 handles full text input
Structured output: Returns consistent JSON for parsing into the UI
Factual accuracy: Critical for legislative analysis—hallucinations are dangerous
Cost efficiency: More economical than alternatives for high-volume batch analysis

solana notes - week 2

Prasiddh Naik — Wed, 06 May 2026 14:26:30 +0000

100DaysOfSolana

i've used normal databases for years, so i kept trying to force solana into that shape. tables, rows, queries. some of that helps, a lot of it breaks.

what surprised me

reading a balance is stupidly simple:

const { value: balanceInLamports } = await rpc
  .getBalance(targetAddress)
  .send();

the code is easy. the mental model is what's hard.

the click moment

ran solana account $(solana address) and saw my wallet data. then realized: anyone can do this. no api keys, no auth. just the public key and you're reading someone's balance.

that's uncomfortable in a good way. in web2 data is hidden unless i expose it. here it's visible unless i design around it.

the sdk

@solana/kit feels normal. not crusty like i expected. async/await, clean imports. the devnet() and mainnet() wrappers aren't just for show—they actually tag the network for type safety. someone thought about DX.

where the database comparison breaks

normal thinking	solana reality
sql joins	lol no. fetch signatures, then fetch details
private by default	public by default
i control who reads	everyone reads
alter table, migrations	nope. design upfront, serialize to bytes

i keep wanting SELECT * FROM transactions WHERE user_id = 123. instead:

const signatures = await rpc
  .getSignaturesForAddress(address, { limit: 5 })
  .send();
// then fetch each one i guess

more manual. that's the tradeoff.

devnet vs mainnet hit different

--- Devnet ---
Balance : 0.001159846 SOL

--- Mainnet ---
Balance : 0.069875097 SOL

same address, same code, different world. staging vs production except anyone can view production.

still fuzzy on

PDAs - when do i actually use them vs regular accounts?
rent - deposit not fee, but the exact economics? need to build something that creates/closes accounts
cross-program calls - just words to me right now
writing transactions - reading is safe. writing feels serious. nervous about it.

send a simple transaction
one PDA example end to end
build something that actually writes, not just reads

where i'm at

day 12. not an expert. but less intimidated.

the code looks familiar while the assumptions underneath are totally different. public data by default. accounts instead of tables. pay for storage not queries. still rewiring my brain.

if you're also confused by accounts, PDAs, or why everything is public: same. i think that's just part of it.

What Does "Identity" Actually Mean on a Blockchain?

Prasiddh Naik — Sat, 25 Apr 2026 11:17:13 +0000

If you've been writing code for a while, you've probably used SSH keys. You generate a key pair, drop the public key on a server, and from that point on, you prove who you are by holding the private key. No username, no password reset. You either have the key, or you don't

Solana identity works on the same principle: you have the key, or you don't — except that, instead of a single server, it's the entire network.

The problem with Web2 identity

In Web2, you have no power; you're just renting space. You don't control your GitHub or Google accounts; the company does. They give you access, but they can also take it away.

Even when it feels like yours, it isn't. Your email address exists because Google or Microsoft allows it to.

How Solana does it differently

On Solana, your identity starts with a single cryptographic keypair — a public key and a private key. The public key is your address, something like 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5. That's what the world sees. The private key never leaves your wallet, and it's the only thing that can authorize actions on your behalf.

No company issues this key pair. No server stores it. You generate it yourself, you hold it, and it works across every application on the Solana network without asking anyone's permission. There's no sign-up form, no email verification, no "log in with Google." Your keypair is your identity, and it's yours in a way that a Web2 account never is.

Ownership that actually means something

Here's the part that takes a moment to sink in: on Solana, only the holder of the private key can sign transactions for an account. Not a company. Not an admin. Not a support team. There's no password reset flow, no "verify your identity" email, no override. If you hold the private key, you control the account. If you lose it, it can't be recovered.

That sounds scary, and it is if you're careless. But it also means no one can lock you out of your own account. No platform ban, no policy change, no company going bankrupt takes your identity with it. The tradeoff is real responsibility — but so is real ownership.
What this identity actually unlocks

On-chain identity isn't just a replacement for a username. Because it's cryptographic, it becomes the foundation for everything else on the network. Token ownership is tied to your keypair. When you vote in a DAO governance proposal, your keypair is the vote. When you interact with a program, your keypair authorizes it. When you build a reputation across DeFi protocols or NFT platforms, it all traces back to the same address.

In Web2, your reputation on GitHub doesn't carry over to LinkedIn, which doesn't carry over to your bank. Each platform starts from zero. On Solana, your keypair is consistent across the entire ecosystem. Any application can read your on-chain history without you having to re-verify anything.

Forem: Prasiddh Naik

BharatZero

What I Built

Demo

Code

prasiddhnaik / Bharat0

BharatZero

Current Coverage

How I Used Gemma 4

solana notes - week 2

100DaysOfSolana

what surprised me

the click moment

the sdk

where the database comparison breaks

devnet vs mainnet hit different

still fuzzy on

next

where i'm at

What Does "Identity" Actually Mean on a Blockchain?