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.
The protocol team engaged Ackee Blockchain Security to perform a security review of Farm Strategies smart contracts with a total time donation of 12 engineering days in a period between May 19 and June 3, 2025.
A second, fix review was performed of the fixes from the previous revision.
We thank Optimism for approving a grant that partly funded this and a previous 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 d85b2cd and the scope was the following:
contracts/connectors/uniswap/UniswapV3Connector.solcontracts/connectors/velodrome/SlipstreamGaugeConnector.solcontracts/connectors/velodrome/SlipstreamNftConnector.solcontracts/connectors/velodrome/VelodromeGaugeRegistry.solcontracts/strategies/FarmStrategy.solcontracts/strategies/MultiFarmStrategy.solcontracts/strategies/NftFarmStrategy.solcontracts/strategies/SweepStrategy.solcontracts/libraries/ZapLib.solcontracts/libraries/NftZapLib.sol
The focus of this audit was to review the integration of the protocol with external protocols Uniswap and Velodrome.
The second review was done on the given commit e5ff820. The scope of the second review was limited to the fixes of issues found in the previous revision and no other code changes were audited. 5 issues were fixed, 7 issues acknowledged by the client.
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 12 findings, ranging from Info to Medium severity. The most severe one was M1, which is a front-running issue through which users’ funds could be stolen by a malicious actor. However, the likelihood of this happening is low. Most findings are related to violations of best practices, code quality issues, and the trust model.
The second security review was limited to issues found in the first security review and no other code changes were audited.
Critical severity
No critical severity issues were found.
High severity
No high severity issues were found.
Medium severity
M1: Front-run of Sickle deployment gives an opportunity for attacker to specify arbitrary approved and referralCode arguments
Low severity
L1: The charge fee can be bypassed for several functions
Warning severity
W1: Withdrawal of funds can be blocked by Collector contract by not accepting tokens
W2: Connectors are a single point of failure
W3: Usage of function with inplace=True argument always fails in gauges that use NFTs
W4: Missing CompoundFor fee calculation
W5: block.timestamp is used for swap deadline
W6: Incorrect price calculation
Informational severity
I1: Missing NatSpec comments
I2: Potential incorrect fee calculation
I3: Unexpected revert in increase function
I4: Missing events in MultiFarmStrategy
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 recommended VFAT to:
- validate
approvedargument indepositfunctions if it equals toSickle.approved; - make trust model more permissionless;
- use
pricesfunction instead ofgetPoolPricefor price calculation; - read and review the complete audit report; and
- address all identified issues.
Ackee Blockchain Security’s full VFAT Farm Strategies audit report can be found here.
We were delighted to audit VFAT again, and look forward to working with them in the future.
