Lista DAO
About
Lista DAO is a decentralized finance protocol on BNB Chain that combines BNB liquid staking (slisBNB), a permissionless lending platform with isolated markets, a Collateralized Debt Position (CDP) system for minting the lisUSD stablecoin, a DEX (Smart Swap), RWA investment vaults, and on-chain credit lending. It serves as comprehensive DeFi infrastructure for users to stake, lend, borrow, swap, and access tokenized real-world assets — all governed by the LISTA token.
Where Does Yield Come From?
Lista DAO offers several ways to earn, each working differently. Here is how the main ones work.
1. Liquid Staking (slisBNB) You stake BNB and get slisBNB in return. Over time, each slisBNB becomes worth more BNB. This happens because Lista DAO lends your BNB to its own validators (the computers that run the blockchain), and those validators earn staking rewards. After the validators take a small cut, 95% of the leftover rewards go to slisBNB holders — shown by a rising exchange rate between slisBNB and BNB. The remaining 5% goes to the protocol's own treasury.
2. Lending and Borrowing (Lista Lending) This is a peer-to-peer lending system. Each market is kept separate ("isolated markets"): one market might let you deposit Asset A and borrow Asset B, with its own safety limits, interest rates, and available funds.
- Lenders deposit into these markets and earn a share of the interest that borrowers pay.
- Borrowers can choose flexible rates (they change over time) or fixed rates locked for 7, 14, or 30 days.
- The protocol takes a fee on borrowing interest (adjustable from 0% to 25% by DAO vote; currently set at 10%). The rest flows to lenders.
3. CDP System (lisUSD stablecoin) You lock up collateral (like BNB, ETH, or stablecoins) and mint lisUSD against it. You pay borrowing interest on whatever lisUSD you have outstanding. As a reward for borrowing, you can also claim LISTA token emissions.
4. Smart Lending & Swap When you supply collateral through Smart Lending, your funds get used as liquidity in Lista's internal exchange (Smart Swap) instead of a regular lending pool. Every trade on that exchange generates a small fee (0.01% per trade), and those fees flow to liquidity providers. So someone holding slisBNB in Smart Lending could potentially earn three layers at once:
- BNB staking rewards (the slisBNB appreciating against BNB)
- Swap fees from trading activity
- Any active emission rewards
5. RWA Markets (Real-World Assets) You can invest in vaults that hold tokenized versions of real-world financial products — for example, US Treasury bills, corporate bonds, or e-commerce financing. These vaults pass along the yields from those underlying instruments (institutional-grade returns from things like government debt or business loans).
6. Lista Credit This is an on-chain credit system where borrowers can take undercollateralized loans (they do not have to lock up full collateral) based on their DeFi reputation. Borrowers pay interest on those loans.
Audits
| Audit / Date | Findings | Verdict |
|---|---|---|
Bailsec01-01-2026 |
| Bailsec found 9 high and 18 medium severity issues in the credit loan system, with several important ones resolved (LISTA double-charge, penalty clamping, max LISTA rounding); however, 33 findings were acknowledged as residual risks (including the lack of liquidations, known Morpho-level attack vectors, and privileged governance powers), meaning ongoing governance diligence and future liquidation audits will be essential for safe operation. |
Cantina (Managed review by Giovanni Di Siena and Chinmay Farkya)15-01-2026 - 29-01-2026 |
| The Cantina audit found 2 high-severity and 3 medium-severity issues, all of which were either fixed (penalty circumvention, interest double-charge, grace-period penalty) or acknowledged with compensating controls (partial liquidation interest forgiveness managed via whitelisted bots); combined with the 12 low-severity and 22 gas/informational items largely addressed, the credit loan contracts show a solid security posture for Phase I deployment. |
| The audit identified one high-severity issue that was resolved before deployment, with all other findings acknowledged but not remediated; the report acknowledges significant design-level risks around liquidation incentives, bad debt socialization, and zombie positions that remain unaddressed, so additional caution and monitoring are warranted. | |
Cantina03-02-2026 - 04-02-2026 |
| All three findings were fixed and verified by Cantina before the report was finalized, removing the identified security risks. The review scope was limited to specific CreditBroker and Moolah modules, and no residual high-severity issues remain open. |
Bailsec01-12-2025 - 31-12-2025 |
| All four high-severity issues were resolved or acknowledged with mitigations in place, and the codebase was deemed sufficiently hardened for the slisBNBx minter migration. Residual risks are limited to acknowledged low-severity edge cases around fee timing and MPC wallet management that do not pose immediate threats to user funds. |
| The audit found no critical or high severity vulnerabilities, and the three medium-severity issues were either acknowledged or partially resolved, indicating that the SmartProvider and SlisBNBxMinter contracts do not contain immediate catastrophic flaws but operators should remain mindful of the acknowledged residual risks around oracle manipulation and MPC wallet cap management. | |
Cantina12-11-2025 |
| All four high-severity findings—centered on accounting desynchronization, interest bypass, and rounding-induced reverts—were fixed and verified by Cantina, resolving the most critical risks before deployment; residual acknowledged items (centralization in bot-triggered refinancing, rate accrual DoS under extreme conditions, and upgradeability immutables) warrant ongoing operational diligence but do not present imminent threats to protocol safety. |
Bailsec01-10-2025 |
| The audit reveals fundamental architectural flaws in the liquidation and collateral pricing mechanisms that can lead to bad debt, unprofitable liquidations, and user lockouts, with most High-severity issues remaining unresolved at the time of reporting. The protocol should not be considered safe until these systemic risks—especially the flawed collateral-price scaling logic—are addressed and remediated. |
BailSec24-11-2025 |
| BailSec identified significant pricing and liquidation reliability risks across both extensions, all of which were addressed or acknowledged; the resolved fixes substantially improve safety, though residual design risks remain around checkPriceDiff pool freezes during volatile conditions, which the team has acknowledged. |
OpenZeppelin18-09-2025 - 03-10-2025 |
| The single critical-impact finding (reentrancy) was resolved, but five medium-severity logic flaws remain acknowledged as out-of-scope for this upgrade, creating residual risk in liquidation health enforcement, fee accrual, dust positions, and bad-debt socialization that should be addressed before relying on the modified lending and AMM components in production. |
Bailsec (Bailsec.io)22-05-2025 |
| This differential audit identified two high-severity mint-unbacked-token and fund-stuck bugs that were resolved, alongside a medium-severity liquidation-blocking issue and several lower-severity findings that were either resolved or acknowledged; the protocol's safety relies on proper deployment of the patched contracts and ongoing monitoring of provider and MPC wallet configurations. |
BlockSec12-05-2025 |
| The audit uncovered 10 security issues including 3 high-severity bugs that could cause loss of funds or incorrect state, all of which were remediated in Version 2, leaving only one low-severity confirmed item (missing callback implementations) with no planned fix. The codebase is substantially safer after the fixes, though residual centralization risks from privileged roles remain as noted in the report. |
CertiK17-04-2025 |
| The audit found no critical or high-severity issues, with the team resolving 3 findings (LDA-03, ERC-03, ILT-01) and acknowledging the remaining centralization and design risks with planned mitigations including TimeLock and multi-sig controls, indicating a manageable security posture for the LP minting and clisBNB functionality. |
BlockSec03-04-2025 |
| The two medium-severity findings were either fixed (incorrect mint address) or mitigated via an off-chain bot sync strategy, and the low-severity issue was confirmed, leaving no unaddressed high or critical risks in the audited scope, though the centralization and price-manipulation notes warrant ongoing operational care. |
Bailsec.io (Bailsec)10-04-2025 |
| The audit identifies several high-severity risks, particularly around the permissioned BOT role in the Liquidator (where one issue remains unresolved) and residual design risks inherited from Morpho Blue; however, critical findings such as fake-market extraction and first-borrower inflation have been resolved. The protocol should ensure the BOT role is fully trusted and monitor oracle-dependent markets closely to mitigate medium-severity attack surfaces. |
BlockSec03-04-2025 |
| BlockSec's audit found one Medium and four Low severity issues, with the Medium (inflation attack) and two Low issues fixed in version 2, while two Low items and all recommendations/notes remain confirmed; the centralization risks and operational notes warrant continued attention from the Lista DAO team before production deployment. |
BlockSec18-12-2024 |
| BlockSec identified 3 exploitable findings (1 High, 2 Medium) in the USDTLpListaDistributor contract, all remediated in Version 2, alongside operational recommendations and centralization notes addressed via Timelock controls; the reviewed codebase appears adequately secured for its intended use after the fixes were applied. |
| BailSec identified and resolved two High-severity reward-accounting bugs that could have led to fund loss, while the remaining acknowledged items are design-tradeoff edge cases mitigated by governance controls and a bot-automated harvest schedule, indicating the contracts are safe for deployment after the fixes. | |
Bailsec27-11-2024 |
| The audit identified one high-severity and four medium-severity issues, with the critical incentive-loss vector resolved and key medium findings fixed; residual acknowledged risks around truncation and pausable bypass are documented design constraints rather than exploitable vulnerabilities given the team's operational safeguards. |
BlockSec26-11-2024 |
| The audit identified one medium and two low severity issues, all of which were either fixed or acknowledged, with no critical or high-risk vulnerabilities remaining in scope, indicating the contracts are reasonably secure for deployment. |
BlockSec22-11-2024 |
| The audit found one medium and one low severity issue, with the medium-risk DoS vulnerability fixed in version 2, leaving the PSM contracts reasonably secured. Residual risks are limited to informational notes on centralization (addressed by TimeLock) and code quality recommendations. |
Salus Security20-11-202422-11-2024 |
| No critical or high-severity vulnerabilities were found; the single medium-severity centralization risk was mitigated by adopting a multisig owner, and all other issues were resolved or acknowledged, making the PSM contracts safe for deployment with the applied fixes. |
Salus Security21-10-2024 |
| The single medium-severity centralization risk was acknowledged by the team with a commitment to multi-sig governance, so no critical contract-level vulnerabilities remain unresolved; the audit indicates the contracts are reasonably safe for deployment provided multi-sig controls are implemented. |
BlockSec16-10-2024 |
| The audit found only one low-severity issue and three recommendations, with no high or medium risks; the five informational notes flag centralization and design concerns that the team plans to address via multi-sig controls and admin oversight. |
PeckShield26-09-2024 |
| The audit found no critical or high-severity issues; the one medium-severity finding (admin key trust) was confirmed and mitigated with multi-sig, while both low-severity findings were fixed, indicating a well-structured codebase with manageable residual risk. |
| No critical or high-severity vulnerabilities were found, both medium-severity findings were resolved or mitigated (multisig migration), and the remaining low/informational items pose minimal residual risk to the protocol's safety. | |
Salus Security13-08-2024 |
| The audit identified one high-severity business logic flaw that was resolved prior to report publication, and medium-severity centralization risks were mitigated via planned multisig ownership, leaving no unresolved high or critical issues. |
BlockSec12-08-2024 |
| All security vulnerabilities identified were either fixed by the project team (Version 2) or acknowledged with mitigations, and the most critical issue — unrestricted share minting — was remediated; residual risks are limited to the noted centralization vector, which is addressed via a planned multi-sig setup. |
BlockSec06-08-2024 |
| The audit identified three medium-severity and three low-severity issues, with several fixed in Version 2, while the remaining confirmed items and centralization risk are acknowledged by the team for future resolution, indicating a reasonably secure codebase with manageable residual risks. |
Salus Security07-08-202408-08-2024 |
| The audit found no critical, high, or medium severity vulnerabilities; the two low-severity issues (centralization risk and missing events) and one informational finding (redundant code) were all acknowledged by the Lista DAO team, with the centralization risk to be mitigated via multi-sig migration, posing minimal safety concern for the protocol. |
BlockSec19-06-2024 |
| All three low-severity vulnerabilities were fixed during the audit, and no critical or high-risk issues were found, indicating the ListaOFT contracts are ready for deployment with acceptable residual risk. |
PeckShield19-06-2024 |
| The audit found no critical or high severity issues, with only a low-severity trust concern over admin keys and an informational gas-efficiency recommendation, indicating the ListaToken contract is sound and ERC20-compliant; the primary residual risk is the inherent centralization of admin-key control. |
PeckShield30-04-2024 |
| The audit found only one low-severity vulnerability and two informational recommendations, all of which were addressed by the team, indicating the oracle contracts were well-designed and secure as of the audit date. |
PeckShield18-04-2024 |
| The audit found only one low-severity and one informational issue in a well-structured codebase, both of which were promptly confirmed and addressed, indicating the slisBNBOracle contract is sound for its intended use. |
Salus Security (SALUS)27-06-202401-07-202402-07-202412-07-2024 |
| The single medium-severity vulnerability was resolved, and remaining low/informational items were either fixed or acknowledged with mitigations, indicating a solid security posture for the Lista token smart contracts at the time of the audit. |
BlockSec16-07-2024 |
| BlockSec identified one high, two medium, and two low severity issues that were all fixed in the audit iteration process, making the contracts safer for launch—though the residual centralization risk is acknowledged and partially mitigated by the planned multi-sig admin. |
PeckShield02-04-2024 |
| The audit found no critical or high-severity vulnerabilities; the one medium-severity finding (admin key trust) was mitigated via multi-sig and all other issues were resolved, indicating that the ListaAirdrop contracts are well-designed and safe for deployment. |
Supremacy03-04-2024 |
| All findings were fixed or mitigated before final release, and the contracts presented no critical or high-severity vulnerabilities at the conclusion of the audit, indicating a reasonable security posture for the airdrop functionality. |
BlockSec03-04-2024 |
| BlockSec identified a single medium-severity signature-replay issue that was fixed by the team, and no high-risk or critical vulnerabilities were found, indicating a generally sound contract. |
Supremacy03-04-2024 |
| The audit identified no critical, high, medium, or low severity vulnerabilities; the sole Informational finding (centralized risk) was addressed by confirming the owner is a multisig wallet. The token contract presents minimal security concerns based on this assessment. |
PeckShield07-05-2024 |
| The audit found no critical or high severity vulnerabilities, and the single medium-severity finding (admin key trust) was mitigated through multi-sig governance, making the contract safe for its intended use. |
BlockSec08-05-2024 |
| The audit identified 3 medium and 2 low severity issues, all but one of which were fixed before the final signed version, indicating a reasonably secure codebase after remediation; the remaining low-severity finding regarding timely reward compounding was acknowledged by the project as an accepted gas-cost trade-off. |
Veridise23-05-2022 - 13-06-2022 |
| The audit uncovered a critical DoS vulnerability and six high-severity issues, all of which were fixed, demonstrating that the Helio Protocol addressed its most material risks before deployment; residual medium and low findings acknowledged as intended behavior do not pose systemic threats to the protocol's core safety. |
SlowMist17-05-2022 - 24-05-2022 |
| The audit identified one critical fund-theft vulnerability and four medium-risk issues, all of which were fixed except a confirmed excessive-authority finding; the code was not deployed to mainnet at the time, mitigating residual risk until governance controls are implemented. |
SlowMist Security Team28-04-2022 - 10-05-2022 |
| All findings were fixed before deployment and the code was not on mainnet at audit time, making this a clean pre-deployment review with no residual open issues. |
PeckShield25-05-2022 |
| The audit identified one high-severity flashloan/MEV reward manipulation risk and several medium/low issues, all of which were addressed by the team (fixed or mitigated) before deployment, making the protocol reasonably robust for its initial release. |
CertiK30-05-2022 |
| The audit found no critical vulnerabilities, but the acknowledged centralization risk (many privileged roles across the system) and the acknowledged reentrancy concern (with the team relying on trusted contracts) represent residual design risks that users should evaluate against the project's decentralization goals. |
Backers
Lista DAO is backed by YZi Labs (formerly Binance Labs), the venture capital and incubation arm of Binance. According to the official Lista DAO documentation, Binance Labs made a strategic investment of $10 million USD in the project. YZi Labs is listed as an investor on the Lista DAO homepage (lista.org) under the "INVESTORS" section, and the FAQ describes Lista as "Backed by Yzi Labs." No other institutional investors or additional funding rounds are disclosed on the project's official website or documentation.
Legal
Legal form
Decentralized autonomous organization (DAO)
Registration jurisdiction
Republic of Seychelles (per Terms of Use, governing law is the laws of the Republic of Seychelles)
Status and notes
Lista DAO is described as a decentralized autonomous organization. The Terms of Use state they are governed by the laws of the Republic of Seychelles and deem the Interface as based in Seychelles. The Legal Disclaimer repeatedly references "Lista DAO" and "Project Contributors" without naming a specific incorporated entity. The FAQ mentions the company worked with GS Legal LLC for a legal opinion on token distribution. The website footer shows '© 2026 LISTA All rights reserved.' No specific company registration number, registered address, or formal entity name (e.g., Ltd, LLC, Foundation) is disclosed.