DQN Web3 Growth Engine by Aniket GhavteDQN Web3 Growth Engine by Aniket Ghavte

DQN Web3 Growth Engine

Aniket Ghavte

Software Engineer

Node.js

TypeScript

Next.js

DQN Org

worked as - Founding Software Developer

DQN – Building a Web3‑Native Growth Engine

DQN Dashboard Overview

I've spent the last few years living at the intersection of product, engineering, and crypto. At some point I got tired of seeing "web3 projects" that were basically landing pages with a smart contract bolted on. So I did what most stubborn CTOs do: I built the platform I wished existed.

I call it DQN.

DQN is a web3‑native growth engine: a backend engine plus operational consoles that let you:

Track real token and NFT activity on‑chain

Turn that data into leaderboards, quests, raffles, and rewards

Run the entire thing with production‑grade security, observability, and admin tooling

In this post, I want to walk you through what I built, why I built it, and how the pieces fit together – in plain English, as if we were sitting across the table with coffee.

What DQN Actually Is (In One Sentence)

DQN is a Node.js + TypeScript Web3 engine (dqn-engine) powering a pair of Next.js operational consoles (dqn-console and 404-console) that together form a complete system to measure, motivate, and reward on‑chain communities.

If you prefer visuals:

High-level architecture diagram: engine + consoles + blockchain

DQN Architecture Overview

The Three Pillars: Engine + Consoles

1. `dqn-engine`: The Web3 Brain

dqn-engine is the backend brain of the system. It's a production‑ready Node.js/TypeScript/Express service that does the heavy lifting:

On‑chain data ingestion

Syncs token transfers and NFT activity from the blockchain (via Alchemy, Moralis, etc.)

Maintains collections such as DqnHolder, NFT, Order, Raffle, Quest, Leaderboard, and more.

Tracks only holders with non‑zero balances and maintains incremental sync state to avoid rescan overhead.

Engagement & rewards logic

Models quests, raffles, blood points (our engagement currency), and leaderboards.

Exposes clean controllers for auth, user, product, blockchain, dqn, volume, etc.

Schedules recurring jobs via node-cron (and a CronManager) to keep data fresh.

Operational reliability

Split API and cron processes (server.ts and cronServer.ts) with watchdog scripts to make sure jobs don't silently die.

Structured logging with Winston, plus separate combined/error logs for debugging.

Dockerized, with CI/CD‑friendly config and multi‑stage builds.

Security & stability

Helmet for secure HTTP headers.

JWT authentication and rich middleware: auth, admin-auth, user, validation, security, health.

Rate limiting, CORS configuration, and input validation via express-validator.

Strong typing end‑to‑end thanks to TypeScript and typed Express/Mongoose models.

From an engineering perspective, the engine is basically a Web3‑aware, security‑hardened API that also runs scheduled jobs, syncs the chain, and drives all the "smart" parts of DQN.

2. `dqn-console`: The Operations & Growth Console

If dqn-engine is the brain, dqn-console is the control room.

This is a Next.js 15 app (App Router) with Tailwind, Radix UI, React Query, Redux, MongoDB, and an authentication layer. It's what an ops/growth/marketing team would actually live in day‑to‑day.

At a high level, dqn-console gives you:

Authentication & access control

Modern auth stack (Clerk / NextAuth + JWT) with protected and public routes.

A clear split between (public) (e.g. login/signup) and (protected) app space.

Operational views

dashboard: top‑level health of the ecosystem.

users: user list and insights, backed by Admin and User models in MongoDB.

events: event/activity streams.

bounties & quests: management UIs for on‑chain and off‑chain tasks with QuestCreationForm and associated flows.

nfts: NFT gallery and controls.

shop: manage items you can tie to blood points, quests, or holdings.

Modern frontend architecture

Radix UI primitives + Tailwind + shadcn‑style components (button, tabs, table, tooltip, etc.).

React Query for server state, Redux Toolkit slices for UI/application state (auth, chats, infinite scroll, search, online members, etc.).

MongoDB + Mongoose models behind a typed db.ts layer.

Clean separation of concerns: actions/ for server actions, hooks/queries for data fetching, components/common for layout and shared widgets.

In practice, this console is where you create campaigns, manage users, configure rewards, and monitor how your community is behaving – all powered by the data and business logic from dqn-engine.

Admin dashboard screenshot placeholder

DQN Admin Console

3. `404-console` (`dqn-leetboard`): The On‑Chain Leetboard

