Skip to main content
Most yield features convert badly for a reason nobody measures until launch: the deposit only works for customers who already hold the right asset on the right chain, and that group is smaller than teams assume. LI.FI Earn gives you the vault data and an execution path that starts from whatever a customer holds, so the feature is available to your whole book rather than a slice of it.

​
What this changes for your product

Every customer can deposit

A customer enters a position from any token on any supported chain. You stop shipping a button that only works for the minority who prepared for it.

A fee you set and keep

You set a fee on deposits and keep it, which makes a yield surface a revenue line rather than a retention feature you pay for.

No DeFi team to hire

One schema covers every supported protocol, so adding the tenth vault costs about what the first one did.

Deeper engagement per customer

A resting balance is a customer who has stopped using the product. A position is one with a reason to come back and check it.
The vault feed layer above and the execution layer below, with one customer selection between them

Discovery and execution are separate calls. You design the product between them.

​
What it costs you to build this yourself

Building a yield surface the direct way means integrating each protocol on its own. Every one has its own contract shape, its own accounting for deposits and returns, its own idea of what a position looks like. You normalize all of it by hand, then do it again for the next protocol, and again for each chain that protocol runs on. Then the harder half. A customer wants to enter a position on a chain they hold nothing on, in an asset they don’t own. Getting them there is a swap, a transfer, and a deposit across two chains. Done as separate steps, a customer who fails partway sits on the wrong chain holding an asset they didn’t ask for, and your support team owns the outcome. LI.FI Earn splits the problem into a data layer and an execution layer, and that separation is what lets you build the product without becoming a DeFi team.

​
Layer one: knowing what is available

The vault feed returns positions from supported protocols in one schema, whatever the underlying protocol does internally. Yield, size, and token composition are directly comparable, which means you can rank and filter without writing a normalizer.

Filter

By chain, asset, or protocol, so the list reflects what your customers actually hold.

Compare

Yield, size, and composition in one schema, with no data wrangling between protocols.

Track

A customer’s open positions and returns, read back in the same shape you used to display the options.
That last part matters more than it sounds. Portfolio views are where a yield feature stops being maintainable, because tracking positions across protocols is a second integration problem wearing the first one’s clothes. Here it’s the same feed.

​
Layer two: getting money into it

Execution is Composer. A customer selects a position and deposits from any token on any supported chain.
Where the atomicity guarantee applies. On a single chain, the swap and the deposit execute in one transaction, so there is no state where a customer is halfway in. When the funds start on a different chain, the source transaction triggers the bridge and the destination actions run once it settles. Each phase is atomic on its own chain, and the flow as a whole is eventually consistent, so track it through the status endpoint rather than assuming a single outcome.
The practical effect on your product is that the deposit path is open to customers who hold something other than the vault’s asset, which is most of them.

​
What stays yours

LI.FI supplies the infrastructure and not the product. Which protocols appear, in what order, with what risk disclosure, and to which customers, are all your decisions. So is monetization: you set a fee on deposits and keep it.

​
What to decide before launch

Data coverage reflects what LI.FI’s sync pipeline has indexed, so a vault existing on a supported protocol is not a guarantee it appears in the feed. Design your interface to render the feed you actually receive rather than a list you expect.
The vault feed handles discovery and tracking. If you have modeled the feed as an execution surface, you’ll find the gap late.
Decide how often you refresh, what you show while a figure is stale, and whether the number a customer saw when they tapped deposit is the number you record against the decision. Any answer works. Not choosing one produces a support conversation you can’t win.
The moment your product surfaces a yield figure, a customer reads it as your recommendation, whatever the small print says.

​
Where to start

Build discovery first and ship it read-only. A list of positions filtered to the assets your customers already hold is useful on its own, and it tells you which protocols to prioritize before you have committed to any of them. Add the deposit second, against one asset and one chain, then widen.

Earn quickstart

Vault selection, deposit, and position tracking end to end.

How Earn works

The data pipeline, the schema, and how the feed stays fresh.

Discover and deposit

Find top vaults, then fund one through Composer.

Supported protocols

Current protocol and chain coverage for the feed.

Talk to the LI.FI team

Bring the assets your customers hold and the shape of the product you want to build. We scope protocol coverage and the fee model with you.