Meme Punch Info
Meme Punch is a Web3 P2E game where memecoin legends fight medieval battles for crypto supremacy. Choose your knight and join the fight. ⚔️
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 not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
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 Meme Punch ($MEPU) contract implements an ERC-20 token with a fixed total supply of 10,000,000,000 units minted in a single step at deployment, three pre-allocated reserves (14,5% to a staking address, 40% to a presale address, and 45,5% to a project-funds address), a self-burn function available to every holder, and the standard allowance suite (transfer, transferFrom, approve, increaseAllowance, decreaseAllowance). The contract is not upgradeable, has no transfer fees, no blacklist, no pause mechanism, and no post-deployment mint path. While the overall design follows common patterns on Ethereum, a few areas need attention:
- The Solidity version pragma is declared as ^0.8.9, which permits compilation with any 0.8.x version from 0.8.9 upward, including releases that contain known compiler bugs. The pragma should be pinned to the exact compiler version used for deployment so that future builds, sister-chain ports, or community forks remain deterministic and reproducible.
- The owner role is currently held by the deployer's externally-owned account, transferred in a single step without an acceptance handshake from the receiving address. Although the owner has no operational power over token balances, fees, or supply, a compromise of the deployer key would still allow an attacker to reassign the owner role and damage the project's reputation among integrators and exchanges. Migrating ownership to a multisig wallet, or renouncing it outright, would eliminate this risk.
- The internal transfer function rejects transfers of zero tokens, which deviates from the ERC-20 specification. Several decentralized finance protocols (exchange routers, vault accounting hooks, batch-sweep utilities, governance snapshot tooling) legitimately submit zero-value transfers as part of their normal flow, and integrations with Meme Punch will revert under those conditions.
- The deployed bytecode was compiled with the Solidity optimizer disabled, which inflates the gas cost paid by every user on every transfer, approve, and transferFrom call. Enabling the optimizer for any future redeployment would meaningfully reduce ongoing user costs without altering behavior.
Ownership Privileges
The ownership of the contract has been retained by the deployer's externally-owned account (0x6e12f7c3...C6607858A), which is a separate address from the three reserve recipients. It is important to highlight that for this contract the owner role is largely decorative: the contract intentionally does not gate any token-state mutation behind an owner-only modifier. The privileges and limitations are as follows:
- The owner can transfer ownership of the contract to another address (single-step, no acceptance required).
- The owner can renounce ownership, permanently setting the role to the zero address.
- The owner has no other functions available; there are no further owner-gated entry points in the contract.
- The owner cannot mint new tokens. No public or external mint function exists, and the total supply is permanently fixed at the value set in the constructor.
- The owner cannot burn tokens belonging to other holders. The burn function is restricted to the caller's own balance.
- The owner cannot blacklist, freeze, or otherwise restrict any account from sending or receiving tokens.
- The owner cannot pause transfers or activate any kind of emergency stop.
- The owner cannot set, change, or collect transfer fees. The contract contains no fee logic.
- The owner cannot upgrade the contract. The code is not deployed behind a proxy and the implementation is permanently immutable.
Security Features
The contract implements several positive security features:
- It is compiled with Solidity 0.8.34, which provides built-in overflow and underflow protection on all arithmetic operations, eliminating an entire category of historical token bugs.
- The total supply is fixed at construction time. No mint path exists after deployment, so the supply cannot be inflated under any circumstance and holders are protected from dilution.
- The contract is not upgradeable. There is no proxy, no initializer, and no mechanism to swap the implementation, so the source code visible on the block explorer is permanently the live code.
- The source on the block explorer is verified with an exact bytecode match, allowing any user to independently confirm that the deployed bytecode corresponds to the audited source.
- The transfer, mint, burn, and approve paths contain no external calls, eliminating reentrancy as an attack surface within the token's own code.
- Standard ERC-20 conformance has been verified at the function-selector, return-type, and event-emission level.
- Zero-address checks are present on transfers, approvals, mints, and burns, preventing the most common class of accidental token loss.
- The owner role has no operational authority over token balances, supply, fees, or transferability, which materially reduces the trust assumption that holders must place in the project team.
Note - This Audit report consists of a security analysis of the Meme Punch ($MEPU) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Meme Punch 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
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
low Issues | 3 findings
Pending
#1 low Issue
Zero-Amount Transfers Revert
The internal _transfer function rejects any transfer of zero tokens with a require statement. The ERC-20 standard explicitly states that transfers of zero value must be treated as normal transfers and must emit the Transfer event. This deviation breaks composability with protocols that legitimately submit zero-value transfers, including decentralized exchange routers, vault accounting hooks, batch sweep utilities, and governance snapshot tooling. Such integrations will revert and abort multi-step transactions when interacting with this token.
Pending
#2 low Issue
Floating Solidity Pragma
The contract declares pragma solidity ^0.8.9, which permits compilation with any Solidity 0.8.x version from 0.8.9 upward. Several known compiler bugs exist in the accepted range, including issues with verbatim deduplication, full-inliner argument evaluation order, ABI re-encoding of static arrays, dirty bytes-array storage writes, and internal-override location changes. None of these vectors are reachable in the current contract, but a floating pragma allows future forks or continuous-integration pipelines to silently pick a vulnerable compiler.
Pending
#3 low Issue
Owner Role Held by a Single Externally-Owned Account
On-chain state shows that the owner role is held by the deployer's externally-owned account, separate from the three reserve recipients. While the owner cannot mint additional supply, burn other holders' tokens, blacklist, freeze, or change fees on this token, a key compromise would still allow an attacker to reassign the owner role to an address they control. This breaks any downstream system or off-chain attestation that uses the owner address as a trust anchor for the project.
optimization Issues | 4 findings
Pending
#1 optimization Issue
Missing Infinite-Allowance Shortcut in transferFrom
The transferFrom function unconditionally decreases the spender's allowance after each call. Modern ERC-20 implementations short-circuit this operation when the current allowance equals the maximum uint256 value, treating it as a permanent infinite allowance. Without this optimization, every transferFrom call against the token writes to the allowance storage slot, paying roughly five thousand additional gas units per transaction.
Pending
#2 optimization Issue
Solidity Optimizer Disabled at Deployment
The deployed bytecode was compiled with the Solidity optimizer disabled, as confirmed by the verified compiler settings on the block explorer. Disabling the optimizer inflates deployment cost and increases the gas paid by every user on every transfer, approve, and transferFrom call by roughly 10 to 25 percent because redundant memory operations are not eliminated. The deployed runtime size is approximately 13.5 KB, leaving relatively little headroom under the 24 576 byte contract-size limit for any future maintenance fork that adds functionality.
Pending
#3 optimization Issue
Storage Variables Could Be Immutable or Constant
The string state variables _name and _symbol are written exactly once in the constructor and are never modified afterwards. Reading them through the public name() and symbol() functions performs an SLOAD on every call. Solidity 0.8.21 and later support immutable strings, and because the values are hardcoded literals, they could even be returned as compile-time constants from pure functions, eliminating both the storage writes at deployment and the storage reads at runtime.
Pending
#4 optimization Issue
Inefficient State-Variable Increment
Several state-variable updates use the compound assignment operator, for example _totalSupply += amount in _mint, the matching subtraction in _burn, and _balances[recipient] += amount in _transfer. With the optimizer disabled this pattern compiles to additional memory operations compared to the equivalent explicit form. With the optimizer enabled the two patterns are equivalent. Because the contract was deployed without the optimizer, every transfer pays a small overhead.
informational Issues | 7 findings
Pending
#1 informational Issue
PUSH0 Opcode Limits Cross-Chain Portability
The deployed bytecode contains the PUSH0 opcode because the Solidity compiler defaults to a Cancun-era EVM target. Ethereum mainnet and most modern Layer-2 networks support PUSH0, but a few older private chains and certain non-Shanghai forks do not. Any cross-chain redeployment of this contract to such a network would fail at contract creation.
Pending
#2 informational Issue
Non-Canonical ERC-20 Parameter Names
The allowance function uses parameter names from and to instead of the canonical owner and spender. The approve function uses to and amount instead of spender and amount. The function selectors are unchanged, so the contract is fully ERC-20 compatible at the wire level, but block-explorer interfaces, ABI-driven dApps, and code-generation tools display the source-level parameter names, which can confuse integrators reviewing the contract.
Pending
#3 informational Issue
Unreachable Zero-Address Check on Sender
The internal _transfer function checks that the sender argument is not the zero address. The two callers, transfer and transferFrom, pass either msg.sender (which can never be the zero address in a successful call) or a sender argument that, if zero, would be caught by the subsequent allowance check inside transferFrom. The require statement is therefore unreachable in practice.
Pending
#4 informational Issue
Constants Not in UPPER_CASE Naming Convention
The constants _decimals, stakingReserve, presaleReserve, and projectFundsReserve do not follow the Solidity naming convention for constants, which is upper case with underscores. Only MAX_SUPPLY follows the convention. This is a stylistic inconsistency with no security or runtime impact.
Pending
#5 informational Issue
Large Numeric Literal Could Use Clearer Notation
The MAX_SUPPLY definition is written as 11_500_000_000 multiplied by ten raised to the decimals constant. Although the underscore separators improve readability, scientific notation or an explanatory comment can make large numeric literals more obviously correct at a glance. This is a stylistic observation only.
Pending
#6 informational Issue
ERC-20 Approval Race Condition
When an owner reduces an existing non-zero allowance to a different non-zero value, the spender can front-run the change by spending the original allowance and then receive the new one in addition. This is a long-known property of the ERC-20 specification and is not a flaw of this contract specifically. The contract provides increaseAllowance and decreaseAllowance as the standard mitigation.
Pending
#7 informational Issue
Single-Step Ownership Transfer
The Ownable implementation transfers ownership in a single transaction without requiring the new owner to accept the role. If the deployer types or pastes a wrong address, including an address that cannot interact with the contract, the role is irrecoverably moved. The only sanity check performed is that the new owner is not the zero address. Although the owner role currently has no privileged functions over the token state, an accidental misroute would still break any downstream integration that reads owner() for trust attribution.