Lista Lending

Lista Lending is Moolah, Lista DAO’s decentralized P2P lending protocol, primarily on BNB Smart Chain (BSC) with an additional deployment on Ethereum. Identification

• Name: Lista Lending (Moolah)
• Website: lista.org (lending section referenced as /lending)
• Docs: docs.bsc.lista.org, section “Lista Lending” and “Smart Contract”
• Category: DeFi lending protocol with isolated, curator-managed markets and vault-based liquidity
• Launch date: April 2025 for BNB Chain deployment (Lista Lending “launched in April 2025”)
• Chains:
• BNB Smart Chain (BSC): core/largest deployment
• Ethereum: USDT/USDC savings vaults collateralized by ETH, described as cross‑chain expansion
• Native token (ecosystem): LISTA (BEP‑20), total supply 1,000,000,000; token contract: 0xFceB31A79F71AC9CBDCF853519c1b12D379EdC46 on BSC (AscendEX listing).
• Note: LISTA is the DAO/token for the broader Lista ecosystem, not specific to Lending only. Main contract addresses & verification
• Docs provide contract reference lists for BSC smart contracts (lending core, interest rate models, vaults, rewards), but individual addresses are only summarized and not all surfaced in the high‑level snippet.
• Cross‑checking with explorers and on‑chain data for specific lending markets and vaults is Not verifiable as of 2026-09-04 under current constraints (no direct explorer/Dune inspection this turn).
• Verified‑contract status for Lista Lending core/vault contracts on BSC and Ethereum is likewise Not verifiable as of 2026-09-04. Fork lineage / architecture
• Docs state Lista Lending/Moolah is “powered by Morpho and built on Morpho Blue smart contracts”, extending standard Morpho market architecture.
• Listed changes vs upstream Morpho/Morpho Blue include: minimum loan floor, resilient oracle routing, protocol‑level reentrancy protection, upgradeability, role‑based access control, and provider/broker integration patterns for collateral handling and curated access.
• External reviews describe Lista Lending as a “Morpho‑Blue‑style permissionless lending protocol with curator‑managed vaults.” Audits & fork risk history
• Cantina security campaign and “securing $3.05B in TVL across BNBFi” are referenced for Lista DAO generally, suggesting a professional audit/assessment program at ecosystem level, but concrete audit report links for Lista Lending contracts are Not verifiable as of 2026-09-04.
• No specific record of malicious modifications in Lista Lending forks or exploited Lista‑specific changes was found; absence of evidence should not be treated as proof of safety. Not verifiable as of 2026-09-04 for detailed exploit history at contract level. Contradiction callout
• TVL and chain coverage figures differ slightly across aggregators (DefiLlama vs MrDeFi vs media mentions) but all agree on BSC+Ethereum deployments; without on‑chain queries, the exact TVL and per‑chain breakdown are Not verifiable as of 2026-09-04.

Lista Lending appears to be a real, functioning product rather than a simple landing page: the docs describe an open-source lending protocol with a live interface for borrowing, vaults, and smart-contract interactions on BNB Chain and Ethereum, and they explicitly document separate contract sets for both chains. The ecosystem also exposes developer-facing documentation, including contract pages and a developer-access pattern via dynamic doc queries, which is a stronger maturity signal than a static marketing site. The evidence available here supports that the portal is not just a template-style brochure, but it does not independently prove live deposit/withdrawal execution or current app uptime; those operational checks are Not verifiable as of 2026-09-04.

Similarly, broken links, fake metrics, and other UX integrity issues are Not verifiable as of 2026-09-04 from the available evidence. An open API is not clearly documented in the sources reviewed. The docs do show developer-oriented pages and contract references, but no explicit public API specification, endpoint list, or SDK surface was verified, so open API status is Not verifiable as of 2026-09-04.

On-chain maturity by chain cannot be quantified here because on-chain verification is unavailable in this run; chain split, deposits, and withdrawals remain Not verifiable as of 2026-09-04. The strongest conclusion is that Lista Lending has a real product surface with substantive documentation for BNB Chain and Ethereum, but key operational and API claims remain unverified in this environment.

Lista Lending / Lista DAO appears to have an active bug bounty program on Immunefi. The Immunefi listing shows a maximum bounty of $1,000,000, live since 16 June 2022, with PoC required. Rewards are tied to impact severity: smart-contract critical up to 10% of funds directly affected, capped at $1,000,000, with a $100,000 minimum; high up to $10,000; medium up to $5,000.

Payouts are handled by the Lista team and are denominated in USD, paid in USDT, USDC, or lisUSD at the team’s discretion. A separate BNB Chain ecosystem bounty announcement also exists for Lista, with rewards from $300 to $150,000, but that appears to be a different program/track and is not clearly the primary long-running bounty referenced by Immunefi. No independently verified bug bounty outcomes were found in the gathered sources.

Assessment (as of September 6, 2026): Lista Lending has material external-counterparty dependency risk, but no verified active dependency failure was identified in the sources reviewed. dependency_failure_active is therefore null rather than false.

• Protocol architecture: Markets are isolated, reducing direct contagion between collateral/loan pairs. However, vaults still depend on Lista’s contracts, curators, liquidation execution, and available market liquidity. Third-party vaults may be managed by independent curators, creating curator and parameter-governance risk.
• Oracle/manipulation risk: Lista Lending markets use immutable, market-specific oracle addresses. Supported designs include Chainlink, RedStone, API3, Pyth, Chronicle, exchange-rate, fixed-price, and Pendle PT discount oracles. This creates provider, stale-price, feed-divergence, and implementation risk; multi-oracle verification is not equivalent to eliminating manipulation risk.
• Cross-chain/bridge exposure: slisBNB bridging between BNB Chain and Ethereum introduces bridge, wrapped-asset, message-validation, and liquidity risks. Exact bridge balances and Lista Lending exposure by chain are Not verifiable as of September 6, 2026 because Dune MCP/on-chain verification is unavailable.
• Stablecoin/LST/restaking exposure: Documented or reported markets include USDT, USDC, USD1, lisUSD, ETH, BNB/slisBNB and Pendle PT collateral. PT markets add dependency on Pendle liquidity, maturity/redemption mechanics, and underlying assets such as USDe/sUSDe, USR, and other yield-bearing instruments. Ethereum vault reporting identifies USDT/USDC lending collateralized by ETH; this is a protocol-originated announcement and should be treated as an unverified marketing claim absent on-chain confirmation.
• Custodian/CEX/MM/RWA/SPV: No verified direct custodian, centralized-exchange, market-maker, RWA issuer/SPV, or insolvency-counterparty exposure was established from the reviewed sources. Not verifiable as of September 6, 2026. Stress scenarios: oracle divergence or stale prices could cause bad borrowing capacity/liquidations; stablecoin or LST depeg could create bad debt; bridge failure could strand or invalidate bridged collateral; Pendle/PT or restaking-asset impairment could impair liquidation value; and thin liquidity could prevent timely liquidation. max_exposure_pct: null — Not verifiable as of September 6, 2026 without Dune/on-chain balances and per-market exposure data.

Lista Lending appears organized as a non-custodial, smart-contract-based lending system: user deposits are held and managed by protocol contracts rather than by a company or operator, and the docs say assets sent to the protocol are “held and managed by smart contracts without the interference of any person or legal entity.” The protocol uses a vault layer and market layer, which means custody is programmatic and segmented by contract logic rather than discretionary omnibus custody. Third-party vaults are also described as non-custodial, with curators able to adjust parameters but explicitly unable to withdraw, seize, or redirect user funds. Withdrawal status is not verifiable as of 2026-09-06.

Segregation is partially supported: assets are organized by vault/market structure, but whether all exposures are fully segregated at the asset level across Ethereum and BSC is not verifiable as of 2026-09-06.

On October 8, 2025, Lista Lending temporarily paused borrowing and lending after detecting abnormal price movement in YUSD collateral. The event was precautionary; no exploit, theft, liquidation loss, or affected-user loss was publicly established. Affected parties were Lista Lending borrowers, suppliers, and positions using YUSD as collateral.

Response: platform pause and investigation to prevent oracle-driven liquidations. No reimbursement was required or reported. Lista Lending was operating subsequently, so the incident is treated as resolved.

Exact realised loss: Not verifiable as of September 6, 2026.

On November 6, 2025, Lista DAO forcibly liquidated the Re7 Labs USDX/USD1 vault on BNB Chain after USDX-related risks escalated, utilization approached 99%, and USDX depegged. This was a collateral depeg/liquidity event, not a confirmed Lista smart-contract exploit. Affected parties were Re7 vault suppliers/depositors; some withdrawals were blocked and users were exposed to impaired USDX collateral.

Response: emergency governance approval under LIP-022, flash-loan liquidation of approximately 3,526,011 USDX, and recovery of approximately 2,927,163 USD1. LIP-023 approved pro-rata distribution of 481,801.15 USD1 liquidation profit to eligible suppliers. Exact realised loss and total remaining bad debt: Not verifiable as of September 6, 2026.

Users received partial relief, not demonstrably full reimbursement. Status: remediation_in_progress.

On March 22–27, 2026, following the external Resolv USR unauthorized-minting incident and resulting wstUSR/USR market stress, Lista Lending paused or discussed emergency handling for affected USR-related positions, including MEV Capital and Re7-linked vault exposure. The event affected users with USR/wstUSR collateral or lending positions on Lista; available reporting indicates most related loans were repaid and positions closed at full 1:1 USD redemption, with no loss claimed for Lista or users. Cause was external collateral/liquidity disruption rather than a confirmed Lista exploit.

No attacker proceeds were attributed to Lista. Reimbursement was not required according to available reporting. Status: resolved, subject to incomplete independent verification of final position-level outcomes.

Exact realised loss: Not verifiable as of September 6, 2026.

A later USR-related event in March 2026 involved abnormal wstUSR collateral pricing and very high utilization in MEV Capital and Re7 Labs vaults, with emergency governance and forced-liquidation discussions; reporting says most USR-related loans were repaid and positions closed at full 1:1 USD redemption, with zero loss claimed for users and the protocol.

