Omniscia vfat Audit
Sickle Contracts Security Audit
Audit Report Revisions
Commit Hash | Date | Audit Report Hash |
---|---|---|
2eb579e976 | January 30th 2025 | 5fb2f6955a |
6ab7af3bb4 | April 17th 2025 | b89be78281 |
986c6b0a71 | April 22nd 2025 | 26e9cbeb74 |
73206ba3b5 | April 24th 2025 | f4402e2fef |
Audit Overview
We were tasked with performing an audit of the vfat codebase and in particular their Sickle Contracts system.
The vfat codebase is composed of multiple modules that are all combined to result in a multi-DeFi interacting vault-like system.
At its core, a Sickle implementation is deployed with an owner and an approved member that acts as the smart contract which integrates with several lending, borrowing, AMM, staking, and liquidity management protocols to offer a one-fits-all solution to vfat's userbase.
To achieve this, several logic implementations are invoked via a Sickle using delegatecall
operations so as to execute the code of each logic component as if it were present in the Sickle contract's codebase itself.
Sickles are not directly interacted with and are instead called via several implementations called "strategies" that couple multi-call delegatecall
payloads that permit a Sickle to execute a predefined set of operations, such as depositing to a protocol or withdrawing liquidity from one.
As each DeFi protocol requires a unique approach to be integrated, the system contains the notion of "connectors" that represent logic implementations permitting a particular Sickle to interact with a specific DeFi system.
In detail, the vfat codebase presently supports the following connector types:
- Farm Connectors: Permitting staking and unstaking interactions with staking protocols, such as Masterchef V2
- Liquidity Connectors: Permitting liquidity provisioning and management with AMM protocols, such as Uniswap V2
The above connector types also possess NFT variants that support the same operations albeit via NFT positions to support protocols that make use of them, like Uniswap V3.
Over the course of the audit, we validated all connectors have been properly implemented to integrate with the DeFi protocol they intend to by utilizing publicly available information about the DeFi protocols involved, their documentation, codebase, as well as deployed smart contract code.
Specifically, we validated the following integrations:
- Uniswap V2 (incl. Pancakeswap variant)
- Uniswap V3 (incl. Pancakeswap variant)
- Compound
- Velodrome Finance (incl. Slipstream & Superchain products)
- Aerodrome Finance
- Ramses Exchange (incl. gauges)
- Nuri Exchange (incl. gauges)
- Equalizer Exchange (incl. gauges)
- Masterchef V2 (incl. w/ support for a referral address)
- Masterchef V3
- Morpho
- Velocore
Beyond the above protocols, we were tasked with validating flash-loan integrations with the following systems:
- Aave V2
- Aave V3
- Balancer V2
- Uniswap V2
- Uniswap V3
- Morpho
- Quickswap
Over the course of the audit, we were able to identify a latent race-condition vulnerability involving the approved address of a Sickle that can manifest due to an improperly exposed function, an inexistent approval operation for Velodrome-like systems, an incorrect integration of Equalizer Exchange gauge implementations, as well as several issues around fees that permit them to be bypassed.
As high-level criticism, we would like to outline that any interaction via the designated strategies of the system usually involves the invocation and utilization of flash-loans that significantly complicates call-flows.
While the de-coupling of the flash-loan logic to a distinct implementation is welcome, the dynamicity supported in callback mechanisms significantly complicates the deciphering of the codebase with little benefit as we have demonstrated the codebase relies on specific callback types (as evidenced by the Uniswap-like decoding mechanisms).
We advise the vfat team to closely evaluate all minor-and-above findings identified in the report and promptly remediate them as well as consider all optimizational exhibits identified in the report.
Post-Audit Conclusion
The vfat team iterated through all findings within the report and provided us with a revised commit hash to evaluate all exhibits on.
We evaluated all alleviations performed by vfat and have identified that certain exhibits have not been adequately dealt with. We advise the vfat team to revisit the following exhibits: SMG-01M
, FSG-03M
Additionally, the following informational
findings remain partially addressed and should be revisited: FSG-01C
, NSR-01C
, VGR-01C
Post-Audit Conclusion (986c6b0a71)
The vfat team evaluated our follow-up alleviations in the aforementioned exhibits, and proceeded to provide either an alleviation or response for each one.
We introduced additional information for exhibit FSG-03M
per the vfat team's request, and assessed that exhibit VGR-01C
has not been addressed as advised at the time this revision of the report was generated.
Post-Audit Conclusion (73206ba3b5)
The vfat team assessed our clarifications on exhibit FSG-03M
as well as our follow-up recommendation on VGR-01C
which we collaboratively discussed.
Both exhibits have been addressed fully in alignment with our recommendations in the latest commit hash evaluated within the audit report.
To note, the delta between the latest commit hash and the second-to-last commit hash is larger than what the aforementioned two changes would entail.
For the purposes of this audit, we solely evaluated the code delta of the two relevant files to ensure the fixes have been appropriately applied.
We consider all outputs of the audit report properly consumed by the vfat team with no outstanding remediative actions remaining.
Audit Synopsis
Severity | Identified | Alleviated | Partially Alleviated | Acknowledged |
---|---|---|---|---|
![]() | 2 | 0 | 0 | 2 |
![]() | 121 | 30 | 0 | 91 |
![]() | 8 | 5 | 0 | 3 |
![]() | 9 | 4 | 0 | 5 |
![]() | 6 | 5 | 0 | 1 |
During the audit, we filtered and validated a total of 82 findings utilizing static analysis tools as well as identified a total of 64 findings during the manual review of the codebase. We strongly recommend that any minor severity or higher findings are dealt with promptly prior to the project's launch as they can introduce potential misbehaviours of the system as well as exploits.
Total Alleviations
The list below covers each segment of the audit in depth and links to the respective chapter of the report: