Quantum Audit Logo
Launch App

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

Is Safe Token Safe?

SAFEEthereum
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 · 2 audits on record
SummaryAI Copilot

The SafeToken contract is an ERC20 token with Pausable and Ownable functionalities, inheriting from OpenZeppelin standards.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 97.4%
  • LP top3 unlocked holders = 98.4%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (80.0% total → 34.4% effective; 4.0% in EOAs, 76.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 97.4% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 98.4% (independent LP — depth risk, pool = 99% 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
76.0%Contracts4.0%20.0%Everyone else
76.0%Contracts4.0%20.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
80.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking76.0%
  • Walletsanonymous holders, free to sell4.0%
  • Everyone elsethe rest of the supply20.0%
Effective concentrationwhat the score reads34.4%
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$264.5K across 3 pairs
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$260.7KShare of depth98.6%
Top-1 Unlocked Holder97.4%
Top-3 Unlocked98.4%
Unlocked LP held by
0x2d93…dada0xa090…151a0x3378…81e20xad0a…4a970x8026…90f10x97b2…d1fc0x7a37…28700x3fda…7af40x6101…3cc60xc790…5678

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

Security Findings

1 High1 Medium1 Low2 Info
High

Significant Centralized Control by Owner

The Ownable pattern grants extensive power to a single address (or multisig) designated as the owner. The owner can pause/unpause all token transfers, bypass the pause mechanism for their own transfers, and rescue any ERC20 tokens accidentally sent to the contract. While the owner is a multisig, which mitigates a single point of failure, this still represents a highly centralized control point. A compromise of the multisig or malicious actions by its signers could lead to severe consequences, including freezing user funds or unauthorized token movements.H-01

Issue

The Ownable pattern grants extensive power to a single address (or multisig) designated as the owner. The owner can pause/unpause all token transfers, bypass the pause mechanism for their own transfers, and rescue any ERC20 tokens accidentally sent to the contract. While the owner is a multisig, which mitigates a single point of failure, this still represents a highly centralized control point. A compromise of the multisig or malicious actions by its signers could lead to severe consequences, including freezing user funds or unauthorized token movements.

Fix

Implement a time-lock mechanism for critical owner-controlled functions (e.g., unpause, transferOwnership, rescueToken). This would introduce a delay before actions take effect, allowing for community oversight and potential intervention. Additionally, consider exploring decentralized governance models for future iterations to distribute control and reduce reliance on a single entity.

Status

Unresolved

Medium

Owner Can Bypass Pause for Transfers

The _beforeTokenTransfer function includes a condition owner() == _msgSender() which allows the contract owner to perform token transfers even when the contract is in a paused state. While this might be an intended emergency feature, it means the owner is not subject to the same restrictions as other users during a pause. This could lead to perceived unfairness, potential market manipulation, or allow the owner to move tokens while other users are restricted.M-01

Issue

The _beforeTokenTransfer function includes a condition owner() == _msgSender() which allows the contract owner to perform token transfers even when the contract is in a paused state. While this might be an intended emergency feature, it means the owner is not subject to the same restrictions as other users during a pause. This could lead to perceived unfairness, potential market manipulation, or allow the owner to move tokens while other users are restricted.

Fix

Clearly document the intended use cases and operational procedures for the owner's ability to bypass the pause. If this functionality is not strictly necessary for emergency operations, consider removing the owner() == _msgSender() condition from the _beforeTokenTransfer function to ensure all users, including the owner, are subject to the same pause restrictions. If kept, ensure robust internal controls for the multisig are in place to prevent misuse.

Status

Unresolved

Low

Initial Large Token Mint to Owner

The contract's constructor mints 1,000,000,000 tokens (with 18 decimals) directly to the deployer/owner address. This means 100% of the initial token supply is held by a single entity. While this is a common pattern for initial token deployments, it grants immense control over the token's initial distribution, liquidity, and potential market impact to the owner. Any subsequent distribution relies entirely on the owner's actions.L-01

Issue

The contract's constructor mints 1,000,000,000 tokens (with 18 decimals) directly to the deployer/owner address. This means 100% of the initial token supply is held by a single entity. While this is a common pattern for initial token deployments, it grants immense control over the token's initial distribution, liquidity, and potential market impact to the owner. Any subsequent distribution relies entirely on the owner's actions.

Fix

Ensure that the distribution plan for these tokens is transparent and clearly communicated to the community. Consider vesting schedules or multi-signature controlled distribution mechanisms to manage the release of these tokens over time, reducing the immediate concentration of power and potential for market shocks.

Status

Unresolved

Info

Non-Upgradeable Contract Design

The SafeToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (e.g., UUPS, Transparent). This design choice means the contract's logic cannot be modified or upgraded after deployment. While this provides immutability and reduces complexity associated with upgrade mechanisms, it also implies that any bugs discovered post-deployment cannot be fixed, and new features cannot be added without a complete redeployment and user migration, which can be a costly and disruptive process.I-01

Issue

The SafeToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (e.g., UUPS, Transparent). This design choice means the contract's logic cannot be modified or upgraded after deployment. While this provides immutability and reduces complexity associated with upgrade mechanisms, it also implies that any bugs discovered post-deployment cannot be fixed, and new features cannot be added without a complete redeployment and user migration, which can be a costly and disruptive process.

Fix

Acknowledge the implications of non-upgradeability. If future flexibility for bug fixes or feature enhancements is desired, consider implementing an upgradeable proxy pattern in future contract deployments. If immutability is the explicit goal, ensure thorough testing and auditing are conducted pre-deployment to minimize the risk of unfixable issues.

Status

Unresolved

Info

Redundant Pause Check in unpause()

The unpause() function explicitly includes require(paused(), "SafeToken: token is not paused");. However, the internal _unpause() function, which unpause() calls, is already protected by the whenPaused modifier. This modifier performs the exact same check, making the explicit require statement in unpause() redundant.I-02

Issue

The unpause() function explicitly includes require(paused(), "SafeToken: token is not paused");. However, the internal _unpause() function, which unpause() calls, is already protected by the whenPaused modifier. This modifier performs the exact same check, making the explicit require statement in unpause() redundant.

Fix

Remove the redundant require(paused(), "SafeToken: token is not paused"); statement from the unpause() function. The whenPaused modifier on _unpause() already ensures the contract is paused before attempting to unpause, simplifying the code without affecting functionality.

Status

Unresolved

Analysis

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

The SafeToken contract is an ERC20 token with Pausable and Ownable functionalities, inheriting from OpenZeppelin standards. It includes a TokenRescuer mechanism. The contract is not upgradeable. The primary risks identified relate to the significant centralized control held by the contract owner over token operations and supply, although the owner is a multisig.

Technical8/10Low risk

The technical architecture is straightforward, leveraging battle-tested OpenZeppelin contracts for ERC20, Ownable, and Pausable functionalities (7.1 Architecture). The code quality is high, with clear logic and adherence to Solidity best practices (7.2 Code Security). For instance, the _beforeTokenTransfer hook prevents transfers to the token contract itself, enhancing safety. A minor informational finding notes a redundant check in the unpause() function (I-02).

Governance3/10High risk

The contract exhibits a high degree of centralized control, with the owner possessing the ability to pause/unpause transfers, bypass pause restrictions for their own transfers, and rescue any ERC20 tokens held by the contract (7.3 Access Control, 7.4 Economic). The constructor mints the entire initial supply of 1 billion tokens to the owner, granting significant economic influence (L-01). While the owner is noted to be a multisig, mitigating single-point-of-failure, the inherent power remains centralized (7.5 Governance).

Upgrades7/10Low risk

The SafeToken contract is deployed as a non-upgradeable implementation (7.7 Upgrades). This design choice provides immutability, ensuring the contract's logic remains constant post-deployment. However, it also means that no future bug fixes or feature enhancements can be implemented without a complete redeployment and user migration, which could be a significant operational undertaking (I-01).

Final RecommendationWhat to do about this score

It is recommended to thoroughly review the operational procedures for the owner's multisig, ensuring robust key management and clear decision-making processes given the extensive control over token operations.

Consider implementing a time-lock for critical owner actions, such as unpausing or transferring ownership, to provide a window for community review and reaction. For future iterations, evaluate the trade-offs between immutability and upgradeability, and if flexibility is desired, explore proxy patterns.

Contract & Record

2 audits on record
TypeSafeToken
NetworkEthereum
Token age2y
Contract0x5afe…eeee
Deployer0xd7df…ca26
Badge for your website
Safe Token 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. Jul 27, 202647Medium
  2. Jul 27, 202663Medium

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

Frequently Asked Questions

Is Safe Token a scam?

Based on automated analysis, Safe Token scores 63/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Safe Token safe to buy?

Our scanner flagged a risk score of 63/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Safe Token been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Would You Like a More Detailed Audit of Safe Token?

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