Vesu

Vesu is a permissionless lending protocol on Starknet with no governance token, focused on money markets and BTCFi use cases. Protocol identification

• Name: Vesu
• Website / App: vesu.xyz
• Docs: docs.vesu.xyz (Vesu V2 developer and user documentation).
• Category: DeFi lending / money market protocol, enabling earning, borrowing, and custom lending pools via “lending hooks”.
• Launch date: Launch day is stated as 10 July 2024.
• Chains: Deployed on Starknet mainnet (Ethereum L2); no credible evidence of other chains.
• Native / governance token: Public materials emphasize no governance, and there is no native protocol token described; STRK rewards stem from Starknet Foundation’s DeFi Spring, not a Vesu token. Main contracts (Starknet) Best available source is the protocol’s own docs; on‑chain cross‑verification via raw data is Not verifiable as of 2026‑09‑04.
• PoolFactory: 0x3760f903a37948f97302736f89ce30290e45f441559325026842b7a6fb388c0
• Oracle: 0xfe4bfb1b353ba51eb34dff963017f94af5a5cf8bdf3dfc191c504657f3c05
• Multiply: 0x7964760e90baa28841ec94714151e03fbc13321797e68a874e88f27c9d58513
• Liquidate: 0x6b895ba904fb8f02ed0d74e343161de48e611e9e771be4cc2c997501dbfb418
• Migrate: 0x02c4399cfb357f836303d16e8173e4de71b4ba78d97121211357a6d73b9f9213
• Incentive distributors: DeFi Spring Distributor 0x387f3eb1d98632fbe3440a9f1385aec9d87b6172491d3dd81f1c35a7c61048f; BTCFi Distributor 0x47ba31cdfc2db9bd20ab8a5b2788f877964482a8548a6e366ce56228ea22fa8
• Example pools: Prime pool 0x451fe483d5921a2919ddd81d0de6696669bccdacd859f72a4fba7656b97c3b5; Re7 USDC Core pool 0x3976cac265a12609934089004df458ea29c776d77da423c96dc761d09d24124 Explorer verification status
• Direct contract‑verification status on Starknet explorers is Not verifiable as of 2026‑09‑04; no independent explorer references were surfaced in the search. Fork lineage / architecture
• Vesu is described as “built from the ground up” to address limitations of Aave/Compound‑style lending and run without governance or intermediaries. This suggests it is not a simple fork of Aave/Compound, though it borrows the “hooks” concept from Uniswap v4 for customizable lending logic.
• No direct evidence of it being a code fork of a prior lending protocol, and no reports of malicious modifications in related forks were found. Not verifiable as of 2026‑09‑04 whether specific contract deltas vs. any upstream codebase have been formally audited. Marketing-claim flag
• Statements that Vesu is “Starknet’s most trusted lending market” and similar phrasing come only from Vesu’s own docs and blog and are unverified marketing claims.

Vesu appears to be a real, live Starknet protocol rather than a static landing page: the public site shows product navigation such as Earn, Borrow, Multiply, Stake & Earn, and Pools, and the docs explicitly describe deposits, withdrawals, borrowing, wallet connection, and app access via vesu.xyz. The documentation set also includes developer pages and user guides, which is a maturity signal beyond a marketing-only site. I did not find web evidence of broken links, fake TVL/holder metrics, or template-style placeholder content in the retrieved sources, so those items are not verifiable as of 2026-09-04.

Likewise, live deposit/withdrawal execution could not be independently checked here, so it is not verifiable as of 2026-09-04. On API support, the docs and GitHub results indicate developer documentation and repository activity, but I did not find a clearly advertised public/open API endpoint or API reference for Vesu itself; not verifiable as of 2026-09-04.

Vesu has an active bug bounty program. The Immunefi listing says the program has been live since 10 July 2024, with a maximum bounty of $100,000 and triage by Immunefi. Vesu’s 2025 disclosure confirms the program was used to report a rounding-convention vulnerability on 23 May 2025 and that the issue was handled with Immunefi, ChainSecurity, Argent’s security team, and pool curators.

In 2026, Vesu also relaunched a bounty on Sherlock, which lists the program as live with max rewards of 100,000 USDC; however, that appears to be a separate program surface rather than the original Immunefi program.

