The developers of Toucan Protocol contracted byterocket to conduct a smart contract audit of their Retirement Certificate smart contract. Toucan is building a protocol that “brings programmable carbon to Web3, unlocking its potential for a regenerative economy.”
The team of byterocket reviewed and audited the above smart contracts in the course of this audit. We started on the 3rd of June and finished on the 8th of June 2022.
The audit included the following services:
byterocket gained access to the code via a public GitHub repository. We based the audit on the master branch’s state on April 24th, 2022 (commit hash da10e1f7d4b45cb4af648e50f838445e233b1d06).
We conducted a manual multi-pass code review of the smart contracts mentioned in section (1). Three different people went through the smart contract independently and compared their results in multiple concluding discussions.
The manual review and analysis were additionally supported by multiple automated reviewing tools, like Slither, GasGauge, Manticore, and different fuzzing tools.
We are categorizing our findings into four different levels of severity:
On the code level, we found 2 bugs or flaws, with 2 non-critical ones. Additionally, we found 1 gas improvement.
The contracts are written according to the latest standard used within the Ethereum community and the Solidity community’s best practices, with some exceptions listed below. The naming of variables is very logical and understandable, which results in the contract being useful to understand. The code is well documented. The developers provided us with a test suite as well as deployment scripts.
Location: RetirementCertificates.sol - Line 97 - 101
Description:
It is a common best practice to only emit events in cases where the state actually changed. This allows external tools to reconstruct the current state and all of the state changes without diving into the code or any specific transactions.
The same also applies to RetirementCertificates.sol in lines 83 - 90 and 92 - 95.
These are the affected lines of code:
Recommendation:
Consider changing the function to only emit the event if minimum retirement amount has actually changed, e.g. via something like this
Location: RetirementCertificates.sol - Line 131
Description:
While throughout the contract, mainly msg.sender is being used to refer to the current caller, in the registerEvent() function, _msgSender() is used. Following the best practice, one of them should be used exclusively unless there is a good reason not to do so.
Recommendation:
Consider exclusively making use of msg.sender or _msgSender(), depending on the requirements.
Description:
In certain circumstances, it saves gas to cache variables that are read often, especially if they are stored in storage and not in memory.
The affected variables are:
Recommendation:
Consider caching the affected variables and reading from the cached version instead of doing costly read actions.
Part of our audits are also analyses of the protocol and its logic. The byterocket team went through the implementation and documentation of the implemented protocol.
The repository itself contained tests and documentation. We found the provided unit tests that are coming with the repository execute without any issues and cover the most important parts of the protocol.
According to our analysis, the protocol and logic are working as intended.
We were not able to discover any additional problems in the protocol implemented in the smart contract.
During our code review (which was done manually and automated), we found 2 bugs or flaws, with 2 non-critical ones. Our automated systems and review tools did not find any additional ones. Besides any bugs or flaws, we found 1 gas improvement.
The protocol review and analysis did neither uncover any game-theoretical nature problems nor any other functions prone to abuse besides the ones that have been uncovered in our findings.
In general, there are some improvements that can be made, but we are happy with the overall quality of the code and its documentation. The developers have been very responsive and were able to answer any questions that we had.
As of the date of publication, the information provided in this report reflects the presently held understanding of the auditor’s knowledge of security patterns as they relate to the client’s contract(s), assuming that blockchain technologies, in particular, will continue to undergo frequent and ongoing development and therefore introduce unknown technical risks and flaws. The scope of the audit presented here is limited to the issues identified in the preliminary section and discussed in more detail in subsequent sections. The audit report does not address or provide opinions on any security aspects of the Solidity compiler, the tools used in the development of the contracts or the blockchain technologies themselves, or any issues not specifically addressed in this audit report.
The audit report makes no statements or warranties about the utility of the code, safety of the code, suitability of the business model, investment advice, endorsement of the platform or its products, the legal framework for the business model, or any other statements about the suitability of the contracts for a particular purpose, or their bug-free status.
To the full extent permissible by applicable law, the auditors disclaim all warranties, express or implied. The information in this report is provided “as is” without warranty, representation, or guarantee of any kind, including the accuracy of the information provided. The auditors hereby disclaim, and each client or user of this audit report hereby waives, releases and holds all auditors harmless from, any and all liability, damage, expense, or harm (actual, threatened, or claimed) from such use.
We store our public audit reports on IPFS; a peer-to-peer network called the "Inter Planetary File System". This allows us to store our reports in a distributed network instead of just a single server, so even if our website is down, every report is still available.
The IPFS Hash, a unique identifier of the report, is signed on-chain by both the client and us to prove that both sides have approved this audit report. This signing mechanism allows users to verify that neither side has faked or tampered with the audit.
