NEW YORK, 18/02/2021 - We’re happy to announce that Multiplier Finance’s latest implementation of smart-contracts was successfully audited by CertiK Professional Services Division. In this spotlight, we elaborate on the scope of the audit, as well as present some of the issues found during the auditing process.
MCL is a lending protocol with flash loan support on BSC, that allows users to deposit and borrow crypto.
Code Review & Auditor’s View
MCL is a lending protocol with flash loan support on BSC, that allows users to deposit and borrow crypto.The initial review was conducted between January 12th, 2021, and January 25th, 2021, by CertiK security engineers Alex Papageorgiou, and Adrian Hetman.
We were tasked with auditing Multiplier Finance, especially their changes made to the lending and staking mechanisms. The project is based on the AAVE protocol modules, such as the lending and safety modules for staking.
The Multiplier team provided documentation that helped with understanding the changes. Nothing major was found, however, we did advise the team to implement certain additional edge-test cases such as transfers to self to accommodate for the new rewarding mechanisms introduced. Code changes are documented and closely conform to the coding style and standards of the original AAVE codebase.
Over the course of the audit, we examined the delta between the AAVE and the Multiplier FinanceMCLcode in great detail, ensuring that the peculiar programming paradigms within AAVE's codebase were conformed to by the changes introduced in the linked repository.
To properly gauge the effect of the changes introduced by the Multiplier Finance team to the codebase, we also examined that the interfaces and inherent requirements of the various modules of the AAVE codebase new code interacts with are properly followed to ensure the expected behavior of the overall system.
We iterated over the new files using our suite of static analysis tools and additionally inspected the test coverage of the new repository to ensure edge cases that may introduce a vulnerability within the new code are accounted for. To this end, we contacted the Multiplier Finance team wherever applicable and informed them of ways they can expand their test suite coverage.
All changes that were carried out in theMCLcodebase bear close resemblance to the coding style of the AAVE codebase itself, ensuring an easily-comprehensible code adjustment that also innately follows the style guidelines of AAVE as well as its functional side effects, such as the Checks-Effects-Interactions pattern.
The following files contained minimal changes mostly related to configurations necessitated by the new functionality introduced. Additionally, some of these contracts were simplified by omitting functionality that was deemed unnecessary in the new version:
The LendingPool.sol and LendingPoolCore.sol contracts were adjusted to support the BNB token, as Multiplier Finance'sMCLis meant to be deployed on BinanceSmart Chain, and introduced a new restriction on borrowing whereby up to 99% of the available liquidity is able to be borrowed rather than 100%.
With regards to novel functionality, a new rewarding mechanism was introduced that replaces the protocol's fees and redistributes them to the users. To this end, we would like to note that the new code introduced beyond L1169 of the LendingPool.sol file conducts expensive iterative loops over the reserves of the protocol, thus prohibiting a large number of assets from being added as reserves to it.
The reward system introduced allows anyone to update the rewards of a specified address, however, it solely allows the owner of the rewards to claim them via the corresponding introduced methods. The LendingPoolLiquidationManager.sol was adjusted to accommodate for different-decimal assets in its calculateAvailableCollateralToLiquidate function to ensure support for any decimal currency exists for the said function.
Additionally, certain segments were adjusted to conform to the adaptations detailed above in LendingPool and LendingPoolCore . Within the CoreLibrary.sol, a function was introduced that aids in the newly introduced check of the Lending Pools to not exceed 99% of the available liquidity in borrows.
The StakedToken.sol implementation was adjusted to update the Governance-based fee reward mechanisms and accommodate for them prior to any adjustment in the users' balances, however, we would like to note that the implementation needs to re-invoke the updateGovernanceStakingRewards depending on the type of token set to be the STAKED_TOKEN as the reward mechanisms could rely on it.
The remaining 2 contracts contained solely configurational changes for the new reward mechanisms. Two new contracts have also been introduced to the codebase, namely:
The vault acts as a deposit address for rewards that are meant to be redeemed at a certain point in the future by users, whereas the reward manager contains the core logic for maintaining and accumulating user rewards based on the fees generated by the system. We would like to state that the reward manager contains a lot of strict required checks that ensure a specified reserve has been added to the set of reward pools on the contract, thus potentially breaking the full breadth of features theMCLcodebase provides if a reserve hasn't been added to the reward pools in time. For this purpose, we advise that whenever a reserve is added the reward manager is automatically informed instead of iterating over all reserves on each insertion.
Overall, the codebase can be considered to be of a high standard and no medium severity, and the above issues have been identified in the codebase.
The in-depth investigation of the smart contract in question included Static Analysis and Manual Review techniques. The auditing process focused on the following considerations:
- Testing smart contract against both common and uncommon attack vectors.
- Assessing the codebase to ensure compliance with current best practices and industry standards.
- Ensuring contract logic meets the specifications and intentions of the client.
- Cross-referencing contract structure and implementation against similar smart contracts produced by industry leaders.
- Through a line-by-line manual review of the entire codebase.
A total of eighteen (18) findings were identified and presented in the vulnerability summary, of which most (15) were of informational nature, and only (5) were minor. No major or critical issues were found during the auditing process, and the Multiplier team alleviated all findings highlighted by the CertiK Professional Services team, pointing towards a well-written codebase by the team’s engineers.
You can review the full audit here.
Multiplier began as a CEFI lender in 2019 before building DEFI protocols in 2020.
In Q1 2021, Multiplier will launch Multi-Chain Lend (MCL) on Binance Smart Chain.
Multi-Chain (Lend) is an algorithmic money market system designed to bring secure and unique lending and borrowing opportunities like flash loans onto the Binance Smart Chain.
The protocol designs are architected and forked based on Aave with revenue sharing components for liquidity providers and token holders that govern the protocol.
bMXX, a BEP-20 token, will be the governance token of Multi-Chain (Lend).
CertiK is an edge-standards cybersecurity firm founded by Computer Science professors hailing from Yale and Columbia University respectively, aiming to improve the security and correctness of smart contracts and blockchain protocols on a global scale.
Leveraging a seasoned team of multi-skilled engineers and security auditors, CertiK’s mission is to apply a plethora of high-level industry practices, covering the entire spectrum of static, manual, and dynamic analyses, in order to ensure each project subject to a formal audit is up-to-date with modern security standards while offering their services to the broader DLT community.
Over the past few years, CertiK has serviced more than 100 top-shelf blockchains, DeFi protocols, among other complex and/or custom smart contracts, including but not limited to Binance, Tera, Bancor, Shapeshift, and Blockstack.
Consult with one of our experts at firstname.lastname@example.org