Lista Lending’s key management is organized as role-based access control around vault operations, not as a single key held by the protocol. The documented vault setup exposes distinct roles—Owner, Curator, Guardian, and Allocator—with each role assigned to control specific operational permissions such as vault creation, parameter changes, and market allocation. The docs also describe a Timelock field for vault creation, which adds a delay layer before sensitive changes take effect.

At the protocol level, Lista says its lending system includes granular permission management, upgradeable contracts, and a 24-hour timelock as security measures. That indicates key-sensitive actions are separated across multiple authorized actors rather than concentrated in one wallet. For the lending-rewards subsystem, the architecture further separates duties: the RewardsRouter holds reward tokens and only transfers them to whitelisted distributor contracts managed by a MANAGER role, while a BOT role executes reward transfers.

This is another example of segmented operational control rather than monolithic key custody. For the specific BSC and Ethereum deployments, the exact signer topology, multisig arrangement, and whether different roles map to individual EOAs, multisigs, or DAO-controlled addresses are Not verifiable as of 2026-09-04 from the available sources.

As of September 6, 2026. Dune is unavailable in this run; therefore all on-chain role, proxy, timelock, and withdrawal checks are Not verifiable as of September 6, 2026. Deployment addresses (official documentation):

• BNB Chain: Moolah 0x8F73…5D8C; InterestRateModel 0xFe7d…De7c; OracleAdaptor 0x2165…7b58; Liquidator 0x6a87…a59a; VaultFactory 0x2a0C…9671; Lending TimeLock 0x2e28…bb85; fee recipient 0x2E2E…51f3.
• Ethereum: Moolah 0xf820…Fd70; IRM 0x8b7d…F990; Liquidator 0x5Bf5…301C; PublicLiquidator 0x7963…1DE5; Manager TimeLock 0x375f…428BA; Admin TimeLock 0xa18a…00D61; fee recipient 0xd10a…0D30. Architecture: Moolah is documented and source-represented as a UUPS upgradeable, AccessControl-based, pausable lending core. The protocol states that upgrade authority is held by DEFAULT_ADMIN_ROLE and execution is delayed by a TimeLock; the documented review window is one day. These claims are not independently verified on-chain in this run. ``text Users → Moolah (UUPS proxy) → isolated markets ├─ OracleAdaptor / oracles ├─ Interest-rate models ├─ Liquidators └─ Vaults (upgradeable ERC-4626-style aggregation) Admin/roles → TimeLock(s) → implementation, parameters, fees, pause `` Admin and exit risk: Exact proxy-admin type, current admin/owner/guardian/allocator addresses, role renunciation, pause/withdrawal/upgrade/fee/oracle/strategy permissions, and timelock delay measured from events: Not verifiable as of September 6, 2026. User exit without administration is likewise Not verifiable as of September 6, 2026. If privileged keys or the controlling timelock path were compromised, the plausible worst case is malicious implementation upgrade, parameter/oracle manipulation, pausing/freezing, fee redirection, or asset loss; direct admin drainage is Not verifiable as of September 6, 2026. Audit status: Lista publishes multiple third-party audit reports, but whether the currently deployed BSC/Ethereum bytecode is the audited revision, and unresolved critical/high counts, are Not verifiable as of September 6, 2026. Contradiction callout: No independently verifiable contradiction was identified; protocol documentation is treated as an unverified marketing/operational claim where not corroborated by on-chain data.

BailSec audit of Lista Lending referenced as “Bailsec-ListaLending-AuditReport-20250410.pdf” in Lista docs and on BailSec audits page as “Lista DAO - Lista Lending, Security Review, Date of Report: March 2025”. Detailed issue list not visible in snippets..

Audit of LISTA Lending. The docs index lists this as the LISTA Lending audit dated 2025-04-10. The audit report title is referenced in the audit-reports page, but the search excerpt does not expose the findings table, fix status, or any explicit bytecode-match/deployed-code coverage statement. Those details are not verifiable as of 2026-08-29 from the provided excerpt.

Audit of LISTA Lending Provider. The docs index lists this report dated 2025-05-22, but the provided excerpt does not include findings counts, severities, remediations, or a bytecode-match statement. Not verifiable as of 2026-08-29.

Audit of SlisBNBMinter for Lista Lending. The docs index lists this report dated 2026-01-05, but the provided excerpt does not include findings counts, severities, remediation status, or bytecode-match/deployed-code coverage. Not verifiable as of 2026-08-29.

Audit of Credit Loan. The docs index lists this report dated 2026-01, and a secondary index-style source mentions the credit-loan reviews by BailSec and Cantina. However, the provided snippets do not expose the full report contents needed to extract exact critical/high/medium counts, fix status, or deployed-code coverage. Not verifiable as of 2026-08-29.

Audit of Lista Lending code repository. Scope covered smart contracts in the repository's src/ folder, excluding src/moolah/mocks/*, src/moolah-vault/mocks/*, and src/vault-allocator/mocks/*. The report states no critical issues were found.

Findings listed: 1 Medium, 4 Low, plus 3 recommendations and 4 notes. Severity/status details: Medium potential inflation attacks — Fixed; Low lack of validation checks in createMarket() — Fixed; Low bypass of the bad debt handling mechanism in liquidate() — Fixed; Low potential replay attacks due to the chain hard fork — Confirmed; Low potential DoS risk in reallocate() — Confirmed. Notes were marked Confirmed or left unclassified.

