{"id":1047,"date":"2025-05-14T13:28:48","date_gmt":"2025-05-14T11:28:48","guid":{"rendered":"https:\/\/ackee.xyz\/blog\/?p=1047"},"modified":"2025-05-14T14:40:34","modified_gmt":"2025-05-14T12:40:34","slug":"vfat-sickle-audit-summary","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/vfat-sickle-audit-summary\/","title":{"rendered":"VFAT Sickle Audit Summary"},"content":{"rendered":"<p class=\"p1\">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.<\/p>\n<p class=\"p1\">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.<\/p>\n<p data-atomic=\"true\" data-lastedited=\"1747141043695\" data-sessionid=\"68027ef2-6bfb-4f57-8baf-6802692c40ad\" data-id=\"94c0f041-cf66-4cac-bc37-17fd7ad11df5\">We thank <a href=\"https:\/\/www.optimism.io\/\" target=\"_blank\" rel=\"noopener\">Optimism<\/a> for approving a grant that partly funded this and an upcoming second audit of VFAT.<\/p>\n<h2><span style=\"font-weight: 400;\">METHODOLOGY<\/span><\/h2>\n<p class=\"p1\">We began our review using static analysis tools, including <a href=\"https:\/\/getwake.io\">Wake<\/a>. We then took a deep dive into the logic of the contracts.<\/p>\n<p class=\"p1\">During the review, we paid special attention to:<\/p>\n<ul>\n<li class=\"p1\">ensuring the arithmetic of the system is correct;<\/li>\n<li class=\"p1\">detecting possible reentrancies in the code;<\/li>\n<li class=\"p1\">checking the safety of delegatecall usage;<\/li>\n<li class=\"p1\">ensuring access controls are not too relaxed or too strict;<\/li>\n<li class=\"p1\">checking the correctness of the upgradeability implementation; and<\/li>\n<li class=\"p1\">looking for common issues such as data validation.<\/li>\n<\/ul>\n<h2><span style=\"font-weight: 400;\">SCOPE<\/span><\/h2>\n<p>The first audit was performed on the commit <code class=\"codehl\">357593f<\/code> and the scope was the following:<\/p>\n<ul>\n<li><code class=\"codehl\">contracts\/Automation.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/ConnectorRegistry.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/NftSettingsRegistry.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/PositionSettingsRegistry.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/Sickle.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/SickleFactory.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/SickleRegistry.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/governance\/SickleMultisig.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/libraries\/FeesLib.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/libraries\/NftSettingsLib.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/libraries\/NftTransferLib.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/libraries\/PositionSettingsLib.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/libraries\/SwapLib.sol<\/code><\/li>\n<li><code class=\"codehl\">contracts\/libraries\/TransferLib.sol<\/code><\/li>\n<\/ul>\n<p>For completeness, it was also necessary to review the following parent contracts:<\/p>\n<ul>\n<li><code class=\"codehl\">base\/Admin.sol<\/code><\/li>\n<li><code class=\"codehl\">base\/Multicall.sol<\/code><\/li>\n<li><code class=\"codehl\">base\/NonDelegateMulticall.sol<\/code><\/li>\n<li><code class=\"codehl\">base\/SickleStorage.sol<\/code><\/li>\n<li><code class=\"codehl\">base\/TimelockAdmin.sol<\/code><\/li>\n<\/ul>\n<p>The fix review was done on the given commit <code class=\"codehl\">1c20e7e<\/code>.<\/p>\n<h2><span style=\"font-weight: 400;\">FINDINGS<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The classification of a security finding is determined by two ratings: <\/span><b>impact<\/b><span style=\"font-weight: 400;\"> and <\/span><b>likelihood<\/b><span style=\"font-weight: 400;\">. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as <\/span><i><span style=\"font-weight: 400;\">medium<\/span><\/i><span style=\"font-weight: 400;\"> severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the <em>W<\/em><\/span><i><span style=\"font-weight: 400;\">arning<\/span><\/i><span style=\"font-weight: 400;\"> or <em>I<\/em><\/span><i><span style=\"font-weight: 400;\">nformational<\/span><\/i><span style=\"font-weight: 400;\"> severity ratings.<\/span><\/p>\n<p class=\"p1\">Our review resulted in <strong>31 findings<\/strong>, 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 <code class=\"codehl\">setReferralCode<\/code> function. Most findings are warnings that point to various missing validations, code quality issues, and best practices violations.<\/p>\n<p>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.<\/p>\n<h3><span style=\"font-weight: 400;\">Critical severity<\/span><\/h3>\n<p>No critical severity issues were found.<\/p>\n<p>&nbsp;<\/p>\n<h3><span style=\"font-weight: 400;\">High severity<\/span><\/h3>\n<p>H1: Whitelisted callers can perform delegatecall on every Sickle<\/p>\n<p>&nbsp;<\/p>\n<h3><span style=\"font-weight: 400;\">Medium severity<\/span><\/h3>\n<p>M1: Referral code setter can be front-run<\/p>\n<p>&nbsp;<\/p>\n<h3><span style=\"font-weight: 400;\">Low severity<\/span><\/h3>\n<p>L1: Non-contract registries can cause reverts<\/p>\n<p>&nbsp;<\/p>\n<h3><span style=\"font-weight: 400;\">Warning severity<\/span><\/h3>\n<p>W1: Incomplete data validation for NFT positions<\/p>\n<p>W2: Duplicate Sickle retrieval<\/p>\n<p>W3: Potential underflow or overflow in tick range calculation<\/p>\n<p>W4: Variable shadowing<\/p>\n<p>W5: Insufficient data validation in the <code class=\"codehl\">PositionSettingsRegistry<\/code> contract<\/p>\n<p>W6: Incorrect price calculation in PositionSettingsRegistry<\/p>\n<p>W7: Incorrect usage of Initializable<\/p>\n<p>W8: Variable naming convention<\/p>\n<p>W9: One-step ownership transfer<\/p>\n<p>W10: Duplicate tokens in feeTokens array can lead to inconsistent fee calculation<\/p>\n<p>W11: Inconsistent handling of ETH and WETH across the FeesLib contract<\/p>\n<p>W12: Ambiguous handling of the native value in the SwapLib contract<\/p>\n<p>W13: Misleading inheritance<\/p>\n<p>W14: No input array length validation<\/p>\n<p>W15: No data validation on registry adding and updates<\/p>\n<p>W16: Missing zero address validation<\/p>\n<p>&nbsp;<\/p>\n<h3><span style=\"font-weight: 400;\">Informational severity<\/span><\/h3>\n<p>I1: Duplicate code<\/p>\n<p>I2: Usage of magic constants<\/p>\n<p>I3: Unconsolidated storage variable definitions<\/p>\n<p>I4: Redundant storage variable<\/p>\n<p>I5: Mapping <code class=\"codehl\">isCustomRegistry<\/code> is redundant<\/p>\n<p>I6: Inconsistent function naming convention<\/p>\n<p>I7: Typographical error in function comment<\/p>\n<p>I8: Misleading error name<\/p>\n<p>I9: Unused errors<\/p>\n<p>I10: Redundant function<\/p>\n<p>I11: Missing duplicate registry validation<\/p>\n<p>I12: Errors in documentation<\/p>\n<h2><span style=\"font-weight: 400;\">TRUST MODEL<\/span><\/h2>\n<p class=\"p1\">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.<\/p>\n<h2><span style=\"font-weight: 400;\">CONCLUSION<\/span><\/h2>\n<p class=\"p1\"><a href=\"https:\/\/ackee.xyz\">Ackee Blockchain Security<\/a> recommends VFAT to:<\/p>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li class=\"p1\">set up off-chain monitoring for the purposes described in the <span class=\"s1\">M1<\/span> finding; and<\/li>\n<li class=\"p1\">address all other reported issues.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>Ackee Blockchain Security\u2019s full VFAT Sickle audit report can be found <\/b><a href=\"https:\/\/github.com\/Ackee-Blockchain\/public-audit-reports\/blob\/master\/2025\/ackee-blockchain-vfat-sickle-report.pdf\"><b>here<\/b><\/a><b>.<\/b><\/p>\n<p><span style=\"font-weight: 400;\">We were delighted to audit VFAT and look forward to working with them again.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&hellip;<\/p>\n","protected":false},"author":30,"featured_media":1049,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,10,80,103],"tags":[21,89,24,104],"class_list":["post-1047","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-audits","category-ethereum","category-solidity","category-wake","tag-audit","tag-audit-summary","tag-ethereum","tag-wake"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2025\/05\/vfat-cover-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2025\/05\/vfat-cover-600x600.png","author_info":{"display_name":"Tom\u00e1\u0161 Kova\u0159\u00edk","author_link":"https:\/\/ackee.xyz\/blog\/author\/tomas-kovarik\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/1047","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=1047"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/1047\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/1049"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=1047"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=1047"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=1047"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}