Assessment — Dependencies & Counterparty Risk (Starknet only; as of September 6, 2026) > Contradiction / correction: The prior finding described Vesu as a USDV CDP/minter. Current evidence identifies Vesu as a permissionless lending protocol with isolated collateral/debt pools—not a USDV issuer. The USDV references appear to concern an unrelated protocol.

• External protocols/assets: Vesu’s risk is primarily asset- and pool-specific. Current public evidence confirms USDC markets and Bitcoin-linked collateral, including WBTC/strkBTC-related use cases. strkBTC introduces dependence on its BTC backing, bridge/federation and redemption mechanisms; xstrkBTC adds Endur liquid-staking/restaking risk where used. Exact pool-by-pool balances, caps and collateral weights are Not verifiable as of September 6, 2026.
• Oracle/manipulation risk — material and demonstrated: Vesu’s V2 contracts configure Pragma oracle keys, source counts, timeouts, aggregation and windows per asset. OpenZeppelin states that correct oracle operation is a dependency. A September 4, 2026 incident reportedly caused 47 liquidations and approximately $3 million of collateral to be liquidated after an upstream Pragma feed supplied incorrect data. This is an observed counterparty/oracle failure mode, not merely theoretical; affected assets, debt losses and recovery amounts remain Not verifiable as of September 6, 2026.
• Bridges: Bridged USDC.e depends on StarkGate/Ethereum, while native USDC uses Circle’s CCTP. strkBTC depends on its Bitcoin-to-Starknet bridge and backing/redemption framework. Bridge outage, message failure, censorship or wrapped-asset depeg could impair collateral liquidity and liquidations.
• Stablecoins/RWA/custodians/CEX/MMs: Vesu has clear USDC stablecoin exposure. Direct exposure to USDT, RWA issuers/SPVs, centralized custodians, CEXs or market makers is Not verifiable as of September 6, 2026. No evidence was found that Vesu itself issues USDV or holds RWA reserves. Failure scenarios: oracle error → wrongful liquidations; USDC or bridged-token depeg → bad debt/liquidity impairment; BTC wrapper/bridge failure → collateral haircut; liquidator or Starknet liquidity shortfall → under-recovery. On-chain exposure percentages are Not verifiable as of September 6, 2026 because Dune MCP is unavailable.

Vesu’s custody is organized as a non-custodial smart-contract model on Starknet: users keep control of their own wallets, deposits are governed by the protocol’s contracts, and Motion Labs says it never takes possession, custody, control, or ownership of user crypto assets. The docs also say funds are never held by Vesu and remain accessible directly onchain, including via a fallback UI if the main frontend is unavailable. The protocol’s pool architecture separates liquidity and parameters by pool, so assets are organized within isolated pool contracts rather than being pooled under a custodian. withdrawal_paused: Not verifiable as of 2026-09-06 segregated_assets: true

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 disclosed a potential share-inflation exploit in the Singleton contract. The attack required adding a new asset to an existing pool and manipulating the inflation-fee reset; Vesu stated users were not affected. Fix: disabled the reset by forcing sufficient share burning when creating markets.

Vesu also paid the reporting whitehat under its bounty program. No attacker exploitation or user reimbursement was reported. Current status: resolved.

On May 23, 2025, a whitehat reported a critical rounding bug in Vesu V1 liquidation logic when receive_as_shares was enabled. A sophisticated attack using a malicious pool extension, attacker-created pool and flashloans could have extracted value. The feature had never been used, and no funds were lost.

Vesu migrated the protocol by May 28, removed receive_as_shares, whitelisted pool extensions, made V2 contracts upgradeable and placed control under a 3-of-5 multisig. No reimbursement was required. Current status: resolved.

Vesu had one publicly documented security incident since launch: a critical rounding-convention vulnerability in the Singleton contract was disclosed on 2025-06-04. The issue was exploitable via liquidation with the receive_as_shares flag, but it was identified by a whitehat through the Immunefi bug bounty program and patched before any funds were stolen.

On September 4, 2026, between 04:08 and 04:10 UTC, a faulty upstream Pragma price feed supplied incorrect prices to multiple Vesu Starknet pools. Automated liquidators then incorrectly liquidated 47 borrowing positions involving approximately $3 million of collateral. Vesu stated that its contracts operated as designed and that no Vesu smart-contract vulnerability was identified.

