> 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/liquid-staking-slisbnb/cross-chain-bridge.md).

# Cross-Chain Bridge

slisBNB moves between BNB Smart Chain and Ethereum as a **LayerZero OFT**. Deployed addresses and endpoint IDs are on [Smart Contract](/for-developer/liquid-staking-slisbnb/smart-contract.md).

## Architecture

Supply is never duplicated: the token is locked on its home chain and minted as a representation on the destination chain.

| Contract           | Chain           | Role                                                                                                                                                      |
| ------------------ | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ListaOFTAdapter`  | BNB Smart Chain | Locks slisBNB on the way out, releases it on the way back. slisBNB itself is a plain ERC-20 — the adapter wraps it rather than the token being OFT-aware. |
| `ListaOFT`         | Ethereum        | Mints on arrival, burns on the way back. Supply here is always backed by the amount locked in the adapter.                                                |
| LayerZero Endpoint | both            | Message transport.                                                                                                                                        |

Both sides carry the same two controls: a **transfer limiter** and an **emergency pause**. The limiter is five separate bounds, not one — see below.

## The transfer path

<div data-full-width="true"><figure><img src="https://1802824789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F60fXF9rALi6luWHVkkGg%2Fuploads%2FZmQdVpBFRMYDeo3fmJuS%2Fimage.png?alt=media&amp;token=a2954e31-a512-4724-bf11-7691b8c54d8c" alt=""><figcaption></figcaption></figure></div>

**BSC → Ethereum.** You send `amount` to `ListaOFTAdapter`; it applies the transfer limiter and pause checks, **locks** the tokens, and passes the message to the LayerZero Endpoint on BSC. The DVN verifies it, the Executor calls `lzReceive()` on the Endpoint on Ethereum, and `ListaOFT` **mints** the equivalent to your address there.

**Ethereum → BSC.** The mirror image: `ListaOFT` checks its own limiter and pause, **burns** the tokens, the message travels the same DVN/Executor path in reverse, and `ListaOFTAdapter` **unlocks** the equivalent on BSC.

Both directions pass the same two Lista-side gates — the limiter and the pause — so a transfer that would breach either fails on the source chain, before any message is sent.

## Trust model

A transfer is not final when the source transaction confirms. LayerZero's **DVN** verifies the message on the destination chain and an **Executor** delivers it by calling `lzReceive`; the destination mint happens only then. So the bridge inherits LayerZero's verification assumptions, plus a Lista-side pause: `pause()` is callable only by the address in `multiSig()` — the same Gnosis Safe on both chains — and `unpause()` only by `owner()`, a different address.

The practical consequence is that a transfer can be accepted on the source chain and still not settle promptly — treat destination arrival as asynchronous and confirm it rather than inferring it from the send.

## Calling it

Use LayerZero's own `SendParam` / `quoteSend` interface; nothing about the call shape is Lista-specific. Two Lista-side conditions make `send()` revert and neither shows up in a LayerZero quote:

* **Dust.** The OFT uses `sharedDecimals = 6`, so raw amounts are truncated down to a multiple of `1e12`. Pass an `amountLD` and `minAmountLD` that are already dust-removed, or the truncated amount falls below `minAmountLD` and the call reverts.
* **Limiter or pause.** Any transfer while paused reverts. So does one that breaches any of five separate bounds, all raising `TransferLimitExceeded()` and all evaluated on the dust-removed amount:

| Bound                            | Reverts when                                          |
| -------------------------------- | ----------------------------------------------------- |
| `singleTransferUpperLimit`       | the amount is above it                                |
| `singleTransferLowerLimit`       | the amount is **below** it — small transfers fail too |
| `maxDailyTransferAmount`         | the global accumulated volume is exceeded             |
| `dailyTransferAmountPerAddress`  | the sender's accumulated volume is exceeded           |
| `dailyTransferAttemptPerAddress` | the sender's accumulated attempt count is exceeded    |

Do not model the counters yourself — their reset rule is not a fixed window. Read `transferLimitConfigs(dstEid)` for the bounds and `dailyTransferAmount` / `userDailyTransferAmount` / `userDailyAttempt` for the current usage immediately before quoting.

## See also

* [LayerZero OFT documentation](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) — `SendParam`, `quoteSend` and the messaging model.


---

# 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/liquid-staking-slisbnb/cross-chain-bridge.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.