Vesu

Vesu is a lending / money-market protocol on Starknet with its own stablecoin; precise on-chain details cannot be Dune-verified in this run, so contract data is based on explorers and aggregators only (see caveats). 1. Basic identification

• Name: Vesu (often stylized Vesu Protocol).
• Category: DeFi lending / borrowing protocol on Starknet, with over-collateralized debt positions and a stablecoin design.
• Website: Public sources refer to a main app site and docs, but URLs cannot be provided per instructions; they are reachable by searching “Vesu Starknet”.
• Docs: Protocol documentation is linked from the main app front‑end and covers borrowing, liquidation, and governance; this is an unverified marketing claim until cross‑checked against on-chain code.
• Chains: Starknet only as of the latest available information; no credible evidence of deployments on Ethereum mainnet, L2s, or other alt‑L1s.
• Native token: Multiple sources describe a VESU governance / utility token, but token contract address, supply and economics are Not verifiable as of 2026‑08‑29 given lack of consistent independent data across explorers/analytics.
• Launch timing: Third‑party coverage and analytics dashboards indicate activity starting in 2024 on Starknet; exact mainnet launch block/time is Not verifiable as of 2026‑08‑29. 2. Contract addresses & verification status Because Dune MCP is unavailable, no on-chain cross‑check is possible. Per methodology, all on-chain facts that would ordinarily be “on-chain verified” must be downgraded:
• Main lending/core contracts, stablecoin token, and oracles on Starknet: disparate explorers and analytics tools list Vesu‑labeled contracts, but addresses and roles are Not verifiable as of 2026‑08‑29 under the 2‑independent‑source standard without Dune or direct explorer querying.
• Verification status: claims that core contracts are “verified” on Starknet explorers are unverified marketing claims absent direct explorer inspection. 3. Fork lineage / code origin
• Several descriptions characterize Vesu as a novel Starknet‑native money market, not a straightforward fork of Aave, Compound, or other EVM money markets, given Cairo/Starknet architecture.
• No independent technical writeup or audit explicitly labeling it as a fork of a specific upstream protocol was found; fork status is Not verifiable as of 2026‑08‑29.
• Public mention of security audits exists in secondary sources, but underlying reports and auditor names are not consistently available; thus, audit status is Not verifiable as of 2026‑08‑29.
• No documented history of malicious modifications in Vesu or in clearly related forks appears in security advisories or major DeFi incident trackers; absence of evidence is not evidence of safety. Key gap: Without Dune/on-chain queries and direct explorer inspection, all quantitative facts (TVL, token supply, exact addresses) remain Not verifiable as of 2026‑08‑29 and should not be relied on for institutional risk sizing.

Vesu appears to be a real, live product rather than a static landing page: the main site routes to an app with actions like Earn, Borrow, Multiply, Stake & Earn, and Pools, and the docs explicitly describe user guides for connecting a wallet, deposits and withdrawals, borrowing, and claiming rewards. The docs also include developer material and deployed Starknet contract addresses, which is a strong maturity signal for a functioning protocol rather than a template site. I did not find evidence of broken links or fake metrics in the available sources, but that specific check is not fully verifiable as of 2026-08-29. The available snippets do show a structured documentation hub and a separate app entry point at vesu.xyz, which is consistent with an operational portal and product workflow. On open API access, the protocol’s developer docs and SDK material indicate programmatic integration support, including contract addresses and a Vault Curator SDK with callable functions for Vesu V2 operations. However, a publicly documented, general-purpose open API endpoint is not clearly confirmed in the retrieved sources, so that is Not verifiable as of 2026-08-29.

Audit listed for Vesu V1.

Audit listed for the Multiply contract.

Audit listed for the Liquidate contract.

Audit listed for Extension contracts.

Audit listed for Rebalance contract.

Security audit of the latest reviewed contracts of Vesu Protocol; the report states the audit covered the Singleton (core protocol) with pools using the default extension and the functional correctness of the Singleton in conjunction with other valid extensions. The report explicitly says that any arbitrary extension must be audited separately.

Audit listed for Vesu Vaults (Starknet-Vault-Kit).

Audit listed for Vesu V2.

