Flavio Espinoza

Single Sign-On | Web3Auth + OIDC — The onboarding collapse. One button replaces the email/password/verify march, and produces a real self-custodial wallet rather than a database row.

1. A.One headless entry point -- uses the Web3Auth no-modal SDK so the login UI is mine, not a third-party popup, while Web3Auth handles the OIDC federation for Google, GitHub, and passwordless email behind a single login(type) call.
2. B.Real wallet, invisible to the user -- after federation, the flow derives a Solana wallet, requests its account, and uses it as the user's identity; the person never sees a seed phrase or a wallet prompt during signup.
3. C.Challenge-response, not a password -- the client fetches a server nonce, signs it with the derived wallet, and exchanges the signature plus public key for a session JWT, so identity is cryptographically proven instead of credential-based.
4. D.Referral capture at the door -- the signup URL's ?ref= code is read off the query string and threaded into the auth challenge, so attribution happens at the exact moment of account creation with no extra step.

The Growth Loop | Referrals, Social Boosts, Achievements — The PLG engine, and the part the recruiter call centered on. When I arrived the referral program already existed -- a 10% bonus with a referral-count tier ladder -- and it was underperforming. My contribution was to compound it: stacked, OAuth-verified social and quiz boosts layered on top, all summing into one live "Total Boost."

1. A.The referral that predated me -- a flat +10% ("Blessed User") for referring or being referred, plus a referral-count tier ladder climbing from +5% (1 referral) to +30% (100). This was already in place before I joined; it was the lever that was not compounding, not something I built.
2. B.What I built -- the stacked social and quiz boosts: +5% for connecting X (a follow on @theblessnetwork), +5% for connecting Discord, and +5% for completing the quiz, each earned through a real OAuth round-trip (the quiz behind reCAPTCHA), not a self-reported checkbox.
3. C.Placeholder teasers, nothing behind them -- the achievements page also rendered four blurred, non-interactive "coming soon" cards (no button, no data, no backend). They are pure visual placeholders for features that did not exist yet -- not live boosts and not logic I wired up.
4. D.One number that compounds -- every real boost sums into a single Total Boost rendered at the top of the achievements page; the social and quiz layer I added is what gave users more rungs to actually reach.
5. E.The X integration that fought back -- the X/Twitter OAuth client had to be made to work against an API mid-rename from twitter.com to x.com with stale docs; Discord's identify/guilds flow was straightforward by comparison.

Real-Time Dashboard & Node Bridge — The operational surface. A Next.js 14 dashboard that shows live node status, earnings, and rankings, and stays in sync with the user's running node through the Chrome extension.

1. A.App Router with auth route groups -- `(auth)` and `(unauthenticated)` route groups cleanly separate protected dashboard pages (home, nodes, referrals, achievements, leaderboard, rewards) from the public login, each with its own layout.
2. B.Live node status without backend polling -- the active-node component talks to the Chrome extension over the Runtime messaging API on a 5-second interval, reading node connection state and earnings straight from the user's local node instead of hammering the gateway.
3. C.Earnings visualization -- a 14-day rolling stacked-bar chart (Recharts) breaks rewards into base, bonus, and referral so a user can see exactly where their tokens come from.
4. D.Pragmatic state management -- React Context holds the Web3Auth session, and SWR owns server data through an authenticated fetcher that injects the JWT on every request, getting caching and revalidation for free.

Extension Gateway | The Backend — The Fastify backend behind the network. It authenticates wallets across chains, registers and tracks compute nodes, computes rewards, absorbs the firehose of node pings, and deploys and invokes the network's serverless functions.

