On September 29, CertiK, a security firm and the leader in Web 3.0 security, provided preliminary comments on the XEN Crypto audit. On September 30, they delivered the final report. There were three issues with varying levels of security. We go over the report and have a community member review the XEN smart contract code.
Report on XEN Audit
CertiK, a cybersecurity firm, conducted manual XEN Crypto code reviews. The code repository for XEN Crypto can be found here: https://github.com/FairCrypto/XEN-crypto and the Litepaper can be found here The audit report can be found at https://www.xencrypto.io/what-is-Xen-Tokenomics/. In the repository, Contracts/XENCrypto.sol is the main part of the XEN Crypto source code and is only 417 lines long. The code is straightforward and simple. Leonid Belyaev and Nicholas Pettas are the main contributors.
Using static analysis techniques, CertiK discovered three issues. One issue is minor and concerns inconsistency between code and documentation, another is subject to debate about the contract’s purpose, and the last one is about the limitation on penalty calculation.
The CertiK suggested code fixes have been promptly applied by the developers, and the documentation has been updated.
CertiK inquiried about the purpose of Migrations.sol in the report. According to Belayev, “this is an auxiliary contract that comes with the Truffle package during the development/testing phase. We do not intend to use it in production.” The contract migrations.sol has been removed, and the AMP calculation has been simplified.
The inconsistency of the code with the documentation was pertaining to the way AMP was decreasing. The documentation the audit report was referring to stated that: “… the reward amplifier (AMP) is a constant, amplifying rewards by 3,000 and decreasing by 30 every 30 days until it reaches the plateau of 1.”; while CertiK asserted that the source code does not decrease the value at a 30-day interval. In fact, since the REWARD_AMPLIFIER_STEP happens to be 30, the reward amplifier should decrease by 1 every day. To bump down 30 (approximately) every month, the calculation would need to be divided by SECONDS_IN_MONTH before multiplying by REWARD_AMPLIFIER_STEP” wrote CertiK.
There was one more inconsistency regarding penalties, where the penalty percentage for 2 days and 5 days was off by 1%. The penalty for minting 2 days late should be 3%, and for 5 days, it should be 35%.
“So there were two things on penalty: 1) Percentages were off in 2 cases (had to deal with rounding functions). We fixed the light paper to match the solidity results. 2) Calculation of the penalty could cause overflow in some potential cases (people would want to claim mint >256 days after maturity, which will be impossible anyway). We fixed this in a post-audit commit, exactly as they suggested. We also found a couple of discrepancies in calculations and fixed them post-audit. In addition, we decided to add another getter to check the current MaxTerm for claiming/mining” said Leonid Belayev.
The maximum penalty has been changed from 100% to 99%. This change stops the users from losing the whole mint after 7 days, and they can always return and finalize the mint with the remaining 1%.
Independent Code review
Independently from CertiK’s audit report, Fashioncoder6, who’s a YouTuber, and XEN community member provided XEN Crypto’s source code review. She walks us through the GitHub repository, reviewing and explaining different functions and parameters of the code. She explains the ins and outs of XEN working under the hood.
The Burn function
The XEN Crypto code also has an interesting burn function that allows for burning XEN tokens and creating a Proof-of-Burn record that can be used by connected DeFi services that will be built on top of the XEN Crypto smart contract.
