SuperReturn A-1

The purpose of BoringVaultSCVersion is to make the boring vault compatible with the SuperchainERC20 standard. To achieve this, it must implement the ERC-7802 standard, which states:

Implementors MUST ensure that the supportsInterface method of ERC-165 returns true for this interface ID to indicate support for IERC7802.

Currently, BoringVaultSCVersion lacks an explicit supportsInterface function implementation.

Remediation to Consider

Implement a supportsInterface function that returns true for the following interface ids:

• type(IERC7802).interfaceId
• type(IERC20).interfaceId
• type(IERC165).interfaceId
• type(IERC1155Receiver).interfaceId
• type(IERC721Receiver).interfaceId

In MorphoDecoderAndSanitizer, the deposit and withdraw functions accept adapterId as their first parameter. The Morpho Router uses this ID to retrieve the adapter's address from its adapters array. Because each adapter controls its own deposit token and the adapterId lacks proper sanitization in the decoder, the boring vault cannot effectively restrict which tokens are permitted for deposits.

Remediation to Consider

Retrieve the adapter's address directly from the Router's public adapters array. Use this address to obtain the depositToken and implement proper address sanitization in the decoder.

In BoringOnChainQueue.sol, the event WithdrawAssetUpdated is defined with this parameter order:

event WithdrawAssetUpdated(
    address indexed assetOut,
    uint24 minimumSecondsToDeadline,
    uint24 secondsToMaturity,
    uint16 minDiscount,
    uint16 maxDiscount,
    uint96 minimumShares
);

Source: BoringOnChainQueue.sol#L167-L174

However, when emitting this event, the updateWithdrawAsset function swaps the order of parameters:

emit WithdrawAssetUpdated(  
    assetOut, secondsToMaturity, minimumSecondsToDeadline, minDiscount, maxDiscount, minimumShares
);

Source: BoringOnChainQueue.sol#L300-L302

The second and third arguments (secondsToMaturity and minimumSecondsToDeadline) are in the wrong order.

Remediation to Consider

Correct the parameter order in the updateWithdrawAsset function to match the event definition.

The AcrossDecoderAndSanitizer implements the depositV3 function, which accepts destinationChainId as its 7th parameter. While the function properly sanitizes all address parameters, it does not validate destinationChainId. Adding this validation would allow the boring vault to control the destination chain where assets can be bridged to.

Remediation to Consider

Add sanitization for the parameter destinationChainId.

In its current state, the project fails to compile. Running forge compile —skip test produces this error:

Error: Encountered invalid solc version in lib/openzeppelin-contracts-upgradeable/contracts/proxy/utils/UUPSUpgradeable.sol: 
No solc version exists that matches the version requirement: ^0.8.22

This error stems from a Solidity version mismatch. The project uses the latest version (v5.3.0) of openzeppelin-contracts-upgradeable, which requires pragma solidity ^0.8.22;, while the boring vault contracts specify pragma solidity 0.8.21;.

Remediation to Consider

To resolve this, either downgrade openzeppelin-contracts-upgradeable to v5.1 (which uses Solidity 0.8.21) or upgrade the boring vault contracts to Solidity 0.8.22.

Both, the BoringVault and BoringVaultSCVersion use different types of storage patterns. They inherit from Auth, which uses regular (sequential) storage, while also inheriting from ERC20Upgradable, which uses unstructured storage. This mixed pattern could cause storage collisions during contract upgrades, so extra caution is needed when upgrading these contracts.

The integrated protocols used by the boring vault for yield generation—OpenEden, Across, Sake, and Morpho—must be trustworthy. A critical security measure is ensuring that the protocol’s owner or other privileged users implement proper multisig setups to eliminate single points of failure.

Analysis of deployed contracts shows that among these protocols, only Across has implemented a proper 3/5 multisig setup. OpenEden on mainnet and Sake on Soneium both use single EOA accounts as owners, which requires extra caution when using these protocols. Furthermore, the Morpho mainnet address uses a different contract than the testnet (Sepolia) version, making the current MorphoDecoderAndSanitizer incompatible with the provided mainnet address.

A detailed breakdown of the supported protocols, their production addresses and their roles is shown below:

OpenEden

Addresses: mainnet → 0x80e49d1bdce8f80c38e88dd5c4c004ddb9b4e887

Roles: owner → EOA

Capability: upgrade, pause minting/redeeming, change configuration settings

Across

Addresses: mainnet → 0x5c7BCd6E7De5423a257D81B442095A1a6ced35C5, soneium → 0x3baD7AD0728f9917d1Bf08af5782dCbD516cDd96

Roles: owner → 3/5 multisig

Capability: upgrade, pause deposits, change configuration settings

Sake

Addresses: soneium → 0x3C3987A310ee13F7B8cBBe21D97D4436ba5E4B5f

Roles: owner → EOA

Capability: upgrade

Morpho

Addresses: mainnet → 0x6566194141eefa99Af43Bb5Aa71460Ca2Dc90245