> For the complete documentation index, see [llms.txt](https://docs.bsc.lista.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bsc.lista.org/for-developer/lista-lending/providers.md).

# Providers

A **provider** is a contract registered against a market and token that takes over part of the flow. Where a collateral-token provider is set, Moolah makes it an **exclusive gate**: only the provider may call `supplyCollateral` / `withdrawCollateral` for that market, and a direct call reverts. So for those collaterals the provider *is* the integration surface.

To find out which provider backs which collateral, see [Integration Patterns](/for-developer/lista-lending/integration-patterns.md); for deployed addresses, [Smart Contract](/for-developer/lista-lending/smart-contract.md).

Check whether a market is provider-gated before building against it:

```solidity
function providers(Id id, address token) external view returns (address);
```

A non-zero result for the collateral token means you must route through it.

***

## BNBProvider — native BNB

Lista's BNB vaults hold **WBNB**. `BNBProvider` is the wrapper that lets a user deposit native BNB and receive vault shares in one call, and unwrap on the way out. Without it you must wrap to WBNB yourself first; sending BNB at the vault will not work.

```solidity
function deposit(address receiver) external payable returns (uint256 shares);
function mint(uint256 shares, address receiver) external payable returns (uint256 assets);
function withdraw(uint256 assets, address payable receiver, address owner) external returns (uint256 shares);
function redeem(uint256 shares, address payable receiver, address owner) external returns (uint256 assets);
```

The amount is `msg.value` — there is no assets argument on `deposit`. On `mint` you send at least the previewed cost (`msg.value >= previewAssets`, else `invalid BNB amount`) and the surplus is refunded.

Each instance is **bound to one vault**, so pick the one deployed for the vault you are targeting.

A newer implementation adds a multi-vault form, but **not every deployed provider runs it** — the calls below are absent from some of the listed addresses and revert with empty returndata there. Probe `vaults` first; if it reverts, you have a single-vault instance and only the four signatures above exist.

```solidity
function deposit(address vault, address receiver) external payable returns (uint256 shares);
function mint(address vault, uint256 shares, address receiver) external payable returns (uint256 assets);
function vaults(address vault) external view returns (bool);
```

On that implementation `vaults(v)` must be `true` or the call reverts `vault not added` — including for the single-argument form, which routes through the provider's own `MOOLAH_VAULT`. So a default vault that was never registered makes even `deposit(receiver)` revert.

The vault's own whitelist still applies to the **receiver** either way — see [Vault Reference](/for-developer/lista-lending/vault-reference.md).

**On the way out, there is nothing to approve.** `withdraw` and `redeem` do not pull your shares: the provider calls the vault's `withdrawFor` / `redeemFor`, which only the registered provider may call, and the vault burns from `owner` directly. Withdrawing your own position needs no allowance at all. Withdrawing someone else's needs *that owner* to have granted **you** — the original caller, not the provider — an ERC-20 allowance on the vault's share token.

***

## SlisBNBProvider — slisBNB collateral

slisBNB collateral is provider-gated, so these are the only ways *you* can voluntarily move it — liquidation is a separate path that seizes it directly, bypassing the provider entirely:

```solidity
function supplyCollateral(
  MarketParams memory marketParams,
  uint256 assets,
  address onBehalf,
  bytes calldata data
) external;

function withdrawCollateral(
  MarketParams memory marketParams,
  uint256 assets,
  address onBehalf,
  address receiver
) external;
```

**Approve the provider**, not Moolah — it pulls slisBNB from you with `transferFrom`. `marketParams.collateralToken` must be slisBNB (`invalid collateral token` otherwise), and `assets` must be non-zero.

On withdrawal the caller must be `onBehalf` or authorized for it (`unauthorized sender`).

Liquidation is the exception to the *user-facing* gate: Moolah transfers the seized collateral straight to the liquidator and then calls the provider's `liquidate(id, borrower)` hook. So collateral can leave a position without anyone calling `withdrawCollateral` — but the provider is still invoked, and on `SlisBNBProvider` that hook re-syncs the position and burns the corresponding `slisBNBx`, so Launchpool eligibility follows the liquidation.

Supplying through this provider also mints the non-transferable `slisBNBx` certificate that carries Binance Launchpool eligibility, and withdrawing burns it. The delegatee that holds it, and how to change it, are covered in [slisBNBx Delegation](/for-developer/clisbnb/delegation.md) — including that the certificate covers the user's part only, not the fee slice.

***

## SmartProvider — StableSwap LP collateral

For Smart Lending's provider, go to [Smart Lending & StableSwap](/for-developer/lista-lending/stableswap-integration.md) — it covers the supply/withdraw variants, the price-difference guard and the collateral token's transfer restrictions.

***

## See also

* [Contract & Interface Reference](/for-developer/lista-lending/contract-reference.md) — the provider gate as Moolah enforces it.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bsc.lista.org/for-developer/lista-lending/providers.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.