Quantum Audit Logo
Launch App

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

Is Rail Safe?

RAILEthereum
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 6, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance6/10Upgrades5/10Checks passed5 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The RailToken contract implements a standard ERC20 token with additional anti-bot logic within its transfer function.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (79.5% total → 33.0% effective; 2.0% in EOAs, 77.5% in contracts — moderate)
  • 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 65 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 6, 2026
77.5%Contracts2.0%20.5%Everyone else
77.5%Contracts20.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
79.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking77.5%
  • Walletsanonymous holders, free to sell2.0%
  • Everyone elsethe rest of the supply20.5%
Effective concentrationwhat the score reads33.0%
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 6, 2026

Liquidity

as of audit · Sep 6$8.57M across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$5.54MShare of depth64.7%
LP Locked42.4% · Null Address, PinkLock02
Top-1 Unlocked Holder42.6%
Top-3 Unlocked57.6%
Unlocked LP held by
0x5a67…4eae0xf527…93e90xc413…099e0xb3ac…68a00x0000…8a900x1f2f…f387

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

Security Findings

1 High2 Medium1 Low1 Info
High

Complex and Potentially Exploitable Anti-Bot Logic

The transfer function contains complex anti-bot logic that relies on tx.gasprice and block.timestamp. An attacker could manipulate tx.gasprice to intentionally trigger the anti-bot mechanism, causing a victim's tokens to be transferred to the hardcoded GARDENER address instead of the intended recipient. The require("true") error message is uninformative, hindering user understanding and debugging. The GARDENER address is hardcoded and cannot be changed, posing a risk if it becomes compromised or inaccessible. This impacts 7.2 Code Security and 7.4 Economic.H-01

Issue

The transfer function contains complex anti-bot logic that relies on tx.gasprice and block.timestamp. An attacker could manipulate tx.gasprice to intentionally trigger the anti-bot mechanism, causing a victim's tokens to be transferred to the hardcoded GARDENER address instead of the intended recipient. The require("true") error message is uninformative, hindering user understanding and debugging. The GARDENER address is hardcoded and cannot be changed, posing a risk if it becomes compromised or inaccessible. This impacts 7.2 Code Security and 7.4 Economic.

Fix

Simplify the anti-bot logic, if possible, and ensure it is robust against manipulation. Replace tx.gasprice checks with more reliable on-chain mechanisms or remove them if the risk outweighs the benefit. Implement clear and descriptive error messages for all require statements. Consider making the GARDENER address and anti-bot parameters configurable by the owner or a multi-signature wallet to allow for updates and emergency changes.

Status

Unresolved

Medium

Centralization Risk with Owner Minting Power

The owner of the contract has the exclusive ability to call governanceMint, allowing them to mint new tokens up to the defined cap. While a cap exists, this still grants significant power to a single entity, potentially leading to token dilution for existing holders or misuse if the owner's key is compromised. There are no additional safeguards like timelocks or multi-signature requirements for this critical function. This impacts 7.3 Access Control and 7.5 Governance.M-01

Issue

The owner of the contract has the exclusive ability to call governanceMint, allowing them to mint new tokens up to the defined cap. While a cap exists, this still grants significant power to a single entity, potentially leading to token dilution for existing holders or misuse if the owner's key is compromised. There are no additional safeguards like timelocks or multi-signature requirements for this critical function. This impacts 7.3 Access Control and 7.5 Governance.

Fix

Consider implementing a multi-signature wallet for the owner address or introducing a timelock for sensitive operations like governanceMint. This would add an extra layer of security and decentralization, reducing the risk of a single point of failure or malicious action.

Status

Unresolved

Medium

Hardcoded Anti-Bot Parameters and Gardener Address

Several critical parameters for the anti-bot mechanism, including ANTI_BOT_LOCKTIME, ANTI_BOT_SOFT_GASLIMIT, ANTI_BOT_HARD_GASLIMIT, ANTI_BOT_AMOUNT_CAP, and the GARDENER address, are hardcoded as constants. This immutability prevents any adjustments to the anti-bot strategy in response to changing market conditions, evolving bot tactics, or if the GARDENER address needs to be updated (e.g., due to compromise). This impacts 7.8 Operations.M-02

Issue

Several critical parameters for the anti-bot mechanism, including ANTI_BOT_LOCKTIME, ANTI_BOT_SOFT_GASLIMIT, ANTI_BOT_HARD_GASLIMIT, ANTI_BOT_AMOUNT_CAP, and the GARDENER address, are hardcoded as constants. This immutability prevents any adjustments to the anti-bot strategy in response to changing market conditions, evolving bot tactics, or if the GARDENER address needs to be updated (e.g., due to compromise). This impacts 7.8 Operations.

Fix

Make critical anti-bot parameters and the GARDENER address configurable by the contract owner or a governance mechanism. This would allow for flexibility and adaptability in managing the anti-bot system post-deployment, ensuring its continued effectiveness and security.

Status

Unresolved

Low

Immutable LP Whitelist

