Vesu
Rejected venues wait the longest for re-review; a rejection has to earn another look before the scheduled date.
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.
- Starknet passes independent review and is admitted to the supported settlement-chain set, and Vesu remains live there
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.
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 verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.
| Chain | Verdict | Grade | Control constraint |
|---|---|---|---|
| Starknet | Approved · limits | hybrid | validity proofs and a regular exit window constrain control, but permissioned proposers and an instant emergency Security Council remain live dependencies. |