Pragma corrected the feed and deployed a root-cause fix; affected pool curators paused markets while Vesu, Pragma, StarkWare, the Starknet Foundation, and curators coordinated recovery. A technical report was expected. Recovery and user reimbursement remained unresolved as of September 6, 2026; affected users were told to keep Earn positions open and submit support tickets to preserve refund eligibility.

This was an oracle-data failure, not an attacker exploit; attacker proceeds are therefore not applicable.

Vesu’s key management is not described as protocol-level custody or admin-key control in the sources provided. The clearest available evidence is that Vesu is permissionless, non-custodial, and built on Starknet’s account abstraction model, where wallet authorization is handled at the account/wallet layer rather than by the protocol itself. In practical terms, that means users manage their own signing keys through their Starknet wallet, and the protocol does not appear to impose a special Vesu-specific key vault, multisig, or governance key scheme in the public documentation supplied.

Starknet accounts can use flexible authorization methods such as multisig, session keys, or passkey-based authentication, but those are wallet/account features, not evidence of a Vesu-managed key system. What is verifiable is that Vesu emphasizes an open model where anyone can supply, borrow, and create markets, with no governance token or intermediary control mentioned in the materials here. Therefore, the most accurate answer is: key management is user-controlled via Starknet wallets/accounts, and no protocol-level key-management arrangement is publicly verifiable from the provided sources.

Not verifiable as of 2026-09-04: whether Vesu has any internal admin keys, emergency signers, upgrade keys, or multisig governance controls, because that detail is not disclosed in the supplied sources.

Assessment — Starknet, as of September 6, 2026 Addresses (repository manifest; not independently verified on-chain): PoolFactory 0x3760f903a37948f97302736f89ce30290e45f441559325026842b7a6fb388c0; deployed Pool 0x451fe483d5921a2919ddd81d0de6696669bccdacd859f72a4fba7656b97c3b5; Oracle 0xfe4bfb1b353ba51eb34dff963017f94af5a5cf8bdf3dfc191c504657f3c05; pausing agent 0x773daa9f2605288be0e7586fa8390b7a9f9c4016dc36f68c7effa48de125583; Pragma oracle/summary are also listed in the manifest. Architecture: Starknet native class replacement, not an EVM proxy: each contract address can call replace_class_syscall to swap its class hash. PoolFactory deploys Pools, vTokens and Oracles; the Factory owner is passed as the initial owner. Pool and Oracle use OpenZeppelin OwnableTwoStep. ``text Factory(owner) ├─deploys/updates→ Pool ──uses→ Oracle ──reads→ Pragma │ ├─ curator: parameters/oracle/fees │ ├─ pausing agent: pause only │ └─ owner: upgrade, pause/unpause └─deploys→ vTokens `` Privileged actions: Owner can upgrade Factory, Pool and Oracle immediately through class replacement; no timelock is present in the reviewed source.

Curator can add assets, change asset/rate/pair parameters, oracle address, fee recipient and curator; Oracle manager can add assets and modify oracle keys, timeout, source count, TWAP and aggregation mode. Pause/exit risk: pause() is callable by owner, curator or pausing agent; unpause() only by owner or curator. modify_position()—the deposit, borrow and withdrawal path—requires not paused, so users cannot exit through the normal path while paused. Drain/rug risk: No explicit owner-only token-drain function was identified. However, a compromised owner key can replace Pool/Oracle code and implement arbitrary withdrawals, fee/oracle manipulation or permanent freezing. Thus admin compromise is economically equivalent to upgrade-enabled drain risk.

Users have no guaranteed permissionless escape during a pause. Audit: OpenZeppelin reports 0 critical and 2 high findings, both resolved in the final audited code; the audit covers code commits, not independently verified deployment equivalence. Verification gaps: Proxy-admin type, current owner/curator/manager/renounced roles, timelock delay, live pause state and deployment-to-audit equivalence: Not verifiable as of September 6, 2026 (Dune unavailable; on-chain checks skipped).

Multiple audits of Vesu V1, Multiply, Liquidate, extensions, Ekubo extension and emergency/permissioned pool fixes on Starknet Cairo.

Audit listed for the Multiply contract.

Audit listed for the Liquidate contract.

Audit listed for Extension contracts.

Audit listed for Rebalance contract.

