Quantum Audit Logo

Is TAKE Safe?

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

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

TAKE TAKE
0xe747…e197
BNB Chain
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the TokenImpl contract, deployed as an upgradeable UUPS proxy on BSC, identified a High-severity issue related to irreversible transfer mode changes, alongside Medium-severity concerns regarding custom storage slot usage and highly centralized control. The contract implements standard ERC-20 functionalities with additional pausing and transfer restriction mechanisms.

1 High2 Medium1 Low1 Informational
Volume 24h
$3.56M
Liquidity
$435.4K
Price
$0.05871
Token Age
1y
Top 10 Holders
94.8%

Security Findings

1 High2 Med1 Low1 Info
High

Irreversible Transfer Mode Change

H-01The `setTransferMode` function contains a conditional check `if ($.transferMode != TransferMode.NORMAL)` which prevents any changes to the transfer mode if the current mode is `NORMAL`. This means that once the token's transfer mode is set to `NORMAL`, it cannot be subsequently changed back to `RESTRICTED` or `CONTROLLED`, permanently disabling the ability to impose transfer restrictions. This significantly limits the operational flexibility and emergency response capabilities of the contract administrators.
IssueThe `setTransferMode` function contains a conditional check `if ($.transferMode != TransferMode.NORMAL)` which prevents any changes to the transfer mode if the current mode is `NORMAL`. This means that once the token's transfer mode is set to `NORMAL`, it cannot be subsequently changed back to `RESTRICTED` or `CONTROLLED`, permanently disabling the ability to impose transfer restrictions. This significantly limits the operational flexibility and emergency response capabilities of the contract administrators.
FixRemove or modify the `if ($.transferMode != TransferMode.NORMAL)` condition in the `setTransferMode` function to allow the `transferController` to change the transfer mode regardless of its current state, provided the `newValue` is valid.
StatusUnresolved
Medium

Custom Storage Slot Usage

M-01The contract utilizes a custom storage slot (`TOKEN_STATE_LOCATION`) for the `TokenState` struct via inline assembly. While a large, seemingly random hash is used, this non-standard approach for defining storage locations in an upgradeable contract introduces a risk of storage collisions. Such collisions could occur with OpenZeppelin's internal storage layout in future upgrades or with other custom storage variables, leading to data corruption or unexpected behavior.
IssueThe contract utilizes a custom storage slot (`TOKEN_STATE_LOCATION`) for the `TokenState` struct via inline assembly. While a large, seemingly random hash is used, this non-standard approach for defining storage locations in an upgradeable contract introduces a risk of storage collisions. Such collisions could occur with OpenZeppelin's internal storage layout in future upgrades or with other custom storage variables, leading to data corruption or unexpected behavior.
FixWhile the current hash likely avoids immediate collision, it is generally safer to rely on OpenZeppelin's `_GAP` mechanism for custom storage in upgradeable contracts or to use a more robust method for calculating unique storage slots. If custom assembly is deemed necessary, ensure a thorough analysis of potential collision vectors, including future OpenZeppelin contract versions.
StatusUnresolved
Medium

High Centralization of Control

M-02The contract design grants significant centralized control to specific roles. The `MINTER_ROLE` has unlimited minting and burning capabilities, directly impacting token supply. The `ADMIN_ROLE` can `pause`/`unpause` transfers and set the `transferController`. The `transferController` can then dictate the `transferMode`, which can halt all transfers (`RESTRICTED`) or limit them to the controller (`CONTROLLED`). This concentration of power creates a single point of failure and a high trust requirement in the holders of these roles.
IssueThe contract design grants significant centralized control to specific roles. The `MINTER_ROLE` has unlimited minting and burning capabilities, directly impacting token supply. The `ADMIN_ROLE` can `pause`/`unpause` transfers and set the `transferController`. The `transferController` can then dictate the `transferMode`, which can halt all transfers (`RESTRICTED`) or limit them to the controller (`CONTROLLED`). This concentration of power creates a single point of failure and a high trust requirement in the holders of these roles.
FixImplement multi-signature wallet control for the `DEFAULT_ADMIN_ROLE`, `ADMIN_ROLE`, and `MINTER_ROLE` to distribute control and reduce the risk associated with a single compromised or malicious entity. Consider introducing time-locks for critical administrative actions to provide a window for community review or emergency intervention.
StatusUnresolved
Low

Limited Scope of `burn` Function for MINTER_ROLE