Finally, there's 404-console, internally titled dqn-leetboard.

This is a Next.js 15 + Tailwind application focused on the external‑facing side of reputation and status:

Token holder leaderboard

Scripts like getTopHolders.ts, parseUsers.js, and CSVs of top holders (top 100/250) feed into the UI.

Uses the same Web3 stack (Ethers, RainbowKit, Wagmi, Viem) to connect wallets and read on‑chain state.

Visual components and assets (like ai404.jpg) to brand the leaderboard as a "404 / error‑themed" experience.

Community‑facing experience

Display real‑time or near real‑time rankings.

Let users connect wallets, see their standing, and understand how to climb the leaderboard.

Use color extraction, motion, and sound (color-thief-browser, framer-motion, use-sound) to make it feel alive rather than "just another table."

If dqn-console is for operators, 404-console is for players and community members. It's where your most engaged holders show off, compare, and get a tangible sense of progress.

Leaderboard screenshot placeholder

DQN Leaderboard (404 Console)

How the Pieces Talk to Each Other

Here's the simplified picture:

Blockchain layer — Token contracts, NFT contracts, transfers, and events live on‑chain.

dqn-engine — Listens to and fetches blockchain events. Normalizes and stores them in MongoDB: holders, NFTs, orders, raffles, volume, blood transactions, etc. Runs cron jobs to keep everything in sync and rebuild leaderboards.

Consoles — dqn-console (internal): authenticated admins/ops use it to create quests, manage rewards, curate products, and inspect users. 404-console (external): community members use it to see rankings, connect wallets, and engage with what you've set up.

APIs — Both consoles talk to dqn-engine via APIs (REST controllers and typed routes). Auth middleware ensures only the right calls are allowed (e.g., admin vs user vs public).

Data flow diagram placeholder

DQN Data Flow Architecture

A Few Things I Was Intentional About (CTO Brain Mode)

Security by default

I didn't want to ship yet another "works on localhost" prototype. So security was non‑negotiable:

Helmet, CORS, and rate limiting baked into the middleware stack.

Input validation via express-validator so the API doesn't accept garbage.

JWT-based auth with separate user/admin flows.

Least‑privilege APIs – everything admin‑sensitive is behind dedicated middleware.

Logs are structured and split; you can actually investigate issues in production.

Operational resilience

It's not a real system until it survives the weekend.

Cron vs API separation: cron and API servers run as distinct processes, each with their own watchdog.

Typed models & tests: Jest is wired for unit/integration tests, plus helpers for auth and Express requests.

Dockerized: you can build and run as containers, or orchestrate via docker-compose alongside other services.

Performance & DX

Performance and developer experience often fight each other; I tried to respect both:

TypeScript everywhere (engine and consoles) to avoid runtime surprises.

Modern frontend tooling (Next.js 15, Turbopack, React Query, Redux Toolkit).

Smart incremental sync on the engine side: we track last processed blocks so we don't keep hammering RPC providers needlessly.

Linting, formatting, and pre‑commit hooks (eslint, prettier, lint-staged, husky) so the codebase stays consistent.

Who Is DQN For?

If you're:

Running a token or NFT project and want something deeper than a Discord bot;

Building a community‑driven app where on‑chain behavior should map to quests, perks, and status;

Or you're just a developer who wants a real reference architecture for a web3 backend plus consoles…

…then DQN is exactly the kind of stack I wish someone had handed me years ago.

Where I Want to Take It Next

A few directions that are on my radar:

More pluggable reward engines – being able to drop in new "reward types" without redeploying the world.

Multi‑chain support – making the engine truly chain‑agnostic with a clean provider abstraction.

Deeper analytics – time‑series, funnels, and cohort analysis directly tied to on‑chain and off‑chain actions.

Self‑serve onboarding – so non‑technical teams can deploy their own DQN instance with minimal friction.

Roadmap / future vision illustration placeholder

DQN Roadmap & Future Vision

Closing Thoughts

I built DQN the way I think a CTO should build: secure by default, production‑first, with real operational workflows in mind – not just pretty screenshots.

If you're interested in:

Adapting this stack to your own project,

Stress‑testing the architecture,

Or just nerding out over Web3 infra and growth mechanics,

feel free to reach out. I'm always happy to talk shop – especially with folks who care about both engineering quality and real user impact.

Like this project

Posted May 21, 2026

Web3-native growth engine for tracking token and NFT activities with a focus on community engagement.

Likes

Views