Cairo Security Clan — Vesu Periphery Update Audit Report.

Cairo Security Clan — Vesu Periphery Audit Report.

Additional Vesu audit PDFs listed by Cairo Security Clan: Vesu Audit Report Final, Vesu Extensions, Vesu Liquidate and Vesu Multiply.

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.

Smart contract audit of Vesu V1 on Starknet.

ChainSecurity — Vesu V2 Audit.

Smart contract audit of Vesu V2 on Starknet.

ChainSecurity — Vesu Protocol Smart Contracts (V1).

Newly confirmed published audit report: Sherlock collaborative audit — Vesu Vaults.

Newly confirmed published audit report: Zenith Security — Vesu V2.

Newly confirmed published audit report: Sherlock collaborative audit — Vesu Vaults / Starknet Vault Kit follow-up.

Newly confirmed published audit report: Zenith Security — Vesu V1.1.

Newly confirmed published audit report: Sherlock collaborative audit — Vesu Starknet Vault Kit.

Newly confirmed published audit report: Sherlock collaborative audit — Vesu V2 Periphery.

Differential smart contract audit of Vesu V2 on Starknet.

Cairo smart contract audits of Vesu on Starknet (two private engagements).

Vesu appears to be a small, public founding team rather than an anonymous one: LinkedIn profiles identify Nils Bundi as Co-Founder & CEO and Johannes E as Co-Founder, and the company page lists Vesu as founded in 2024 with 1–10 employees. Nils Bundi’s profile shows prior roles as founder/CEO of Ultrasound Labs, co-founder/board member at DeFi Collective, and a long academic career at ZHAW, which supports real-world fintech/quant finance credibility rather than a pure web-front project. Johannes E’s profile shows prior software/blockchain engineering roles at atpar AG, Blockhaus Tokenised Ecosystems, T-Systems, and Fraunhofer, which is consistent with a technical DeFi builder background.

On the team’s public track record, Vesu’s own materials say it is a fully open, permissionless lending protocol on Starknet with no governance body and no governance token, and the project GitHub exists publicly. Independent coverage and audit-related material indicate the protocol has published audits and a bug bounty, and that a critical vulnerability was found, disclosed, and patched without user losses, which is a meaningful positive operational signal. For the reality check, the available evidence points to a real operating startup with identifiable founders, a named Swiss location (Zug/Switzerland in profiles), and external audit/bug-bounty activity—not an obvious anonymous or purely marketing-driven front.

However, a real office, onshore/offshore corporate structure, and legal entity details are Not verifiable as of 2026-09-04 from the provided sources, and the “real business” conclusion is limited to public team, engineering, and security artifacts rather than verified corporate filings.

Vesu’s reputation appears generally positive but security-conscious, with repeated descriptions as a fully permissionless, non-custodial Starknet lending protocol and public emphasis on audits, bug bounty activity, and open development. Independent coverage also highlights a live vulnerability disclosure and patch process that reportedly avoided user losses, which supports a favorable operational security reputation rather than a history of hacks or insolvency. The main reputational caution is security complexity: ChainSecurity said the codebase had a large attack surface, elevated risk of undiscovered vulnerabilities, and relied heavily on one core smart-contract developer during the audit period.

OpenZeppelin’s V2 differential audit found 24 issues (2 high, 3 medium, 5 low) but reported no critical vectors that could drain liquidity or compromise security. On criticism / unresolved concerns, the clearest items are technical rather than fraud-related: high complexity, extensibility, and audit findings that imply ongoing smart-contract risk. I found no credible evidence in the supplied results of a rug pull, insolvency event, sanctions action, or regulator/court case involving Vesu.

On founders / investors / legal-regulatory: the supplied results do not reliably identify named founders or investors, and those details are Not verifiable as of 2026-09-04. Likewise, I found no confirmed legal or sanctions concerns in the provided sources. The protocol’s own materials and secondary writeups portray Vesu as “fully open” and “permissionless,” but that is best treated as protocol-supplied positioning rather than independent validation.

Economic model (as of September 6, 2026): Vesu is a permissionless Starknet lending market, not a standalone yield vault. Users supply supported assets and earn variable interest paid by borrowers; borrowers post collateral and pay interest. Vesu V2 supports permissionless pool creation, configurable pool parameters, oracle-based collateralization and liquidations. Assets/strategy: Current exposure includes ETH/LSTs, STRK, stablecoins and BTC-related assets; Vesu also expanded into Ekubo-token and yield-bearing-stablecoin markets.

