Crazy Embryo Club — a probabilistic on-chain reward engine with anti-streak fairness
Role: Backend developer (sole author, 89 commits / 100% of the repo) · Client: 3BUX LLC Stack: Node.js 20 · Express · MongoDB (Mongoose 7, 14 models) · Algorand JS SDK v2 · Redis (ioredis) · Bull · Cloudinary · Firebase · MailerSend/Nodemailer · PM2 (cluster, cron pinned to instance 0) Live: crazyembryo.club · API api.crazyembryo.club/api/v1 · Algorand mainnet On-chain: 5 sub-collections, 2,879 ASAs verified on-chain (creator addresses in the proof index) Timeline: Apr 2025 → Feb 2026 (~10 months)
The problem
Crazy Embryo Club is an NFT collection with a game economy bolted on: holders stake their CEC NFTs into time-boxed "Missions," pay an ASA entry fee, and win tiered rewards — ALGO, ASAs, or NFTs — drawn by a weighted-probability engine. That last part is the whole product, and it's deceptively hard:
- The draw must feel fair and be solvent. A pure random draw streaks — a run of top-tier wins drains the reward pool and kills the economy; a run of nothing-wins makes players quit. Both are failure modes.
- Rewards are real on-chain assets. Paying out means minting/transferring ASAs and NFTs from custodial wallets — under the same chain-unreliability constraints every Algorand backend faces.
- It's a public mainnet collection. 2,879 assets across five sub-collections are already minted and enumerable; the backend has to reason about real holders and real staked assets, not a database it controls.
Architecture
An EligibleNfts allowlist (a 1,119-line generated file) is the source of truth for which on-chain assets can stake. Mission reward wallets are ephemeral: each runs through a pending → available → unavailable state machine with its key AES-encrypted at rest, so reward custody is scoped and short-lived rather than one hot wallet holding everything.
The hardest decision: a 4-tier reward engine that defends its own economy
A naïve reward draw is one Math.random() against a static weight table. I built a 4-tier weighted-probability engine (a 145 KB controller) that actively corrects for the two failure modes randomness creates:
- Anti-streak / pity boosts. If a player keeps missing the top tier, a no-tier-1 boost gradually raises their odds; a consistency boost rewards sustained participation; progressive boosts compound over a losing run — so the system trends toward "feels fair" instead of leaving outcomes to raw variance.
- Per-tier caps. Each tier has a cap that throttles how fast it can be awarded, so a lucky cluster can't drain the high-value pool — the economy stays solvent without me hand-tuning emissions.
The tradeoff: this is far more stateful than a stateless dice roll — every draw reads and writes a player's streak history and the pool's tier budgets. I accepted that complexity because on a real-money-adjacent economy, "provably uniform random" is the wrong target; "fair-feeling and self-limiting" is the right one, and it can only come from a draw engine that remembers.
What I designed for
- Chain resilience.
algoUtils.js(62 KB) wraps ASA mint/transfer, atomic transaction groups, opt-ins, NFD, and Pera in circuit breakers + a Bottleneck limiter + backoff retry — reward payouts survive a flaky node instead of failing the mission. - Custodial-key hygiene. Mission wallets are ephemeral and AES-encrypted; keys never live longer than the mission that needs them.
- A hardened public surface. Helmet + a CSP pipeline (report-only mode with a violation collector), CORS allowlist, mongo-sanitize, xss-clean, and an endpoint allowlist.
- Holder comms + asset ops. Email (MailerSend/Nodemailer) + Discord alerts on wins; a chunked upload → Cloudinary pipeline for collection media.
Results
- 89 commits, sole author — 100% of the repo — a live mainnet NFT-staking economy, end to end.
- 14 models · ~30 endpoints, a 4-tier probabilistic reward engine with anti-streak pity logic, and 2,879 enumerable on-chain assets across 5 creator accounts.
- Custodial mission-wallet orchestration with AES-at-rest keys and a CSP-hardened surface.
What this demonstrates
Designing an economy, not just an API: a probabilistic system that stays fair and solvent under real variance, on-chain reward settlement hardened against an unreliable chain, scoped custodial key handling, and the security discipline (CSP, sanitization, allowlists) for a public mainnet product I owned entirely.