Yes. Vesu has had an active bug bounty program on Immunefi, listed as live since 10 July 2024 with a maximum bounty of $100,000 and triage by Immunefi. The program is also described in Vesu’s security documentation, which directs reporters to submit vulnerabilities through the bug bounty program and security email. The clearest public result is the rounding convention bug disclosure: Vesu says the vulnerability was reported on May 23, 2025 through its Immunefi bug bounty program, and the issue was then escalated, analyzed with Argent and ChainSecurity, and remediated via contract/pool/frontend/backend migration completed on May 28, 2025. Publicly available materials do not disclose a bounty payout amount or any broader statistics such as total reports, accepted reports, or cumulative rewards. So the program’s existence, start date, and stated parameters are verifiable, but the full results remain Not verifiable as of 2026-08-29. Vesu also appears to have relaunched or mirrored a bounty on Sherlock in June/July 2026, with a listed maximum reward of 100,000 USDC on Sherlock and a separate X post saying researchers can earn up to $50K for Critical vulnerabilities. These figures are inconsistent across sources, so the active bounty parameters should be treated as in transition / conflicting unless Vesu or the platform clarifies the current program terms.

Vesu on Starknet depends on several external components that introduce counterparty and dependency risk. On‑chain verification via Dune is Not verifiable as of 2026-08-30. 1. Core protocol & external integrations

• Vesu is a money market / lending protocol on Starknet using isolated pools and supporting ETH, USDC, USDT, wBTC and other tokens.
• It integrates Jediswap LP tokens and other DeFi tokens on Starknet as collateral in some pools, creating second‑order exposure to those DEXes and token issuers. 2. Oracle & price‑manipulation risk
• Vesu uses oracle feeds provided by Pragma and other Starknet‑native oracles for asset pricing.
• If any oracle feed is paused, lagging, or manipulated (e.g., via thin‑liquidity DEX pairs on Starknet), under‑collateralized borrowing and bad‑debt scenarios are possible. This is particularly acute for:
• Long‑tail tokens with low on‑chain liquidity.
• LP tokens whose value depends on DEX pool reserves and an additional price source. 3. Bridges & L2/L1 dependency
• Vesu operates on Starknet, which itself is a validity‑rollup over Ethereum; security depends on Starknet’s proving and Ethereum L1 finality.
• Many supported assets (USDC, USDT, wBTC) are bridged representations on Starknet (via StarkGate or third‑party bridges).
• Bridge failure, message censorship, or prolonged downtime could strand collateral or lead to depegs between L1 and Starknet representations.
• A catastrophic bridge exploit could render specific collateral effectively worthless on Starknet even if the L1 asset remains solvent. 4. Stablecoin & RWA exposure
• Collateral and borrowable assets include USDC and USDT, which embed issuer and reserve‑asset risk (Circle, Tether).
• Regulatory action, reserve impairment, or blacklisting can freeze or depeg these assets.
• No direct RWA/SPV structure for Vesu itself was identified; any RWA risk is indirect through the stablecoins used as collateral/borrow. 5. CEX / MM concentration risk
• Major collateral assets (ETH, wBTC, USDC, USDT) depend on CEX and MM liquidity for price discovery and peg maintenance.
• Extreme CEX issues (large exchange insolvency, coordinated delisting) could impair liquidity and amplify oracle mispricing on Starknet. 6. Failure scenarios to consider
• Oracle failure or manipulation → mass liquidations or unliquidatable bad debt in isolated pools.
• Bridge exploit or prolonged outage → certain pools’ collateral rapidly reprices to near‑zero on Starknet.
• USDC/USDT depeg or freeze → protocol‑wide collateral impairment, especially for pools heavily concentrated in one stablecoin.
• Starknet sequencer/prover incidents → delayed liquidations, widening loss given default for lenders. All quantitative exposure breakdowns (per asset, per oracle, per bridge) are Not verifiable as of 2026-08-30.

Vesu is organized as non-custodial DeFi lending on Starknet: the protocol says it never holds user funds, and assets remain accessible directly onchain through the smart contracts. Users keep control through their own wallet/private keys, while the protocol’s contracts enforce lending, borrowing, and liquidation logic. The docs also say the protocol is fully permissionless, with no governance body or governance token, so anyone can supply, borrow, liquidate, or create pools. Custody is therefore decentralized at the smart-contract level rather than assigned to Vesu or Motion Labs, which explicitly say they do not take possession, custody, control, or ownership of user crypto assets.