The prior finding that markets were concentrated in ETH/STRK derivatives and stablecoins is therefore incomplete, not contradicted. Plain lending is asset- and rate-exposed; borrowing/recursive lending (“looping”) increases directional exposure and liquidation risk. It is not inherently market-neutral.

Third-party strategy layers such as Troves can automate Vesu loops, but those are external products, not Vesu-native yield. No restaking mechanism was verified as a Vesu-native strategy. Yield: Core supply yield is organic money-market interest. STRK/DeFi Spring rewards are subsidized and may materially inflate displayed returns.

Sustainable yield therefore depends on borrower demand, utilization and incentive continuation. Historical APY volatility and a defensible organic/subsidized percentage split are Not verifiable as of September 6, 2026. Withdrawals/constraints: Deposits can be withdrawn, including max-withdraw functionality, but available liquidity and outstanding debt can constrain withdrawals. Borrowers must repay or remain above collateral thresholds; liquidation is possible.

No fixed user lock-up was verified. Fees, gates, per-market caps, protocol revenue allocation and exact collateral parameters are Not verifiable as of September 6, 2026. TVL/APY: DeFiLlama reports $11.99m TVL, all on Starknet, $4.58m active loans, 44 tracked pools, 5.3% average supply APY and -9.9% 30-day TVL change. Product-level TVL, historical APY distribution/volatility, and Dune-vs-DeFiLlama reconciliation are Not verifiable as of September 6, 2026; Dune was unavailable.

As of September 6, 2026, Vesu’s reserve/treasury position remains not publicly verifiable. The current documentation describes Vesu as operating through self-custodied wallets and, in V2, isolating user funds across separate Pool instances with standalone ERC-4626 VToken vaults; this supports a segregated pool architecture, not evidence of a centralized treasury. No publicly identified treasury or reserve address, reserve size, asset composition, custody provider, reserve-policy document, or formal reserve attestation was found.

The V2 deployment manifest identifies protocol contracts—including the pool factory, pool, oracle, assets, Pragma contracts, and a pausing agent—but does not designate any of them as a treasury or reserve wallet. Control: the published V2 code exposes pool-level owners, shutdown-mode agents, fee configuration, fee-claiming, and upgrade mechanisms. These are protocol-control roles, not proof of treasury custody or reserve ownership; the current controlling addresses and multisig/security model are not independently established here.

On-chain balances and composition via Dune: Not verifiable as of September 6, 2026. Dune MCP was unavailable in this run, so no Dune query ID, execution ID, block-height snapshot, USD valuation, or liabilities calculation can be provided. No reserve figure is inferred from DeFiLlama or protocol-reported data.

Attestations: Not verifiable as of September 6, 2026. No independent reserve attestation or proof-of-reserves report was located in the reviewed sources. Contradiction callout: No numerical treasury or reserve claim was found that could be reconciled against on-chain data. The absence of a disclosed treasury should not be interpreted as a zero balance; it is an information gap.

Vesu currently has no live tradable native token on Starknet; all tokenomics are either absent or in a pre‑launch/planned state. Any figures below are therefore Not verifiable as of 2026‑09‑04 on-chain. ### Native token, supply, market cap

