Bank Of Chain Case Study

Introduction

Bank Of Chain sought the expertise of Shellboxes to undergo a rigorous security assessment. This assessment spanned from October 12th to December 4th, 2022. The primary objective of this evaluation was to identify and rectify potential vulnerabilities within the smart contracts of Bank Of Chain. By meticulously analyzing the alignment between the smart contract code and its design document, we aimed to uncover any semantic discrepancies that might exist. Furthermore, we provided recommendations to not only address security concerns but also to optimize the code for better performance and efficiency. The results of our assessment highlighted several areas where the smart contracts could benefit from enhancements, given the various security and performance issues identified.

About Bank Of Chain

Bank Of Chain, commonly referred to as BoC, stands as a beacon of innovation in the rapidly evolving decentralized finance (DeFi) landscape. Its primary mission is to empower everyday users with a wealth management tool on the blockchain that is as close to “risk-free” as possible. To achieve this, BoC meticulously integrates a range of handpicked protocols from the vast crypto universe. This includes, but is not limited to, Automatic Market Makers (AMMs), established lending protocols, and high-performing yield aggregators. Through these strategic collaborations, BoC aims to offer its users a seamless and secure financial experience on the blockchain.

Our Partnership

The collaboration between ShellBoxes and Bank Of Chain is a testament to the commitment both entities have towards ensuring the highest standards of security and functionality in the DeFi space. Recognizing the transformative potential of BoC in reshaping the financial landscape, ShellBoxes took on the responsibility of rigorously assessing and fortifying the platform’s underlying smart contract infrastructure. Our partnership was built on mutual respect, transparency, and a shared vision for a safer and more efficient decentralized financial ecosystem. Throughout the engagement, both teams worked closely, exchanging insights and expertise, to ensure that the BoC platform not only meets but exceeds industry standards. This partnership underscores the importance of combining innovative financial solutions with robust security measures to foster trust and drive adoption in the DeFi sector.

Auditing Approach

In the assessment of Bank Of Chain, the ShellBoxes team faced the intricate challenge of ensuring a comprehensive, precise, and efficient audit without compromising on depth or detail. To adeptly tackle this multifaceted task, a combination of manual and automated testing methodologies was employed. Manual testing was paramount for identifying discrepancies in logic, procedural flows, and execution sequences. It was instrumental in verifying that the protocol’s invariants aligned seamlessly with BoC’s business logic and were accurately represented in the code. Such meticulous scrutiny was crucial to ensure the timely identification and rectification of potential security vulnerabilities. Conversely, automated testing was leveraged to broaden the audit’s scope and swiftly detect any sections of the code that strayed from established security norms. This methodology enabled the ShellBoxes team to cover an expansive audit terrain and quickly spotlight potential security concerns. By synergizing these methodologies, the team struck a perfect balance of speed, precision, depth, and breadth, ensuring a holistic and rigorous security evaluation of Bank Of Chain.

Findings

Throughout the audit process, the BankOfChain team showcased exemplary professionalism and dedication. Their proactive approach, combined with thorough documentation, significantly streamlined the audit. It was evident that they prioritized security, as they swiftly addressed and rectified the majority of the identified vulnerabilities. While the smart contracts of BankOfChain are fundamentally well-architected and crafted, there remains room for enhancement in their implementation. The audit revealed a spectrum of vulnerabilities, categorized as follows:

• Critical-severity: 1 vulnerabilities
• High-severity: 5 vulnerabilities
• Medium-severity: 4 vulnerabilities
• Low-severity: 6 vulnerabilities
• Undetermined-severity: 1 vulnerabilities

We will delve deeper into each severity category to provide a detailed overview of the identified vulnerabilities.

Critical Findings

During the audit of Bank Of Chain’s smart contracts, a critical vulnerabilities was identified:

• Re-initialization Attacks: Multiple contracts in the Bank Of Chain’s architecture utilized the initialize method for state initialization. However, many convex strategy contracts lacked the initializer modifier, leaving them exposed to re-initialization attacks. This vulnerability allowed any external actor to overwrite the vault and harvester addresses, granting them the ability to harvest all rewards and withdraw all capital invested in the strategy. To address this, the Bank Of Chain team implemented the initializer modifier, ensuring the initialize function could only be invoked once, thereby safeguarding against potential threats.

These vulnerabilities, while critical, was swiftly rectified by the Bank Of Chain team, underscoring their dedication to ensuring the security and protection of their users.

High Findings

During the audit of Bank Of Chain’s smart contracts, several high-severity vulnerabilities were identified:

• Locked Investor’s Funds: A change in the vaultBufferAddress or the pegTokenAddress could result in locking the investor’s funds in the vault. The team addressed this by adding a require statement to ensure that the new address can only be set once.
• Risk of Locked Funds: The forceRemoveStrategy function could potentially lock the investor’s funds if the repay call fails. The team acknowledged this issue, emphasizing that this function would only be used in exceptional circumstances.
• Potential Fund Lock in Swap: In the swap function, a scenario was identified where user’s funds could get locked without being utilized. The team rectified this by ensuring that the msg.value is equal to zero when the _sd.srcToken is different from the NativeToken.NATIVE_TOKEN.
• Desynchronization Risk: The vault manager could desynchronize the vesting by changing the token, causing the new token to use the old token’s parameters. The team mitigated this by eliminating the Dripper.sol contract.
• Governor Taking Harvested Rewards: The setProfitReceiver function allowed the governor to potentially take all the harvested rewards. The team acknowledged this, stating that the authority will be transferred to the governance contract.