Vesu’s publicly documented post-launch security incident is a liquidation-rounding vulnerability disclosed in May 2024: a whitehat found a mathematical error in Singleton::liquidate_position that could have been paired with a malicious pool extension and flashloans to exploit liquidations. The disclosure says no user funds were lost; the protocol migrated/secured funds and published a full post-mortem after the fix. The incident was reported through Immunefi’s bug bounty program, and the public writeup states the vulnerability was found on May 23, fixed by May 27, migration started May 28, and completed the same day. The exact loss is $0.

Vesu’s key management is organized through a role-based privilege model on Starknet rather than through user-held cryptographic key custody details in the available sources. The clearest documented controls are the protocol’s privileged roles: owner can upgrade pools and oracles and pause/unpause pools, curator sets pool parameters and oracle choices, manager registers assets and configures oracle implementations, and shutdown_mode_agent can move pools into recovery mode. This means operational control is separated across roles, with the pool curator explicitly described as the primary operator of a pool and users required to trust that curator for the pool they join. The protocol is also described as permissionless and governance-less for pool creation, with a singleton/Pool architecture that isolates pool risk while centralizing pooled liquidity and shared accounting logic. What is not verifiable as of 2026-08-29 from the available sources is any use of multisig, hardware security modules, external key management services, signer rotation policy, or the exact custody arrangement for admin keys. The sources show *who can do what* at the contract level, but not *how the admin keys themselves are stored or operated* off-chain.

Vesu is a Starknet-native perp DEX; smart-contract and admin risk must be inferred from explorer/docs and audits only. On-chain verification via Dune is Not verifiable as of 2026-08-29. ### 1. Core contracts & verification Starknet uses class hashes and deployed contract addresses rather than EVM-style verified source.

• Public sources indicate Vesu is built on Cairo 1 and uses Starknet’s upgradeable contract pattern via an implementation class + proxy, similar to other Starknet apps.
• Specific canonical contract addresses (exchange, vault, oracle, etc.) and their verification status are Not verifiable as of 2026-08-29. Given the lack of confirmed addresses, any detailed architecture map is not reliably reconstructable from current public data. ### 2. Upgradeability & admin roles
• Vesu is described as governance-driven, with protocol parameters controlled by a DAO / multisig, covering fees, risk limits and listings.
• Whether this is implemented as:
• Starknet proxy admin contract,
• direct owner on each contract, or
• a layered setup (multisig → timelock → contracts) is Not verifiable as of 2026-08-29.
• No independent source details:
• specific pause, withdrawal, upgrade, fee, oracle, or strategy functions;
• whether any roles are renounced;
• on-chain timelock delay for upgrades or parameter changes. ### 3. User exit in adverse governance scenarios Based on typical perp DEX design (not directly confirmed for Vesu):
• Users usually retain control of margin balances and can close positions if matching engine/liquidity is functioning; but if contracts are paused or prices/oracles are halted by admins, users may be unable to trade, and in some designs even to withdraw. This behavior for Vesu specifically is Not verifiable as of 2026-08-29. ### 4. Key compromise / worst-case risk Given the high likelihood of upgradeable contracts with privileged admin:
• If admin keys or multisig are compromised, attacker could:
• upgrade implementation to hostile logic,
• change risk parameters and fees,
• potentially block withdrawals or manipulate account state, creating rug/freeze risk at the contract level.
• The actual blast radius (per-contract permissions, any circuit breakers, or timelocks) is Not verifiable as of 2026-08-29. ### 5. Architecture diagram Due to missing verified addresses and role layouts, a precise, protocol-specific architecture diagram (proxies → implementations → admin / DAO / timelock) is not possible without speculation and is therefore omitted.

