Quantum Audit Logo

Is Asentum Safe?

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

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

Asentum ASE
0x041f…80b2
Ethereum
Not verifiedThis 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 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The ASENTUM contract is an ERC20 token with custom access control features for trading enablement and exception lists. The contract leverages OpenZeppelin's `ERC20`, `Ownable`, and `ReentrancyGuard` implementations. While the core ERC20 logic is robust, the extensive owner-controlled mechanisms introduce significant centralization risks and potential for economic manipulation.

1 High2 Medium1 Low1 Informational
Volume 24h
$66.4K
Liquidity
$172.9K
Price
$0.001563
Token Age
4mo
Top 10 Holders
84.7%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control and Potential for Abuse

H-01The contract owner, defined by the `Ownable` pattern, possesses extensive control over critical token functionalities. This includes the ability to enable/disable trading globally via `enableTrading()` and to arbitrarily add or remove addresses from an exception list using `setExceptionStatus()`. This level of centralization introduces a significant single point of failure and a high trust requirement, as the owner could potentially manipulate market conditions, halt trading for non-exception addresses, or create unfair advantages.
IssueThe contract owner, defined by the `Ownable` pattern, possesses extensive control over critical token functionalities. This includes the ability to enable/disable trading globally via `enableTrading()` and to arbitrarily add or remove addresses from an exception list using `setExceptionStatus()`. This level of centralization introduces a significant single point of failure and a high trust requirement, as the owner could potentially manipulate market conditions, halt trading for non-exception addresses, or create unfair advantages.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract owner to distribute control and require multiple approvals for critical operations. Alternatively, explore time-locks or community governance mechanisms for sensitive functions like `enableTrading()` and `setExceptionStatus()` to reduce the risk of malicious or erroneous actions.
StatusUnresolved
Medium

Trading Pause Mechanism (Denial of Service Risk)

M-01The `tradingEnabled` flag, controlled by the owner, allows for the complete pausing of token transfers for all addresses not on the exception list. While intended as an emergency measure, this mechanism can lead to a denial of service for legitimate users, preventing them from transferring their tokens. This could be exploited to freeze liquidity or manipulate market sentiment.
IssueThe `tradingEnabled` flag, controlled by the owner, allows for the complete pausing of token transfers for all addresses not on the exception list. While intended as an emergency measure, this mechanism can lead to a denial of service for legitimate users, preventing them from transferring their tokens. This could be exploited to freeze liquidity or manipulate market sentiment.
FixIf a pause mechanism is deemed essential, consider implementing a time-locked pause or a pause with a predefined duration to prevent indefinite freezing of funds. Clearly document the conditions under which trading can be paused and the expected duration. Ensure that the pause mechanism cannot be used to permanently lock user funds.
StatusUnresolved
Medium

Exception List Manipulation Risk

M-02The `isException` mapping allows the owner to grant or revoke transfer privileges for specific addresses, bypassing the `tradingEnabled` restriction. This power, while offering flexibility, could be abused to create a whitelist of favored addresses or a blacklist of disfavored ones, leading to an unfair and centralized control over who can trade the token.
IssueThe `isException` mapping allows the owner to grant or revoke transfer privileges for specific addresses, bypassing the `tradingEnabled` restriction. This power, while offering flexibility, could be abused to create a whitelist of favored addresses or a blacklist of disfavored ones, leading to an unfair and centralized control over who can trade the token.
FixDefine clear, transparent policies for how the exception list will be managed and under what circumstances addresses will be added or removed. Consider implementing a public log or event for all changes to the exception list to enhance transparency. If possible, limit the scope or duration of exceptions, or introduce a community-driven process for managing this list.
StatusUnresolved
Low

Unnecessary ReentrancyGuard Implementation

L-01The contract inherits `ReentrancyGuard`, but its core ERC20 transfer functions (`_transfer`, `_mint`, `_burn`) do not involve external calls that could lead to reentrancy. The `_beforeTokenTransfer` and `_afterTokenTransfer` hooks are also not overridden to introduce external calls in the provided code. Therefore, the `nonReentrant` modifier is not applied to any function where it would provide a security benefit, making its inclusion largely redundant.
IssueThe contract inherits `ReentrancyGuard`, but its core ERC20 transfer functions (`_transfer`, `_mint`, `_burn`) do not involve external calls that could lead to reentrancy. The `_beforeTokenTransfer` and `_afterTokenTransfer` hooks are also not overridden to introduce external calls in the provided code. Therefore, the `nonReentrant` modifier is not applied to any function where it would provide a security benefit, making its inclusion largely redundant.
FixRemove the `ReentrancyGuard` inheritance and associated code if no external calls are intended within the token transfer hooks or other critical functions. This will reduce contract complexity, deployment size, and potentially save gas on deployments and interactions, as the `_status` variable and its updates are no longer needed.
StatusUnresolved
Info

Hardcoded Uniswap Router Address

I-01The `uniswapRouter` address is hardcoded as a public constant within the contract. While this is a common practice for known, stable addresses, it limits flexibility. If the Uniswap router address changes in the future (e.g., due to an upgrade or migration) or if the protocol wishes to integrate with a different DEX, the contract would need to be redeployed.
IssueThe `uniswapRouter` address is hardcoded as a public constant within the contract. While this is a common practice for known, stable addresses, it limits flexibility. If the Uniswap router address changes in the future (e.g., due to an upgrade or migration) or if the protocol wishes to integrate with a different DEX, the contract would need to be redeployed.
FixConsider making critical external addresses configurable by the owner (e.g., via an `onlyOwner` function) or through a governance mechanism. This allows for adaptability to future ecosystem changes without requiring a full contract redeployment. If the address is truly immutable and no other DEX integrations are planned, this can remain as is.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The ASENTUM contract is built upon well-audited OpenZeppelin libraries, providing a solid foundation for its ERC20 functionality (7.1 Architecture, 7.2 Code Security). The use of `unchecked` blocks for arithmetic operations is correctly applied after necessary `require` checks, optimizing gas usage without introducing overflow/underflow vulnerabilities. However, the inclusion of `ReentrancyGuard` is largely unnecessary for a standard ERC20 token, adding complexity without a clear security benefit in this context (7.2 Code Security).

GovernanceMedium6/10

The contract exhibits a high degree of centralized control through the `Ownable` pattern (7.3 Access Control). The owner has exclusive power to enable/disable trading and manage an exception list, which can whitelist or blacklist addresses from trading restrictions (7.4 Economic). This centralization introduces a single point of failure and a significant trust requirement, as the owner could potentially manipulate market conditions or deny service to users (7.8 Operations). The initial mint of all tokens to the deployer further concentrates power (7.4 Economic).

UpgradesLow8/10

The ASENTUM contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no specific upgrade safety concerns related to proxy patterns. Any future changes to the contract logic would require deploying a new contract and migrating assets, which is a standard procedure for non-upgradeable contracts.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

84.7% in top 10
14.4% in wallets70.3% in contracts
Effective Concentration42.5%

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

$172.9K

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 Locked100.0% · Null Address, TeamFinance

Key Addresses

1 addresses
Deployer
0xb6e4…cb81

What Raised This Score

5 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 30% (84.7% total → 42.5% effective; 14.4% in EOAs, 70.3% 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

Related Audits

6 more on the record
Safe Token (SAFE)High RiskLQTYHigh RiskBiconomy (BICO)Medium RiskVestra DAO (VSTR)High RiskMOMOHigh RiskLisk (LSK)Medium Risk

Would You Like a More Detailed Audit of Asentum?

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

Get Detailed Audit