On-chain security analysis — is it a scam or legit?
The Erc20 token contract exhibits critical functionality gaps, including a missing internal transfer function and a truncated approve function, rendering it non-operational and non-compliant with the ERC-20 standard.
Read the full analysisEach factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed
Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x7cd0…2e470x9bd2…168c0x46cb…e6be0xb3ac…68a00xf2ed…6f2a0x4985…2b2bNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_transfer Functiontransfer function, which is a core part of the ERC-20 standard, calls an internal _transfer function. However, the _transfer function is not defined anywhere in the provided contract code. This omission renders the token's fundamental transfer functionality non-operational, preventing any token movements.C-01The transfer function, which is a core part of the ERC-20 standard, calls an internal _transfer function. However, the _transfer function is not defined anywhere in the provided contract code. This omission renders the token's fundamental transfer functionality non-operational, preventing any token movements.
Implement the _transfer internal function, ensuring it correctly handles balance updates, allowance checks (if applicable for transferFrom), and emits the Transfer event. This function should contain the core logic for moving tokens between addresses.
Unresolved
approve Functionapprove function, which is essential for ERC-20 token delegation, is incomplete in the provided code snippet. The function body abruptly ends, preventing its proper execution and introducing an unknown security risk or complete malfunction.C-02The approve function, which is essential for ERC-20 token delegation, is incomplete in the provided code snippet. The function body abruptly ends, preventing its proper execution and introducing an unknown security risk or complete malfunction.
Complete the implementation of the approve function. Ensure it correctly updates the _allowed mapping for the msg.sender and spender, handles the spender != address(0) check, and emits the Approval event. Consider implementing the recommended mitigation for the ERC-20 approve race condition (setting allowance to 0 first).
Unresolved
transferFrom ImplementationIERC20 interface defines the transferFrom function, which allows a spender to transfer tokens on behalf of another address. However, the Erc20 contract does not implement this function. This violates the full ERC-20 standard and prevents delegated token transfers, impacting interoperability with other DeFi protocols.H-01The IERC20 interface defines the transferFrom function, which allows a spender to transfer tokens on behalf of another address. However, the Erc20 contract does not implement this function. This violates the full ERC-20 standard and prevents delegated token transfers, impacting interoperability with other DeFi protocols.
Implement the transferFrom function as specified by the ERC-20 standard. This function should check the allowance of the spender from the from address, deduct the transferred amount from the allowance, and then perform the token transfer using the internal _transfer function.
Unresolved
launched (boolean) and exchanges (mapping) are declared within the Erc20 contract but are not utilized in any of the provided functions. This indicates either incomplete functionality that was planned but not implemented, or dead code that can be removed.L-01The state variables launched (boolean) and exchanges (mapping) are declared within the Erc20 contract but are not utilized in any of the provided functions. This indicates either incomplete functionality that was planned but not implemented, or dead code that can be removed.
Review the contract's design to determine the intended purpose of launched and exchanges. If they are part of future functionality, ensure they are properly integrated. If they are no longer needed, remove them to reduce contract size and improve clarity.
Unresolved
totalSupply ImmutabilitytotalSupply variable is declared as immutable, meaning its value is set once in the constructor and cannot be changed thereafter. This design choice fixes the total supply of the token, preventing any future burning or minting capabilities.I-01The totalSupply variable is declared as immutable, meaning its value is set once in the constructor and cannot be changed thereafter. This design choice fixes the total supply of the token, preventing any future burning or minting capabilities.
Confirm that a fixed token supply, without any possibility of future burning or minting, aligns with the project's long-term economic model. If dynamic supply management is ever desired, totalSupply should not be immutable and appropriate mint/burn functions with access control would be required.
Unresolved
The Erc20 token contract exhibits critical functionality gaps, including a missing internal transfer function and a truncated approve function, rendering it non-operational and non-compliant with the ERC-20 standard. The absence of the transferFrom function further limits its utility. These issues pose severe operational risks and require immediate resolution before deployment or use.
The technical architecture is based on a standard ERC-20 token with OpenZeppelin-like Ownable access control and a custom Address library. The code quality is severely impacted by critical omissions: the core _transfer function is missing (7.2 Code Security), and the approve function is truncated (7.2 Code Security). Additionally, the transferFrom function, a key part of the ERC-20 standard, is not implemented (7.2 Code Security). These issues make the token non-functional and non-compliant.
The contract implements a basic Ownable pattern for access control (7.3 Access Control), allowing the owner to manage ownership. There is no complex governance mechanism or economic model beyond the standard ERC-20 token functionality. The totalSupply is immutable (7.1 Architecture), fixing the token supply at deployment. The launched and exchanges variables are declared but unused, indicating potential incomplete economic logic (7.4 Economic).
The contract is a standard implementation contract and does not incorporate any proxy patterns or upgrade mechanisms (7.7 Upgrades). Therefore, it is not designed to be upgradeable. Any changes to the contract logic would require a new deployment and migration of assets, if applicable.
It is imperative to complete the implementation of the _transfer function and the approve function to restore core token functionality.
The transferFrom function must also be implemented to ensure full ERC-20 standard compliance. Additionally, review and either implement or remove the unused launched and exchanges state variables to clarify the contract's intended design and prevent dead code. A thorough review of the complete codebase is recommended to ensure all ERC-20 functions are correctly and securely implemented.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The RUSSELL contract on Base is 0x0c5142bc58f9a61ab8c3d2085dd2f4e550c5ce0b. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for RUSSELL is 11/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $416.7K.
As of Sep 4, 2026, the 10 largest holders own 22.2% of the supply. The Holders section on this page shows who they are by holder type.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