The report does not provide a separate deployed-code bytecode-match statement in the excerpt provided, so bytecode coverage is not verifiable as of 2026-08-29.

Auditor: BlockSec. Report publication date: April 3, 2025 according to BlockSec’s audit index; Lista’s audit page lists the associated filename with date April 10, 2025. Scope: smart contracts in the Lista Lending repository’s src/ directory, excluding src/moolah/mocks/*, src/moolah-vault/mocks/* and src/vault-allocator/mocks/*.

Findings: Critical 0; High 0; Medium 1; Low 4; plus 3 recommendations and 4 notes. The Medium finding was a potential inflation attack. Low findings covered createMarket() validation, liquidate() bad-debt handling, chain-fork replay risk and reallocate() denial-of-service risk.

Fix status: Medium and two Low findings marked Fixed; two Low findings marked Confirmed. Recommendations/notes were generally marked Confirmed or left without a remediation status. Covers deployed code: Not verifiable as of September 5, 2026.

BlockSec explicitly limits conclusions to the reviewed code version; no bytecode/commit match to deployed BSC or Ethereum addresses was established.

Security Audit Report for Lista's Lista Lending. Target: Lista Lending smart contracts (src/ folder of Lista repo, excluding mocks). Report referenced in Lista docs as “Blocksec-ListaLending-AuditReport-20250410.pdf”.

Separate audit of “LISTA Lending Provider” referenced in Lista docs as “Blocksec-ListaLending-Provider-20250522.pdf”. No detailed findings in snippet.

Managed review of Credit Loan. A secondary overview states the review ran 2026-01-15 to 2026-01-29 and found 0 critical, 2 high, 3 medium, 12 low, and 11 info issues, with the listed high/medium items described as fixed or mitigated by compensating controls in the overview. The excerpt does not include the underlying report or any explicit bytecode-match/deployed-code coverage statement, so deployed-code coverage is not verifiable as of 2026-08-29.

Cantina engagement focused on PancakeSwap LP token integration within the CDP module for Lista DAO, validating LP collateral accounting, oracle pricing, staking mechanisms, and liquidation routines. This is adjacent to, but not identical with, the core Lista Lending contracts.

Newly verified published-report listing: BailSec review of Smart Collateral and Liquidators Extension.

Bytecode–match / deployed-code coverage for Lista Lending contracts on BSC and Ethereum cannot be independently verified without Dune or direct on-chain diffing; available audit reports do not include explicit bytecode-hash matching to currently deployed addresses.

Audit of Smart Collateral for Lista Lending. The docs index lists this report dated 2025-10-20, but the provided excerpt does not include findings counts, severities, remediation status, or bytecode-match/deployed-code coverage. Not verifiable as of 2026-08-29.

PeckShield published an audit for OpenLeverage/Lista Lending smart contracts, focusing on lending, margin trading, liquidation, and configuration management on BSC and Ethereum.

According to SlowMist’s official audit PDF for Lista Lending (formerly OpenLeverage), the audit covers core lending and margin trading contracts on BNB Chain and Ethereum, with focus on trading pair creation, lending pools, liquidation, and reward mechanisms.

Lista Lending is part of Lista DAO, a BNB Chain–native DeFi protocol with a relatively well‑identified, non‑anon founding and operating team, closely linked to Binance’s ecosystem. ### Founders & Leadership

• Founders: Binance’s LISTA project page states that Lista DAO was founded by Terry Huang and Toru.
• COO: A Binance Square interview identifies Terry as *Chief Operating Officer* of Lista DAO.
• BD Lead: The same interview names Lorena as *Business Development Lead*, previously a BD Manager at Binance.
• Team size & background: Terry describes a team of ~20 developers, “most of whom have experience in centralized exchanges and blockchain innovation,” explicitly mentioning prior roles at Binance. ### Public vs. Anonymous; Prior Track Record
• Key leaders (Terry, Toru, Lorena) are publicly identified by name and prior roles, not presented as anonymous personas.
• Prior experience is largely centralized exchange / Binance operations and BD, not a long public history of running independent DeFi protocols.
• No credible sources in the retrieved data report past protocol hacks or major failures attributable to these founders. Not verifiable as of 2026‑09‑04. ### Corporate / Funding Reality Check
• Lista’s docs state the protocol is “backed up by Binance Lab (now YZi Labs), with a strategic investment of 10M USD”. This is an unverified marketing claim until independently confirmed, but it is echoed by Binance‑hosted materials that highlight deep integration with Binance’s Launchpool, Megadrop, and HODLer programs.
• Binance price/listing pages confirm LISTA as the governance token of Lista DAO and indicate that Lista DAO operates on BNB Chain, aligning with the protocol narrative.
• Whether Lista is run through a specific legal entity, jurisdiction (onshore vs offshore), or physical office location is not disclosed in the retrieved sources. *Not verifiable as of 2026‑09‑04*. ### Real Business vs. Pure Web Front
• Lista Lending is described as a live lending product on BNB Chain with audited smart contracts (BlockSec and BailSec) referenced in the official docs and GitHub audit links.
• Multiple independent venues (Binance listing/interview, CoinMarketCap explainer, The Block press release) treat Lista DAO as an active DeFi protocol integrated into the broader BNB ecosystem.
• Combined, these suggest a real operating DeFi business, not merely a thin web front, though the exact corporate structure and physical presence remain opaque. Not verifiable as of 2026‑09‑04. ### Name / Chain Check
• All retrieved sources clearly tie Lista Lending / Lista DAO to BNB Chain and LISTA/LIS token, and there is no conflicting namesake protocol on Ethereum in the surfaced data.

Lista Lending’s reputation appears generally positive but still partly reliant on project-published claims. Public materials identify the team behind Lista DAO as Toru Watanabe and Terry Huang, and multiple sources describe Binance Labs (now YZi Labs) as a strategic investor in a $10M round. Independent coverage also notes that Lista Lending expanded to Ethereum and added curator relationships with Gauntlet and RockawayX.

On security, the protocol claims repeated audits by firms including PeckShield, Veridise, SlowMist, BlockSec, Supremacy, and BailSec; BailSec also hosts audit reports and attributes comments to co-founder Terry. The project also advertises an active bug bounty / responsible disclosure program. I did not find credible web evidence, in the gathered sources, of fraud, rug-pull, insolvency, sanctions, or formal regulatory action specific to Lista Lending.

That said, absence of evidence is not evidence of absence; these items are Not verifiable as of 2026-09-04. Main unresolved concerns are therefore operational rather than scandal-related: much of the positive reputation evidence comes from protocol documentation and PR, so it should be treated as partially self-reported until independently corroborated. One source also says there are no institutional or angel investors in "Lista," which conflicts with Binance Labs/YZi Labs being described elsewhere as a strategic investor; this contradiction should be treated as unresolved.

Strategy / assets in-out. Lista Lending is a collateralized, variable-rate lending market and vault system. Suppliers deposit supported assets such as BNB, slisBNB, lisUSD, ETH-related assets and other listed tokens; borrowers post collateral and receive a loan asset, repaying principal plus floating interest. Collateral can be liquidated when LTV breaches the market’s LLTV. Yield source / sustainability. Base lender yield is borrower interest driven by utilization and an AdaptiveCurveIRM.

Some vaults may allocate liquidity externally—for example, documentation gives allocations to pt-clisBNB/lisUSD and Venus—creating external protocol, oracle, and strategy risk. Lista rewards may also be displayed/claimable, so headline APY can be partly subsidized; the organic share is not quantifiable from available evidence. APY history and volatility: Not verifiable as of September 6, 2026. Risk posture. The lending leg is economically market-neutral to suppliers only if asset prices and liquidity are ignored; borrowers and collateral holders retain directional crypto exposure.

Strategies involving slisBNB or other yield-bearing collateral add staking/LST exposure. Looping is technically possible, but no verified protocol-wide leverage ratio is available. Restaking exposure is not established for Lista Lending specifically.

External exposure exists in permissionless/curated vaults and must be assessed vault-by-vault. Withdrawals, gates and fees. Suppliers may withdraw when vault liquidity is available; withdrawals can be restricted by liquidity. Borrowers must repay before recovering collateral. Documented parameters include a 0–25% protocol fee on borrow interest and optional curator fees up to 50% of vault profits; defaults may be 0%.

Vaults can have caps, guardians and timelocks, but a universal user lock-up is not established. Revenue / collateral. Revenue sources include borrow-interest fees and liquidation fees; exact realized revenue is not independently verified here. Collateral includes crypto assets such as BNB, ETH, slisBNB and wBETH for lisUSD-related borrowing. TVL / trend contradiction. Dune on-chain TVL, product split, chain split, and trend comparison: Not verifiable as of September 6, 2026. DeFiLlama’s BSC page reports $1.326B for the broader Lista DAO across two chains, but this is not Lista Lending-only TVL and must not be substituted for product TVL.

Lending-specific Ethereum deployment is also not independently confirmed. Assessment: lending interest is the core organic source; incentives and external vault allocations make reported APY potentially mixed and strategy-dependent.

Assessment (as of September 6, 2026):

• Liquid reserves / treasury size: Not verifiable as of 2026-09-06. No independent reserve statement, treasury balance sheet, or reliable on-chain balance reconciliation was found. Dune on-chain verification is unavailable in this run; therefore no Dune query ID/execution ID is provided.
• Known reserve address: Lista’s documentation identifies a BNB Chain “Lista DAO Risk Fund” at 0x618579671f4B5a96Ff6Ac3Fb66224df39Ce9d325. The stated policy allocates 50% of management-fee revenue from Lista-created/self-operated lending vaults to the fund; third-party vaults are excluded. The documentation states assets are held in multisignature wallets managed by the Lista DAO Foundation, with the core team administering deployment. These custody/control statements are unverified protocol claims absent independent wallet-control or balance verification.
• Composition: Not verifiable as of 2026-09-06. No reliable token-by-token composition or USD valuation for the Risk Fund was found. Ethereum treasury/reserve addresses were not identified.
• Reserve policy: The stated use is compensation for verified exploits, bad debt, liquidation losses, and black-swan events affecting Lista’s self-operated vaults; it excludes market volatility, user error, and external-protocol risk.
• Liabilities: Not verifiable as of 2026-09-06. DeFiLlama reports approximately $95.82m in active loans, but this is an analytics-platform estimate of protocol borrowing exposure, not a verified liability ledger or reserve shortfall.
• Attestations: Not verifiable as of 2026-09-06. BlockSec and BailSec audit references concern smart-contract security, not proof-of-reserves or reserve attestations. > Contradiction / change: The prior check recorded DeFiLlama TVL of $625.39m (September 4, 2026). The current page shows $885.85m—$875.57m BSC and $10.28m Ethereum—with BSC representing 98.8%. This is TVL, not treasury or reserves, so it must not be used as a reserve estimate. Bottom line: A reserve mechanism and one BSC Risk Fund address are publicly documented, but reserve size, balances, composition, Ethereum coverage, liabilities, and independent attestations remain unverified.

Lista Lending does have a native token: LISTA. ### 1. Token identity

• Name / ticker: Lista (LISTA)
• Chains: BNB Chain (BSC), Ethereum.
• Contract addresses:
• BSC: Not verifiable as of 2026-09-04.
• Ethereum: Not verifiable as of 2026-09-04. ### 2. Supply, market cap, FDV Public aggregators list LISTA with a fixed max supply and circulating supply, but without on-chain confirmation this is not verifiable as of 2026-09-04 for exact values.
• Total / max supply: Not verifiable as of 2026-09-04.
• Circulating supply: Not verifiable as of 2026-09-04.
• Market cap / FDV: Analytics platforms (e.g., market trackers) show non-zero market cap and FDV, but precise figures are stale data or unverifiable as of 2026-09-04. ### 3. Utility and governance From protocol-facing documentation and listings (treated as *unverified marketing claims*):
• Utility:
• Governance voting over protocol parameters (e.g., collateral settings, interest-rate parameters, risk frameworks).
• Incentives for supplying/borrowing within Lista Lending.
• Potential use in staking or “points / rewards” style programs around the lending protocol.
• Governance role: LISTA is positioned as the governance token for the broader Lista ecosystem, including lending, liquid staking, and related products.
• All of the above are unverified marketing claims as of 2026-09-04. ### 4. Revenue share / burns / staking
• Claims of fee distribution, buybacks, or burns to LISTA holders appear in ecosystem descriptions but lack independent confirmation; not verifiable as of 2026-09-04.
• Any staking APY, lockups, or reward schedules for LISTA itself are not verifiable as of 2026-09-04. ### 5. Emissions, unlocks, allocations
• Emissions schedule & unlock timetable: Only partially described in marketing materials; no independent confirmation that announced unlocks executed on-chain; not verifiable as of 2026-09-04.
• Allocations (team / investors / treasury / community): Token distribution charts exist in ecosystem presentations, but without contract-level confirmation they remain unverified marketing claims. ### 6. Concentration, controls, liquidity
• Top-holder concentration / insider wallets: Not verifiable as of 2026-09-04.
• Admin functions (mint, blacklist, fee-switch) & controllers: Not verifiable as of 2026-09-04.
• DEX liquidity & listings: LISTA is referenced on major BSC/Ethereum DEXs and some CEX listings, but depth and venue breakdown are not verifiable as of 2026-09-04. Overall: almost all LISTA tokenomics details depend on protocol/aggregator disclosures and lack on-chain or independent verification as of 2026-09-04.

Lista Lending is a lending protocol on BNB Chain, and its docs state that BTCB can be used as collateral and that positions are liquidated when collateral value falls below the market’s LLTV/MCR threshold. In a stress scenario where BTC falls below $10,000, BTC-linked collateral such as BTCB would lose value proportionally, pushing borrowers closer to liquidation or into liquidation if their loan health drops below threshold. The docs also state that when the smart contract cannot complete liquidation, the position is moved to the Liquidation Zone for purchase.

For BSC-specific BTC exposure, the listed collateral markets include BTCB in the lending interface, with LLTVs in the 70% to 90% range depending on market, and one Lista post says BTCB collateral for borrowing WBNB had a current borrowing rate and up to $100M caps. That means a BTC crash below $10,000 would primarily stress BTCB-backed borrows on BNB Chain; exact liquidation counts, bad debt, and TVL impact are not verifiable as of 2026-09-04 without on-chain data. For Ethereum, the provided sources do not establish an active Ethereum deployment for Lista Lending, so any Ethereum-chain BTC-stress estimate is not verifiable as of 2026-09-04.

For Lista Lending on BSC and Ethereum, a 20% depeg of the largest collateral would likely trigger liquidations on positions whose health factor falls below the protocol’s liquidation threshold; however, the actual loss amount is not verifiable as of 2026-09-04 because no on-chain position data or collateral inventory is available in this run. DeFi lending protocols generally liquidate when collateral value drops below the liquidation threshold, and systemic risk can propagate through cascade liquidations and liquidity crunches. For context, Lista’s own risk commentary notes that lisUSD has experienced a near-20% depeg historically, but that is a market note rather than a protocol exposure calculation.

If the “largest collateral” is a volatile asset with an LT in the common DeFi range, even a 20% price shock can materially raise liquidation pressure, but the exact impact depends on each chain’s open debt, collateral mix, and liquidation parameters, which are not verifiable as of 2026-09-04. Because on-chain checks are unavailable here, the prudent stress-test output is:

• Expected effect: higher liquidation volume and potential bad debt if liquidations cannot clear fast enough.
• Chain split: Not verifiable as of 2026-09-04 for BSC vs. Ethereum exposure.[Not verifiable as of 2026-09-04]
• Loss estimate: Not verifiable as of 2026-09-04.[Not verifiable as of 2026-09-04]

For Lista Lending, a top-counterparty insolvency mainly propagates through the liquidation path, not through a lender-specific credit waterfall. If a borrower becomes undercollateralized, the protocol’s contracts trigger liquidation: a liquidator repays some or all debt, receives collateral plus a liquidation incentive, and the position is closed; if the protocol cannot complete liquidation, the position can move into the Liquidation Zone for community purchase at a discount. Expected loss path:

• Normal case: losses are absorbed by the borrower’s collateral first, via liquidation at discount/bonus mechanics.
• If liquidation is incomplete: the position may enter the Liquidation Zone, where community buyers take over discounted collateral, reducing residual loss risk.
• If a verified exploit or black-swan event creates user losses or bad debt: the Lista Lending Risk Fund is intended to compensate affected users, including liquidation losses and bad debt. Who absorbs it:
• Primary absorber: borrower collateral.
• Secondary absorber: liquidators/community buyers who earn the incentive/discount by taking the position.
• Backstop absorber: Lista DAO Risk Fund, but only for verified exploit/black-swan losses per the docs. Compensation:
• Liquidators are compensated with collateral plus a gas compensation / liquidation incentive for executing liquidation.
• If the Risk Fund is used, affected users are repaid from that reserve. Impact path through smart contracts:
• Price/oracle check → LTV exceeds LLTV → liquidation callable by external parties → debt repayment and collateral transfer via contract → if the contract cannot fully clear the debt, the remaining position is listed for discounted takeover in the Liquidation Zone. For BSC vs Ethereum, the docs confirm both chains exist, but the web evidence gathered here does not provide chain-by-chain loss-share or insolvency exposure numbers. Not verifiable as of 2026-09-04.

For the stress scenario of committed fraud by the DAO or owners, I found no verifiable evidence that Lista Lending’s DAO or owners committed fraud. The available material instead shows a protocol that is audited, has a public bug bounty, and has documented security incidents/pauses rather than proof of owner- or DAO-level fraud. What *is* verifiable is that the Lista brand has been impersonated by a fraudulent scam site (vote-lista[.]com) designed to drain wallets; that is an external phishing/scam issue, not evidence that the protocol DAO or owners themselves committed fraud.

There are also reports of a USR-related incident and a temporary pause tied to unusual collateral price action, but the cited reports describe mitigation and repayment, not fraudulent conduct by the DAO or owners. Given the evidence available, the appropriate stress-case classification is: Not verifiable as of 2026-09-04 for committed fraud by the DAO or owners.

For Lista Lending, a “stress scenario” with primary yield source negative over the last 30 days is not verifiable as of 2026-09-04 from the provided sources. The search results contain general banking stress-test methodology and one Lista Docs roadmap item, but they do not provide on-chain or independent evidence for Lista Lending’s 30-day yield-source performance on BSC or Ethereum. The available sources also do not establish which yield stream should be treated as the protocol’s *primary yield source* for Lista Lending, nor do they provide chain-separated exposure or TVL by source.

Because Dune/on-chain verification is unavailable in this run, any numerical claim about a negative 30-day primary yield would be an unverified marketing claim or an unsupported inference. What can be said from the results is only that stress-testing frameworks generally define adverse scenarios as significantly negative conditions, but those references are about traditional financial institutions rather than this DeFi protocol.

As of September 13, 2026, Lista Lending is a core-team-controlled DAO hybrid, not a fully autonomous DAO. Governance/process. veLISTA voting is proportional to veLISTA balance; voting lasts 3 days and requires >50% of votes cast. Only the Lista DAO Core Team can submit formal proposals; community proposals are advisory. Passed proposals are implemented by the Lista DAO team within 1–2 weeks.

The Core Team retains veto/corrective powers, including pausing contracts, rejecting unsafe gauges, and adjusting borrow rates without a Snapshot vote. This makes governance real for signaling and parameter approval, but not sovereign over execution or emergency action. Contracts and funds. The published deployment lists a BSC Lending TimeLock and Ethereum Manager/Admin TimeLocks. Vault managers/curators must use timelock contracts, but vaults are upgradeable and curators control economic parameters, allocations, caps and fees.

Documentation says curators cannot withdraw, seize or redirect user funds; protocol-level emergency measures require a Lista governance multisig. Frontend/company. The Terms describe a non-custodial interface whose maintainers do not control underlying protocols, governed by Seychelles law, and prohibit U.S. persons from access. No legal entity name, registration number, directors, or verified corporate operator was identified. Therefore company identity and frontend-control attribution are Not verifiable as of September 13, 2026. Concentration/multisig. Dune/on-chain verification was unavailable in this run.

Voting concentration, top holders, timelock delay, multisig threshold, signer identities, signer independence, and current admin role assignments are Not verifiable as of September 13, 2026. An older 2024 audit documented privileged withdrawal/admin powers in legacy Lista contracts and recommended multisig plus timelock; it does not establish the current Lista Lending deployment’s permissions. Assessment: DAO governance is symbolic-to-partial rather than fully controlling; core-team veto, proposal gatekeeping and execution discretion are material centralization risks.

Assessment (as of September 4, 2026; on-chain checks unavailable):

• Entity / jurisdiction: The product identifies itself as Lista DAO, a decentralized autonomous organization, not a named corporation. Its Terms of Use select Republic of Seychelles law and deem the interface based in Seychelles. No incorporated entity name, registration number, registered address, or liability-limiting foundation/company was identified. Entity: Lista DAO (formal legal entity not disclosed). Jurisdiction: Seychelles (contractual choice of law/interface situs, not verified incorporation).
• Terms / restrictions: The interface excludes U.S. persons and U.S.-organized entities, prohibits VPN circumvention, and restricts sanctioned persons/territories. Disputes are stated to proceed to binding arbitration, although the arbitration body is left as a placeholder in the published text.
• KYC/AML: The Terms say the interface may temporarily collect personally identifiable information for operational/compliance purposes and for detecting prohibited use. The token disclaimer says identity documents may be requested for distribution eligibility. However, no comprehensive protocol-level KYC/AML program, VASP registration, customer due-diligence framework, or transaction-monitoring policy was identified. Not verifiable as of September 4, 2026.
• Classification / regulatory posture: Lista characterizes the interface as non-custodial, informational infrastructure and states it is not regulated or supervised. It separately describes Lista Lending as permissionless lending and third-party curators as independent operators. These are contractual/marketing positions, not regulatory determinations. The token disclaimer expressly states no regulator has examined or approved the materials.
• Warnings / enforcement / cases / sanctions: No regulator enforcement action, court case, or sanctions designation against Lista DAO or an identified Lista entity was found in the reviewed sources. This is not evidence of clearance; the absence of a disclosed legal entity complicates attribution and service of process. Privacy risk: the Terms disclaim confidentiality except where legally required, creating material data-protection uncertainty.
• Legal structure vs. actual risk: “DAO,” non-custodial, and Seychelles-law language may reduce contractual clarity but do not eliminate potential liability for identifiable contributors, interface operators, curators, or governance participants. Lending, stablecoin, tokenized-RWA, and credit products create jurisdiction-specific licensing, consumer-protection, securities/commodities, AML, and insolvency risks. Structured fields: active_enforcement: false (no identified action); sanctioned: false (no identified designation); entity: “Lista DAO; formal entity not disclosed”; jurisdiction: “Seychelles (Terms of Use governing law/interface situs; incorporation not verified).”

No exact GLEIF LEI record for 'Lista DAO', 'Lista Lending'. OFAC SDN screening of 'Lista DAO', 'Lista Lending': no match. SEC litigation and administrative release feeds: no mention.

Lista Lending uses its own stablecoin, lisUSD, so own_stablecoin = true and stable = true based on issuer/docs descriptions. However, the exact depeg count, last depeg date, and max depeg percentage are not fully verifiable in this run, so those fields should remain null if strict verification is required. The web evidence gathered does indicate lisUSD has depegged multiple times, including a reported near-20% depeg on 2022-12-03, smaller ~3% depegs on 2023-12-20 and 2024-04-12, and a more recent depeg on 2025-03-16 to 0.9762 (about 2.38% below peg).

Because these reports come from secondary sources rather than on-chain verification, the safest structured output is: own_stablecoin=true, stable=true, depeg_count=null, max_depeg_pct=null, last_depeg_date=null, stablecoin_ids=["lisUSD"].

Lista Lending’s primary risks are market- and curator-specific rather than a single protocol-wide pool risk: markets and vaults are permissionless, while curators control key economic parameters. The protocol lists multiple audits, oracle fallbacks, timelocks and an Immunefi bounty, but these controls do not eliminate implementation, oracle, liquidation or governance risk. On-chain exposure, TVL, bad debt and BSC-versus-Ethereum allocation: Not verifiable as of September 5, 2026.

Lista Lending’s top strengths are: capital efficiency, via its vault-and-market/P2P design that aims to maximize utilization and lower borrowing costs; permissionless flexibility, because users can create specialized markets with customized parameters and broader token support; risk control, through granular collateral/liquidation settings and risk isolation between markets; pricing reliability, with a multi-oracle design intended to reduce manipulation and liquidation errors; and security/upgradeability, supported by audited smart contracts, reentrancy protection, and upgradeable contracts that let the protocol evolve over time. A few additional strengths stand out for institutional users: Lista is designed to support advanced strategies and integrations, including liquid-staking loops and fixed-term or fixed-rate lending flows, which can broaden use cases beyond standard borrow/lend activity. The protocol also emphasizes ecosystem fit on BNB Chain, where low gas costs can make small and frequent operations more economical than on higher-fee networks.