• Public sources describe a planned native ve-token for Vesu, but do not provide a confirmed name/ticker or contract address on Starknet.
• No reliable data on total or circulating supply, market cap, or FDV is available from independent analytics (DefiLlama, CoinGecko, CoinMarketCap) as of this date.
• Conclusion: Vesu has no deployed, trackable ERC‑20 token on Starknet that is recognized by major aggregators. Not verifiable as of 2026‑09‑04. ### Token utility & governance
• Materials describing Vesu’s design (ve-style governance, gauges for yield allocation, and governance control over parameters) appear in medium‑style articles and community posts, but these are either pre‑launch designs or high‑level descriptions without deployed contracts or addresses.
• Therefore, claims about governance roles, revenue share, buybacks, burns, or staking rewards are unverified marketing claims unless tied to live token contracts, which are not found in independent sources. Not verifiable as of 2026‑09‑04. ### Emissions & unlocks
• No emissions schedule, cliff/linear unlock calendar, or vesting contracts for a Vesu token are documented on reputable analytics or auditors’ sites.
• There is no independent confirmation that any announced unlocks have occurred on-chain. Not verifiable as of 2026‑09‑04. ### Allocations & holder concentration
• No audited or third‑party breakdown of team / investor / treasury / community allocations is available.
• Without a verifiable token contract, top-holder concentration, insider wallets, and vesting enforcement cannot be analyzed. Not verifiable as of 2026‑09‑04. ### Contract controls (mint/blacklist/fee‑switch)
• In absence of a confirmed token contract, whether Vesu’s token would include mint, pause, blacklist, or fee‑switch functions — and who controls them (EOA, multisig, or governance) — is unknown from independent sources. Not verifiable as of 2026‑09‑04. ### DEX liquidity & listings
• Major Starknet DEXs and token trackers do not show a Vesu-native token pool with meaningful liquidity (e.g., USDC/VE… pair).
• No centralized exchange listings for a Vesu token are found on independent aggregators. From an institutional risk perspective, treat Vesu as non‑tokenized or pre‑token: there is no on-chain–verified tokenomics to underwrite at this time. Not verifiable as of 2026‑09‑04.

Under a BTC drop below $10,000, the key risk for Vesu on Starknet is collateralized-borrow liquidation pressure on BTC-backed positions, especially any looped or high-LTV strategies that use BTC or strkBTC as collateral. Vesu’s own risk documentation says its pool extensions use liquidation logic, and that if liquidations fail in a stressed market, bad debt can be allocated to lenders in the affected pool; it also says oracle rejection can pause the pool, blocking withdrawals. The most concrete external indicator of BTC stress on Starknet is that Starknet’s BTC lending markets have already seen heavy liquidation activity in volatility events: Starknet reported 56 liquidations and more than half a million dollars worth of BTC in one volatile period, with no bad debt in that episode.

That suggests the liquidation machinery has operated under stress before, but it does not prove resilience at a BTC price below $10,000. For Vesu specifically, the publicly available materials confirm that BTC-related borrowing routes exist on Starknet through Vesu integrations and that users can borrow against BTC collateral, but they do not provide verifiable live exposure, pool-level concentration, or current liquidation thresholds from the supplied sources. Therefore, the size of Vesu’s actual downside exposure to a sub-$10,000 BTC scenario is Not verifiable as of 2026-09-04.

Operationally, the main stress outcomes would be:

• More liquidations as BTC collateral value falls relative to debt.
• Potential oracle-pause events if price feeds become stale or insufficiently diverse.
• Possible lender losses in any pool where liquidations fail and bad debt is realized. So the stress answer is: Vesu is structurally exposed to a sharp BTC drawdown through liquidation risk, but the magnitude of protocol-level loss is not verifiable from the provided sources.

For a 20% depeg of the largest collateral, the direct impact on Vesu cannot be quantified from the available sources because the current on-chain collateral mix, pool-level exposure, and liquidation parameters for Starknet are not verifiable as of 2026-09-04. The protocol documentation does confirm that Vesu uses full liquidation, requires positions to remain overcollateralized, and states that any bad debt is instantaneously allocated to lenders in the affected pool rather than absorbed by a protocol backstop. This means the stress outcome depends on three missing inputs: the share of total borrowed value backed by that collateral, the liquidation discount/market depth during the depeg, and whether the pool can liquidate fast enough before collateral value falls below debt.

Vesu’s design also isolates risk by pool, so losses would be confined to the relevant pool rather than automatically socialized across all pools, unless the stressed collateral is used across multiple pools. The only recent public dashboard result available in the search set shows $29.12M total borrowed and $9.08M of another risk metric on the Vesu site, but the snippet does not provide the underlying asset composition needed to model a 20% depeg, so it is not sufficient for a loss estimate. Not verifiable as of 2026-09-04: largest collateral asset on Starknet Vesu, its share of pool TVL/borrowed exposure, and resulting dollar loss under a 20% depeg.

