← Back

LI.FI - Transformation to enterprise payment stack

2025 - Now · Product Leadership

Context

LI.FI is a B2B crypto liquidity API that powers transactions for 800+ customers, with a cumulative volume of $60B+ processed. Every major crypto wallet and application uses LI.FI under the hood. I joined as Product Lead through LI.FI's acquisition of Catalyst, the crypto payments company I founded.

At LI.FI, I sit in leadership and lead the new products group, known as LI.FI 2.0. I'm responsible for roadmap strategy, prioritisation, and execution across four teams totalling 15+ engineers and PMs.

Strategic Bet

LI.FI had found strong product-market fit as a liquidity aggregator for the crypto-native market. Unfortunately, the market had a ceiling, and as we grew, we realised that the pool of crypto-native customers was largely exhausted, and incremental growth was slowing.

I saw that the market was much larger for crypto-curious fintechs, i.e., neobanks and payment providers who wanted the UX and cost benefits of blockchain without exposing their users to crypto complexity.

But we needed to fundamentally reimagine our products in order to serve their users. Unlike crypto users, they did not understand concepts like gas, private keys, and transaction signing. Enterprise fintechs need something akin to what card networks offered: deterministic outputs, SLA-backed reliability, fiat entry points, and zero wallet friction for end users.

None of that existed at LI.FI when I joined. My job was to build it.

Discovery

I worked closely with the BD team to map the active sales pipeline, identify where deals were stalling, and run discovery calls with target potential customers.

Three requirements surfaced consistently:

  1. Predictable, fixed fees. Fintech users would not tolerate the variable gas cost of blockchains. Moreover, neobanks and payment providers build margin models on predictable, known unit economics.
  2. No wallet connection. A product that requires a connected wallet with onchain funds excludes fintech users entirely.
  3. Fiat and CEX entrypoints. The majority of fintech end users hold assets in fiat.

Implementation

Stablecoin API (Requirement #1)

Onchain stablecoin transfers have unpredictable outputs due to gas costs, margins taken by bridges, slippage, etc. All of which vary in cost. The goal of Stablecoin API was to eliminate variable cost and guarantee 1:1 execution (e.g., 100 USDC in, 100 USDC out) regardless of which chains are involved.

Stablecoin API has two components:

  1. A relayer + gasless endpoint abstract away gas complexity from users.
  2. An intents system and solver marketplace (leveraging acquired Catalyst tech) where solvers compete to fill orders. Fintech customers received custom quotes with zero slippage and zero gas requirements.

Key product decisions:

  • Monetisation model. With 1:1 custom quoting, Stablecoin API had to be monetised in a completely different way.
  • Build vs buy vs partner. Decision to build a solver in-house, buy an existing team, or partner with third-party solvers.

Payment Addresses & Smart Account (Requirement #2)

After predictable fees were solved, we moved onto offering a walletless deposit experience. We designed two solutions:

  1. Payment Addresses. One-time generated addresses that could receive onchain funds.
  2. Smart Account. Programs that perform specified actions post-receipt.

A fintech user, coming from fiat or a CEX, sends funds to a Payment Address with an encoded instruction (e.g., after receipt, bridge 100 USDC from Arbitrum to Base). The Smart Account detects the deposit, executes the instruction, retries if needed, and refunds the user if execution fails.

Key product decisions:

  • Non-custodial. Building the Smart Account non-custodially was slower to build, but the only acceptable path for enterprise fintechs with compliance and liability obligations.
  • One-time addresses. Each address is single-use. Reusable addresses would require LI.FI to hold custody between deposits.

On-Ramp / Checkout (Requirement #3)

We added on-ramp and checkout via card options to the LI.FI Widget, a UI component that customers could use off-the-shelf. Users see fiat, card and CEX funding options alongside the existing wallet connection flow.

Key product decisions:

  • Defensive move. This was scoped explicitly to meet feature parity with competitors in the same deal conversations as us.
  • No separate UI. We decided this flow would live natively the LI.FI widget, so that no separate integration was required.

Hard Decisions Made

Early on, we evaluated acquiring a company that appeared to accelerate our delivery timelines on parts of the payments stack. After heavy technical due diligence, it became clear that the technical architecture had no material synergies with LI.FI's stack. Integration would have required more engineering time than building in-house, with the added risk of inheriting technical debt and potential cultural fit issues with the acquired team. I eventually made the call to walk away and redirect the budget to aggressive engineering hiring instead.

Focusing on the fintech opportunity also meant that we we explicitly deprioritised other things:

  • Expanding to new chains beyond Base, Ethereum, Solana, and Tron (where USDC and USDT volume is concentrated)
  • Adding support for long-tail stablecoins and RWAs
  • Shipping new swap features
  • New features for crypto native companies

But the revenue opportunity and the entrance into a new, larger market was more appealing - with a higher expected payout.

Go To Market

We launched with the messaging that LI.FI is the only payments product that gives fintechs access to crypto rails without crypto complexity.

Sequencing of releases:

  1. Stablecoin API shipped first. Largest revenue opportunity, most defensible product, and the clearest proof point for the fintech thesis. 1:1 execution is hard to replicate without LI.FI's solver network and existing distribution.
  2. Checkout next as a defensive move. The feature was time-sensitive, lower engineering lift, and scoped to parity rather than differentiation. Unblocked major deals including a partner evaluating LI.FI for a billion-dollar monthly volume opportunity.
  3. Payment Addresses last. Higher engineering complexity than Checkout. Sequenced after Stablecoin API because enterprise API deals were the priority — Payment Addresses unlocked a different motion: on-ramp providers and CEX withdrawal flows where no wallet UI exists.

Outcomes

LI.FI processes $60B+ in total transfer volume across 80M+ transactions for 800+ partners. Specific metrics for the payments products are commercially sensitive and available on request.

Reflections

Constant pulse checks with customers

Defensive features like Checkout only become obvious when you have direct visibility into the sales pipeline and are talking to customers regularly. At first glance, Checkout looks like a low-revenue feature not worth prioritising. However, with the added context that a competitor would offering it to the same customers, it was unambiguous. Staying close to the sales process allows PMs to catch these calls early.

Embedding intelligence

AI should have been more actively scoped and prioritised in these features. An intelligence layer can allow solvers to quote more aggressively; it can allow Smart Accounts to more accurately perform actions to reduce retries and refunds. This is the next frontier of exploration for us product-wise.