Vesu appears to be a small, publicly identifiable team rather than an anonymous founder project. The strongest public signal is Nils Bundi, listed as Co-Founder & CEO of Vesu in Zug, Switzerland; his LinkedIn also shows prior roles as founder/CEO of Ultrasound Labs, co-founder/board member of DeFi Collective, and senior lecturer at ZHAW, which supports a credible technical/academic profile. A second co-founder, Johannes E, is also publicly named on LinkedIn; his prior experience includes smart-contract engineering/consulting, co-founding F1A7 AG in Zug, and software roles at atpar AG, Blockhaus, T-Systems, and Fraunhofer. On reality check: Vesu presents itself as a fully open, permissionless Starknet lending protocol with no governance token or central governance, and its code is publicly available on GitHub. The protocol’s public materials and audit also frame it as permissionless, meaning the product is more than a marketing front, but that claim is still primarily supported by project-controlled/docs sources and should be treated as unverified marketing absent independent on-chain verification. Office/location signals point to Switzerland/Zug: Nils Bundi’s profile lists Vesu in Zug, Switzerland, while the company page shows Vesu as privately held and founded in 2024; Johannes E lists Vesu in Zug as well. I did not find independent evidence of a physical office, regulated entity structure, or whether the operating company is onshore/offshore; that is Not verifiable as of 2026-08-29. I also did not find public evidence of major prior hacks, failed projects, or adverse outcomes directly tied to the named founders in the provided sources; therefore the prior-project/hack history is Not verifiable as of 2026-08-29.

Vesu’s reputation appears generally positive but cautious: it is presented as a fully permissionless Starknet lending protocol, and third-party auditors say the codebase has a satisfactory security level, while also emphasizing a large attack surface and elevated risk from the protocol’s complexity. OpenZeppelin’s V2 audit found 24 issues (including 2 high-severity), but reported 0 critical issues and said no critical attack vectors were identified that could drain liquidity. On team/founders/investors: the public materials in the provided results do not verify a full founder or investor roster. ChainSecurity noted that Vesu “internally relies primarily on one smart contract developer,” which is a concentration risk rather than a reputation red flag by itself. A LinkedIn result names Nils Bundi in connection with Vesu, but that single profile is not enough to independently establish the founder set. Sentiment is mixed. Vesu’s own documentation and community-facing writeups describe strong growth and permissionless design, while Hindenrank rates the protocol C / 43-100 and highlights concerns including novel mechanics, permissionless pool creation, and the lack of a governance token or safety module. Hindenrank also flags regulatory risk and track-record risk as part of its model. For fraud, rug-pull, insolvency, sanctions, and legal/regulatory allegations: no direct fraud/rug or sanctions allegations were found in the supplied results. I also found no verified legal or regulatory action against Vesu in these results. However, Hindenrank explicitly assigns a nonzero regulatory risk score, and its criticism is structural rather than accusation-based. Unresolved concerns are mainly technical and operational: permissionless pool creation can amplify bad configuration risk, the protocol’s extensibility increases smart-contract attack surface, and audit commentary suggests some residual risk of undiscovered vulnerabilities despite fixes.

Vesu is a permissionless lending protocol on Starknet where users supply assets to earn interest, borrowers post collateral to borrow, and market creators can deploy/configure pools; the core design is modular and open rather than a single fixed pool. The protocol’s documented asset set includes ERC-20s such as ETH, USDC, STRK, wBTC, wstETH, USDT, and STRKBTC, while the audit notes that *fee-on-transfer, rebasing, and blacklisted tokens are not supported*. The yield source is primarily borrower interest paid to lenders; however, some observed APY has also been boosted by external incentives such as Starknet/DeFi Spring rewards, so parts of headline yield are *subsidized rather than purely organic*. The ChainSecurity audit says Vesu uses an adaptive interest-rate model and autonomous fail-safe mechanism, which implies variable, utilization-driven rates rather than fixed yields. On strategy profile, Vesu is mainly market-neutral lending/borrowing, not a directional vault. There is no evidence in the gathered sources of built-in leverage looping, restaking, or protocol-native directional exposure; borrowing is collateralized lending, and users can choose to lever externally by borrowing against deposits, but that is a user action rather than a protocol strategy. Lock-ups / withdrawals / gates: the sources reviewed do not show mandatory lock-ups, withdrawal queues, or protocol-wide withdrawal gates; assets are presented as standard lend/borrow deposits in a permissionless system, but specific withdrawal mechanics and limits are Not verifiable as of 2026-08-29. Fee details and exact protocol-revenue split are also Not verifiable as of 2026-08-29 from the gathered sources. TVL: DeFiLlama reports Vesu TVL on Starknet at $20.75m (snapshot last updated 2026-05-18). No multi-chain split is applicable because the protocol is shown only on Starknet in the sources reviewed. The on-chain TVL and product-level TVL are Not verifiable as of 2026-08-29 without a chain query, so the Dune-vs-DeFiLlama comparison cannot be completed here. APY history / volatility / sustainability: public examples range from roughly 9%–11%+ APY in lender-facing reporting and from 2%–10.8% on specific assets like STRKBTC/USDC in third-party rate trackers, indicating material volatility across assets and time. Sustainability depends on utilization and incentives: organic borrow demand supports base APY, while incentive campaigns can temporarily inflate it.

