Quantum Audit Logo

Is Redstone Safe?

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

Is this your token? Publish your own audit on this page →

Redstone RED
0xc43c…b5de
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The RedstoneToken contract implements a standard ERC20 token with a fixed maximum supply and a centralized minter role. The contract utilizes battle-tested OpenZeppelin libraries, enhancing its technical security. Key features include a two-step minter role transfer mechanism and a hard-coded maximum supply limit. The primary risks identified relate to the significant power vested in the single minter address and minor operational considerations for minter role management.

1 High1 Medium1 Low1 Informational
Volume 24h
$196.5K
Liquidity
$493.6K
Price
$0.1216
Token Age
1y
Top 10 Holders
59.5%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Minter Role with Significant Power

H-01The `minter` address has exclusive control over the `mint` function, allowing it to create new tokens up to the `MAX_SUPPLY` of 1 billion tokens. This centralized control represents a single point of failure. If the `minter`'s private key is compromised, a malicious actor could mint a large number of tokens, leading to severe inflation and dilution of existing token holders' value. While the `MAX_SUPPLY` is capped, the ability to mint up to this limit at will by a single entity poses a substantial economic risk.
IssueThe `minter` address has exclusive control over the `mint` function, allowing it to create new tokens up to the `MAX_SUPPLY` of 1 billion tokens. This centralized control represents a single point of failure. If the `minter`'s private key is compromised, a malicious actor could mint a large number of tokens, leading to severe inflation and dilution of existing token holders' value. While the `MAX_SUPPLY` is capped, the ability to mint up to this limit at will by a single entity poses a substantial economic risk.
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `minter` role to distribute control and require multiple approvals for minting operations. For very large mints, consider adding a time-lock mechanism to allow for community oversight or emergency intervention.
StatusUnresolved
Medium

Minter Role Transfer Lacks Revocation/Timeout

M-01The `proposeNewMinter` function allows the current `minter` to propose a new address to take over the role. However, there is no mechanism for the current `minter` to revoke this proposal once made, nor is there a time limit for the `proposedMinter` to accept the role. If an incorrect address is proposed, or if the proposed address becomes unresponsive, the current `minter` must issue a new proposal to overwrite the previous one, which could lead to operational delays or temporary uncertainty regarding the minter's succession.
IssueThe `proposeNewMinter` function allows the current `minter` to propose a new address to take over the role. However, there is no mechanism for the current `minter` to revoke this proposal once made, nor is there a time limit for the `proposedMinter` to accept the role. If an incorrect address is proposed, or if the proposed address becomes unresponsive, the current `minter` must issue a new proposal to overwrite the previous one, which could lead to operational delays or temporary uncertainty regarding the minter's succession.
FixConsider adding a `revokeMinterProposal` function that allows the current `minter` to cancel an outstanding proposal. Alternatively, implement a time-based expiry for proposals, requiring the `proposedMinter` to accept within a certain timeframe, after which the proposal becomes invalid.
StatusUnresolved
Low

Minter Can Propose Zero Address

L-01The `proposeNewMinter` function does not explicitly prevent the `minter` from proposing `address(0)` as the new minter. While `acceptMinterRole` would prevent `address(0)` from ever accepting the role (as `msg.sender` cannot be `address(0)`), this scenario would leave the `proposedMinter` state variable set to `address(0)`. This is a minor operational inconvenience, as the current `minter` would then need to issue another valid proposal to a non-zero address.
IssueThe `proposeNewMinter` function does not explicitly prevent the `minter` from proposing `address(0)` as the new minter. While `acceptMinterRole` would prevent `address(0)` from ever accepting the role (as `msg.sender` cannot be `address(0)`), this scenario would leave the `proposedMinter` state variable set to `address(0)`. This is a minor operational inconvenience, as the current `minter` would then need to issue another valid proposal to a non-zero address.
FixAdd a `require(newProposedMinter != address(0), "Cannot propose zero address")` check at the beginning of the `proposeNewMinter` function to prevent setting the proposed minter to the zero address.
StatusUnresolved
Info

Lack of Pausability Mechanism

I-01The RedstoneToken contract does not include any mechanism to pause token transfers or minting operations. While not a direct vulnerability, a pausability feature can be crucial for emergency situations, such as responding to critical vulnerabilities discovered in the token contract itself or in integrated DeFi protocols. Without it, immediate action to prevent further damage might be impossible.
IssueThe RedstoneToken contract does not include any mechanism to pause token transfers or minting operations. While not a direct vulnerability, a pausability feature can be crucial for emergency situations, such as responding to critical vulnerabilities discovered in the token contract itself or in integrated DeFi protocols. Without it, immediate action to prevent further damage might be impossible.
FixConsider integrating a pausability mechanism (e.g., using OpenZeppelin's `Pausable` contract) controlled by a trusted entity, such as a multi-signature wallet. This would allow for emergency halting of critical functions if unforeseen issues arise.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The RedstoneToken contract demonstrates good technical security, leveraging OpenZeppelin's robust ERC20 implementation (7.2 Code Security). The contract correctly enforces a maximum supply limit during minting operations, preventing uncontrolled inflation. Access control for the `mint` function is properly restricted to the designated `minter` (7.3 Access Control). However, the centralized nature of the `minter` role, while technically sound, introduces a single point of failure if compromised, impacting 7.1 Architecture.

GovernanceHigh1/10

The economic model of RedstoneToken is defined by a fixed `MAX_SUPPLY` of 1 billion tokens, which is a positive aspect for long-term value (7.4 Economic). However, the `minter` role holds significant power, capable of minting up to the maximum supply, which represents a high centralization risk (7.5 Governance). While the two-step transfer mechanism for the `minter` role is a good practice, the lack of a revocation mechanism for a proposed minter could lead to operational delays or uncertainty.

UpgradesHigh3/10

The RedstoneToken contract is not designed to be upgradeable (7.7 Upgrades). This eliminates risks associated with proxy patterns, upgradeability logic, and potential upgrade path vulnerabilities. The contract's immutability ensures its logic remains constant post-deployment.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

59.5% in top 10
11.1% in wallets48.4% in contracts
Effective Concentration30.4%

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

$515.5K across 5 pairs
Uniswap v4ETHanalysed$493.6K95.8%Uniswap v4USDT$15.0K2.9%Pancakeswap v3WETH$6.8K1.3%Uniswap v3USDC$650.0%Uniswap v3WETH$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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x6f94…185b
Unlocked LP Held By
0x9b81…7db9

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (59.5% total → 30.4% effective; 11.1% in EOAs, 48.4% in contracts — moderate)
  • 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 = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 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

Related Audits

6 more on the record
SEIHigh RiskDolomite (DOLO)High RiskPinLink (PIN)High RiskSPACE ID (ID)High RiskHarryPotterObamaSonic10Inu (BITCOIN)High RiskUSDS Stablecoin (USDS)High Risk

Would You Like a More Detailed Audit of Redstone?

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

Get Detailed Audit