Quantum Audit Logo
Launch App

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

Is Tutorial Safe?

TUTBNB Chain
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 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance4/10Upgrades10/10Checks passed5 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
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.

Read the full analysis
What raised the score
  • Top-10 concentration > 70%
  • LP top1 unlocked holder = 63.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
8.9%Contracts81.7%Wallets9.4%Everyone else
8.9%81.7%Wallets9.4%
ContractsWalletsEveryone elseBubble area = share of supply
90.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking8.9%
  • Walletsanonymous holders, free to sell81.7%
  • Everyone elsethe rest of the supply9.4%
Effective concentrationwhat the score reads85.2%
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$2.83M across 28 pairs
Show 4 more pairs

The 18 remaining pairs hold $283 between them and are not listed. The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

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

Security Findings

1 High2 Medium1 Low1 Info
High

Irreversible Transition to MODE_NORMAL

The 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.H-01

Issue

The 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.

Fix

Confirm 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.

Status

Unresolved

Medium

Critical Owner Role for Token Utility

The 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.M-01

Issue

The 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.

Fix

Ensure 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.

Status

Unresolved

Medium

Risk of Permanent Transfer Restriction upon Ownership Renouncement

The 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.M-02

Issue

The 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.

Fix

The 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.

Status

Unresolved

Low

Centralized Control in MODE_TRANSFER_CONTROLLED

When _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.L-01

Issue

When _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.

Fix

Clearly 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.

Status

Unresolved

Info

Fixed Supply Token

The _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.I-01

Issue

The _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.

Fix

Document 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.

Status

Unresolved

Analysis

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

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.

Technical9/10Low risk

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.

Governance4/10Medium risk

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).

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

Prioritize a thorough review of the intended lifecycle and operational procedures for the token's transfer modes, especially the irreversible transition to MODE_NORMAL.

Implement robust key management for the owner address, potentially utilizing a multi-signature wallet, given the critical role the owner plays in enabling token utility and managing transfer restrictions. Ensure all stakeholders are fully aware of the implications of each transfer mode and the permanent nature of certain state changes.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0xcaae…99f3
Deployer0x853d…23cc
Badge for your website
Tutorial 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. Aug 11, 202632Low

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

Related Audits

6 more on the recordAll audits
Bnb Tiger InuBNBTIGER · BNB Chain32LowBREWCATBNB Chain32LowMarina ProtocolBAY · BNB Chain32LowARKBNB Chain33LowmubarakBNB Chain31LowAlaya Governance TokenAGT · BNB Chain31Low

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 Is this your token? Publish your own audit on this page