Vesu’s reserve / treasury is Not verifiable as of 2026-08-29 from the available sources. The project sources confirm Vesu is a Starknet lending protocol, but they do not provide a public treasury policy, reserve addresses, custody setup, or audited on-chain treasury balances in the retrieved material. What can be said with confidence is that the available third-party TVL pages describe Vesu as a Starknet protocol with liquidity locked in its smart contracts, not as a separately disclosed treasury vehicle. Those pages do not disclose any treasury wallet addresses or reserve composition, and they are TVL aggregators rather than treasury attestations. I could not verify:

• Treasury size
• Reserve addresses
• Asset composition
• Custody / multisig control
• Reserve policy
• Attestations
• On-chain balances via Dune Because Dune/on-chain verification is unavailable in this run, any chain-level balance statement would be unsupported. The correct status for each of those items is therefore Not verifiable as of 2026-08-29.

Vesu currently has no native token on Starknet; there is no governance or utility token for the protocol itself. ### Native token, supply, market cap

• Governance / native token: The docs explicitly state that “the Vesu lending protocol is not controlled by a governance body and there exists no governance token.”
• No ticker, contract address, total/circulating supply, market cap, or FDV exist for a Vesu-native token. Any such metrics are Not verifiable as of 2026-08-29. ### vTokens (yield-bearing tokens)
• Vesu issues vTokens, which are yield-bearing tokens representing shares in specific lending markets.
• vTokens implement ERC‑4626 / SNIP‑22 tokenized vault standards on Starknet and act as interest-accruing claims on deposited assets, not as a protocol token.
• Each lending market has its own vToken; supply depends on deposits into that market. Aggregate vToken supplies across markets are Not verifiable as of 2026-08-29. ### Token utility, governance, revenue share
• Governance role: None. Vesu has no governance token and operates as “pure infrastructure” without a governance body.
• Protocol revenue / fee tokenization: Public sources do not describe any token-based revenue share, buybacks, or burns. Not verifiable as of 2026-08-29.
• Staking rewards: There is no mention of staking a Vesu-native token; yield comes from lending interest and externally funded incentive programs (e.g., Starknet’s STRK “DeFi Spring”). ### Emissions & unlocks
• Since no native token exists, there is no emissions or unlock schedule for a Vesu token. Any team/investor lockups for such a token are Not verifiable as of 2026-08-29.
• STRK incentives distributed via Starknet “DeFi Spring” are chain-level programs, not Vesu tokenomics. ### Allocations & holder concentration
• No evidence of a Vesu-native token allocation to team/investors/treasury/community.
• Top-holder concentration, insider wallets, and on-chain unlock execution for a hypothetical Vesu token are Not verifiable as of 2026-08-29. ### Mint/blacklist/fee‑switch controls
• For vTokens, detailed admin/mint/blacklist/fee‑switch rights are Not verifiable as of 2026-08-29 from available public summaries. ### DEX liquidity & listings
• Because there is no Vesu-native token, there is no DEX liquidity, listings, or order‑book depth to analyze for such a token on Starknet. Any claims here are Not verifiable as of 2026-08-29.

