> 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/clisbnb/delegation.md).

# Delegation

`slisBNBx` is a non-transferable certificate, so a holder cannot move it with a normal ERC-20 `transfer`. Instead, the protocol lets an account choose **which wallet holds the `slisBNBx` minted on its behalf**. This is called delegation, and it is the mechanism used to route a position's `slisBNBx` (and therefore its Binance Launchpool eligibility) to another wallet, such as a Binance Web3 MPC wallet.

Delegation is managed by `SlisBNBxMinter`, the mint-and-burn engine for `slisBNBx`, deployed on BNB Smart Chain at [`0x2959c423bfe5Cc6E41516599D982A29C0773F11a`](https://bscscan.com/address/0x2959c423bfe5Cc6E41516599D982A29C0773F11a). See [Lista Lending BSC Core](/for-developer/lista-lending/smart-contract/smart-contract-bsc-core.md) for the other `slisBNBx` addresses — this page's [Smart Contract](/for-developer/clisbnb/smart-contract.md) only lists the Launchpool/provider contracts, not `SlisBNBxMinter`.

## Delegation model

| Property             | Behavior                                                                                                                                                                                                                                                                                                                                            |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Scope                | **Per account, not per position.** A single delegatee holds the account's whole recorded `slisBNBx` position across all collateral modules (the `slisBNB` provider and the `slisBNB/BNB` LP provider). Note this is the **user's part only** — each module mints a fee slice to a Lista wallet, which is not part of the delegated amount.          |
| Granularity          | **No partial delegation through the minter.** `SlisBNBxMinter.delegateAllTo` is all-or-nothing. The legacy CDP providers are a separate, still-live path that does support per-amount delegation — see the note below.                                                                                                                              |
| Default              | If an account has never set a delegatee, the holder defaults to **the account itself**. Note this default is applied lazily: `delegation[account]` is written during the first balance-changing rebalance, so **reading it beforehand returns `address(0)`, not the account**. Treat a zero result as "delegated to self", not as unset-and-broken. |
| Mutability           | **Can be changed at any time** via `delegateAllTo`. It is *not* fixed at mint time.                                                                                                                                                                                                                                                                 |
| Effect on collateral | Delegation only changes **who holds the `slisBNBx` certificate**. It does not move, re-own, or otherwise affect the underlying collateral in Moolah.                                                                                                                                                                                                |

The minter stores delegation as a single mapping, `delegation[account] => delegatee`, and tracks each account's own `slisBNBx` across every module in `userTotalBalance[account]` (the user part, excluding the per-module fee slice minted to Lista). Both are read-only and queryable on-chain.

## Changing the delegatee

Reassigning the delegatee is **atomic**: the minter burns the account's recorded `userTotalBalance` from the old holder and mints the same amount to the new delegatee in a single call (a delegatee may hold for several accounts, so this is not necessarily their whole balance). No rebalance against collateral happens during the switch — only the holder changes.

### `delegateAllTo` (called by the account)

```solidity
function delegateAllTo(address newDelegatee) external;
```

Called by the account itself (`msg.sender`). It delegates the account's whole `slisBNBx` balance to `newDelegatee`.

* No-op if `newDelegatee` already equals the current delegatee (this equality check runs first).
* Otherwise, the zero address is rejected as a new delegatee.
* Internally: reads `userTotalBalance[account]`, burns that amount from the current holder (the old delegatee, or the account itself if none was set), records `delegation[account] = newDelegatee`, then mints the burned amount to `newDelegatee`.

A module-only variant, `syncDelegatee(address account, address newDelegatee)`, does the same thing from a registered collateral module. It is not callable by an integrator.

## Legacy `SlisBNBProvider.delegateAllTo` is disabled

The `SlisBNBProvider` collateral module also exposes `delegateAllTo(address)` from an earlier design. Once that provider is wired to the minter, its own `delegateAllTo` **reverts with `"not supported"`** and delegation for it must go through `SlisBNBxMinter.delegateAllTo`.

> The same `slisBNBx` token has several minters, and the legacy CDP providers are still live and unpaused. Those support **per-amount** delegation and are not gated by the minter, so "all delegation goes through the minter" holds for the modules the minter owns, not for the token as a whole. Read the specific provider before assuming which path applies.

```solidity
// SlisBNBProvider.delegateAllTo — legacy path, gated off once the minter is set
require(slisBNBxMinter == address(0), "not supported");
```

## Events

These track delegation and the resulting certificate movements. Note **none of their parameters is `indexed`**, so you cannot filter by account at the node — fetch by address and topic0, then filter client-side:

| Event                  | Emitted by       | Signature                                                                                             | Meaning                                                                                                         |
| ---------------------- | ---------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `ChangeDelegateTo`     | `SlisBNBxMinter` | `ChangeDelegateTo(address account, address oldDelegatee, address newDelegatee, uint256 amount)`       | Delegatee reassigned; `amount` is the `slisBNBx` actually burned from the old holder and minted to the new one. |
| `UserModuleRebalanced` | `SlisBNBxMinter` | `UserModuleRebalanced(address account, address module, uint256 userPart, uint256 feePart)`            | Per-module `slisBNBx` recomputed for the account during a rebalance.                                            |
| `Rebalance`            | `SlisBNBxMinter` | `Rebalance(address account, uint256 latestModuleBalance, address module, uint256 latestTotalBalance)` | A module triggered a rebalance; `latestTotalBalance` is the account's new total across modules.                 |

> The `SlisBNBProvider` contract emits its own `ChangeDelegateTo(address account, address oldDelegatee, address newDelegatee)` (note: **no `amount` field**) only from the legacy, now-disabled path. For the current minter architecture, listen for the `SlisBNBxMinter` event above.

## Integration notes

* **Read, don't expect transfers.** `slisBNBx` is non-transferable. To find an account's certificate holder, read `delegation[account]` — a zero result means the account itself, not an error; to find the account's own amount, read `userTotalBalance[account]`.
* **Withdrawing burns from the holder, not from you.** When collateral leaves Moolah the minter burns `slisBNBx` from whichever wallet currently holds it — the delegatee, if you set one. You do not need to hold the certificate, or to control that wallet, to withdraw. If the holder's balance is short of the amount to burn, the minter burns what is there rather than reverting, so a withdrawal never fails on the certificate leg.
* **Delegation does not auto-rebalance.** `delegateAllTo` moves the existing balance as-is. Subsequent collateral supply/withdraw will rebalance the certificate to the *current* delegatee.
* **The new holder receives Launchpool eligibility.** Because eligibility is computed off-chain from `slisBNBx` balances, the wallet that holds the certificate after delegation is the one credited with rewards.


---

# 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/clisbnb/delegation.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.