Is Rail Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Complex and Potentially Exploitable Anti-Bot Logic

H-01The `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.

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

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

StatusUnresolved

Medium

Centralization Risk with Owner Minting Power

M-01The `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.

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

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

StatusUnresolved

Medium

Hardcoded Anti-Bot Parameters and Gardener Address

M-02Several 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.

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

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

StatusUnresolved

Low

Immutable LP Whitelist

L-01The `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.

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

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

StatusUnresolved

Info

Usage of tx.origin for Anti-Bot Logic

I-01The 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.

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceMedium6/10

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

UpgradesMedium5/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

79.5% in top 10

2.0% in wallets77.5% in contracts

Effective Concentration33.0%

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

$8.57M across 6 pairs

Uniswap v3WETHanalysed$5.54M Uniswap v2WETH$1.54M SushiswapWETH$1.04M Uniswap v4USDC$245.5K SushiswapDAI$195.2K Uniswap v4USDC$9.0K

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 Locked42.4% · Null Address, PinkLock02

Top-1 Unlocked Holder42.6%

Top-3 Unlocked57.6%

Key Addresses

7 addresses

Deployer

0x3f84…737f

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.

What Raised This Score

6 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeRailToken

Audit History

1 audit on record

Sep 657

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

Is Rail Safe?

Security Findings

Complex and Potentially Exploitable Anti-Bot Logic

Centralization Risk with Owner Minting Power

Hardcoded Anti-Bot Parameters and Gardener Address

Immutable LP Whitelist

Usage of tx.origin for Anti-Bot Logic

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Rail?