For Vesu on Starknet, the loss path in a top-counterparty-insolvent stress is: if a borrower’s position becomes undercollateralized and liquidation cannot fully repay the debt, the remaining shortfall is treated as bad debt and is allocated immediately to the liquidity providers in that pool in proportion to their share of pool liquidity. Vesu’s documentation also says pools are isolated into separate Pool instances, so the loss is intended to stay inside the affected pool rather than be socialized across the whole protocol. The expected loss path is therefore: borrower defaults or price move pushes the position insolvent → liquidation bot / liquidation logic attempts to close the position → collateral sale proceeds may be insufficient → residual bad debt is written into the pool state → lenders absorb the loss through reduced claim value / pool share value.

The protocol’s published risk report says this bad debt is allocated “instantaneously” to lenders in the pool. The absorbing party is the pool’s lenders / liquidity providers, not a protocol treasury or insurance module. The protocol sources provided here do not describe any dedicated backstop, treasury recapitalization, or governance-funded compensation mechanism; therefore Not verifiable as of 2026-09-04 whether any exogenous compensation exists beyond pool-level loss allocation.

The smart-contract impact path is described as follows: the liquidation model executes within the pool’s contracts; on failure to fully cover debt, the shortfall is recognized in the same transaction that resolves the liquidation, and the pool’s accounting is updated so LPs bear the loss. Vesu’s pool isolation architecture means the state transition should be localized to the specific Pool instance containing the insolvent position. A separate audit describes recovery / shutdown modes when a pool pair falls into insolvency, including restricted actions such as increasing collateral or decreasing debt during recovery and only withdrawing collateral in redemption mode, indicating additional contract-level fail-safes around insolvency handling.

For Vesu on Starknet, a committed fraud by the DAO or owners is not verifiable as of 2026-09-04. The available materials show Vesu is described as a non-custodial lending protocol, and its security docs emphasize that funds are never held by Vesu and are accessible directly onchain, which reduces the relevance of a custody-based owner-theft scenario. What is verifiable is that Vesu publicly disclosed and remediated a critical technical vulnerability in its Singleton contract involving rounding behavior in liquidations; the disclosure says a whitehat found it through Immunefi, that user funds could have been stolen in an exploit, and that the fix removed the affected logic and whitelisted pool extensions.

OpenZeppelin also reported on a later Vesu V2 differential audit, but that is an audit/security update, not evidence of DAO or owner fraud. So for a stress scenario focused specifically on fraud by the DAO or owners, the evidence base does not support a confirmed fraud event, governance theft, or malicious owner action. The appropriate risk statement is: Not verifiable as of 2026-09-04.

For Vesu on Starknet, a stress scenario with a negative primary yield source over the last 30 days means the underlying lending/borrow market is generating a *negative net return* after fees, incentives, or losses. Vesu’s documentation confirms it is a lending protocol built around isolated pools on Starknet, so yield is pool-specific rather than protocol-wide. What this implies for risk analysis:

• A negative 30d primary yield source would pressure depositor returns in the affected pool, even if the protocol remains operational.
• In a lending design, the main stress channel is typically lower borrow demand, higher bad-debt risk, or a mismatch between interest earned and incentives paid; Vesu’s docs explicitly describe liquidation and bad-debt allocation to lenders under stress.
• Because pools are isolated, stress is more likely to remain contained to the specific pool rather than automatically spreading across all Vesu markets. What is not verifiable as of 2026-09-04 from the available sources:
• The exact 30-day primary yield figure for the selected Vesu pool.
• Whether the negative yield is driven by borrower rates, incentives, rewards decay, or realized losses.
• The current TVL, utilization, and chain-level exposure for the specific Starknet pool. Independent cross-checks available in the search results are limited. DefiLlama shows Vesu has tracked pools and an average APY metric, but that is an aggregator view, not a raw on-chain verification. DIA’s vault page for a Vesu wstETH vault reports 0.00% APY and negative risk statistics, which is consistent with weak or stressed yield conditions, but it is still an analytics source rather than on-chain truth. Bottom line: the appropriate stress finding is negative primary yield over 30 days for the selected Starknet Vesu market, with pool-level contagion limited by isolation, but depositor economics likely impaired.

Assessment as of September 13, 2026: Vesu has no evidenced operative token-holder DAO. Governance is currently operationally multisig/company controlled; the documented end-state is future revocation of upgrade permissions in favor of decentralization. The Vesu Security Council is described as a Starknet 4-of-6 multisig at 0x024b…C9403, with 50% external signers.

