Quantum Audit Logo

Is RUSSELL Safe?

On-chain security analysis — is it a scam or legit?

RUSSELL RUSSELL
0x0c51…ce0b
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

2 Critical1 High1 Low1 Informational
Volume 24h
$60.8K
Liquidity
$389.5K
Price
$0.002386
Token Age
1y
Top 10 Holders
22.2%

Security Findings

2 Crit1 High1 Low1 Info
Critical

Missing `_transfer` Function

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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Critical

Truncated `approve` Function

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.
IssueThe `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.
FixComplete 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).
StatusUnresolved
High

Missing `transferFrom` Implementation

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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Low

Unused State Variables

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.
IssueThe 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.
FixReview 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.
StatusUnresolved
Info

`totalSupply` Immutability

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.
IssueThe `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.
FixConfirm 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.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

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.

GovernanceLow7/10

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).

UpgradesLow8/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

22.2% in top 10
8.2% in wallets14.0% in contracts
Effective Concentration13.8%

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.

Liquidity Depth

$416.7K across 7 pairs
Uniswap v2WETHanalysed$389.5K93.5%Uniswap v4USDC$13.7K3.3%Uniswap v3WETH$10.0K2.4%AerodromeWETH$3.3K0.8%AerodromeWETH$1600.0%Uniswap v4USDC$140.0%
Show 1 more pairShow less
AerodromeUSDC$10.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

7 addresses
Deployer
0x6368…502c
Unlocked LP Held By
0x7cd0…2e470x9bd2…168c0x46cb…e6be0xb3ac…68a00xf2ed…6f2a0x4985…2b2b

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

3 factors
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit

Each 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

Related Audits

6 more on the record
ClawBankLow RiskDebtReliefBot (DRB)Low RiskCoinye West (COINYE)Low RiskBasecatLow RiskSKI MASK DOG (SKI)Low RiskBriun Armstrung (BRIUN)Low Risk

Would You Like a More Detailed Audit of RUSSELL?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit