Quantum Audit Logo
Launch App

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

Is Rally Safe?

RALLYEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance1/10Upgrades2/10Checks passed2 of 5Findings1 Critical · 1 High · 2 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The audit of the Token contract identified several areas for improvement, primarily concerning ERC-20 standard compliance and centralization risks.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (31.9% total → 29.3% effective; 27.5% in EOAs, 4.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
4.3%27.5%Wallets68.1%Everyone else
4.3%27.5%Wallets68.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
31.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking4.3%
  • Walletsanonymous holders, free to sell27.5%
  • Everyone elsethe rest of the supply68.1%
Effective concentrationwhat the score reads29.3%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$5.98M across 14 pairs
Show 4 more pairs

The 4 remaining pairs hold $6.9K between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$5.47MShare of depth91.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x9210…7e7e

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

Security Findings

1 Critical1 High2 Medium1 Low1 Info
Critical

Missing totalSupply() Function Implementation

The contract declares IERC20 but does not implement the totalSupply() function as required by the ERC-20 standard. While a public totalSupply state variable exists, many dApps and tools rely on the explicit function call for compatibility. This omission can lead to integration issues and unexpected behavior with external systems expecting a standard ERC-20 token.C-01

Issue

The contract declares IERC20 but does not implement the totalSupply() function as required by the ERC-20 standard. While a public totalSupply state variable exists, many dApps and tools rely on the explicit function call for compatibility. This omission can lead to integration issues and unexpected behavior with external systems expecting a standard ERC-20 token.

Fix

Implement the totalSupply() function to return the value of the totalSupply state variable, ensuring full ERC-20 compliance. Example: `function totalSupply() external view override returns (uint) { return totalSupply; }`

Status

Unresolved

High

High Centralization Risk

The owner and issuer roles possess significant power. The owner can change the issuer, and the issuer has the ability to mint new tokens up to the maxSupply. This centralized control means that a compromise of the owner or issuer's private key could lead to unauthorized token minting, market manipulation, or a complete loss of trust in the token's supply integrity.H-01

Issue

The owner and issuer roles possess significant power. The owner can change the issuer, and the issuer has the ability to mint new tokens up to the maxSupply. This centralized control means that a compromise of the owner or issuer's private key could lead to unauthorized token minting, market manipulation, or a complete loss of trust in the token's supply integrity.

Fix

Consider implementing a multi-signature wallet for the owner and issuer roles to distribute control and reduce the risk associated with a single point of failure. Explore time-locks or governance mechanisms for critical actions like changing the issuer or minting large amounts of tokens.

Status

Unresolved

Medium

Ownership Transfer to address(0) Possible

The transferOwnership function allows the current owner to set pendingOwner to address(0). If this occurs, the confirmOwnership function, which requires msg.sender == pendingOwner, can never be called, effectively locking the ownership transfer mechanism. The current owner would remain the owner indefinitely, unable to transfer ownership to a new, valid address.M-01

Issue

The transferOwnership function allows the current owner to set pendingOwner to address(0). If this occurs, the confirmOwnership function, which requires msg.sender == pendingOwner, can never be called, effectively locking the ownership transfer mechanism. The current owner would remain the owner indefinitely, unable to transfer ownership to a new, valid address.

Fix

Add a require statement in transferOwnership to prevent setting newOwner to address(0). For example: `require(newOwner != address(0), 'New owner cannot be the zero address');`

Status

Unresolved

Medium

setIssuer to address(0) Disables Minting

The setIssuer function allows the owner to set the issuer address to address(0). If issuer is set to address(0), the mint function becomes permanently unusable because the only(issuer) modifier will always fail. While the owner can later set a new valid issuer, this action could temporarily halt token issuance and might be an unintended consequence if not carefully managed.M-02

Issue

The setIssuer function allows the owner to set the issuer address to address(0). If issuer is set to address(0), the mint function becomes permanently unusable because the only(issuer) modifier will always fail. While the owner can later set a new valid issuer, this action could temporarily halt token issuance and might be an unintended consequence if not carefully managed.

Fix

Consider adding a require statement in setIssuer to prevent setting newIssuer to address(0) unless this is an explicit, intended mechanism to permanently disable minting. If temporary disablement is desired, implement a separate pause/unpause mechanism for minting.

Status

Unresolved

Low

Standard ERC-20 approve Front-Running Vulnerability

The approve function, as implemented, is susceptible to a known ERC-20 front-running vulnerability. If a user approves an amount for a spender and then attempts to change that approved amount to a different value (especially a lower one), an attacker can front-run the second transaction. The attacker could spend the original approved amount before the new allowance is set, potentially leading to a double-spend of the allowance.L-01

Issue

The approve function, as implemented, is susceptible to a known ERC-20 front-running vulnerability. If a user approves an amount for a spender and then attempts to change that approved amount to a different value (especially a lower one), an attacker can front-run the second transaction. The attacker could spend the original approved amount before the new allowance is set, potentially leading to a double-spend of the allowance.

Fix

While this is a common ERC-20 limitation, consider using increaseAllowance and decreaseAllowance functions (as seen in OpenZeppelin's ERC-20 implementation) instead of directly setting the allowance. This pattern mitigates the front-running risk by requiring explicit increments or decrements.

Status

Unresolved

Info

Use of unchecked Blocks

The contract utilizes unchecked blocks for arithmetic operations in functions like mint, transferFrom, and updateBalance. These blocks are correctly preceded by require statements (e.g., require(totalSupply + value <= maxSupply) or require(balanceOf[from] >= value)) that ensure the operations will not overflow or underflow. This is a valid optimization in Solidity 0.8.x to save gas by explicitly opting out of default overflow/underflow checks.I-01

Issue

The contract utilizes unchecked blocks for arithmetic operations in functions like mint, transferFrom, and updateBalance. These blocks are correctly preceded by require statements (e.g., require(totalSupply + value <= maxSupply) or require(balanceOf[from] >= value)) that ensure the operations will not overflow or underflow. This is a valid optimization in Solidity 0.8.x to save gas by explicitly opting out of default overflow/underflow checks.

Fix

No direct action is required as the unchecked blocks are used safely. However, it is crucial to maintain rigorous testing and review of any changes to these functions to ensure that the preceding require statements always provide adequate protection against arithmetic overflows/underflows.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit of the Token contract identified several areas for improvement, primarily concerning ERC-20 standard compliance and centralization risks. A critical issue is the missing implementation of the totalSupply() function, which is essential for ERC-20 compatibility. High centralization of control through the owner and issuer roles presents significant economic risk. Additionally, certain administrative functions carry risks of accidental role locking or irreversible actions. The contract demonstrates good practices in preventing common integer overflows/underflows and includes necessary address checks.

Technical5/10Medium risk

The contract exhibits a generally sound technical foundation, utilizing unchecked blocks correctly with preceding require statements to prevent integer overflows (7.2 Code Security). Necessary address(0) checks are implemented in critical functions like mint and updateBalance. However, a critical technical flaw is the absence of the totalSupply() function, which is a mandatory part of the ERC-20 standard, hindering compatibility with external systems (7.1 Architecture). The standard ERC-20 approve function is also susceptible to front-running, a common but notable issue (7.2 Code Security).

Governance1/10High risk

The contract design incorporates a highly centralized governance model, where an owner can control the issuer role, and the issuer can mint tokens up to maxSupply (7.5 Governance, 7.4 Economic). This centralization introduces a significant single point of failure; compromise of the owner or issuer key could lead to severe economic consequences, including arbitrary token minting. Furthermore, the transferOwnership function allows setting pendingOwner to address(0), which could permanently lock the ownership transfer mechanism if accidentally invoked (7.3 Access Control). The setIssuer function also allows setting the issuer to address(0), effectively disabling minting until the owner re-establishes a valid issuer (7.3 Access Control).

Upgrades2/10High risk

This contract is not designed to be upgradeable, as it does not implement any proxy pattern (7.7 Upgrades). Therefore, there are no upgrade-related risks to assess. Any changes to the contract's logic would require a new deployment and migration of assets, if applicable.

Final RecommendationWhat to do about this score

It is strongly recommended to implement the missing totalSupply() function to ensure full ERC-20 compatibility.

Review the centralization model and consider implementing multi-signature control for critical roles like owner and issuer to mitigate single points of failure. Implement safeguards in transferOwnership to prevent setting pendingOwner to address(0) and consider adding a mechanism to revert setIssuer if it's set to address(0) or if minting is intended to be temporarily paused.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age5mo
Contract0x1964…d08c
Deployer0xa6b1…495b
Badge for your website
Rally security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202680High
  2. Aug 11, 202675High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the RALLY contract address?

The Rally contract on Ethereum is 0x19640000000ba88d36206beb10d0e86011c8d08c. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Rally a scam?

Quantum Audit's risk score for Rally is 80/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is RALLY liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $5.98M.

Who holds RALLY?

As of Sep 4, 2026, the 10 largest holders own 31.9% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
AVAEthereum80HighGlobal DollarUSDG · Ethereum81HighBigShortBetsBIGSB · Ethereum81HighFrankencoinZCHF · Ethereum81HighHeyAnonANON · Ethereum81HighKyber Network Crystal v2KNC · Ethereum81High

Would You Like a More Detailed Audit of Rally?

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