ViewReward — ads + airdrops with trustless on-chain settlement

Role: Backend developer (sole author, 1,647 commits, ~26k LOC) · Client: Apostrophe Corp Stack: Node.js · Express · MongoDB (Mongoose, 36 models) · Redis (ioredis + Bull + Redlock) · PM2 (cluster) · Algorand JS SDK · Cloudinary · Nodemailer · mongo-sanitize · express-rate-limit Live: viewreward.app (archived/low-traffic) · Timeline: Aug 2023 → Feb 2026 (~2.5 yrs) · Surface: 205 endpoints · 18 controllers · 16 routers · 9 crons

The problem

ViewReward lets projects fund airdrops and buy ad spots, and lets users claim airdrops. Money moves in both directions on Algorand, which creates the core challenge: you cannot trust anything the client tells you about a payment. A sponsor claiming "I funded the pool" or a user claiming "I'm eligible" has to be proven against the chain, and a popular airdrop is a juicy target for drain attacks. The backend's real job is being the trustworthy referee between sponsors, claimers, and the ledger.

Architecture

Auth is wallet-based: a user logs in with their Algorand address and gets a short-lived JWT access token plus a refresh token stored in an httpOnly cookie, with silent refresh every 8–10 minutes — so the access token stays out of JavaScript's reach while sessions stay seamless.

The hardest decision: a 3-step, on-chain-verified funding flow

Creating an airdrop isn't one request — it's a three-step state machine, and each step is gated on a transaction the backend independently verifies on-chain:

1. Create (pending) → the backend returns a dedicated go-between wallet address for the sponsor to fund.
2. Fund + opt-in → the sponsor sends ALGO (to cover transfers, opt-ins, and minimum-balance requirements) and submits the txID; the backend verifies it on-chain before opting the wallet into the asset.
3. Stock + activate → the sponsor transfers the airdrop assets and submits that txID; the backend verifies it, then flips the airdrop to active.

The tradeoff I accepted: this is more complex and more stateful than a one-click flow, and it introduces a custodial go-between wallet. I chose it because it's the only honest way to do it — every value-moving step is confirmed against the ledger before the system commits, so a sponsor can't activate an unfunded airdrop and the platform never fronts assets it hasn't received. The same pattern powers templates (reusable airdrop configs) and the advert workflow (spot pricing, admin approval, renewal, expiry).

What I designed for failure (and abuse)

• An on-chain transitive Sybil-detection engine — the deepest defense. One person spinning up hundreds of wallets to farm a single airdrop is the canonical attack. I built an engine that traces funding graphs across Algorand accounts — following who funded whom, transitively — to cluster wallets that share an origin and exclude the cluster before payout. It reasons about the public ledger, not just per-request rate limits, so it catches coordinated farming that looks innocent one wallet at a time.
• Rate-limiting against pool-drain — the headline threat. Claims are rate-limited and bounded by per-day user caps and 24-hour cooldowns, so a popular airdrop can't be emptied by rapid or scripted claims.
• Automated lifecycle — cron workers move airdrops through pending → active → inactive → expired and, when one ends, automatically refund the remaining ALGO and tokens back to the sponsor (handling opt-in/opt-out and minimum-balance edge cases on-chain).
• Fee + revenue integrity — configurable algoFee / tokenPercentage, tracked unclaimed fees, and per-ASA revenue accounting, so the platform's take is reconcilable.
• Input hardening — mongo-sanitize and rate limiting on the public surface.

Results

• 1,647 commits, sole author — among my largest and longest-running backends — over ~2.5 years, on a PM2 cluster with Redlock concurrency.
• 36-model schema covering airdrops, claims, adverts, ad settings, templates, fees, revenue, and user metrics across 18 controllers / 205 endpoints / 9 cron workers.
• An on-chain transitive Sybil-detection engine (funding-graph clustering) plus a funding flow where every value-moving step is verified on-chain before the system commits — the properties that make a multi-party airdrop platform safe to run.

What this demonstrates

Designing for an adversarial environment: trustless multi-step settlement verified against the ledger, drain-resistant claim limits, automated financial lifecycle with on-chain refunds, and secure session handling — the backend discipline that fintech and on-chain-settlement roles screen for.