Frontend infrastructure

07 / 12

Bifront SDK

Reusable TypeScript wallet, provider, asset, and React abstractions shared across product frontends.

Role
Frontend / SDK Lead
Problem
Standards-compatible wallets still differed in connection lifecycle, events, extension injection, and mobile behavior.
Strategy
Provider discovery and wallet state were separated. Each implementation adapted to a common wallet interface, while events flowed through one SDK-owned layer and product React code consumed stable providers and hooks.
Outcome
Allowed several product frontends to reuse wallet and asset behavior.

01

Problem definition

Why this problem had to be solved

Bifront SDK brought repeated wallet connection, provider calls, network switching, contract execution, and asset data into shared TypeScript packages.

What users and the system were facing

  • Each product implemented wallet behavior and error handling differently.

  • Several injected wallets could compete for the same browser provider.

  • Account, chain, connection, mobile deep-link, and reconnection behavior varied by wallet.

Frontend ownership

I led the SDK’s frontend architecture and core implementation across package boundaries, wallet normalization, React APIs, test applications, and production integration.

  • Nx package boundaries and shared utilities

  • Provider utilities, wallet core, and React provider

  • Asset, balance, price, and chain hooks

  • Unit, integration, and wallet test applications

02

Solution strategy

A system strategy carried into production

Provider discovery and wallet state were separated. Each implementation adapted to a common wallet interface, while events flowed through one SDK-owned layer and product React code consumed stable providers and hooks.

System model

Product interfaces use React providers and hooks, which call wallet core and asset packages. Those packages normalize EIP-1193 providers, APIs, and contract operations.

Implementation decisions

  • Normalized wallet providers behind a common interface.

  • Handled EIP-1193 and EIP-6963 discovery, events, and stable provider selection.

  • Provided signing, calls, sends, gas estimates, network switching, and receipt waiting.

  • Deduplicated concurrent data requests and cleaned up request lifecycle behavior.

03

Outcome

What changed—and what I learned

  • Allowed several product frontends to reuse wallet and asset behavior.

  • Reduced repeated product-specific integration paths.

  • Reduced duplicate API work through concurrent-request deduplication and lifecycle cleanup.

Learning

Shared infrastructure succeeds when it defines error and lifecycle contracts, not only method signatures.

Today

I would publish a versioned support matrix and error model first, keep browser-only providers fully lazy, enforce tree-shaking and bundle budgets, and run wallet contract tests in CI.

Built with

  • TypeScript
  • React
  • Nx
  • EIP-1193
  • EIP-6963
  • WalletConnect
  • Unit testing

Public links

Architecture-level explanation only; private source and internal payloads are intentionally not shown.

Work together

Need this level of frontend ownership?

Contact me