L-01The `burn` function, accessible only by the `MINTER_ROLE`, is implemented as `_burn(msg.sender, amount)`. This means a minter can only burn tokens from their *own* balance. If the intention was for the `MINTER_ROLE` to manage the overall token supply by burning tokens from any address (e.g., a treasury or a specific user's balance), the function signature would typically include an `address from` parameter. As implemented, its utility for general supply management by the minter is limited to their personal holdings.
IssueThe `burn` function, accessible only by the `MINTER_ROLE`, is implemented as `_burn(msg.sender, amount)`. This means a minter can only burn tokens from their *own* balance. If the intention was for the `MINTER_ROLE` to manage the overall token supply by burning tokens from any address (e.g., a treasury or a specific user's balance), the function signature would typically include an `address from` parameter. As implemented, its utility for general supply management by the minter is limited to their personal holdings.
FixClarify the intended functionality of the `burn` function. If the `MINTER_ROLE` should be able to burn tokens from arbitrary addresses, modify the function to accept an `address from` parameter and ensure appropriate access control checks are in place (e.g., `_approve` or `_permit` mechanisms if burning from others' balances). If the current behavior is intended, document this limitation clearly.
StatusUnresolved
Info

Initial Transfer Mode Default to `CONTROLLED`

I-01Upon initialization, the `transferMode` is set to `TransferMode.MAX_VALUE`, which corresponds to `CONTROLLED` mode. In `CONTROLLED` mode, token transfers are restricted such that either the sender or the receiver must be the designated `transferController`. This means that immediately after deployment and initialization, the token's transfer functionality is significantly limited, potentially impacting initial liquidity provision or user interactions.
IssueUpon initialization, the `transferMode` is set to `TransferMode.MAX_VALUE`, which corresponds to `CONTROLLED` mode. In `CONTROLLED` mode, token transfers are restricted such that either the sender or the receiver must be the designated `transferController`. This means that immediately after deployment and initialization, the token's transfer functionality is significantly limited, potentially impacting initial liquidity provision or user interactions.
FixEnsure that all stakeholders are aware of the initial `CONTROLLED` transfer mode and its implications. Clearly communicate the process and conditions under which the `transferMode` can be changed to `NORMAL` (if desired) and the irreversible nature of that change (as per H-01).
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages well-audited OpenZeppelin upgradeable components for its ERC-20, pausing, access control, and reentrancy guard features (7.2 Code Security). The UUPS upgrade mechanism is correctly implemented with `DEFAULT_ADMIN_ROLE` authorization (7.7 Upgrades). However, a High-severity issue exists where the `setTransferMode` function prevents changing the transfer mode from `NORMAL`, making transfer restrictions irreversible if set to `NORMAL` (7.3 Access Control, 7.2 Code Security). Additionally, the use of a custom storage slot for `TokenState` introduces a potential for storage collisions (7.1 Architecture, 7.7 Upgrades).

GovernanceMedium4/10

The contract exhibits a highly centralized governance and economic model, with `MINTER_ROLE`, `ADMIN_ROLE`, and `transferController` possessing significant power over token supply and transferability (7.5 Governance, 7.4 Economic). The `ADMIN_ROLE` can set the `transferController`, who in turn controls the `transferMode`. A critical economic flaw is the inability to re-enable transfer restrictions once the `transferMode` is set to `NORMAL`, which could permanently disable intended control mechanisms (7.4 Economic). The initial `transferMode` is `CONTROLLED`, meaning transfers are restricted from deployment (7.8 Operations).

UpgradesMedium6/10

The contract correctly implements the UUPS upgradeable proxy pattern, with `_authorizeUpgrade` restricted to the `DEFAULT_ADMIN_ROLE` (7.7 Upgrades). This provides a secure mechanism for future contract logic updates. However, the use of a custom storage slot (`TOKEN_STATE_LOCATION`) for `TokenState` introduces a non-standard element that requires careful management to prevent potential storage collisions during future upgrades or modifications (7.1 Architecture, 7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

94.8% in top 10
22.2% in wallets72.6% in contracts
Effective Concentration51.2%

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

$437.0K across 6 pairs
Pancakeswap v3WBNBanalysed$435.4K99.6%UniswapUSDT$9980.2%Pancakeswap v3USDX$5460.1%Pancakeswap v3USDT$940.0%Pancakeswap v2Subject 3$440.0%Pancakeswap v2WBNB$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

5 addresses
Deployer
0x6ca2…4a9a
Unlocked LP Held By
0x5f05…79390x78e7…54340x359e…191d0x987b…5417

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

What Raised This Score

8 factors
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (94.8% total → 51.2% effective; 22.2% in EOAs, 72.6% in contracts — heavy)
  • 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 = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 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
Caldera (ERA)High Risk0GHigh RiskPro Token (PRO)High RiskStarpower Network (STAR)High RiskElonCoinHigh RiskSUMMERHigh Risk

Would You Like a More Detailed Audit of TAKE?

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

Get Detailed Audit