Flagship product family · Current work
01 / 12
BTCFi
A product family for issuing BtcUSD against Bitcoin and using it across lending, vaults, DeFi, Native BTC, and partner products.
- Role
- Frontend Lead
- Problem
- The hardest problem was preserving one trustworthy user intent as the product expanded across protocols, networks, sessions, and integration contexts.
- Strategy
- The frontends separate product journeys, domain state, transaction processes, and wallet/API/contract adapters. Long-running work is restored from durable process state and reconciled with current wallet, network, balance, and product context instead of trusting temporary UI state.
- Outcome
- Carried BTCFi from a BTC-backed stablecoin application into yield, recoverable Native BTC, and platform-integration experiences.
Current focus · Partner-facing BTCFi frontend
01
Problem definition
Why this problem had to be solved
BTCFi started with one clear job: use Bitcoin as collateral to issue BtcUSD. It grew into vault, Native BTC, developer, and partner products that share the same transaction foundations.
What users and the system were facing
BTC and EVM systems use different addresses, confirmation models, assets, and timing.
A financial intent can cross wallets, protocols, APIs, contracts, and sessions before the product action is complete.
Stablecoin, vault, ecosystem, developer, and partner surfaces had to share a coherent product model without hiding their different actions and risks.
Frontend ownership
I led frontend architecture and most implementation across the core BTCFi generations and developer example, contributed to Boost and Ecosystem surfaces, and currently work on the partner-facing frontend.
Application foundations, responsive systems, and domain architecture
Stablecoin minting, dashboard, vault, position, deposit, withdrawal, borrow, repay, and claim flows
Durable order and transaction-process recovery across sessions
Partner configuration boundaries, testing, observability, and production hardening
02
Solution strategy
A system strategy carried into production
The frontends separate product journeys, domain state, transaction processes, and wallet/API/contract adapters. Long-running work is restored from durable process state and reconciled with current wallet, network, balance, and product context instead of trusting temporary UI state.
System model
BTCFi connects user intent and wallet validation to product actions, durable transaction processes, network and contract execution, reconciliation, and partner or developer integration surfaces.
Product evidence
Selected product surfaces
Historical product interfaces. Values shown are captured UI states, not current TVL, APY, or performance claims.
Product and delivery map
One product family, six connected surfaces
BTCFi grew from a BTC-collateralized stablecoin experience into Native BTC, yield, ecosystem, developer, and partner surfaces. The level of my ownership varied by surface and is stated explicitly.
Integrated DeFi foundation
BTCFi V1
A single production experience connected BTC collateral, BtcUSD, lending, liquidity, staking, rewards, bridges, and portfolio risk.
Implementation details · 2
- Built reusable supply, withdraw, mint, repay, claim, liquidity, and staking flows.
- Separated product actions from wallet, protocol, API, and contract adapters.
Native BTC evolution
BTCFi V2
The interaction model expanded from EVM receipts to recoverable Native BTC orders that could outlive one browser session.
Implementation details · 2
- Modeled Bitcoin confirmation, bridging, contract action, reconciliation, and completion as distinct stages.
- Restored durable order progress after refresh, delayed confirmation, or re-entry.
Yield and vault surface
BTCFi Boost
A yield-aggregator experience turns BTC and BtcUSD opportunities into product discovery, deposit, withdrawal, position, and recovery flows.
Implementation details · 2
- Contributed frontend implementation and production maintenance across vault and position experiences.
- Supported observable wallet and action flows without presenting yield as guaranteed.
Product discovery hub
BTCFi Ecosystem
A product hub connects BTCFi, Boost, and applications that use BtcUSD so users can understand where the stablecoin and BTC positions can be used.
Implementation details · 2
- Contributed to the frontend surface and its product-discovery experience.
- Kept adjacent products legible as one ecosystem without collapsing their different risks or actions.
Current focus
Partner frontend
I currently work on a configurable partner-facing BTCFi frontend for product discovery, deposits, withdrawals, claims, and transaction history.
Implementation details · 2
- Keep partner configuration, wallet context, product data, and transaction processes behind explicit boundaries.
- Harden long-running submissions and cancellations against duplicate actions, stale state, and reconciliation races.
Integration proof
Developer platform example
A working reference application demonstrates vault, position, deposit, claim, and close flows for teams integrating the platform.
Implementation details · 2
- Turned platform capabilities into end-to-end, testable product journeys.
- Covered API, wallet, and contract boundaries without exposing internal partner payloads.
Implementation decisions
Turned BTC collateral and BtcUSD minting into reusable product and transaction patterns across lending, liquidity, yield, and partner contexts.
Designed explicit progress and recovery across Bitcoin confirmation, bridging, contract actions, and final reconciliation.
Built integration journeys that kept wallet, network, product, vault, and position context aligned.
Strengthened current partner flows against duplicate submissions, stale state, cancellation races, and delayed completion.
03
Outcome
What changed—and what I learned
Carried BTCFi from a BTC-backed stablecoin application into yield, recoverable Native BTC, and platform-integration experiences.
Established reusable transaction patterns across core product, developer example, and partner-facing work.
Kept long-running financial actions understandable through refresh, delayed confirmation, cancellation, and re-entry.
Learning
A product family needs shared semantics for intent, ownership, progress, recovery, and partial completion—not merely shared components.
Today
I would standardize every long-running action around a server-authoritative event log, explicit state machine, idempotent mutations, and contract tests for wallet changes, duplicate signatures, stale processes, cancellation, and observer delays.
Built with
Work together