VFAT is a yield aggregator that uses the Sickle smart contract wallet for yield farming. It reduces complex operations such as entering and exiting positions, compounding, or rebalancing, into single transactions.
VFAT engaged Ackee Blockchain Security to perform a security review of the VFAT protocol with a total time donation of 18 engineering days in a period between March 4 and March 28, 2025. A second security review then focused on the fixes of issues found in the first security review; no other code changes were audited.
We thank Optimism for approving a grant that partly funded this and an upcoming second audit of VFAT.
METHODOLOGY
We began our review using static analysis tools, including Wake. We then took a deep dive into the logic of the contracts.
During the review, we paid special attention to:
- ensuring the arithmetic of the system is correct;
- detecting possible reentrancies in the code;
- checking the safety of delegatecall usage;
- ensuring access controls are not too relaxed or too strict;
- checking the correctness of the upgradeability implementation; and
- looking for common issues such as data validation.
SCOPE
The first audit was performed on the commit 357593f and the scope was the following:
contracts/Automation.solcontracts/ConnectorRegistry.solcontracts/NftSettingsRegistry.solcontracts/PositionSettingsRegistry.solcontracts/Sickle.solcontracts/SickleFactory.solcontracts/SickleRegistry.solcontracts/governance/SickleMultisig.solcontracts/libraries/FeesLib.solcontracts/libraries/NftSettingsLib.solcontracts/libraries/NftTransferLib.solcontracts/libraries/PositionSettingsLib.solcontracts/libraries/SwapLib.solcontracts/libraries/TransferLib.sol
For completeness, it was also necessary to review the following parent contracts:
base/Admin.solbase/Multicall.solbase/NonDelegateMulticall.solbase/SickleStorage.solbase/TimelockAdmin.sol
The fix review was done on the given commit 1c20e7e.
FINDINGS
The classification of a security finding is determined by two ratings: impact and likelihood. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as medium severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the Warning or Informational severity ratings.
Our review resulted in 31 findings, ranging from Informational to High severity. The most severe finding H1 would allow an admin (malicious or compromised) to drain all user wallets. The medium severity issue M1 allows front-running of the setReferralCode function. Most findings are warnings that point to various missing validations, code quality issues, and best practices violations.
The second security review was limited to issues found in the first security review and no other code changes were audited. 20 issues were fixed, 3 issues fixed partially, 7 issues acknowledged, and H1 was invalidated by VFAT. Read the finding details in the full audit report linked at the end of the article.
Critical severity
No critical severity issues were found.
High severity
H1: Whitelisted callers can perform delegatecall on every Sickle
Medium severity
M1: Referral code setter can be front-run
Low severity
L1: Non-contract registries can cause reverts
Warning severity
W1: Incomplete data validation for NFT positions
W2: Duplicate Sickle retrieval
W3: Potential underflow or overflow in tick range calculation
W4: Variable shadowing
W5: Insufficient data validation in the PositionSettingsRegistry contract
W6: Incorrect price calculation in PositionSettingsRegistry
W7: Incorrect usage of Initializable
W8: Variable naming convention
W9: One-step ownership transfer
W10: Duplicate tokens in feeTokens array can lead to inconsistent fee calculation
W11: Inconsistent handling of ETH and WETH across the FeesLib contract
W12: Ambiguous handling of the native value in the SwapLib contract
W13: Misleading inheritance
W14: No input array length validation
W15: No data validation on registry adding and updates
W16: Missing zero address validation
Informational severity
I1: Duplicate code
I2: Usage of magic constants
I3: Unconsolidated storage variable definitions
I4: Redundant storage variable
I5: Mapping isCustomRegistry is redundant
I6: Inconsistent function naming convention
I7: Typographical error in function comment
I8: Misleading error name
I9: Unused errors
I10: Redundant function
I11: Missing duplicate registry validation
I12: Errors in documentation
TRUST MODEL
The protocol requires users to trust administrators who control critical parameters (fees, whitelists, Connector updates) and Automators who execute operations on their behalf. While users control their Sickle instances and position settings, the system maintains centralized control points. Trust risks are partially mitigated through hardcoded limits and multisig requirements; however, users must accept risks of centralized control and potential transaction manipulation by Automators who can control transaction timing.
CONCLUSION
Ackee Blockchain Security recommends VFAT to:
-
- set up off-chain monitoring for the purposes described in the M1 finding; and
- address all other reported issues.
Ackee Blockchain Security’s full VFAT Sickle audit report can be found here.
We were delighted to audit VFAT and look forward to working with them again.
