Quantum Audit Logo

Is Tutorial Safe?

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

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

Tutorial TUT
0xcaae…99f3
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of the Token contract, an ERC20-compliant token with custom transfer restrictions, identified several design-level risks related to its `_mode` mechanism and owner privileges. While the core ERC20 implementation is robust, the irreversible nature of mode changes and the critical dependency on owner actions for token utility present significant operational and economic considerations. The contract is not upgradeable and has a fixed supply.

1 High2 Medium1 Low1 Informational
Volume 24h
$701.5K
Liquidity
$2.79M
Price
$0.02396
Token Age
1y
Top 10 Holders
90.6%

Security Findings

1 High2 Med1 Low1 Info
High

Irreversible Transition to MODE_NORMAL

H-01The `setMode` function includes a condition `if (_mode != MODE_NORMAL)` which means that once the token's transfer mode is set to `MODE_NORMAL`, it can never be reverted to `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`. This makes the transition to fully unrestricted transfers irreversible, limiting future flexibility for the project to re-introduce transfer controls if needed.
IssueThe `setMode` function includes a condition `if (_mode != MODE_NORMAL)` which means that once the token's transfer mode is set to `MODE_NORMAL`, it can never be reverted to `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`. This makes the transition to fully unrestricted transfers irreversible, limiting future flexibility for the project to re-introduce transfer controls if needed.
FixConfirm if this irreversible transition is the intended design. If flexibility to re-impose restrictions is desired, remove the `if (_mode != MODE_NORMAL)` condition. If it is intended, ensure this critical design decision is clearly documented and communicated to all users and stakeholders.
StatusUnresolved
Medium

Critical Owner Role for Token Utility

M-01The `Token` contract initializes with `_mode = MODE_TRANSFER_RESTRICTED`, meaning no transfers are possible until the owner explicitly calls `setMode` to change it. This places a critical dependency on the owner to perform an operational step to enable the token's basic utility, creating a single point of failure if the owner key is compromised or lost.
IssueThe `Token` contract initializes with `_mode = MODE_TRANSFER_RESTRICTED`, meaning no transfers are possible until the owner explicitly calls `setMode` to change it. This places a critical dependency on the owner to perform an operational step to enable the token's basic utility, creating a single point of failure if the owner key is compromised or lost.
FixEnsure robust key management practices for the owner address, such as using a multi-signature wallet. Clearly document the operational steps required to activate token transfers and the associated risks if these steps are not performed or the owner key is compromised.
StatusUnresolved
Medium

Risk of Permanent Transfer Restriction upon Ownership Renouncement

M-02The `Ownable` contract allows the owner to `renounceOwnership()`. If ownership is renounced while `_mode` is `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`, and `_mode` has not been set to `MODE_NORMAL`, the token's transferability could become permanently locked or restricted as there would be no owner to call `setMode`.
IssueThe `Ownable` contract allows the owner to `renounceOwnership()`. If ownership is renounced while `_mode` is `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`, and `_mode` has not been set to `MODE_NORMAL`, the token's transferability could become permanently locked or restricted as there would be no owner to call `setMode`.
FixThe owner should ensure the `_mode` is set to the desired final state (e.g., `MODE_NORMAL`) *before* considering renouncing ownership. If renouncing ownership is planned, this operational sequence is critical to prevent unintended permanent restrictions.
StatusUnresolved
Low

Centralized Control in MODE_TRANSFER_CONTROLLED

L-01When `_mode` is set to `MODE_TRANSFER_CONTROLLED`, only transfers where the `from` or `to` address is the contract owner are permitted. This effectively centralizes all token movement through the owner, which might not align with user expectations for a decentralized token and could be perceived as a high degree of control.
IssueWhen `_mode` is set to `MODE_TRANSFER_CONTROLLED`, only transfers where the `from` or `to` address is the contract owner are permitted. This effectively centralizes all token movement through the owner, which might not align with user expectations for a decentralized token and could be perceived as a high degree of control.
FixClearly communicate the implications of `MODE_TRANSFER_CONTROLLED` to token holders, emphasizing the owner's centralized role in facilitating transfers during this phase. Ensure transparency regarding the project's intent for this mode.
StatusUnresolved
Info

Fixed Supply Token

I-01The `_mint` and `_burn` functions are internal and only `_mint` is called once in the constructor. There are no public functions to mint or burn tokens after deployment, meaning the total supply is fixed at the amount specified during construction.
IssueThe `_mint` and `_burn` functions are internal and only `_mint` is called once in the constructor. There are no public functions to mint or burn tokens after deployment, meaning the total supply is fixed at the amount specified during construction.
FixDocument that the token has a fixed supply and no further minting or burning is possible after deployment. This clarifies the tokenomics for potential holders and investors.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract utilizes standard OpenZeppelin patterns for ERC20 and Ownable functionalities, demonstrating good code quality (7.2 Code Security). `unchecked` blocks are used appropriately, safeguarded by preceding `require` statements. However, the `setMode` function's irreversible transition to `MODE_NORMAL` represents a technical design decision with permanent implications for token transferability (7.1 Architecture), which could be a source of future operational inflexibility.

GovernanceMedium4/10

The token's economic utility is heavily dependent on the owner's actions due to its initial `MODE_TRANSFER_RESTRICTED` state (7.4 Economic, 7.8 Operations). The `setMode` function allows the owner to transition through different transfer restriction levels, but the change to `MODE_NORMAL` is irreversible, permanently removing the ability to re-impose restrictions (7.5 Governance). Furthermore, renouncing ownership while in a restricted mode could permanently lock token transfers, posing a significant risk (7.3 Access Control).

UpgradesLow10/10

The contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). There are no proxy patterns or upgrade mechanisms present, meaning its logic cannot be altered after deployment. This eliminates upgrade-related risks but also removes the possibility of fixing design flaws or adding new features post-deployment.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

90.6% in top 10
81.7% in wallets8.9% in contracts
Effective Concentration85.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

$2.83M across 28 pairs
Pancakeswap v3WBNBanalysed$2.79M98.8%UniswapUSDT$21.5K0.8%Pancakeswap v3USDT$12.0K0.4%Pancakeswap v2Astherus$1490.0%Pancakeswap v2WBNB$1490.0%Pancakeswap v2TENGE$950.0%
Show 4 more pairsShow less
Pancakeswap v2naiive$760.0%Pancakeswap v2gorilla$720.0%Pancakeswap v2priceless$580.0%Pancakeswap v3USD1$550.0%

The 18 remaining pairs hold $283 between them and are not listed.

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 Burned0.1%
LP Locked36.8% · Dead Address, GoPlus SafeToken Locker
Top-1 Unlocked Holder63.0%
Top-3 Unlocked63.2%

Key Addresses

9 addresses
Deployer
0x853d…23cc
Unlocked LP Held By
0x5036…6a200xfd85…0a220x49f4…7c930xa80e…61f00x1a70…fb990x59eb…d05f0x6a85…cf030x6084…6065

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

What Raised This Score

5 factors
  • Top-10 concentration > 70% (90.6% total → 85.2% effective; 81.7% in EOAs, 8.9% in contracts — extreme)
  • LP top1 unlocked holder = 63.0% (independent LP — depth risk, pool = 99% 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
Bnb Tiger Inu (BNBTIGER)Medium RiskARKMedium RiskmubarakMedium RiskAlaya Governance Token (AGT)Medium RiskCheese Head (CHEESE)Medium Risk牛来Medium Risk

Would You Like a More Detailed Audit of Tutorial?

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

Get Detailed Audit