Paravel Citadel DAO Aave Adaptor and Permission Script Smart Contract Audit

</nav>
<article class="report">
<h1 id="introduction">Introduction</h1>
iosiro was commissioned by Paravel to perform a smart contract audit of their Aave V3 leverage adaptor & micro-manager, and associated Foundry permission scripts used to configure vault access control. Two auditors conducted the audit between January 27, 2026, and February 3, 2026, using 10 audit days.
<h4 id="overview">Overview</h4>
Paravel extended the Boring Vault framework into a multi-agent Aave V3 leverage management system with Uniswap V3 swaps and cross-vault fund movement. The audit focused on the contracts and scripts central to this system: the <code>PrvlAaveBorrow</code> adaptor, the legacy <code>PrvlFlashloanAaveBorrowV5</code> micro-manager, and 12 Foundry permission scripts in <code>script/Permissions/</code>.
The audit identified 11 findings: 1 medium, 4 low, and 6 informational-risk, along with 9 code quality improvement suggestions. The most impactful finding was that the <code>PrvlAaveBorrow</code> adaptor was deployed without the necessary role capabilities configured, rendering it unusable by the vault system. Other finding themes included gaps in input validation for numeric parameters, token-handling edge cases, and the maintainability of the permission scripts.
During the audit, Paravel removed the in-scope contracts (<code>PrvlAaveBorrow.sol</code> and <code>PrvlFlashloanAaveBorrowV5.sol</code>) and associated deployment scripts from the codebase. Leverage management operations (borrow, repay, and settle) are now composed off-chain and submitted directly to the vault via <code>manageVaultWithMerkleVerification</code> on <code>ManagerWithMerkleVerification.sol</code>, with no on-chain adaptor in production. As a result, all medium- and low-risk findings were closed. One informational finding related to the permission scripts remained open at the conclusion of the audit.
<table class="findings-count">
<thead>
<tr>
<th> </th>
<th>Critical</th>
<th>High</th>
<th>Medium</th>
<th>Low</th>
<th>Informational</th>
</tr>
</thead>
<tbody>
<tr>
<td>Open</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>Resolved</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>4</td>
<td>5</td>
</tr>
</tbody>
</table>
<hr/>
<h4 id="scope">Scope</h4>
The assessment focused on the source files listed below, with all other files considered out of scope. Any out-of-scope code interacting with the assessed code was presumed to operate correctly without introducing functional or security vulnerabilities.
<ul>
<li>Project name: <a href="https://github.com/ParavelDAO/boring-vault">boring-vault</a></li>
<li>Initial audit commit: <a href="https://github.com/ParavelDAO/boring-vault/commit/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d"><code>b5154a8</code></a></li>
<li>Final review commit: <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a></li>
<li>Files: <code>src/adaptors/PrvlAaveBorrow.sol</code>, <code>src/micro-managers/PrvlFlashloanAaveBorrowV5.sol</code>, <code>script/Permissions/*.s.sol</code></li>
</ul>
A specification is available in the <a href="#specification">Specification section</a> of this report.
<h1 id="disclaimer">Disclaimer</h1>
This report aims to provide an overview of the assessed smart contracts’ risk exposure and a guide to improving their security posture by addressing identified issues. The audit, limited to specific source code at the time of review, sought to:
<ul>
<li>Identify potential security flaws.</li>
<li>Verify that the smart contracts’ functionality aligns with their documentation.</li>
</ul>
Off-chain components, such as backend web application code and keeper functionality, were explicitly not within the scope of this audit.
Given the unregulated nature and ease of cryptocurrency transfers, operations involving these assets face a high risk from cyber attacks. Maintaining the highest security level is crucial, necessitating a proactive and adaptive approach that accounts for the experimental and rapidly evolving nature of blockchain technology. To encourage secure code development, developers should:
<ul>
<li>Integrate security throughout the development lifecycle.</li>
<li>Employ defensive programming to mitigate the risks posed by unexpected events.</li>
<li>Adhere to current best practices wherever possible.</li>
</ul>
<h1 id="methodology">Methodology</h1>
The audit was conducted using the techniques described below.
<dl>
<dt>Code review</dt>
<dd>The source code was manually inspected to identify potential security flaws. Code review is a useful approach for detecting security flaws, discrepancies between the specification and implementation, design improvements, and high-risk areas of the system.</dd>
<dt>Dynamic analysis</dt>
<dd>The contracts were compiled, deployed, and tested in a test environment, both manually and through the test suite provided. Dynamic analysis was used to identify additional edge cases, confirm that the code was functional, and to validate the reported issues.</dd>
<dt>Automated analysis</dt>
<dd>Automated tooling was used to detect the presence of various types of security vulnerabilities. Static analysis results were reviewed manually, and any false positives were removed. Any true positive results are included in this report.</dd>
</dl>
<h1 id="audit-findings">Audit findings</h1>
The table below provides an overview of the audit’s findings, with detailed write-ups in the following sections.
<table class="findings">
<thead>
<tr>
<th>ID</th>
<th>Issue</th>
<th>Risk</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="#IO-PRV-APS-001">IO-PRV-APS-001</a></td>
<td>Missing role capabilities configuration for PrvlAaveBorrow adaptor</td>
<td class="rating-medium">Medium</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-002">IO-PRV-APS-002</a></td>
<td>Removing token configuration clears approval</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-003">IO-PRV-APS-003</a></td>
<td>Quoter/execution mismatch</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-004">IO-PRV-APS-004</a></td>
<td>Weak slippage controls</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-005">IO-PRV-APS-005</a></td>
<td>Ignored repay return value</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-006">IO-PRV-APS-006</a></td>
<td>Missing SafeTransferLib limits token compatibility</td>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-007">IO-PRV-APS-007</a></td>
<td>Missing quoter zero-check</td>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-008">IO-PRV-APS-008</a></td>
<td>Missing authority zero-check</td>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-009">IO-PRV-APS-009</a></td>
<td>repay() amountIn not validated against supplyAmount</td>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-010">IO-PRV-APS-010</a></td>
<td>settle() amountIn unknowable due to interest accrual</td>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-PRV-APS-011">IO-PRV-APS-011</a></td>
<td>Foundry key management</td>
<td class="rating-informational">Informational</td>
<td class="status-open">Open</td>
</tr>
</tbody>
</table>
Each issue identified during the audit has been assigned a risk rating. The rating is determined based on the criteria outlined below.
<dl>
<dt>Critical risk</dt>
<dd>The issue could result in the theft of funds from the contract or its users.</dd>
<dt>High risk</dt>
<dd>The issue could result in the loss of funds for the contract owner or its users.</dd>
<dt>Medium risk</dt>
<dd>The issue resulted in the code being dysfunctional or the specification being implemented incorrectly.</dd>
<dt>Low risk</dt>
<dd>A design or best practice issue that could affect the ordinary functioning of the contract.</dd>
<dt>Informational</dt>
<dd>An improvement related to best practice or a suboptimal design pattern.</dd>
</dl>
In addition to a risk rating, each issue is assigned a status:
<dl>
<dt>Open</dt>
<dd>The issue remained present in the code as of the final commit reviewed and may still pose a risk.</dd>
<dt>Resolved</dt>
<dd>The issue was identified during the audit and has since been satisfactorily addressed, removing the risk it posed.</dd>
<dt>Closed</dt>
<dd>The issue was identified during the audit and acknowledged by the developers as an acceptable risk without actioning any change.</dd>
</dl>
<a name="IO-PRV-APS-001"></a><h2 id="io-prv-aps-001-missing-role-capabilities-configuration-for-prvlaaveborrow-adaptor" class="break-before">IO-PRV-APS-001 Missing role capabilities configuration for PrvlAaveBorrow adaptor</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-medium">Medium</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/DeployPrvlBorrow.s.sol">script/DeployPrvlBorrow.s.sol</a></td>
</tr>
</tbody>
</table>
The <code>PrvlAaveBorrow</code> adaptor is deployed using <code>DeployPrvlBorrow.s.sol</code>, but no role capabilities are configured for its vault functions in the deploy script or any other script in the <code>Permissions/</code> directory. The adaptor’s <code>supply()</code>, <code>reducePosition()</code>, and <code>settle()</code> functions are all gated by Solmate’s <code>requiresAuth</code> modifier, which checks the <code>RolesAuthority</code> contract for role-based access.
Without role capabilities, calls from the vault into the adaptor revert due to missing authorization. The vault is not the owner of the adaptor, and no role has been granted capability to call these functions.
<h3 id="recommendation">Recommendation</h3>
The role capabilities for <code>PrvlAaveBorrow</code> should be configured during deployment or via a dedicated permission script using the following function calls:
<pre tabindex="0" class="chroma"><code>rolesAuthority.setRoleCapability(STRATEGIST_ROLE, adaptor, PrvlAaveBorrow.supply.selector, true);
rolesAuthority.setRoleCapability(STRATEGIST_ROLE, adaptor, PrvlAaveBorrow.reducePosition.selector, true);
rolesAuthority.setRoleCapability(STRATEGIST_ROLE, adaptor, PrvlAaveBorrow.settle.selector, true);
rolesAuthority.setUserRole(VAULT, STRATEGIST_ROLE, true);
</code></pre>A distinct adaptor is required for each vault, so this role configuration would need to be applied for each adaptor/vault pair.
<h3 id="client-response">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-002"></a><h2 id="io-prv-aps-002-removing-token-configuration-clears-approval" class="break-before">IO-PRV-APS-002 Removing token configuration clears approval</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L222">PrvlAaveBorrow.sol#L222</a></td>
</tr>
</tbody>
</table>
<code>PrvlAaveBorrow.setTokenConfig()</code> grants token-level approvals from the adaptor to Uniswap and Aave for the configured base and deposit tokens:
<pre tabindex="0" class="chroma"><code>ERC20(config.baseToken).approve(address(uniswapV3Router), type(uint256).max);
ERC20(config.baseToken).approve(address(aave), type(uint256).max);
ERC20(config.depositToken).approve(address(uniswapV3Router), type(uint256).max);
ERC20(config.depositToken).approve(address(aave), type(uint256).max);
</code></pre><code>PrvlAaveBorrow.removeTokenConfig()</code> then unconditionally zeroes out those same approvals:
<pre tabindex="0" class="chroma"><code>ERC20(config.baseToken).approve(address(uniswapV3Router), 0);
ERC20(config.baseToken).approve(address(aave), 0);
ERC20(config.depositToken).approve(address(uniswapV3Router), 0);
ERC20(config.depositToken).approve(address(aave), 0);
</code></pre>If two or more token configurations share the same base or deposit token, removing one configuration clears the approvals required by the other still-active configurations. This would temporarily cause subsequent calls that use the remaining token configs to fail until approvals are restored, e.g., by removing all configs and re-adding the required ones.
<h3 id="recommendation-1">Recommendation</h3>
The potential for this issue should be documented for callers of <code>PrvlAaveBorrow.removeTokenConfig()</code>. Alternatively, per-token reference counts could be maintained so that approvals are only zeroed when no remaining config needs them.
<h3 id="client-response-1">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-003"></a><h2 id="io-prv-aps-003-quoterexecution-mismatch" class="break-before">IO-PRV-APS-003 Quoter/execution mismatch</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/micro-managers/PrvlFlashloanAaveBorrowV5.sol#L203">PrvlFlashloanAaveBorrowV5.sol#L203</a></td>
</tr>
</tbody>
</table>
When calling <code>PrvlFlashloanAaveBorrowV5.getBorrowUserData()</code>, a swap amount is calculated internally as <code>swapAmount = collateralAmount + borrowAmount</code> and used to obtain a quote from the Uniswap V3 Quoter. However, the actual swap amount encoded in the flashloan callback data is taken from <code>exactInputParams.amountIn</code>, which is provided by the caller. These two values are never checked against each other and could differ:
<pre tabindex="0" class="chroma"><code>uint256 swapAmount = collateralAmount + borrowAmount;
uint256 supplyAmount = quoter.quoteExactInput(exactInputParams.path, swapAmount);

bytes memory swapData = abi.encodeWithSelector(
 EXACT_INPUT_SELECTOR,
 exactInputParams // includes amountIn which could differ from swapAmount
);

bytes memory supplyData = abi.encodeWithSelector(
 SUPPLY_SELECTOR, depositToken, supplyAmount, boringVault, 0
);
</code></pre>The <code>supplyAmount</code> is quoted using <code>swapAmount</code>, but the actual swap will use <code>exactInputParams.amountIn</code>. If <code>amountIn < swapAmount</code>, the swap produces less output than <code>supplyAmount</code> and the Aave supply reverts. If <code>amountIn > swapAmount</code>, extra vault tokens may be consumed silently.
<h3 id="recommendation-2">Recommendation</h3>
The <code>exactInputParams</code> struct may not be necessary as the values could be derived in the function call, saving calldata and mitigating this issue. Alternatively, explicit validation should be added to ensure <code>exactInputParams.amountIn</code> equals the computed <code>swapAmount</code>.
<h3 id="client-response-2">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlFlashloanAaveBorrowV5</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-004"></a><h2 id="io-prv-aps-004-weak-slippage-controls" class="break-before">IO-PRV-APS-004 Weak slippage controls</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L108">PrvlAaveBorrow.sol#L108</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L138">#L138</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L167">#L167</a></td>
</tr>
</tbody>
</table>
The <code>swapMinOut</code> slippage limit in <code>PrvlAaveBorrow.supply()</code>, <code>PrvlAaveBorrow.reducePosition()</code>, and <code>PrvlAaveBorrow.settle()</code> is confirmed to be non-zero, but a value of 1 wei would still be accepted:
<pre tabindex="0" class="chroma"><code>if (swapMinOut == 0) revert PrvlAaveBorrow__minOutCannotBeZero();
</code></pre>A compromised or incorrectly configured strategist could execute swaps with effectively zero slippage protection. Because the Boring Vault’s merkle verification system constrains address arguments but not numeric parameters, the <code>swapMinOut</code> value is entirely under the strategist’s control.
<h3 id="recommendation-3">Recommendation</h3>
The functions should derive a slippage limit value from the swap amount. A slippage tolerance (e.g., 1%) could be configured for the contract and used to calculate a minimum acceptable output based on the swap input amount. This would require an oracle or quoter price for the output token.
<h3 id="client-response-3">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-005"></a><h2 id="io-prv-aps-005-ignored-repay-return-value" class="break-before">IO-PRV-APS-005 Ignored repay return value</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L143-L145">PrvlAaveBorrow.sol#L143-L145</a></td>
</tr>
</tbody>
</table>
Both <code>PrvlAaveBorrow.reducePosition()</code> and <code>PrvlAaveBorrow.settle()</code> pull base token from the vault and call <code>aave.repay()</code>, but the contract ignores the returned <code>uint256</code> repaid amount:
<pre tabindex="0" class="chroma"><code>ERC20(config.baseToken).transferFrom(msg.sender, address(this), repayAmount);
aave.repay(config.baseToken, repayAmount, config.aaveVariableRate, msg.sender);
</code></pre>In Aave V3, <code>repay()</code> returns the actual amount repaid and caps repayment at the outstanding debt. If the caller supplies more than required, the surplus remains in the adaptor instead of being returned to the vault. This breaks the invariant that the adaptor should hold no funds. The stranded tokens would require a separate <code>PrvlAaveBorrow.sweepERC20()</code> call to recover.
<h3 id="recommendation-4">Recommendation</h3>
The amount returned by <code>repay()</code> should be captured, and any excess should be refunded to the vault in the same transaction:
<pre tabindex="0" class="chroma"><code>uint256 repaid = aave.repay(config.baseToken, repayAmount, config.aaveVariableRate, msg.sender);
if (repayAmount > repaid) {
 ERC20(config.baseToken).transfer(msg.sender, repayAmount - repaid);
}
</code></pre><h3 id="client-response-4">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-006"></a><h2 id="io-prv-aps-006-missing-safetransferlib-limits-token-compatibility" class="break-before">IO-PRV-APS-006 Missing SafeTransferLib limits token compatibility</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol">PrvlAaveBorrow.sol</a></td>
</tr>
</tbody>
</table>
<code>PrvlAaveBorrow</code> uses Solmate’s <code>ERC20</code> for all <code>transfer</code>, <code>transferFrom</code>, and <code>approve</code> calls but does not use <code>SafeTransferLib</code>. Solmate’s <code>ERC20</code> ABI-decodes return data as <code>bool</code>, which reverts when a token returns no data (0 bytes). Some ERC-20 tokens, most notably USDT, return <code>void</code> on these functions.
Fork tests confirm all current production tokens (WETH, USDC, wstETH, aWstETH, variableDebtWETH) return <code>bool</code> and work correctly. If a future <code>setTokenConfig</code> attempts to register a non-standard token, the transaction reverts unconditionally – this is a denial of service (broken config), not a fund-loss vector.
<h3 id="recommendation-5">Recommendation</h3>
The ERC20 return value requirement should be documented on <code>setTokenConfig</code>. Using <code>SafeTransferLib</code> should be considered for forward compatibility.
<h3 id="client-response-5">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-007"></a><h2 id="io-prv-aps-007-missing-quoter-zero-check" class="break-before">IO-PRV-APS-007 Missing quoter zero-check</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/micro-managers/PrvlFlashloanAaveBorrowV5.sol#L47-L78">PrvlFlashloanAaveBorrowV5.sol#L47-L78</a></td>
</tr>
</tbody>
</table>
The <code>PrvlFlashloanAaveBorrowV5</code> constructor validates that all addresses are non-zero except for <code>_quoter</code>. If <code>_quoter</code> is <code>address(0)</code>, the contract deploys successfully but <code>PrvlFlashloanAaveBorrowV5.borrow()</code> permanently reverts since it calls <code>quoter.quoteExactInput()</code> in <code>getBorrowUserData()</code>. The <code>repay()</code> and <code>settle()</code> functions still work since <code>getRepayUserData()</code> does not use the quoter.
Since <code>quoter</code> is <code>immutable</code>, a misconfigured deployment cannot be fixed and must be redeployed.
<h3 id="recommendation-6">Recommendation</h3>
The <code>_quoter</code> parameter should be added to the zero-address validation for consistency with other parameters.
<h3 id="client-response-6">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlFlashloanAaveBorrowV5</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-008"></a><h2 id="io-prv-aps-008-missing-authority-zero-check" class="break-before">IO-PRV-APS-008 Missing authority zero-check</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L80-L94">PrvlAaveBorrow.sol#L80-L94</a></td>
</tr>
</tbody>
</table>
The <code>PrvlAaveBorrow</code> constructor validates <code>_owner</code>, <code>_uniswapV3Router</code>, <code>_aave</code>, and <code>_vault</code> for zero address, but does not validate <code>_authority</code>:
<pre tabindex="0" class="chroma"><code>constructor(
 address _owner,
 address _authority, // NOT zero-checked
 address _uniswapV3Router,
 address _aave,
 address _vault
) Auth(_owner, Authority(_authority)) {
 if (_owner == address(0)) revert PrvlAaveBorrow__invalidZeroAddress();
 if (_uniswapV3Router == address(0)) revert PrvlAaveBorrow__invalidZeroAddress();
 if (_aave == address(0)) revert PrvlAaveBorrow__invalidZeroAddress();
 if (_vault == address(0)) revert PrvlAaveBorrow__invalidZeroAddress();
 // _authority not checked
</code></pre>With <code>authority == address(0)</code>, the first condition in Solmate’s <code>isAuthorized()</code> is always false, so only <code>user == owner</code> grants access. This means vault functions cannot be called by the vault via <code>RolesAuthority</code>, rendering the adaptor unusable by the vault system.
<h3 id="recommendation-7">Recommendation</h3>
The <code>_authority</code> parameter should be added to the zero-address validation for consistency with other parameters.
<h3 id="client-response-7">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-009"></a><h2 id="io-prv-aps-009-repay-amountin-not-validated-against-supplyamount" class="break-before">IO-PRV-APS-009 repay() amountIn not validated against supplyAmount</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/micro-managers/PrvlFlashloanAaveBorrowV5.sol#L156-L158">PrvlFlashloanAaveBorrowV5.sol#L156-L158</a></td>
</tr>
</tbody>
</table>
In <code>PrvlFlashloanAaveBorrowV5.repay()</code>, the caller provides three independent parameters: <code>borrowAmount</code>, <code>supplyAmount</code>, and <code>exactInputParams</code>. The function passes these directly to <code>getRepayUserData()</code> without validating their coherence. The repay flow is:
<ol>
<li>Repay <code>borrowAmount</code> of debt to Aave</li>
<li>Withdraw <code>supplyAmount</code> of collateral (deposit token) from Aave</li>
<li>Swap the withdrawn deposit token to base token using <code>exactInputParams</code></li>
</ol>
For the swap to consume all withdrawn collateral, <code>exactInputParams.amountIn</code> should equal <code>supplyAmount</code>. However, there is no validation that this is the case. Mismatched values would either cause a revert (safe failure) or leave unused tokens in the vault.
<h3 id="recommendation-8">Recommendation</h3>
Validation should be added to ensure <code>exactInputParams.amountIn</code> equals <code>supplyAmount</code>.
<h3 id="client-response-8">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlFlashloanAaveBorrowV5</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-010"></a><h2 id="io-prv-aps-010-settle-amountin-unknowable-due-to-interest-accrual" class="break-before">IO-PRV-APS-010 settle() amountIn unknowable due to interest accrual</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/micro-managers/PrvlFlashloanAaveBorrowV5.sol#L162-L166">PrvlFlashloanAaveBorrowV5.sol#L162-L166</a></td>
</tr>
</tbody>
</table>
In <code>PrvlFlashloanAaveBorrowV5.settle()</code>, the function withdraws all collateral using <code>type(uint256).max</code> but requires the caller to provide <code>exactInputParams.amountIn</code> for the subsequent swap:
<pre tabindex="0" class="chroma"><code>function settle(DecoderCustomTypes.ExactInputParamsRouter02 calldata exactInputParams)
 external requiresAuth
{
 uint256 debtAmount = ERC20(debtToken).balanceOf(boringVault);
 bytes memory innerUserData = getRepayUserData(
 type(uint256).max, type(uint256).max, exactInputParams
 );
 _executeFlashloan(innerUserData, debtAmount.mulDivDown(105, 100));
}
</code></pre>The actual collateral amount withdrawn depends on the aToken balance at execution time, which accrues interest block by block. The caller must provide <code>amountIn</code> before knowing the exact withdrawal amount.
If <code>amountIn</code> is less than the actual withdrawn amount, some deposit token remains unused in the vault after the swap. If <code>amountIn</code> is greater than the actual withdrawn amount, the swap reverts.
<h3 id="recommendation-9">Recommendation</h3>
It should be documented that <code>settle()</code> may leave dust and require a follow-up sweep operation. Alternatively, the aToken balance should be read and validated against the provided <code>amountIn</code>.
<h3 id="client-response-9">Client response</h3>
Closed due to the removal of the legacy file <code>PrvlFlashloanAaveBorrowV5</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.
<a name="IO-PRV-APS-011"></a><h2 id="io-prv-aps-011-foundry-key-management" class="break-before">IO-PRV-APS-011 Foundry key management</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-open">Open</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/tree/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions">script/Permissions/</a></td>
</tr>
</tbody>
</table>
The permission scripts load private keys from a <code>.env</code> file to sign messages as the Paravel deployer. This approach requires the private key to be exported from the wallet and stored in plain text on the host machine. If the host were compromised, an attacker would have direct access to the key.
<h3 id="recommendation-10">Recommendation</h3>
Foundry’s <a href="https://getfoundry.sh/guides/best-practices/key-management/">key management best practices</a> support hardware wallets for signing messages. This approach is more robust, as the private key is not exported from the hardware device; instead, Foundry constructs the message, sends it to the wallet for signing, and receives the signed output.
<h1 id="code-quality-improvement-suggestions">Code quality improvement suggestions</h1>
Code improvement suggestions without security implications are listed below.
<table class="codequality">
<thead>
<tr>
<th>ID</th>
<th>Location</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>IO-PRV-APS-012</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/micro-managers/PrvlFlashloanAaveBorrowV5.sol#L38">PrvlFlashloanAaveBorrowV5.sol#L38</a></td>
<td><code>PrvlFlashloanAaveBorrowV5</code> defines <code>MAX_SLIPPAGE = 0.1e4</code>, which is never referenced anywhere in the contract. This creates the misleading impression that slippage is bounded. The unused constant should be removed or actual slippage validation should be implemented.</td>
</tr>
<tr>
<td>IO-PRV-APS-013</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/micro-managers/PrvlFlashloanAaveBorrowV5.sol#L77">PrvlFlashloanAaveBorrowV5.sol#L77</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L206">PrvlAaveBorrow.sol#L206</a></td>
<td>When setting the <code>aaveVariableRate</code> in the <code>PrvlFlashloanAaveBorrowV5</code> constructor and <code>PrvlAaveBorrow.setTokenConfig()</code>, the value should be confirmed to be <code>2</code> for variable rates. Other values are <a href="https://aave.com/docs/aave-v3/smart-contracts/pool#write-methods-borrow-input-parameters">invalid</a> for Paravel vaults.</td>
</tr>
<tr>
<td>IO-PRV-APS-014</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/src/adaptors/PrvlAaveBorrow.sol#L241-L243">PrvlAaveBorrow.sol#L241-L243</a></td>
<td>The <code>PrvlAaveBorrow.sweepERC20()</code> function transfers tokens to the vault but does not emit an event. All other state-changing functions emit events, making this an inconsistency. A <code>TokensSwept</code> event should be added.</td>
</tr>
<tr>
<td>IO-PRV-APS-015</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/AddAgentTeamPermmisons.s.sol">AddAgentTeamPermmisons.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlPermisionsMainnetUSDC.s.sol#L47">SetPrvlPermisionsMainnetUSDC.s.sol#L47</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlPermisionsMainnetWETH.s.sol#L46">SetPrvlPermisionsMainnetWETH.s.sol#L46</a></td>
<td>Several file names contain typos (e.g. “Permmisons” → “Permissions”, “Permisions” → “Permissions”). Additionally, “custome” should be “custom” in <code>SetPrvlPermisionsMainnetUSDC.s.sol</code> (L47) and <code>SetPrvlPermisionsMainnetWETH.s.sol</code> (L46).</td>
</tr>
<tr>
<td>IO-PRV-APS-016</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/tree/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions">script/Permissions/</a></td>
<td>All deployed contract addresses and role constants are declared independently within each script, with no shared constants file. This design has poor readability and is likely to cause copy-paste errors. A shared constants contract should be created and inherited by all scripts.</td>
</tr>
<tr>
<td>IO-PRV-APS-017</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/tree/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions">script/Permissions/</a></td>
<td>Scripts could be organised into subdirectories based on the target chain (e.g., <code>mainnet/</code>, <code>sepolia/</code>, <code>local/</code>). If scripts are intended to be executed in a specific order, a number could be appended to indicate sequence, or the sequence could be consolidated into a monolithic script.</td>
</tr>
<tr>
<td>IO-PRV-APS-018</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlPermisionsMainnetUSDC.s.sol">SetPrvlPermisionsMainnetUSDC.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlPermisionsMainnetWETH.s.sol">SetPrvlPermisionsMainnetWETH.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlAgentPermisionsMainnetForkUSDC.s.sol">SetPrvlAgentPermisionsMainnetForkUSDC.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlAgentPermisionsSepoliaUSDC.s.sol">SetPrvlAgentPermisionsSepoliaUSDC.s.sol</a></td>
<td>Variables already typed as <code>address</code> are unnecessarily wrapped in <code>address()</code> when passed to <code>setUserRole()</code> in <code>SetPrvlPermisionsMainnetUSDC.s.sol</code>, <code>SetPrvlPermisionsMainnetWETH.s.sol</code>, <code>SetPrvlAgentPermisionsMainnetForkUSDC.s.sol</code>, and <code>SetPrvlAgentPermisionsSepoliaUSDC.s.sol</code>. The redundant casts should be removed.</td>
</tr>
<tr>
<td>IO-PRV-APS-019</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/TransferAuths.s.sol">TransferAuths.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/SetPrvlPermisionsMainnetUSDC.s.sol">SetPrvlPermisionsMainnetUSDC.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/RemoveTestAddress.s.sol">RemoveTestAddress.s.sol</a></td>
<td>Several scripts contain unused variables and imports: <code>TransferAuths.s.sol</code> has an unused <code>testAddress</code> variable; <code>SetPrvlPermisionsMainnetUSDC.s.sol</code> has an unused <code>BoringSolver</code> import; <code>RemoveTestAddress.s.sol</code> has an unused <code>updatedUserRoles</code> variable (missing verification check); and multiple files contain unused <code>Authority</code> and <code>StdJson</code> imports.</td>
</tr>
<tr>
<td>IO-PRV-APS-020</td>
<td><a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/GrantStrategistMultisigRole.s.sol">GrantStrategistMultisigRole.s.sol</a>, <a href="https://github.com/ParavelDAO/boring-vault/blob/b5154a8f2978681b7d3f25fda16e2d3cef4f3f6d/script/Permissions/GrantAgentAuthorityRole.s.sol">GrantAgentAuthorityRole.s.sol</a></td>
<td><code>GrantStrategistMultisigRole.s.sol</code> and <code>GrantAgentAuthorityRole.s.sol</code> have network selection logic in <code>setUp()</code> but <code>run()</code> uses hardcoded addresses that ignore the selection. A helper function <code>getRolesAuthorityAddress()</code> exists but is never called. The helper function should be used in <code>run()</code>, or the network selection logic should be removed entirely.</td>
</tr>
</tbody>
</table>
<h3 id="client-response-10">Client response</h3>
<dl>
<dt>IO-PRV-APS-012</dt>
<dd>Closed due to the removal of the legacy file <code>PrvlFlashloanAaveBorrowV5</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.</dd>
<dt>IO-PRV-APS-013</dt>
<dd>Closed due to the removal of the legacy files <code>PrvlFlashloanAaveBorrowV5</code>, and <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.</dd>
<dt>IO-PRV-APS-014</dt>
<dd>Closed due to the removal of the legacy file <code>PrvlAaveBorrow</code> in <a href="https://github.com/ParavelDAO/prvl-protocol/commit/56629206dd336503416822c91e87d4fac4e9ec90"><code>5662920</code></a>.</dd>
<dt>IO-PRV-APS-015</dt>
<dd>Open.</dd>
<dt>IO-PRV-APS-016</dt>
<dd>Open.</dd>
<dt>IO-PRV-APS-017</dt>
<dd>Open.</dd>
<dt>IO-PRV-APS-018</dt>
<dd>Open.</dd>
<dt>IO-PRV-APS-019</dt>
<dd>Open.</dd>
<dt>IO-PRV-APS-020</dt>
<dd>Open.</dd>
</dl>
<h1 id="specification">Specification</h1>
The following section outlines the system’s intended functionality at a high level, based on its implementation in the codebase. Any perceived points of conflict should be highlighted with the auditing team to determine the source of the discrepancy.
<h2 id="system-architecture">System architecture</h2>
The Paravel protocol uses a two-tier vault architecture built on the Boring Vault framework. End users deposit into client vaults (e.g., iPrvlWETH, iPrvlUSDC), which allocate capital to agent vaults via cross-vault transfers. Agent vaults execute DeFi strategies – primarily leveraged Aave V3 lending positions with Uniswap V3 swaps.
All vault operations are gated by Solmate’s <code>Auth</code> and <code>RolesAuthority</code>. Each vault instance has its own <code>RolesAuthority</code> contract. The <code>ManagerWithMerkleVerification</code> contract restricts vault operations via merkle proofs, where each leaf encodes a decoder/sanitizer address, a target contract, whether ETH can be sent, a function selector, and packed address arguments.
<h2 id="prvlaaveborrow">PrvlAaveBorrow</h2>
<code>PrvlAaveBorrow</code> was a standalone adaptor contract that handled Aave V3 supply/borrow leverage positions with Uniswap V3 swaps. It inherited Solmate’s <code>Auth</code> for access control and <code>ReentrancyGuard</code>.
The call flow was: Strategist → <code>ManagerWithMerkleVerification</code> → <code>BoringVault.manage()</code> → <code>PrvlAaveBorrow</code>.
The adaptor supported multiple token pairs via a <code>tokenConfigs</code> mapping. Each <code>TokenConfig</code> stored the base token (borrowed asset, e.g., WETH), deposit token (collateral, e.g., wstETH), Aave aToken/debtToken addresses, interest rate mode, and Uniswap V3 swap paths. The config ID was a deterministic hash of the four token addresses.
The three core functions were:
<dl>
<dt><code>supply()</code></dt>
<dd>Opened or increased a leveraged position. Pulled base token from the vault, swapped to deposit token via Uniswap V3, supplied to Aave as collateral on behalf of the vault, borrowed base token from Aave on behalf of the vault, and returned borrowed tokens to the vault.</dd>
<dt><code>reducePosition()</code></dt>
<dd>Partially unwound a position. Pulled base token, repaid Aave debt, pulled aTokens, withdrew collateral from Aave, swapped deposit token back to base token and returned it to the vault.</dd>
<dt><code>settle()</code></dt>
<dd>Fully closed a position. Dynamically read the vault’s current debt and collateral balances, repaid all debt, withdrew all collateral, and swapped everything back to base token.</dd>
</dl>
Admin functions (<code>setTokenConfig</code>, <code>removeTokenConfig</code>, <code>sweepERC20</code>) managed the token configuration registry and handled emergency token recovery.
The adaptor transiently held tokens during operations – all tokens started and ended in the <code>BoringVault</code>. The vault must have pre-approved the adaptor for base token and aToken transfers, and must have called <code>approveDelegation()</code> on the Aave debt token to allow the adaptor to borrow on its behalf.
<h2 id="prvlflashloanaaveborrowv5">PrvlFlashloanAaveBorrowV5</h2>
<code>PrvlFlashloanAaveBorrowV5</code> extended <code>UManager</code> and used Balancer flash loans to execute the full leverage loop atomically. Unlike <code>PrvlAaveBorrow</code>, this contract stored merkle proofs on-chain via six setter functions and supported a single token pair per deployment (all token addresses were immutable).
The call flow involved two-level merkle verification: an outer proof authorized the vault to call <code>Manager.flashLoan()</code>, and inner proofs authorized the actual DeFi operations (swap, supply, borrow or repay, withdraw) that executed inside the flashloan callback.
The three core functions (<code>borrow</code>, <code>repay</code>, <code>settle</code>) each constructed nested calldata and executed it via <code>_executeFlashloan()</code>, which in turn called <code>manager.manageVaultWithMerkleVerification()</code>.
Both <code>PrvlAaveBorrow</code> and <code>PrvlFlashloanAaveBorrowV5</code> were removed during the audit. In the current production architecture, borrow, repay, and settle operations are composed off-chain and submitted directly to the vault via <code>manageVaultWithMerkleVerification</code> on <code>ManagerWithMerkleVerification.sol</code>. The merkle root, which is maintained by the team multisig / Vault System Owner, governs which operations are permitted. No on-chain adaptor currently fulfils this role.
<h2 id="permission-scripts">Permission scripts</h2>
Twelve Foundry scripts in <code>script/Permissions/</code> configure the protocol’s role-based access control system. These scripts grant roles such as <code>OWNER_ROLE</code>, <code>UPDATE_EXCHANGE_RATE_ROLE</code>, and <code>DEPOSITOR_VAULT_ROLE</code> primarily to Gnosis Safe multisig addresses and set role capabilities on target contracts. The mainnet permission scripts (<code>SetPrvlPermisionsMainnetUSDC.s.sol</code>, <code>SetPrvlPermisionsMainnetWETH.s.sol</code>) are the primary production scripts, while others handle testnet deployments, role grants, and administrative operations.

</article>
</main>
</div>

‍

Secure your system.

Request a service

Start Now →