During the time frame of September 19th to October 3rd, 2022, Shellboxes was tasked by Consilience Group Limited to assess the security of the Consilience system. Our examination involved a systematic evaluation of the potential security risks related to the utilization of smart contracts. Our approach spotlighted any mismatch between the code and design of the smart contracts and proposed further enhancements to optimize the code. Our findings indicated that despite numerous security and performance problems, there is still room for improvement in the current version of smart contracts.
Consilience Group offers a white-label platform to investment communities that wish to streamline their operations and launch their own Fungible Asset-backed Security Tokens (FAST) – asset-backed micro-currencies. This enables incubators, accelerators and VCs to unlock the potential of sweat equity and create secondary liquidity opportunities.
Consilience introduce the FAST platform; An autonomous, distributed Web3 investment management platform for Private Equity investor groups. The FAST platform fractionalizes and securitizes assets into Fungible Asset-Backed Security Tokens (FAST) that are governed by blockchain Smart Contract.
The ShellBoxes team was faced with the challenge of balancing various important factors such as speed, efficiency, accuracy, and scope when conducting their security testing. To address this challenge, they decided to use a combination of both manual and automated testing methods.
Manual testing was considered essential for detecting errors in logic, procedure, and execution. It also played an important role in verifying the protocol’s invariants from the business logic to ensure that they aligned with the code implementation. This level of manual scrutiny was deemed necessary to ensure that any potential security threats were identified and addressed.
On the other hand, automated testing was utilized to broaden the scope of the security assessment and to quickly detect any code that did not comply with the established security best practices. Automated testing allowed the ShellBoxes team to cover a larger surface area and detect any potential security issues at a much faster pace.
In this way, the team was able to strike a balance between speed, practicality, accuracy, and scope, thereby ensuring that the security evaluation was comprehensive and thorough.
Overall, the smart contracts that were analyzed are well designed and put together, utilizing the diamond proxy pattern. The implementation of this pattern offers several benefits, including modularity and upgradeability. However, there is room for improvement in their implementation by fixing the detected flaws. An assessment revealed that there were 1 high-severity, 4 medium-severity, and 1 low-severity vulnerabilities present in the smart contracts.
The identification of these vulnerabilities highlights the importance of thoroughly reviewing and testing smart contracts before deploying them in a live environment. Addressing these flaws would not only enhance the security of the smart contracts but also improve their functionality and performance.
It is worth noting that even well-designed smart contracts can have vulnerabilities and it is imperative to regularly conduct security evaluations to ensure their continued safety and stability. The discovery of the identified vulnerabilities shows that there is still room for improvement in the implementation of these smart contracts.
Each smart contract, known as a FAST (Fungible Asset-Backed Security Tokens), includes an attribute called transferCredits, which plays a critical role in allowing members to perform transfer operations. The transfer credits are essential for executing transfer transactions, and when a FAST runs out of transfer credits, it becomes impossible for members to transfer their tokens.
However, this attribute is not based on the users, but rather on the FAST itself, making transfer credits a shared resource among FAST members. This means that two members could potentially consume all of the transfer credits, resulting in a denial of service for all members. This would effectively lock the funds of all members within the contract until the issuer member intervenes.
This highlights the importance of carefully managing shared resources within smart contracts to ensure the stability and security of the system. In this case, it is necessary to consider implementing measures to prevent the depletion of transfer credits and to mitigate the risk of a denial of service scenario. The Shellboxes team recommended attaching the transferCredits attribute to the member instead of the fast itself, or to limit the transfer credits that can be spent by one member of the fast.
The issues labeled as A2, B1, and D1 represent the centralization risk and the power that the Issuer has, where the the Issuer can retrieve anyone’s tokens, can perform upgrades, can burn the fast’s tokens. The issue C1 is that one issuer member can remove other issuers members, due to the fact that the removeMember function can be called by any member allowing him to remove another one with the same privilege wich can harm the logic of the contract. For in instance, a new issuer member will be able to remove all the other members.
The setContractOwner function within the smart contract enables the contract owner to assign ownership to another address. This feature is useful for delegating ownership responsibilities and streamlining the management of the contract.
However, if the contract owner mistakenly enters an incorrect address or the address(0) as the _newOwner, the contract will become ownerless, which could lead to a Denial of Service (DoS) in privileged actions. This scenario would severely impact the functionality and security of the contract, and any actions requiring owner privileges would no longer be accessible.
Therefore, it is essential to carefully consider the implications of delegating ownership and to ensure that the correct address is entered when using the setContractOwner function. This helps to minimize the risk of DoS scenarios and ensure the continued stability and security of the smart contract.
The Shellboxes development team has included an additional section in the code to enhance its structure, cleanliness, and optimization. This section outlines several best practices that aim to improve the code’s overall efficiency and performance.
Some of the suggested best practices include removing unnecessary initializations and arguments. For instance, when a variable is declared in Solidity, it automatically gets initialized with its default value, so there is no need to explicitly set it to the default value. Additionally, the setIsSemiPublic function is used to modify the fast’s type, but the flag argument is redundant since the type can only be changed from private to semi-public. In this case, the isSemiPublic attribute can be set directly to ‘true’ to change the fast’s type without the need for the unnecessary argument.
By following these best practices, the code can become more streamlined and optimized, making it easier to maintain and debug in the future.
The project offers a testing mechanism to improve the correctness of smart contracts; In addition, the test coverage percentage is acceptable; as it cover most functionalities and test cases in order to guarantee the integrity of the code and the functionality of the protocol.
In this audit, we examined the design and implementation of Consilience contracts and discovered several issues of varying severity. The Consilience team addressed two issues raised in the initial report and implemented the necessary fixes, while classifying the rest as a risk with low-probability of occurrence. Shellboxes’ auditors advised the Consilience team to maintain a high level of vigilance and to keep those findings in mind in order to avoid any future complications.
© 2024 ShellBoxes All Rights Reserved
