Memetric (MEMETRIC) security report
Radar by SecureChain AI scanned Memetric on Ethereum. The verified token has no upgradeability, blacklist, pause, tax, or post-deployment mint controls. Medium findings cover full initial allocation to the deployment caller, irreversible zero-address transfers, and the inherited Permit2 infinite-allowance design.
The verified contract does not expose owner-controlled fees, blacklist controls, pausing, upgradeability, or post-deployment minting. Its principal risks are launch-allocation centralization, irreversible zero-address transfers, and the inherited Permit2 infinite-allowance design. These are material control and token-accounting risks, but no direct unauthorized mint or owner-drain path was found in the supplied source.
Trust score: 78/100. Source verified: Yes. Chain: ethereum. Contract: 0x8cc63a25c14e6abc438ebb9d74c00d4f9282fc49.
This report was last modified on 2026-10-16 and contains 3 material findings.
medium finding: Transfers to the zero address permanently lock tokens
The inherited ERC20 transfer and transferFrom paths accept address(0) as the recipient. Tokens sent there become irrecoverable, while totalSupply remains unchanged because this is a transfer rather than a burn. An accidental or integration-induced zero-address transfer can therefore cause permanent token loss and supply-accounting ambiguity.
Evidence: Solady ERC20.transfer and transferFrom do not reject to == address(0); they subtract from the sender and add to the recipient. The supplied Solady source explicitly states that transfers to the zero address are allowed and that totalSupply is not reduced by transfers.
Recommendation: Override transfer and transferFrom, or the relevant transfer hooks, to reject zero-address recipients unless this behavior is an intentional documented feature. Use _burn when reducing supply is intended.
medium finding: Permit2 is treated as an infinite allowance spender
The inherited Solady ERC20 implementation makes allowance(owner, Permit2) return uint256.max and allows Permit2 transferFrom calls without decrementing a stored allowance. Users who authorize Permit2 through the token's approval or signature flow therefore grant an unlimited token-spending permission to that external contract, creating a dependency on Permit2's security and authorization mechanisms.
Evidence: _givePermit2InfiniteAllowance() returns true. allowance returns type(uint256).max for the canonical Permit2 address, approve and permit require the maximum value for that spender, and transferFrom bypasses allowance checks when msg.sender equals Permit2.
Recommendation: Clearly disclose the Permit2 integration and its unlimited-allowance semantics. Users and integrations should authorize Permit2 only when intended; a custom override can disable the behavior if this external dependency is not required.
medium finding: Entire initial supply is assigned to the deployment caller
The constructor mints the full configured supply directly to msg.sender. The token contract provides no vesting, distribution restrictions, or recovery controls, so the deployment caller or launchpad initially controls the complete token allocation until it is transferred elsewhere.
Evidence: MemetricToken.constructor sets _name and _symbol, then calls _mint(msg.sender, supply). No later distribution, vesting, or allocation-enforcement logic exists in MemetricToken.
Recommendation: Document the deployment and launchpad allocation process, use independently verifiable distribution or vesting contracts where appropriate, and communicate that the token contract itself does not enforce allocation decentralization.