Pashov Audit Group has completed over 400 security audits, discovered more than 4,000 vulnerabilities, and helped secure over $100 billion in TVL. Its client list includes Aave, Uniswap, Ethena, LayerZero, Pendle, and Ether.fi: the institutional credibility benchmark for smart contract security in DeFi. H1 2025 totalled approximately $3.1 billion in total Web3 losses, the worst six-month period since early 2023. Smart contract bugs specifically accounted for approximately $263 million of that figure. Institutional investors and exchanges in 2026 routinely require proof of audit completion before integrating protocols; the depth of the audit, not just its existence, determines institutional confidence.

The distinction between an infrastructure audit and a specific vault configuration audit is the most important due diligence question for any institutional DeFi vault allocation. Veda's BoringVault is audited. That audit does not cover the specific Merkle whitelist configuration of a vault built on Veda. Lucidly's syToken vaults at app.lucidly.finance have a Pashov audit covering the specific vault configuration: which markets are approved, what leverage parameters are permitted, and what the execution engine cannot do regardless of operator instructions. This article explains what a DeFi vault audit covers, what the Pashov standard specifically examines for vault products, and how to read an audit to answer the questions institutional due diligence actually asks.

Why the difference between infrastructure and configuration audits matters

Most DeFi infrastructure is audited. Morpho Blue's 650 lines of immutable code have multiple independent audits. Veda's BoringVault is audited. OpenZeppelin's ERC-4626 base implementation is audited. These infrastructure audits are necessary but insufficient for institutional vault due diligence. They answer: "Is the underlying code secure?" They do not answer: "Is this specific vault's constraint configuration secure, and what can the execution engine mathematically not do?"

The Sherlock audit pricing reference made this explicit: "An audit certificate from a top-tier firm carries documented weight with institutional investors, major exchanges, and sophisticated counterparties during fundraising and listing reviews." The institutional question is not whether a named firm signed off on the infrastructure; it's whether a named firm signed off on the specific vault configuration being evaluated. A fund deploying $10 million into a vault needs the second document, not the first. The Pashov audit on the Details tab at app.lucidly.finance is that second document for Lucidly's syToken vaults.

What a DeFi vault audit covers: the seven examination areas

1. Access control architecture

Access control exploits drove $1.63 billion of H1 2025's $3.1 billion in losses: the largest category by far. The access control examination in a vault audit covers: who can call which functions, what multisig or timelock requirements apply to privileged operations, and whether there are any functions that allow unilateral operator action over depositor funds. For execution-owned vaults using Merkle-verified whitelisted calldata, the audit specifically documents: what functions are in the whitelist (approved protocol interactions), what functions are not in the whitelist (explicitly prevented actions), and what happens if an operator tries to call a function outside the whitelist (the transaction reverts). The Pashov audit for Lucidly's syToken vaults documents the specific whitelist configuration covering approved Morpho Blue markets, approved leverage parameters, and the execution engine's permission scope.

2. Economic security and share price manipulation

ERC-4626 vaults are susceptible to share price inflation attacks where an early depositor manipulates the initial share price to cause rounding losses for subsequent depositors. The audit examines the dead deposit protection: a seed deposit to address 0x000...dEaD establishing a baseline share supply that makes inflation attacks economically unfeasible. The audit also examines the share price accounting precision: rounding direction in convertToShares() and convertToAssets() functions, and whether rounding consistently favours the vault rather than the depositor in edge cases. Incorrect rounding direction is a class of vulnerability that doesn't require malicious actors; it can cause systematic value extraction through normal operations.

3. Reentrancy vulnerabilities

Reentrancy is one of the oldest and most persistently exploited vulnerability classes in DeFi. The DAO hack in 2016, Cream Finance variants, and multiple subsequent incidents all involved reentrancy. The vault audit examines every external call in the contract (deposits, withdrawals, reward claims, rebalancing operations); and verifies that state changes happen before external calls (checks-effects-interactions pattern) or that reentrancy guards are in place. For vaults that interact with multiple external protocols (Morpho Blue markets, oracle contracts, token contracts), the attack surface for cross-contract reentrancy is larger than for single-protocol contracts.

4. Oracle manipulation and price feed reliability

Every leveraged vault position depends on oracle accuracy for health factor calculations. The audit examines: which oracle providers are used for each collateral asset in the approved market set, what manipulation resistance each oracle has (number of independent price sources, TWAP versus spot pricing, heartbeat and deviation thresholds), and what happens if an oracle returns a stale or manipulated price during a liquidation trigger. For blue-chip collateral markets (ETH, BTC, wstETH), the audit confirms that multiple independent oracle sources (Chainlink, Chronicle, Pyth) provide the price feeds with documented freshness and deviation tolerances. For any market where a single oracle failure could cause incorrect liquidations, this is a documented finding that requires mitigation.

5. Liquidation mechanics under stress conditions

A leveraged vault audit specifically examines what happens to the vault's position under stress scenarios: rapid collateral price decline, borrowing rate spike, oracle latency, and liquidity provider withdrawal pressure simultaneously. The examination covers: at what health factor does the execution engine trigger rebalancing, what is the execution engine's permitted leverage range (minimum and maximum), and whether there are market conditions under which the vault's health factor could approach the liquidation threshold faster than the execution engine can respond. For Lucidly's continuous execution architecture, the audit specifically documents the block-by-block monitoring frequency and the approved rebalancing actions within the whitelist.