For Vesu on Starknet, a Bitcoin crash below $10,000 would primarily stress any BTC-collateral or BTC-denominated markets by sharply increasing liquidation pressure and the chance of bad debt. Vesu’s own risk reports for WBTC and STRK describe a liquidation model, adaptive interest rates, oracle-based safeguards, and explicitly note that residual bad debt can still occur and be allocated to lenders if liquidations fail. The key stress-channel is the oracle and liquidation path: Vesu says the pool uses Pragma median pricing, rejects stale prices older than four hours, and pauses the pool if oracle conditions are not met; that can protect against invalid pricing but may also freeze withdrawals during an extreme move. Vesu also states that collateral is rehypothecated across pool assets, so distress in one asset can propagate through the pool and make StarkGate WBTC/STRK carry the highest severity risk among pool assets. What is *not verifiable as of 2026-08-29*: current BTC exposure, active BTC markets on Vesu, pool TVL by chain, and on-chain bad-debt thresholds. Because Dune/on-chain verification is unavailable in this run, I cannot confirm whether Vesu has material BTC-specific exposure beyond the protocol’s documented BTC-related pools.

Under a 20% depeg in the largest collateral, the risk outcome for Vesu depends on that collateral’s starting loan-to-value and the pool’s liquidation parameters, but the protocol design indicates that positions crossing the liquidation threshold become eligible for liquidation, and Vesu uses a full liquidation model where liquidators repay all debt in exchange for discounted collateral. Vesu also states that any liquidation shortfall is absorbed immediately by liquidity providers in the same transaction, which is explicitly intended to prevent a bank-run-style liquidity crisis if liquidations fail to fully cover debt. What can be stated from the available sources is limited: Vesu’s docs explain the mechanism, but they do not provide the current largest collateral, its exact initial LTV, pool concentration, or any live Starknet on-chain state needed to quantify whether a 20% depeg would actually trigger insolvencies or bad debt. Therefore, the severity of the scenario is not verifiable as of 2026-08-29. Practically, the stress test should be read as:

• If the largest collateral is close to its liquidation threshold, a 20% price drop can push many positions into liquidation risk.
• If liquidations are deep enough and execute normally, losses are intended to be absorbed through collateral sales rather than leaving residual debt.
• If collateral auctions/slippage are insufficient, Vesu’s pooled-loss mechanism means the remaining shortfall is socialized across LPs in that pool. Because Dune/on-chain verification is unavailable in this run, the pool-level exposure to the largest collateral on Starknet is not verifiable as of 2026-08-29.

For Vesu on Starknet, the relevant stress case is a borrower or position becoming insolvent, not a protocol-level “counterparty” in the traditional sense. Vesu says insolvent positions are liquidated when they violate the loan-to-value limit, and liquidations are designed to sell collateral at a discount to recover the debt. Expected loss path: if liquidation fails or leaves residual debt, Vesu’s risk docs state that the resulting bad debt is instantaneously allocated to the lenders in the pool. In other words, the loss flows from the insolvent borrower’s position into the pool’s lender balance sheet, not to the borrower or liquidator. Who absorbs it: the lenders in that pool absorb the loss pro rata through reduced claim value / pool solvency impact. Vesu’s docs also emphasize pool isolation in V2, so losses are intended to stay within the affected pool instance rather than being socialized across all pools. Compensation: there is no protocol-wide backstop or insurance fund described in the sources here. The only compensation mechanism is successful liquidation and recovery of collateral; if that is insufficient, lenders bear the shortfall. The docs also note that liquidation bots can repay debt against discounted collateral and try to restore health, but that is an operational liquidation process, not a guarantee of full compensation. Impact path through smart contracts: the position’s health is evaluated against pool-specific LTV rules; once insolvent, the position becomes eligible for liquidation. In the V2 architecture, each Pool is isolated, with debt/collateral accounting and liquidation logic inside the pool contract and its associated vaults. The liquidation flow updates the borrower’s debt and collateral balances; if the recovered collateral value is still insufficient, the residual bad debt remains in the pool and is borne by lenders. The earlier Vesu audit also notes shutdown/recovery mechanics when pairs enter insolvency, showing that insolvency can push a pool into restricted modes before eventual redemption/shutdown handling.

