Building LI.FI's enterprise payment stack

Context

LI.FI is a B2B crypto liquidity API powering transactions for 800+ customers, with $60B+ in cumulative volume processed. I joined as Product Lead through LI.FI's acquisition of my startup Catalyst.

I lead the new products group called LI.FI 2.0, and am responsible for roadmap strategy, prioritisation, and execution across four teams totalling 15+ engineers and product managers.

Strategic Bet

LI.FI had found strong product-market fit as a liquidity aggregator for the crypto-native market, but their success made their growth slow, as they nearly exhausted the pool of crypto-native customers.

A larger opportunity arose with crypto-curious fintechs, neobanks and payment providers that wanted the cost and UX benefits of blockchain without exposing their users to crypto complexity. However, serving them required a fundamentally different product, as their users have no concept of gas, private keys, or transaction signing.

Discovery

I worked closely with the sales team to analyse the pipeline, identify where fintech deals were stalling, and run discovery calls with prospective customers.

As a result, three requirements surfaced:

1. Predictable, fixed fees. Fintech users don't tolerate variable costs.
2. No wallet connection. A product requiring a connected wallet largely excludes fintech users.
3. Fiat entrypoints. For obvious reasons.

What We Built

Tron and Solana Support (Requirement #0)

During sales conversations, I discovered that for neobanks, nearly 70% of inbound stablecoin volume arrives from Tron and Solana, even though most existing crypto products are built for Ethereum chains.

Unfortunately, both chains are very different from Ethereum (e.g., Tron uses a different address format, different token standards, different gas mechanics), but it was a P0 requirement to fulfill for customers.

Stablecoin API (Requirement #1)

Onchain stablecoin transfers carry unpredictable outputs such as gas costs, bridge margins, and slippage. We built Stablecoin API to guarantee 1:1 execution regardless of which chains are involved (i.e., 100 USDC in, 100 USDC out).

It's comprised of two components: (1) a gasless endpoint that abstract gas complexity from users, and (2) an orderflow marketplace built with Catalyst tech, where fintech users were provided with custom quotes with zero slippage and zero gas cost.

We recovered costs through monthly invoicing (which customers preferred), and billing customers at a pre-agreed rate for volume processed during the period.

Payment Addresses & Smart Account (Requirement #2)

With predictable fees solved, the next challenge was a walletless deposit experience. For that, we shipped two net-new products: (1) Payment Addresses, one-time generated addresses that receive onchain funds, and (2) a Smart Account that executes specified actions on receipt.

A fintech user coming from fiat can on-ramp funds to a Payment Address with an encoded instruction (e.g., swap from 100 USDC to Y token on receipt). The Smart Account detects the deposit, executes the instruction, retries if needed, and refunds the user if execution fails.

We decided to build the Smart Account non-custodially even though it would be slower to deliver. In my eyes, it was the only acceptable path for enterprise fintechs with compliance and liability obligations. Addresses are also single-use, as reusable addresses would require LI.FI to hold custody between deposits.

Checkout (Requirement #3)

We added on-ramp and card checkout options to the LI.FI Widget, giving users fiat, card, and CEX funding options alongside the existing wallet connection flow.

Tradeoffs Made

Focusing on the fintech opportunity meant deliberately deprioritising other areas:

• Expanding to 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 customers

The fintech market is larger and the revenue opportunity is more compelling, so IMO the trade-offs were worth making.

Go To Market

We launched the payments stack with the positioning that LI.FI is the only payments provider giving fintechs access to crypto rails without crypto complexity.

We launched in this order:

• Stablecoin API first. Largest revenue opportunity, most defensible product, and the clearest proof point for the fintech thesis.
• Checkout second. Time-sensitive, lower engineering lift, scoped to parity. It unblocked deals at risk, including a partner evaluating LI.FI for a billion-dollar monthly volume opportunity.
• Payment Addresses third. Higher engineering complexity than Checkout but less in demand than Stablecoin API.

Outcomes

The payments stack is live with a set of lighthouse partners. Combined, they are processing hundreds of millions of dollars in stablecoin volume through the API. Specific metrics for individual partners are commercially sensitive, but I can share two examples:

1. Stablecoin payments product at one of the world's largest exchanges, built for merchants accepting crypto. Their users send from any chain or from fiat, and the merchant receives exactly what was quoted.
2. Crypto-native neobank processing over $100M in stablecoin deposits each month, using the Stablecoin API to route inbound USDT and USDC from Tron, Solana, and EVM chains into their treasury automatically.

Reflections

Product must be closer to sales than ever

With AI, it's become trivially easy to build features, but now it's more important than ever to determine what features to build and why I strongly believe that Product Managers need to be deeply involved in the sales and customer success processes; that's the only way to really understand customers' needs and requirements.

Also, in a B2B context, the PM is typically the final decision maker on whether to use a vendor, not BD. So having PMs attend and even lead sales calls leads to a higher likelihood of closing a deal.

Walking away from an acquisition

Early in the discovery process, I evaluated acquiring a company that initially seemed it to accelerate our delivery timeline. However, after technical due diligence, I realised that integration would have cost more engineering time vs. building in-house (+ inheriting their technical debt and no certainty the team would stay).

I made the call to walk away from the deal and put that budget into aggressive engineering hiring instead. In hindsight it was the right move, but in the moment, with a ton of pressure to delivery on time, it was a difficult one to make.