Vesu

Vesu is a permissionless modular lending protocol whose official documentation places supply, borrowing, pool creation and transaction execution on Starknet. The DefiLlama API read on 2026-08-15 reported about $12.1M supplied and $5.5M borrowed, only on Starknet. Size is not the deciding rejection: Starknet is outside the registry’s reviewed settlement-chain set, so the shared rejected-chain dossier controls before pool-level underwriting can begin.

Review triggers: events that reopen the verdict
• Starknet passes independent review and is admitted to the supported settlement-chain set, and Vesu remains live there

Watched nightly: a warning on its venues or files, or a cited document that changes, reopens the memo. The first confirmation is due 2026-11-15.

The research file

Mechanism and settlement applicability

Vesu’s current documentation describes supplying, borrowing and leveraged positions on Starknet, plus permissionless lending pools and hooks. Starknet’s own developer documentation implements Vesu deposit, withdrawal, borrow and repayment as Starknet transactions. This establishes Starknet as the settlement perimeter rather than an incidental deployment label.

Current observation

The official Vesu documentation remained live and Starknet-specific at the 2026-08-15 review. The DefiLlama protocol API reported approximately $12.1M supplied and $5.5M borrowed, with Starknet as the only chain. Those adapter figures bound the current survey but do not independently validate pool assets, oracle integrity or exit depth.

Control and exit applicability

Vesu V2 uses a PoolFactory, permissionless pools, pool-specific configuration, oracles, vTokens and liquidation logic. Users can withdraw and repay through Starknet transactions, subject to the relevant pool’s liquidity and controls. The audited contract architecture and permissionless configuration require later protocol review, but they cannot substitute for admitting the underlying settlement chain.

Why the class rule decides

The shared v1 rejected-chain dossier controls because all currently evidenced Vesu lending, control and exit paths settle on Starknet, which is not in the reviewed chain set. Reopen only after Starknet is independently reviewed and admitted and Vesu remains live there; then perform an individual review of pool creators and parameters, governance and emergency controls, collateral, oracles, liquidations, audits and incidents, liquidity and stressed exits.

Class rule

The rejected chain class is outside the approved structures, so every protocol in it is not approved until the rule changes. The rule is about the structure, not an adverse finding about this protocol, and it is not a client instruction. The events that would reopen it are listed with the memo.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• Vesu — official documentation · primary · accessed 2026-08-15
  Supports: Starknet, supply, borrow, leveraged positions, permissionless pools, hooks
• Starknet Docs — Vesu transaction builder · primary · accessed 2026-08-15
  Supports: Vesu integration, Starknet transactions, deposit, withdrawal, borrow, repay
• ChainSecurity — Vesu V2 audit · primary · accessed 2026-08-15
  Supports: Vesu V2 architecture, PoolFactory, permissionless pools, oracles, vTokens, liquidation
• DefiLlama — Vesu survey record · secondary · accessed 2026-08-15
  Supports: current TVL, current borrowing, Starknet-only perimeter, survey category

Inherited controls

The research above describes the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The layer with the most administrative power sets the position’s effective control; that describes control, not quality or suitability.