No timelock or proposal/voting process is documented. Top-holder concentration and voting power are Not verifiable as of September 13, 2026 because Dune MCP is unavailable; no on-chain claim is made. Control map: core-contract upgrades are controlled by the Security Council/singleton owner.

Source code shows the singleton owner can replace the implementation, while pool owners can set debt caps, LTV, liquidation, shutdown, interest-rate, asset and fee parameters, transfer pool ownership, and appoint shutdown agents. These powers are code-level capabilities; current on-chain role assignments and whether any role can directly drain user funds are Not verifiable as of September 13, 2026. Frontend/development appears company-controlled through the Vesu GitHub organization and Motion Labs AG copyright, but frontend deployment authority is not independently documented.

Company: Motion Labs AG, Zug, Switzerland; Swiss commercial-register number CH-170.3.049.529-9; UID CHE-457.437.885. Moneyhouse lists Nils Andri Bundi, Grégoire Jacques F. Le Jeune D'Allegeershecque, and Johannes Escherich as directors, with Bundi holding individual signing authority.

Beneficial ownership is not disclosed in the accessible record. Vesu’s Terms of Service are linked to vesu.xyz, but their operative legal terms were Not verifiable as of September 13, 2026. CONTRADICTION / LIMITATION: the protocol describes itself as permissionless, but its security documentation confirms current upgrade centralization; the stated decentralization is future-oriented, not current governance.

Vesu appears to be operated/linked to Motion Labs AG per its Terms of Service, which says the terms are a binding agreement for use of www.vesu.xyz offered by Motion Labs AG, a software development studio. The service terms prohibit use in violation of applicable law, including money laundering, terrorist financing, fraud, theft, and sanctions laws, and they prohibit access by users in the United States and by persons in sanctioned countries or subject to sanctions. Vesu’s privacy page says personal information is handled by email-only newsletter/marketing operations and references its privacy notice; no separate KYC policy was found.

On available sources, Vesu is best treated as a non-custodial DeFi interface/protocol with compliance restrictions at the interface level rather than a formally identified regulated financial institution. I did not find evidence of a court case, regulator action, or sanctions designation specific to Vesu or Motion Labs AG in the gathered sources. Because on-chain checks are unavailable in this run, the actual control/legal risk cannot be fully verified; Not verifiable as of 2026-09-04.

No exact GLEIF LEI record for 'Motion Labs AG', 'Vesu'. OFAC SDN screening of 'Motion Labs AG', 'Vesu': no match. SEC litigation and administrative release feeds: no mention.

Vesu does not appear to issue its own stablecoin; the protocol materials describe Vesu as a Starknet lending protocol and list external stable assets such as USDC and USDT, including native USDC migration on Starknet, but no Vesu-issued stablecoin is evident. The stablecoin used in Vesu markets appears to be external stablecoins (primarily USDC/USDT), and no depeg event for those used assets could be verified from the available sources, so the depeg count, last depeg date, and max depeg percentage are not verifiable as of 2026-09-06.

Vesu’s principal risks arise from permissionless market configuration, oracle dependence, evolving Cairo smart-contract complexity, liquidation/liquidity stress, and privileged administration. Vesu V2 has undergone external audits, but audits are time-boxed and do not eliminate residual protocol, market, or operational risk. On-chain balances, exposure concentration, and current bad-debt history are Not verifiable as of September 5, 2026 because Dune access is unavailable.

Vesu’s top strengths on Starknet are: permissionless market creation, modular/isolated pool design, capital efficiency from pooled liquidity, strong risk transparency and custom risk parameters, and security-focused architecture with audits and non-custodial funds. Vesu is repeatedly described as fully open and permissionless, with anyone able to create lending pools without centralized governance; this is one of its clearest differentiators. Its modular structure combines pooled liquidity with isolated pools, so markets can be tailored while bad debt in one pool does not contaminate others.

The protocol is also positioned around capital efficiency, using pooled liquidity to support a broad range of lending activity and improve liquidity utilization versus fully fragmented designs. Vesu emphasizes risk transparency through explicit risk frameworks and intuitive market-level risk information, which helps users assess positions before depositing or borrowing. Finally, the protocol’s security posture is strengthened by its non-custodial design, fallback UI, and audit coverage; OpenZeppelin reported no critical-severity issues in its V2 differential audit.