Malachite Info
$MALA is no longer just a meme inspired by Arc's consensus technology. We came prepared to build — MalaSwap is an all-in-one, AI-powered platform on Arc, bringing real utility to the ecosystem.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is renounced
The contract does not include owner functions that allow post-deployment modifications.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The Malachite (MALA) contract implements an ERC20 token with a fixed supply of 1,000,000,000 MALA at 18 decimals that was minted once at deployment, the unmodified OpenZeppelin v5.5.0 transfer and allowance logic, and a read-only tokenURI function that points to off-chain token metadata. The contract has no owner, no administrative functions, no transfer fees, no pause or blacklist mechanism and no upgrade path. The code deployed on Arc Mainnet at 0x4F7DC89dc44aD08c20d9680d2Ee9cfad69BFDa55 matches the published source code exactly, including the compiler metadata.
Ownership Privileges
The ownership of the contract has been left out entirely by design: there is no owner, administrator or role-based access control, so there are no privileges that could be renounced, transferred or abused. No address retains any special rights, in particular:
- No address can mint new tokens. The total supply of 1,000,000,000 MALA was created once at deployment and can never increase.
- No address can burn, freeze, confiscate or otherwise move tokens that belong to other holders.
- No address can pause transfers, blacklist wallets, enable or disable trading, or impose transaction or wallet limits.
- No address can introduce or change fees. Transfers are always free of any token tax.
- The contract is not upgradeable, so its code and behaviour can never be changed or replaced.
- The token metadata, including logo, description and links, is served by an off-chain web service run by the launch platform and can be changed without any trace on-chain.
- Tokens accidentally sent to the token contract address cannot be recovered, because no rescue function exists.
- The launch factory and the contract that holds the initial liquidity position are unverified and were not part of this audit. Their bytecode suggests that the liquidity cannot be withdrawn, but this could not be confirmed from verified source code.
Security Features
The contract implements several positive security features:
- It is built on the unmodified and widely used OpenZeppelin ERC20 implementation, with overflow-checked arithmetic and descriptive custom errors.
- It is fully permissionless and immutable, with no external calls, no delegate calls, no self-destruct and no hidden functions, which we also confirmed at bytecode level.
- The supply is fixed, transfers and approvals reject the zero address, and native currency sent to the contract is refused.
- The deployed bytecode was independently reproduced from the published source with an exact match, and its behaviour was confirmed with extensive property-based and formal testing.
Audit Findings
No critical, high or medium severity issues were identified. One low severity issue relates to a standard ERC-20 behaviour that lets anyone record zero-value transfers on behalf of any holder. This is already being used on-chain to plant look-alike addresses in holders' transaction histories, so holders should always verify the full destination address before sending tokens. The remaining observations are informational and concern the standard allowance race condition, event coverage, irrecoverable transfers to the token address, off-chain metadata hosting, compiler settings, code style and explorer verification, together with one minor gas optimization. Since the contract is immutable, these points can only be addressed in future deployments of the template or through user guidance.
Note - This Audit report consists of a security analysis of the Malachite (MALA) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Malachite (MALA) team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
low Issues | 1 findings
Pending
#1 low Issue
Zero-value transferFrom allows anyone to spoof transfers from any holder (address poisoning)
The inherited transferFrom accepts a value of zero from any caller, even one without any allowance, because the allowance check only fails when the requested amount is larger than the current allowance. Every such call emits a genuine-looking Transfer event from the victim to an address chosen by the caller, while no balance changes. This is the building block of address poisoning scams, in which look-alike addresses are planted in a holder's history in the hope that the holder later copies the wrong one. The pattern is already being used against MALA holders: twelve zero-value transfers were recorded between blocks 21,984,520 and 22,216,892, including a direct call by 0x6834cD18182D336f05bCAE9756cac8A51eb65627 that logged a transfer from 0xcE79CCc11e453CFD5CCAC5094DEa194aCeDdB891 to the look-alike 0x58Fa7d5F822BcFA27d9Ff224a4cA22E487753B04, and a batch transaction that spoofed three holders at once. The behaviour follows the ERC-20 specification and the contract itself loses no funds, but holders can lose tokens by trusting their transaction history.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Redundant zero-address check in the constructor
The constructor reverts with BadInput when the receiver is the zero address, but the inherited _mint function performs the same check and reverts with ERC20InvalidReceiver. The duplicated comparison slightly increases the deployment cost, which is paid again for every launch created from this template.
informational Issues | 9 findings
Pending
#1 informational Issue
ERC-20 approve race condition
Changing an existing non-zero allowance with approve overwrites the previous value in one step. A spender who watches pending transactions can use the old allowance just before the change is included and then use the new allowance as well, ending up with the sum of both. The token inherits OpenZeppelin v5, which no longer ships increaseAllowance and decreaseAllowance, and it does not implement permit, so there is no built-in way to adjust an allowance atomically. This is a known property of the ERC-20 standard rather than a defect specific to MALA.
Pending
#2 informational Issue
Allowance consumption in transferFrom does not emit an Approval event
When transferFrom consumes part of an allowance, the reduced allowance is written to storage without an Approval event. The ERC-20 standard does not require this event, but off-chain services that rebuild allowances from logs, such as dashboards and allowance revocation tools, will show outdated and higher allowances than the real ones.
Pending
#3 informational Issue
Tokens sent to the token contract address are irrecoverable
The transfer functions only reject the zero address as a recipient. Tokens sent to the token contract's own address are accepted, and because the contract has no owner and no recovery function they can never be moved again. The same applies to any other ERC-20 token sent to this address by mistake. No such transfers had been recorded at the time of review.
Pending
#4 informational Issue
Token metadata depends on a mutable, centrally hosted web endpoint
The tokenURI value is fixed at deployment, but it points to an HTTP endpoint on a hosted platform (arc-api-production-ef9c.up.railway.app) that serves the name, description, logo, website and social links. The operator of that service can change or remove this content at any time without any trace on-chain, so wallets and aggregators could display altered logos or links, including malicious ones, or nothing at all if the service goes offline. At the time of review the name and symbol in the metadata matched the on-chain values, while the optional ERC-1046 fields interop and decimals were not provided. Balances and transfers are not affected.
Pending
#5 informational Issue
Floating pragma
The source uses pragma solidity ^0.8.24, which allows compilation with any later 0.8.x release. The deployed bytecode was produced with exactly 0.8.24, so the deployed token is not affected, but rebuilding the launch template with another compiler would produce bytecode that differs from the audited version.
Pending
#6 informational Issue
Compiler 0.8.24 is affected by later disclosed bugs (not applicable to this contract)
Solidity 0.8.24 is listed as affected by four bugs disclosed after its release: MemoryByteArrayElementDeleteClearsWholeWord, SpillSlotCollisionAcrossMutualRecursion, UnsoundSpillInMutualRecursion and LostStorageArrayWriteOnSlotOverflow. We checked the preconditions of each. The first one only affects the legacy code generator while this contract was compiled via IR, the two spill bugs require mutually recursive functions that do not exist here, and the storage bug requires arrays that straddle the end of storage, which the three string variables in standard slots do not. None of them affects the deployed token.
Pending
#7 informational Issue
Code style, missing NatSpec and generic error
The constructor and tokenURI are written in a compressed single-line style without spacing, which departs from the Solidity style guide and makes review harder. The constructor, the BadInput error and the non-standard tokenURI function carry no NatSpec documentation, and BadInput is reused for two different conditions, a zero receiver and a zero supply, without any parameters, which makes failed deployments harder to diagnose.
Pending
#8 informational Issue
Explorer verification is a similar match without constructor arguments or license
The explorer shows the source code of this address through a similar match with 0x802D3166AD677d3AA993c85910598885568099bf. As a result the constructor arguments are not displayed and the license is listed as not specified, although the source declares MIT. We recompiled the published sources with the recorded settings and obtained an exact match of the runtime bytecode, including the metadata hash, and of the creation code with the decoded constructor arguments, so this is purely a transparency matter.
Pending
#9 informational Issue
Launch factory and liquidity position holder are unverified and outside the audited scope
The token was created by the unverified and upgradeable factory proxy 0x80B42Aed46d73f47119dC444beA28A9e68F32BF4. In the same transaction the factory received the entire supply, created the MALA/USDC Uniswap V3 pool with a 1% fee, deposited practically the whole supply as single-sided liquidity, moved the position NFT (ID 3896) to the unverified contract 0x39A2cf0bDB6b404B34c87e2f9C19c4D025d875D5 and bought about 10.26% of the supply for the creator 0x2E487604AB068380Af5f0916d8b88b97711FE2C8. A bytecode-level review of the position holder shows only fee collection, the ERC-721 receiver hook and two getters, with no path to remove liquidity or move the NFT, and the position's liquidity was unchanged at block 22,365,220. This suggests that the launch liquidity is effectively locked, but without verified source code it cannot be confirmed. The token contract itself grants no rights to any of these contracts.