$MRUN Smart Contract Passed Security Audit
“Overall, this smart contract is well-designed and engineered… We believe this token passes security qualiﬁcations to be listed on digital assets exchanges.”
— OnGrid Systems
As most people in crypto are probably aware, a smart contract audit is one of the strong fundamentals of a project that reveals possible vulnerabilities in the smart contract that may expose funds to rugpull or exploitation by 3rd-parties. And we are glad to announce to our community that $MRUN Smart Contract is now Audited.
Metarun’s $MRUN token Smart Contract was recently audited by OnGrid Systems and based on a set of ratings involving impact and overall risk severity assessment, the following summary was reached:
Below are excerpts from the report to highlight the notes provided by the Audit team:
1. MRN-1 Old compiler pragma
-Category: Conﬁguration, SWC ID:SWC-102
The contract has the following pragma directive:
Currently, the latest version of the oﬃcial Solidity compiler is v0.8.13, but at the time of contract deployment (February 23, 2022), the actual version was v0.8.11. As usual, it is recommended to stay on top of the new versions, which could avoid problems. But in the given case, later releases v0.8.12 and v0.8.18 introduced just minor bugﬁxes and improvements and don’t seem to signiﬁcantly aﬀect the code.
Recommendation: since the contract is already deployed, no action required
2. MRN-2 Outdated library dependency
Currently deployed contracts use OpenZeppelin library of version v4.4.2 (actual a the contract deployment date)
Currently, the latest stable version of the OpenZeppelin is v4.5.0. If the contract had not been deployed, we would recommend updating the dependencies and “freezing” them with yarn. But for the reasons stated above in MRN-1, you don’t need to touch this dependency.
Recommendation: Since the contract is already deployed, no action required.
3. MRN-3 Excessive authority of token deployer
The contract implements two roles — MINTER_ROLE and DEFAULT_ADMIN_ROLE that are assigned simultaneously by the constructor and both powers still present on the deployer address. Within the meaning of separation of powers, unnecessary capabilities of MINTER_ROLE should be revoked once supply was minted.
Recommendation: If the manual issuance of new tokens is not planned anymore, the MINTER_ROLE can be safely revoked.
“MINTER_ROLE is required for the economy system designed in Metarun. Once the “Conditional minting” system is finalized, Minter role will be removed from the deployer wallet and assigned to “Conditional minting contract” or “Reward contract”.
Regardless of the presence/absence of MINTER_ROLE on the deployer’s address, the token is still capped at 1,000,000,000 units.”
Metarun developers have taken note of these observations and are following up on the recommendations internally.
Detailed analysis of the audit findings are provided in the Audit Report here: