Fellow Marvinauts, understanding a contract audit is almost as difficult as writing the contract itself. While companies like Certik and others do a great job at ensuring the safety of the contract, they don’t always explain it in a way the rest of us can understand.
Here is the in-depth breakdown of the recent Certik audit for Marvin Inu.
Audit Score
There seems to be a lot of confusion around the “audit score,” with a few Marvinauts worried about why it’s so low. To clarify, there is no audit score. The integrity of an audit can’t be easily measured on a 1–100 scale because different ‘issues’ listed in the audit have a different impact on the contract if they aren’t resolved. And every contract is a little different so it would be nearly impossible to make a 1–100 comparison.
The number you see are the total findings from Certik and each finding has it’s own individual solution. Below we’ll share each finding and what the amazing dev team has done to address it.
Centralization Risk — Major Risk
All this means is that our contract allows us to control the taxes for the project. This is common practice, and necessary, for small-cap projects in the beginning. These taxes help fun our marketing and development efforts to keep Marvin on a safe and steady trajectory toward Mars.
The only way to resolve this completely is to renounce the contract and eliminate the ability to change tax. At this time we have chosen not to do that because we have bigger plans for Marvin, such as listings on central exchanges. To get on a CEX we will likely have to lower our taxes at the time, so we need the ability to do that when the time comes.
The reason it’s labeled as a major risk is due to the fact that a single, “the owner,” has the ability to alter the contract which can leave it open to attack from bad actors. To mitigate this risk we use multi-signature wallets so no single entity can make a major change.
Insecure Condition Checking — Medium Risk
This was a logic error that could render the takeFee as always false under a very specific attack.
This was a simple fix where modified one line of code to ensure takeFee is always true.
Unused Return Value — Medium Risk
This is a volatility error dealing with adding liquidity to Marvin. If our slippage is too high it creates a risk of being front run.
To combat this the team keeps the slippage as close to 0 as possible when adding liquidity.
Contract gains non-withdrawable BNB via the swapAndLiquify function — Medium Risk
What this means is that whenever liquidity is added to Marvin there will be a small amount of tokens left over. This is because we first need to swap part of the Marvin tokens for BNB in order to complete the pairing. This swap naturally causes a small dip in the price of Marvin so the MARVIN-BNB doesn’t completely line up to 50/50.
This only occurred when there was a tax for LP and since that has been reduced to zero (0) and burning has ceased it’s a non-issue. While this was occurring the team was doing strategic buy backs to offset the difference.
3rd party dependencies — Minor Risk
This is only to inform you that we’re currently using PancakeSwap as a 3rd party provider for swapping Marvin and that our contract is being accessed by them.
In the future, we will have our own MarvinSwap but this isn’t necessary at the current time and the dev team's resources are better spent on higher-value additions to the project.
Potential Sandwich Attacks — Minor
While this sounds like a delicious problem to occur, it is unfortunately not the same as your last food fight. A sandwich attack happens when a bad actor manipulates a transaction to front-run and then back-run the transaction to profit off the difference that creates in the token price.
To prevent this from happening we have already changed our buy tax back to 8%.
lastLpBurnTime could be changed by owner — Minor
This deals with adding liquidity but is a non-issue.
The contract is setup so that trading won’t begin until it’s turned on after the team has added liquidity. It cannot be used to stop trading once it’s begun.
logical issue in swapBack() — Minor
Another logical error that helps the contract swap for taxes.
Since the deployed contract cannot be changed we decided to retain the code base unchanged because there are no issues in the execution of this codebase.
Informational Findings
As the name says, these findings are more for informational purposes and include Certik recommendations. These aren’t necessarily meant to be addressed but merely suggestions from Certik.
Missing Emit Events
This is tied to the centralization risk and will be resolved once renounce the contract. It doesn’t pose any
Variables That Could Be Declared as constant
They recommended changing gas fees to a constant, we’ve decided to keep our current setup. By having a limit on the gas fee it helps prevent someone from front running a transaction.
Improper Usage of public and external Type
This is another finding that will be resolved once we renounced the contract in the future.
Declaration Naming Convention
This is another preference suggestion. We used all lower case and they suggested using camel case. It makes no difference from an output standpoint.
Missing Zero Address Validation
This is a recommendation to use a conventional coding style. We prefer writing in Martian though so we’ll keep this for now.
Discussion on the sources of lp tokens
This was simply asking where we were getting tokens for the manual burning process. Manual burns are off for now, previously the tokens were acquired through our buy and sell tax.
