> ## Documentation Index > Fetch the complete documentation index at: https://docs.li.fi/llms.txt > Use this file to discover all available pages before exploring further. # Every Customer Can Fund an Account, Whatever They Hold > Let every customer fund an account from whatever they already hold, and turn idle balances into a revenue line. A customer who can't fund an account doesn't become a customer. LI.FI removes the two reasons they fail: the asset they hold isn't one you support, and the chain they hold it on isn't one you've integrated. Funding, withdrawal, and yield all resolve through one integration, so your account coverage stops being a function of your engineering backlog. ## What this changes for your product > **More funded accounts** > > A customer funds from any asset on any supported chain and the deposit lands as the asset your ledger expects. The people you were turning away at the first screen can now complete signup. > **A revenue line on movement** > > Every transfer through your integration can carry [your own fee](https://docs.li.fi/introduction/integrating-lifi/monetizing-integration.md), set as a percentage and forwarded to a wallet you control. Funding stops being a cost center. > **Idle balances that earn** > > [LI.FI Earn](https://docs.li.fi/earn/overview.md) turns a resting balance into a yield position in one signature, which gives you a product to sell to customers who have already funded and then stopped. > **New chains without new work** > > Coverage follows LI.FI's live [chain](https://docs.li.fi/introduction/chains.md) and [liquidity](https://docs.li.fi/introduction/tools.md) set. Adding a market becomes a product decision instead of a quarter of integration work. ![Customer assets on any chain, LI.FI routing and execution in the middle, and one settlement asset on your ledger](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/neobank-account-boundary.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=0d5e13316987aea3f8bd3dcd9fc7223c) Funding and withdrawal are the same call, reversed. ## What it costs you to build this yourself You launch on one chain with one settlement asset, because that is what your first partner uses. Then a customer wants to fund from something you don't hold. A second partner settles somewhere else. A yield feature needs a third venue. Each addition is another integration, another set of failure modes, and another thing your support team has to learn. The feature was never the work. The work sits underneath it: finding liquidity per chain, choosing between transfer paths, setting a slippage policy that suits a dollar balance rather than a trade, telling apart tokens that share a ticker but not a contract, and making sure a customer who has just arrived on a chain can do anything once they get there. Every one of those is a place a funding attempt dies, and each one you fix by hand is engineering time you aren't spending on the account product itself. > **What you build** > > The account model, the ledger, the customer experience, and the rules about who may do what. > **What LI.FI absorbs** > > Route discovery per chain, liquidity-source selection, token variants, native gas on arrival, and transfer monitoring under one status vocabulary. ## How the account behaves A customer funds from whatever they hold, on whatever chain they hold it, and the deposit arrives as the asset your ledger expects. Withdrawal is the same call reversed, so a customer moving out to a different chain gets a route back instead of an error message. An idle balance can also earn. LI.FI Earn surfaces yield positions across supported protocols and executes the deposit. [Composer](https://docs.li.fi/composer/overview.md) runs the swap and the deposit in one transaction on the destination chain, which is what keeps a customer from stranding between two steps. > [!TIP] > > One failure mode catches most first launches. A customer arriving on a chain for the first time holds a balance and no native asset to pay for anything, so their next action fails before it starts. [Gas Fronting](https://docs.li.fi/guides/gas-subsidy.md) converts part of the transfer into the destination chain's native asset and delivers both together, which turns a dead end into an ordinary first transaction. If you want the outcome without building the front end, the [Widget](https://docs.li.fi/widget/overview.md) is an embeddable interface you style to match your product. It's the shortest path from a decision to something a customer can use. ## Where the line sits LI.FI routes and executes. Onboarding, screening your own customers, and regulatory reporting stay with you, and nothing about the integration changes that. LI.FI applies [token screening](https://docs.li.fi/introduction/learn-more/hypernative-token-screening.md) at the asset level, which is a different question from whether a given customer should be transacting at all. For teams moving at size, two [enterprise features](https://docs.li.fi/enterprise/overview.md) change the economics rather than the architecture. > **[Stablecoin 1:1](https://docs.li.fi/enterprise/stablecoin-1-1.md)** > > Like-for-like dollar swaps priced at par instead of through pool liquidity, so a large transfer gets the same rate as a small one and per-hop leakage stops eating the margin. > **[Smart Deposit Addresses](https://docs.li.fi/enterprise/smart-deposit-address.md)** > > A swap completed from a single token transfer to a unique address, with no approval and no router transaction. Suits a custodial product that can't ask a customer to sign a contract interaction. ## What to decide before launch > **Who pays source-chain gas, and do you check it** > > A customer still pays source-chain gas from their own native balance. Check it against the quote before you ask anyone to sign, or you'll ship a button that fails for the people who most need it. > **How the ledger records a partial outcome** > > A cross-chain transfer can complete with the customer holding a related asset rather than the exact one requested. That is a normal outcome, and it happens when the destination swap couldn't execute inside safe bounds. Decide how the ledger records it first, because recording it as a failure is wrong and recording it as an exact match is also wrong. [Intermediate tokens](https://docs.li.fi/guides/intermediate-tokens.md) lists what shows up and when. > **Whether the on-chain side is a cost center or a revenue line** > > Fee forwarding is set per integration, so decide the rate before you price the rest of the product rather than after. ## Where to start Most neobanks start with funding, because it's the gap customers hit first and the one that costs you the most while it stays open. That is a quote request and a status poll, the smallest piece of the integration and the quickest to put in front of customers. Yield comes second, once funding works and balances are sitting still. > **[Getting started](https://docs.li.fi/introduction/integrating-lifi/getting-started)** > > Pick an integration surface and make your first call. > **[LI.FI Earn](https://docs.li.fi/earn/overview.md)** > > Vault discovery and one-click deposits for idle balances. > **[Composer](https://docs.li.fi/composer/overview.md)** > > Swap and deposit in a single signed transaction. > **[Enterprise features](https://docs.li.fi/enterprise/overview.md)** > > Par pricing and transfer-based deposits, enabled per integrator. > **[Talk to the LI.FI team](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)** > > Bring your chains, your settlement assets, and your volumes. We scope the starting point against your roadmap and confirm which enterprise features fit. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.