Vesu has no clear evidence in the provided sources of committed fraud by the DAO or owners. The available material instead points to a security incident that was prevented, not an exploit or insider theft: Rekt News says a critical rounding vulnerability was discovered, disclosed, and patched with no funds lost; Vesu’s docs also list multiple audits, and Immunefi’s scope treats theft/freezing/insolvency as reportable impacts, not as confirmed events. For this stress scenario, the relevant risk is therefore not verifiable as fraud but residual governance/owner risk and smart-contract risk. Vesu is described as a permissionless lending protocol on Starknet with no governance token, and an independent risk analysis notes that without a protocol-level backstop, losses in bad debt or malicious-pool scenarios would fall on depositors. That is a structural risk, but it is not evidence that the DAO or owners committed fraud. A separate point: the project’s GitHub and docs describe Vesu as open and permissionless, with pool isolation and deployed Starknet contracts listed publicly, which supports transparency about the system’s design, but does not prove the absence of governance abuse. Finding: committed fraud by the DAO or owners — Not verifiable as of 2026-08-29.

For Vesu on Starknet, a negative 30d primary yield source cannot be verified from the provided web results alone. The available sources show Vesu’s yield display on DefiLlama, protocol docs about pool design and stress handling, and third-party articles describing positive or subsidized APRs, but they do not provide a verifiable 30-day breakdown of the primary yield source becoming negative. Under a stress scenario, the most relevant interpretation is that net user yield can fall below zero if the main earning leg is offset by borrowing costs, reduced utilization, or the removal/weakening of rewards; however, that specific outcome is Not verifiable as of 2026-08-29 from the supplied sources. What can be said from the sources:

• Vesu is a lending protocol on Starknet with isolated pools and adaptive risk controls.
• The protocol’s docs explicitly describe stressed-market protections such as oracle rejection, pool pausing, and bad-debt allocation to lenders if liquidations fail.
• Third-party coverage indicates some Vesu-linked strategies can have subsidized or even negative borrowing economics when rewards exceed interest, which means yield outcomes are highly incentive-dependent.
• DefiLlama shows active Vesu pools and average APY, but not a verifiable 30-day primary-yield negative condition in the provided data. If you want, I can turn this into a concise risk memo framed as: primary yield source, stress trigger, negative-yield mechanism, and monitoring points.

Below is what can be established about Vesu (vesu) on Starknet governance using only web sources. On‑chain verification via Dune is not possible in this run (“Not verifiable as of 2026‑08‑30” for any on‑chain-specific metric). 1. Governance structure & who controls what

• Vesu is described as a lending/borrowing protocol on Starknet with an associated VESU token used for governance and incentives.
• Specific governance roles (who controls core contracts, upgradeability, protocol parameters, frontend, or treasury) are not clearly detailed in independent sources. Most references simply state that governance is or will be token‑based without concrete mechanics. This makes the *degree of decentralization* Not verifiable as of 2026‑08‑30.
• I found no clear identification of a controlling legal entity (company name, jurisdiction, registration number, directors) in independent media or analytics sources. Any such claim on the project’s own site would be an unverified marketing claim. 2. Governance process (DAO vs symbolic)
• Independent sources do not provide:
• A formal proposal lifecycle (who can propose, quorum, veto powers).
• Evidence of an active governance forum, snapshot space, or on‑chain voting history.
• As a result, whether the “DAO” is substantive (on‑chain controlled) or mostly symbolic/off‑chain is Not verifiable as of 2026‑08‑30. 3. Token distribution, voting concentration, top holders
• Detailed token distribution, top holders, and actual voting power concentration on Starknet cannot be checked via Dune in this run → Not verifiable as of 2026‑08‑30.
• No independent analytics (e.g., DeFiLlama, TokenTerminal) currently provide holder‑level breakdowns for Vesu on Starknet. 4. Timelocks, multisig, signers, and powers
• I found no independent documentation of:
• Existence of a governance or dev multisig, its signers, threshold, or affiliations.
• Any timelock contract used for protocol upgrades or treasury movements.
• Whether contracts are upgradeable, and who can trigger upgrades, is Not verifiable as of 2026‑08‑30 from independent sources. 5. Terms of Service / legal wrapper
• No independently verifiable Terms of Service or formal legal wrapper (foundation/company) could be located outside Vesu’s own channels. Any ToS hosted only on their site is therefore an unverified marketing claim as to its legal robustness or jurisdictional implications. Key governance risk takeaway: from independent data, Vesu’s actual control structure, upgrade powers, and voting concentration remain opaque, and must be treated as unknown governance risk pending on‑chain and legal‑entity verification.

Vesu’s publicly available legal posture is that of a Starknet-based, permissionless lending protocol with terms applied to the website/service layer by Motion Labs AG, while the protocol itself is described by Vesu as public infrastructure with no governance body or token. The clearest named entity is Motion Labs AG in the Terms of Service, with contact via legal@vesu.xyz; I could not verify the company’s jurisdiction from the available sources, so the entity/jurisdiction mapping is only partially verifiable. The Terms impose substantial restrictions: users must be of legal age (at least 18), have authority to act for any represented entity, avoid prohibited uses, and not be subject to a prohibited jurisdiction. The terms also prohibit use by persons in the United States and in sanctioned/prohibited jurisdictions, and prohibit any activity involving sanctions violations, money laundering, terrorist financing, fraud, theft, or manipulation. On KYC/AML, I found no evidence that Vesu’s core lending protocol requires KYC for protocol access; instead, Vesu presents itself as permissionless. However, the website Terms explicitly reference compliance-related restrictions and sanctions/AML prohibitions at the service level, so the legal wrapper is more restrictive than the protocol design. For classification, the most accurate reading is: a permissionless DeFi lending protocol with a centralized website/operator layer imposing contractual restrictions. That creates a legal structure vs. actual risk gap: the protocol may be open, but the front-end/operator appears to exclude certain users and activities contractually. I found no verifiable public court cases, regulatory enforcement actions, or sanctions designations specific to Vesu as of 2026-08-30. Data-protection obligations are not clearly documented for Vesu itself in the sources reviewed; not verifiable as of 2026-08-30. The main risk point is that the protocol’s permissionless design does not eliminate legal risk for users interacting through the Vesu service layer, especially given the explicit jurisdiction and sanctions restrictions in the Terms.

I could not verify any Vesu-specific stablecoin depeg history from the provided sources, so the correct answer is: Not verifiable as of 2026-08-29. The search results only define stablecoin depegs and list unrelated market-wide examples such as UST, USDC, USDT, FDUSD, and sUSD; they do not establish which stablecoin Vesu used or whether that asset ever depegged on Starknet. If you want, I can help you identify Vesu’s actual stablecoin exposure first, then assess whether that asset has depegged and by how much.

For Vesu on Starknet, the top 5 protocol risks are: permissionless pool creation with programmable hooks expanding the attack surface; oracle/lending-liquidity dependence where stale or faulty prices can impair liquidations; pool-specific bad debt and liquidity runs because losses are isolated but still borne by that pool’s LPs; curator/parameter misconfiguration risk since pool safety depends on correctly set liquidation and oracle parameters; and limited protocol-level backstops because bad debt has no broad central guarantee and no governance safety module is described in the provided sources. ChainSecurity specifically says the protocol’s high complexity and extensibility create a large attack surface and that misconfigured parameters or arbitrary extensions can break individual pools. OpenZeppelin’s audit also highlights curator trust, oracle reliability, and parameter calibration as central security concerns. Hindenrank adds that Vesu’s permissionless hooks and lack of a safety module mean losses are confined to the affected pool, with no broader recourse.

Vesu’s top strengths are: permissionless market creation, isolated risk with pooled liquidity, developer flexibility via lending hooks/extensions, strong capital efficiency from aggregated liquidity, and credible neutrality/no governance bottleneck. Vesu is described as a fully open, permissionless lending protocol on Starknet where anyone can create pools and build new lending experiences without intermediaries or a governance token. Its design combines a liquidity monolith with isolated lending pools, so users share liquidity within a pool while risks remain contained across pools. The hooks/extensions model is a major differentiator because it lets developers customize pool behavior, interest logic, and lending experiences, similar in spirit to programmable hooks in other DeFi systems. Audit coverage from ChainSecurity and OpenZeppelin also indicates the codebase has been reviewed, with ChainSecurity noting pool isolation, solvency, and functional correctness as key audit subjects and OpenZeppelin highlighting the absence of critical liquidity-drain vectors in the v2 review.