These high-severity vulnerabilities, while significant, were either addressed or acknowledged stating the reason by the Bank Of Chain team, demonstrating their proactive approach to ensuring the safety and security of their platform and its users.

Medium Findings

During the audit of Bank Of Chain’s smart contracts, several medium-severity vulnerabilities were identified:

• Exchange Adapter Spoofing: The governor or delegate has the ability to modify the addresses of the exchange adapters, potentially introducing a malicious contract that simply takes the caller’s funds without performing the expected swap. The team acknowledged this issue, emphasizing that the effect can be achieved when new strategies are deployed.
• Centralization Risk in Fund Transfer: The transferToken function in the Dripper and Harvester contracts grants the governor complete control, allowing them to transfer any amount of any asset to the treasury. This could disrupt the vesting structure and result in unexpected behavior. The team acknowledged this issue, stating that the authority will be transferred to the governance contract.
• Transaction Order Dependency: A race condition vulnerability was identified where the order of transactions could affect the outcome, especially in the burn and rebase functions. The team addressed this by adding the redeemFeeBps and trusteeFeeBps as arguments to these functions, ensuring that the fee values provided match those stored in the smart contract.
• Front-run Risk during Initialization: Contracts that use the initialize function instead of a constructor for upgradability are vulnerable to front-running attacks during initialization. The team acknowledged this risk and stated that they will execute both initialization and deployment simultaneously during deployment.

These medium-severity vulnerabilities, while noteworthy, were either addressed or acknowledged providing the reason by the Bank Of Chain team, showcasing their dedication to improving the security and robustness of their platform.

Low Findings

During the audit of Bank Of Chain’s smart contracts, several low-severity vulnerabilities were identified:

• Missing Address Verification: Some functions lacked a safety check for the address, potentially allowing the address-type arguments to be set to the zero address. This could render certain contract functionalities inaccessible. The team addressed this by verifying that the address arguments are different from the address(0).
• Price Manipulation by Owner: The valueInterpreter and priceProvider variables could be set to any contract, potentially allowing the owner to manipulate prices by pointing to a malicious contract. The team acknowledged this issue, stating that the authority will be transferred to the governance contract.
• Use of .transfer() for Ether Transfers: The use of .transfer() and .send() for transferring Ether is not recommended due to potential gas repricing issues. The team acknowledged this issue and stated that they will consider the recommended method for addressing it in the future if necessary.
• Approve Race Condition: The standard ERC20 implementation contains a race condition in its approve function. The team addressed this by adding a safety check that ensures the allowance can only change from zero to a value or from a value to zero.
• Validation of _exchangeAdapters Argument: The length and address of the _exchangeAdapters argument were not validated, potentially allowing the contract to be initialized without any exchange adapters. The team addressed this by verifying the _exchangeAdapters argument’s length and ensuring the addresses are different from the address(0).
• Floating Pragma: The contract used a floating-point pragma, which is not recommended for production. The team addressed this by locking the pragma version to 0.8.17.

These low-severity vulnerabilities, while not critical, highlight areas of improvement. The Bank Of Chain team’s prompt acknowledgment and resolution of these issues demonstrate their commitment to ensuring the security and robustness of their platform.

Undetermined Findings

In the audit of Bank Of Chain’s smart contract, a discrepancy was noted:

• Mismatch between Code and Documentation: The documentation mentioned a buyback mechanism for the BoC governance token in the Treasury. However, the actual Treasury contract lacked this feature. The Bank Of Chain team acknowledged this and indicated that they’re updating their documentation to address the inconsistency. Proper alignment between documentation and code is vital for clarity and trust.

Best Practices

In the audit of Bank Of Chain's smart contract, several best practices were identified. These included removing unused functions in the AssetHelpers contract to reduce its size, avoiding redundant variable initialization, renaming the removeStrategy function to better reflect its functionality, and using more descriptive names for functions like isKeeper and isVaultOrGov. The Bank Of Chain team promptly made the required adjustments to align with these recommendations, ensuring greater clarity, efficiency, and security in the codebase.

Conclusion

The comprehensive audit of the Bank Of Chain contract provided a deep dive into its design and functionality, revealing a spectrum of issues that required attention. The proactive response from the Bank Of Chain team was commendable, as they promptly addressed and rectified 9 of the identified concerns. While some issues were deemed to have a low likelihood of occurrence, they still hold potential risks. The insights provided by Shellboxes’ auditors were invaluable, emphasizing the importance of continuous vigilance in the ever-evolving landscape of smart contracts. As the Bank Of Chain team moves forward, it's crucial to keep these findings at the forefront, ensuring the platform's security and integrity for its users. The collaboration between the auditors and the Bank Of Chain team serves as a testament to the importance of rigorous testing and iterative improvement in the blockchain space.