The lps mapping, which whitelists addresses to bypass the anti-bot logic, is populated only during contract deployment in the constructor. There is no function to add or remove addresses from this whitelist after deployment. This immutability can lead to operational inflexibility if new liquidity providers need to be added or if existing LP addresses change or become compromised. This impacts 7.8 Operations.L-01

Issue

The lps mapping, which whitelists addresses to bypass the anti-bot logic, is populated only during contract deployment in the constructor. There is no function to add or remove addresses from this whitelist after deployment. This immutability can lead to operational inflexibility if new liquidity providers need to be added or if existing LP addresses change or become compromised. This impacts 7.8 Operations.

Fix

Consider adding an onlyOwner function to manage the lps whitelist, allowing the owner to add or remove addresses as needed. This would provide necessary flexibility for project operations without compromising security, especially if combined with multi-signature or timelock controls for the owner.

Status

Unresolved

Info

Usage of tx.origin for Anti-Bot Logic

The contract uses tx.origin as part of its anti-bot logic (tx.origin == msg.sender). While tx.origin is generally discouraged for access control due to phishing risks, its use here is to differentiate between direct calls and contract calls for anti-bot purposes, which is a common pattern. However, it's still a less robust identifier than msg.sender and can be a source of confusion or unexpected behavior in complex interactions. This impacts 7.2 Code Security.I-01

Issue

The contract uses tx.origin as part of its anti-bot logic (tx.origin == msg.sender). While tx.origin is generally discouraged for access control due to phishing risks, its use here is to differentiate between direct calls and contract calls for anti-bot purposes, which is a common pattern. However, it's still a less robust identifier than msg.sender and can be a source of confusion or unexpected behavior in complex interactions. This impacts 7.2 Code Security.

Fix

While not a critical vulnerability in this specific context, it's generally best practice to avoid tx.origin where possible. If the intent is to prevent contract interactions, alternative methods like checking msg.sender == address(this) or using a specific whitelist for allowed contracts might be considered, though they come with their own complexities.

Status

Unresolved

Analysis

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

The RailToken contract implements a standard ERC20 token with additional anti-bot logic within its transfer function. While leveraging well-audited OpenZeppelin libraries for core functionality, the custom anti-bot mechanism introduces considerable complexity and potential for unintended transfers. Centralization risks exist due to the owner's minting capabilities and the immutability of critical anti-bot parameters and whitelisted addresses. The contract is not upgradeable, which simplifies upgrade safety but means any issues with the anti-bot logic or parameters cannot be easily rectified post-deployment.

Technical7/10Low risk

The contract utilizes battle-tested OpenZeppelin libraries for ERC20 and Ownable functionalities, which contributes positively to its baseline security (7.2 Code Security). However, the custom anti-bot logic in the transfer function introduces significant complexity and potential vulnerabilities. This logic relies on tx.gasprice and block.timestamp, which can be manipulated, potentially leading to unintended transfers of user funds to a hardcoded 'GARDENER' address (7.2 Code Security, 7.4 Economic). The use of require("true") for an error message is uninformative and hinders debugging.

Governance6/10Medium risk

The contract exhibits centralization risks as the owner has the exclusive ability to governanceMint new tokens, which could lead to token dilution if not managed responsibly (7.3 Access Control, 7.5 Governance). The cap mechanism limits total supply, but the owner can still mint up to this cap. Furthermore, the lps (liquidity providers) whitelist, which bypasses anti-bot logic, is set immutably in the constructor and cannot be updated, posing operational inflexibility if LP addresses change or new LPs need to be added (7.8 Operations).

Upgrades5/10Medium risk

The RailToken contract is not designed as an upgradeable proxy. It is a standard implementation contract, meaning its logic cannot be changed after deployment. This eliminates upgrade-related risks such as proxy misconfigurations or storage collisions (7.7 Upgrades). However, it also means that any discovered vulnerabilities or desired feature enhancements in the custom logic cannot be patched or implemented without a new deployment.

Final RecommendationWhat to do about this score

It is highly recommended to thoroughly review and simplify the anti-bot logic within the transfer function.

Consider making critical anti-bot parameters and the 'GARDENER' address configurable by the owner or a multi-signature wallet to allow for adjustments post-deployment. Implement clear and descriptive error messages for all require statements to improve user experience and debugging. Evaluate the necessity and implications of the owner's governanceMint function and consider implementing a timelock or multi-signature for such powerful actions to mitigate centralization risks.

Contract & Record

1 audit on record
TypeRailToken
NetworkEthereum
Token age5y
Contract0xe76c…a33d
Deployer0x3f84…737f
Badge for your website
Rail 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 6, 202657Medium

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

Related Audits

6 more on the recordAll audits
Paxos GoldPAXG · Ethereum57MediumIlluviumILV · Ethereum57MediumFlying TulipFT · Ethereum57MediumTether GoldXAUT · Ethereum58MediumSustainable Aviation FuelSAF · Ethereum56MediumMatrixMTX · Ethereum58Medium

Would You Like a More Detailed Audit of Rail?

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