Client Project (NDA)Web3 Rewards SystemFinTech · DeFi · BlockchainConfidential

Building a Modular Web3 Rewards Claim System for a FinTech Platform

The platform ran both rewards systems in parallel in production without incident, giving the business real usage data to compare providers under identical conditions. Because the second integration was fully isolated, the team retained the option to promote it, retire it, or plug in further providers through the same modular pattern later, turning what could have been a risky one-off integration into a repeatable approach for evaluating future reward partners.

Role: Led the frontend architecture and implementation of the new rewards module, designing it to stay fully isolated from the existing codebase while reusing shared infrastructure such as wallet connectivity.

The business challenge

A production financial platform already had one on-chain rewards mechanism live and generating real user activity. Leadership wanted to test a second rewards provider to compare performance and engagement, but the existing system could not be touched. Any bug introduced during the new integration risked breaking reward payouts for active users, which made stability the top priority. The two systems also needed to share the same wallet connection layer, so users would not be asked to reconnect or re-authenticate depending on which rewards program they were using.

The approach & technical solution

Rather than bolting the second provider directly onto the existing codebase, I designed a modular service layer that treated each rewards provider as an interchangeable module behind a shared interface. This meant the new integration could be built, tested, and shipped without modifying a single line of the original implementation. Reusable React hooks handled eligibility checks, reward-balance fetching, and claim status independently of which provider was active, while wallet authentication and transaction signing were shared across both systems so users experienced one consistent connection flow regardless of which rewards program they interacted with. Handling the full transaction lifecycle — pending, success, failure, and retry — was central to the work, since on-chain transactions can fail or stay pending for reasons outside the application's control, and users needed clear, honest feedback at every stage rather than a spinner that never resolved.

Business outcome

The platform ran both rewards systems in parallel in production without incident, giving the business real usage data to compare providers under identical conditions. Because the second integration was fully isolated, the team retained the option to promote it, retire it, or plug in further providers through the same modular pattern later, turning what could have been a risky one-off integration into a repeatable approach for evaluating future reward partners.

More case studies

  • Client Project (NDA)DeFi Portfolio DashboardBlockchain AnalyticsConfidential

    Designing a High-Performance DeFi Portfolio Dashboard

    Problem

    Users wanted one dashboard that could answer a simple question — what do I currently hold, and how is it performing — without checking several different tools. Behind that simple question sat a hard technical problem: wallet balances, staking positions, reward accruals, historical activity, and protocol-level data all lived in different APIs and blockchain sources, each with its own response time, rate limit, and data shape. Fetching all of it on every page load risked a dashboard that felt sluggish exactly when users most wanted fast, reliable numbers.

    Solution

    A unified DeFi portfolio dashboard data layer with parallel fetching, intelligent caching, per-data-type refresh strategy, and reusable visualization components for balances, staking, and protocol metrics.

    Next.jsReactTypeScriptTanStack QueryREST APIsBlockchain APIs

    The result was a dashboard that handled a genuinely complex, multi-source dataset while still feeling fast and consistent to use. Because the components and data-fetching patterns were built to be reusable, the team was able to add new asset types and data views afterward without rebuilding the underlying infrastructure.

    Read Case Study
  • Client Project (NDA)Frontend ArchitectureEnterprise Web3Confidential

    Refactoring a Scalable Frontend Architecture for a Growing Web3 Product

    Problem

    As the product grew, new features kept shipping, but each one seemed to take longer than the last. Different parts of the application had implemented similar logic in slightly different ways, folder structures varied by feature, and there was no single source of truth for how API calls or TypeScript models should be written. The team wasn't lacking talent; they were fighting inconsistency that compounded with every new feature.

    Solution

    A refactored Web3 frontend architecture with reusable components, consistent folder structure, centralized API layer, standardized TypeScript models, and cleaner deployment/environment workflows.

    Next.jsReactTypeScriptTailwind CSSVercel

    The cleaner architecture reduced duplicated logic across the application and gave the team a consistent pattern to follow for new features, shortening the gap between starting a feature and shipping it. Just as importantly, it made the codebase easier for other engineers to onboard into, since the same conventions applied everywhere instead of varying feature by feature.

    Read Case Study
View all case studies →Contact →