6. Upgrade path and admin key risk

For non-upgradeable vault contracts, the audit confirms that the bytecode deployed on-chain matches the audited source code and that there is no proxy upgrade mechanism that could replace the implementation. For contracts with upgrade mechanisms, the audit examines the upgrade governance: what multisig requirements apply, what timelocks protect against rapid unilateral upgrades, and whether a single compromised key can substitute a malicious contract implementation. The institutional preference is non-upgradeable core contracts with timelocked parameter updates: the same design Morpho Blue uses for its lending market parameters.

7. Integration-specific edge cases

Each external protocol a vault integrates with introduces integration-specific edge cases. The audit examines the vault's behaviour if a Morpho Blue market pauses lending, if a collateral asset's oracle goes stale during an active leveraged position, if a token contract implements non-standard transfer logic that could cause accounting errors, and if a network congestion event prevents rebalancing transactions from landing in time during a market stress event. These edge case examinations are specific to the combination of protocols the vault uses; a Morpho Blue vault audit covers different edge cases than a Compound vault audit, even if both use the same ERC-4626 base.

How to read the Pashov audit for Lucidly's syToken vaults

Open the Details tab at app.lucidly.finance and the Pashov audit is the first document listed. The document structure follows the standard audit format: executive summary (what the audit covered and the overall risk assessment), scope (specific contracts and commit hashes reviewed), findings by severity (Critical, High, Medium, Low, Informational), and remediation status (which findings were fixed before deployment). For institutional due diligence, the executive summary answers the overview question: does the vault's execution architecture have any unresolved material vulnerabilities? A clean executive summary with no unresolved Critical or High findings is the baseline institutional requirement.

The detailed findings section answers specific due diligence questions. Access control findings confirm the Merkle whitelist constraints: the execution engine's permitted actions are documented with specific approved contracts, function selectors, and parameter ranges. Liquidation mechanics findings confirm the health factor monitoring architecture and approved rebalancing parameters. Oracle findings confirm which price feeds are used for each collateral type in the approved market set. For a fund's risk committee presenting the DeFi vault allocation for approval, extracting these three sections from the audit provides the specific technical documentation that answers the three most common due diligence questions: what can the execution engine do, what can it not do, and what happens in extreme market conditions. For the broader due diligence framework, see the article on how to pick a DeFi vault: the 10-question framework.

The gap between audited infrastructure and audited configuration

The practical due diligence gap that matters for institutional allocation: most vault products operating on audited infrastructure (Veda BoringVault, OpenZeppelin ERC-4626) have not published a specific audit of their vault's Merkle whitelist configuration. The infrastructure audit covers the general code. The configuration audit covers this specific vault's permitted actions. For a fund deploying capital, the configuration audit is the document that answers: "What has an independent security firm documented about what this specific vault can and cannot do with my capital?"

Pashov Audit Group can complete a focused review of a single contract in 3-5 days, while a comprehensive audit of a complex DeFi protocol takes 2-4 weeks. The cost ranges from $25,000 to $100,000 for most DeFi protocol audits per the Sherlock market reference. The audit cost is immaterial relative to capital at risk. Existence of a specific configuration audit is the non-negotiable gate for institutional funds that require audit documentation before deploying. For the full context on what vault architecture choices determine the audit requirements, see the article on DeFi vault architecture patterns: which design is right for your strategy and the full institutional scorecard in the article on institutional DeFi vault scorecard: rating every major product.

Frequently asked questions

What does a DeFi vault audit cover that an infrastructure audit doesn't?

A DeFi vault audit covers the specific constraint configuration applied to the vault: which markets are approved for deployment, what leverage parameters are permitted, what access controls apply to privileged operations, and what the execution engine cannot do regardless of operator instructions. An infrastructure audit (Veda BoringVault, OpenZeppelin ERC-4626) covers the general smart contract code that multiple vaults share. The institutional due diligence question requires the vault-specific audit, not the infrastructure audit. A vault built on audited infrastructure with an unreviewed Merkle whitelist configuration has a documented infrastructure audit and an undocumented constraint configuration. The Pashov audit for Lucidly's syToken vaults at app.lucidly.finance is the specific configuration audit; it covers the exact approved markets, leverage parameters, and execution boundaries for the syUSD, syETH, and syBTC vaults, not just the underlying framework code.

How does an institutional fund use the Pashov audit in its due diligence process?

The Pashov audit serves three specific functions in an institutional fund's due diligence process. Risk committee documentation: the audit's executive summary and access control findings answer the risk committee question "what can the vault operator do with our capital?": the answer is "only what is in the Merkle whitelist, which the audit documents specifically." LP disclosure: the audit provides the source document for the smart contract risk section of the fund's LP disclosures: "vault execution is constrained by a Pashov-audited Merkle whitelist (available on request)" is a specific, verifiable statement rather than a general "the vault is audited" claim. General counsel review: the audit's findings on admin key risk and upgrade path answer the legal question about whether a single operator can unilaterally change the vault's strategy or extract depositor funds outside the audited constraint architecture. Access the Pashov audit from the Details tab at app.lucidly.finance.