1. A.Multi-chain wallet auth -- one challenge-response auth service verifies signatures from MetaMask (EVM), Keplr (Cosmos), Martian (Aptos), and Solana, with chain-specific verification so a signature from one chain can never be replayed on another.
2. B.Batched ping ingestion -- node "I'm alive" pings land in an in-memory queue and flush every 15 seconds in 1,000-document chunks into MongoDB time-series collections, so thousands of nodes can report without drowning the database in writes.
3. C.Rewards and referral aggregation -- MongoDB aggregation pipelines compute node earnings and roll the 10% referral bonus across a user's referred network, which is the server-side truth the dashboard's boost UI reflects.
4. D.Secrets encrypted by default -- function environment variables and third-party credentials are stored AES-256-CBC encrypted with a per-field initialization vector, and HashiCorp Vault is integrated to inject external secrets at invocation, so credentials are never persisted in plaintext.
5. E.Built to run lean -- a three-package monorepo with multi-stage Docker builds, GitHub Actions CI/CD publishing to ghcr.io and npm, and deployment onto Akash decentralized cloud behind a Caddy reverse proxy with Cloudflare DNS for automatic TLS.

Achievement Quiz Service | extension-aux — A standalone Fastify service, separate from the main gateway, that powers the achievement quiz behind the +5% quiz boost. I built the quiz feature end to end in February 2025, in parallel with the run-dashboard -- the front-end form, the reCAPTCHA, and the scoring wiring -- on top of a service scaffold I did not stand up myself.

1. A.The quiz front end -- the QuizForm on the client renders the survey, collects answers, and submits them to the aux API, then refreshes the achievements page so the user sees the boost land.
2. B.Bot-proofed solo, end to end -- a Google reCAPTCHA v2 widget on the client issues a token, and the aux API verifies it server-side against Google's siteverify, rejecting any submission without a valid token so bots cannot farm the boost.
3. C.Two endpoints, both JWT-gated -- one reports whether the user has already completed the quiz (driving the "Take Quiz" vs "Done" state), and the other validates the captcha, scores the answers, and persists the result to MongoDB.
4. D.Deliberately decoupled -- it runs at its own auxiliary URL, off the core gateway, so the quiz and its bot protection deploy and scale independently of auth, nodes, and rewards.

Design System & Responsive Side Nav | bless-ui — The shared front-end library -- a shadcn/Radix + Tailwind set of building blocks published as its own Docsify-documented package. Most of it is standard component parts; the piece worth calling out is the responsive side navigation, which the founders were exacting about.

1. A.A device-aware state machine, not a CSS toggle -- a Zustand store (my first time using Zustand) holds device, isExpanded, and width, and snaps the nav to one of three widths: 260px expanded on desktop, a 72px icon-only rail on tablet, and 0 (hidden) on mobile.
2. B.Breakpoint-driven -- a custom useSidenav hook listens to window resize and maps width to device (<=640 mobile, 641-1024 tablet, >1024 desktop), so the rail collapses to a skinny bar exactly at iPad width and re-expands on desktop, automatically.
3. C.The layout breathes with it -- the main layout resizes the content region via calc(100% - {width}px) with a 300ms transition, and the nav labels fade out when collapsed, so the page reflows smoothly instead of snapping.
4. D.Active-route aware -- the nav reads the Next.js pathname to highlight the current page and keeps it in sync as the user navigates.
5. E.Documented as a real library -- the components ship with their own Docsify docs site so the rest of the team could consume them as a design system.

Landing Page & Docs — The public front of bless.network. Beyond the app, I rebuilt the company's top-of-funnel surface from scratch. (From my account; the landing page itself is not in the repo snapshot -- the Docsify docs are.)

1. A.Redesigned the main bless.network landing page end to end -- the prior site was little more than two links (into /dashboard and into /docs); I rebuilt it into a real marketing and conversion front door, the first thing a prospective node operator sees.
2. B.Rebuilt /docs in Docsify -- migrated the documentation into a maintainable Docsify site, the same approach used for the bless-ui component docs, so docs could be updated in plain markdown.

Supporting Services — One last piece, for completeness. bless-auth -- a Go + Vite email one-time-passcode service (login, verify, JWT issuance). It still ships on the live login page as the "BlessAuth" tab alongside the Web3Auth SSO that now leads.