Quantum Audit Logo
Launch App

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

Is Tesla, Inc. Safe?

TSLABBNB 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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 4 Medium · 1 Info6
SummaryAI Copilot

The SecuritiesToken contract, an upgradeable ERC-20 token, implements robust access control, compliance, and pause functionalities, leveraging OpenZeppelin standards.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 4 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 70% (93.0% total → 89.1% effective; 86.6% in EOAs, 6.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 4 Medium 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
6.4%86.6%Wallets7.0%
6.4%86.6%Wallets7.0%
ContractsWalletsEveryone elseBubble area = share of supply
93.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.4%
  • Walletsanonymous holders, free to sell86.6%
  • Everyone elsethe rest of the supply7.0%
Effective concentrationwhat the score reads89.1%
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$375.5K across 8 pairs
Show 2 more pairs

The risk score reads depth across every pair.

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$227.2KShare of depth60.5%
Top-1 Unlocked Holder34.6%
Top-3 Unlocked70.4%
Unlocked LP held by
0xde6a…c0550x556b…d59e0x755a…2c890xd5f7…f8d40x7565…8bb40xd9a2…040b0x1fee…ed6f0xac9c…e5ab0x9a4c…5b260xceef…22be

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

Security Findings

1 High4 Medium1 Info
High

Centralized Control over Token Supply and Critical Parameters

The DEFAULT_ADMIN_ROLE possesses extensive and immediate control over critical token functionalities. This includes the ability to enable/disable minting and burning, set compliance and pause managers, change the token's name, symbol, and identifier, and manage all roles. The ISSUER_ROLE can also mint and burn tokens. This high degree of centralization (7.3 Access Control, 7.4 Economic, 7.5 Governance) means that a single compromised administrative key or malicious administrator could significantly impact the token's supply, functionality, and perceived value without any delay or external oversight.H-01

Issue

The DEFAULT_ADMIN_ROLE possesses extensive and immediate control over critical token functionalities. This includes the ability to enable/disable minting and burning, set compliance and pause managers, change the token's name, symbol, and identifier, and manage all roles. The ISSUER_ROLE can also mint and burn tokens. This high degree of centralization (7.3 Access Control, 7.4 Economic, 7.5 Governance) means that a single compromised administrative key or malicious administrator could significantly impact the token's supply, functionality, and perceived value without any delay or external oversight.

Fix

Implement a multi-signature wallet for the DEFAULT_ADMIN_ROLE to distribute control among multiple trusted parties. For highly sensitive operations, consider integrating a timelock mechanism to introduce a delay before changes take effect, allowing for community review or emergency intervention. Explore options for progressive decentralization of certain administrative powers if feasible for the project's long-term vision.

Status

Unresolved

Medium

Issuers Can Update UI Multiplier

The _authorizeMultiplierUpdate() function, which gates the ability to change the _uiMultiplier, allows both the DEFAULT_ADMIN_ROLE and the ISSUER_ROLE to perform this action. While the _validateMultiplier function enforces bounds (1e9 to 1e27) and _setUIMultiplier limits the effective timestamp to 365 days in the future, granting issuers the power to change this critical parameter (7.3 Access Control, 7.4 Economic) could lead to confusion, misrepresentation of token value, or potential market manipulation if not properly governed or if issuers act maliciously.M-01

Issue

The _authorizeMultiplierUpdate() function, which gates the ability to change the _uiMultiplier, allows both the DEFAULT_ADMIN_ROLE and the ISSUER_ROLE to perform this action. While the _validateMultiplier function enforces bounds (1e9 to 1e27) and _setUIMultiplier limits the effective timestamp to 365 days in the future, granting issuers the power to change this critical parameter (7.3 Access Control, 7.4 Economic) could lead to confusion, misrepresentation of token value, or potential market manipulation if not properly governed or if issuers act maliciously.

Fix

Re-evaluate whether the ISSUER_ROLE should have the authority to update the UI multiplier. If this is an intended feature, ensure that the implications are clearly communicated to token holders and that robust governance procedures are in place for issuers. Consider restricting this power solely to the DEFAULT_ADMIN_ROLE or requiring a multi-signature approval for such changes.

Status

Unresolved

Medium

Reliance on External Client Contracts for Core Logic

The _update function, which is central to all token transfers, calls _checkTokenIsPaused() and _checkIsCompliant(). These functions interact with external PauseManagerClient and ComplianceClient contracts (7.6 External, 7.2 Code Security). The security and integrity of these external contracts are paramount. A vulnerability, compromise, or malicious implementation within these client contracts could directly impact the token's transfer functionality, potentially leading to freezing of funds, unauthorized transfers, or reentrancy issues if the external contracts are not carefully designed and audited.M-02

Issue

The _update function, which is central to all token transfers, calls _checkTokenIsPaused() and _checkIsCompliant(). These functions interact with external PauseManagerClient and ComplianceClient contracts (7.6 External, 7.2 Code Security). The security and integrity of these external contracts are paramount. A vulnerability, compromise, or malicious implementation within these client contracts could directly impact the token's transfer functionality, potentially leading to freezing of funds, unauthorized transfers, or reentrancy issues if the external contracts are not carefully designed and audited.

Fix

Conduct thorough security audits of the PauseManagerClient and ComplianceClient contracts. Ensure that these external contracts are immutable or have robust, timelocked upgrade mechanisms. Implement strict access controls on who can set these client contract addresses. Consider adding circuit breakers or emergency pause mechanisms within the SecuritiesToken itself that can override or disable interactions with potentially compromised external clients.

Status

Unresolved

Medium

Beacon Proxy Centralization Risk

The contract is deployed behind a Beacon Proxy (7.7 Upgrades). While this pattern offers flexible upgradeability and efficient management of multiple proxies, it centralizes control over the contract's logic. The owner of the Beacon contract has the unilateral power to upgrade the implementation for all associated proxies. A compromise of the Beacon owner's key or a malicious action by the owner could lead to a complete and immediate change of the token's functionality, potentially resulting in loss of funds or unauthorized operations (7.5 Governance, 7.8 Operations).M-03

Issue

The contract is deployed behind a Beacon Proxy (7.7 Upgrades). While this pattern offers flexible upgradeability and efficient management of multiple proxies, it centralizes control over the contract's logic. The owner of the Beacon contract has the unilateral power to upgrade the implementation for all associated proxies. A compromise of the Beacon owner's key or a malicious action by the owner could lead to a complete and immediate change of the token's functionality, potentially resulting in loss of funds or unauthorized operations (7.5 Governance, 7.8 Operations).

Fix

Implement a multi-signature wallet for the Beacon owner address to distribute control. Integrate a timelock mechanism for all Beacon upgrade operations to introduce a delay, allowing for community review and mitigating the impact of a compromised key. Clearly document the upgrade process and the role of the Beacon owner.

Status

Unresolved

Medium

Lack of Timelock for Critical Administrative Operations

Several critical administrative functions, such as setMintEnabled, setBurnEnabled, setCompliance, setPauseManager, setName, setSymbol, setIdentifier, and role management functions, can be executed immediately by the DEFAULT_ADMIN_ROLE (7.3 Access Control, 7.8 Operations). The absence of a timelock for these operations means that a single compromised administrative key could instantly make significant, irreversible changes to the token's behavior, parameters, or external dependencies without any warning or opportunity for intervention.M-04

Issue

Several critical administrative functions, such as setMintEnabled, setBurnEnabled, setCompliance, setPauseManager, setName, setSymbol, setIdentifier, and role management functions, can be executed immediately by the DEFAULT_ADMIN_ROLE (7.3 Access Control, 7.8 Operations). The absence of a timelock for these operations means that a single compromised administrative key could instantly make significant, irreversible changes to the token's behavior, parameters, or external dependencies without any warning or opportunity for intervention.

Fix

Integrate a timelock mechanism for all critical administrative functions. This would introduce a mandatory delay between the initiation and execution of sensitive changes, providing a window for detection of malicious activity, community oversight, or emergency response. This significantly reduces the risk associated with a single point of failure.

Status

Unresolved

Info

_checkAdminOrIssuer is Private

The _checkAdminOrIssuer function is declared as private. While it is correctly used by the onlyAdminOrIssuer modifier, making it internal view instead of private view would offer more flexibility (7.1 Architecture, 7.2 Code Security). This would allow inheriting contracts to directly call this function for internal checks without needing to duplicate the logic or rely solely on the modifier, potentially improving code reusability and extensibility for future upgrades or derived contracts.I-01

Issue

The _checkAdminOrIssuer function is declared as private. While it is correctly used by the onlyAdminOrIssuer modifier, making it internal view instead of private view would offer more flexibility (7.1 Architecture, 7.2 Code Security). This would allow inheriting contracts to directly call this function for internal checks without needing to duplicate the logic or rely solely on the modifier, potentially improving code reusability and extensibility for future upgrades or derived contracts.

Fix

Consider changing the visibility of _checkAdminOrIssuer from private to internal view to allow for greater flexibility and reusability by inheriting contracts, if such extensibility is a design goal.

Status

Unresolved

Analysis

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

The SecuritiesToken contract, an upgradeable ERC-20 token, implements robust access control, compliance, and pause functionalities, leveraging OpenZeppelin standards. It features a scalable UI multiplier and controlled mint/burn mechanisms suitable for a securities token. Key strengths include secure upgradeability patterns and input validation. However, the contract exhibits a high degree of centralization, particularly with the DEFAULT_ADMIN_ROLE possessing extensive immediate control over critical token parameters, supply, and external dependencies. The Beacon Proxy pattern also centralizes upgrade authority. Several medium-severity findings highlight these centralization and dependency risks.

Technical4/10Medium risk

The contract demonstrates good adherence to secure coding practices, utilizing OpenZeppelin's upgradeable standards and Solidity 0.8+ for overflow protection. It includes robust input validation for string parameters and zero addresses (7.2 Code Security). The modular architecture with inherited components is well-structured (7.1 Architecture). However, the core transfer logic (_update) relies on external ComplianceClient and PauseManagerClient contracts, introducing a dependency risk where vulnerabilities in these external systems could impact token operations (7.6 External, 7.2 Code Security).

Governance1/10High risk

The SecuritiesToken contract features a strong access control model with DEFAULT_ADMIN_ROLE and ISSUER_ROLE for managing token operations (7.3 Access Control). Minting and burning are controlled by roles and configurable flags, providing flexibility for a securities token (7.4 Economic). However, the DEFAULT_ADMIN_ROLE holds extensive power, including immediate control over minting, burning, compliance, pause managers, and the ability to change the UI multiplier, which presents a high degree of centralization and economic risk (7.5 Governance, 7.4 Economic). The absence of timelocks for critical administrative actions further exacerbates this centralization risk (7.8 Operations).

Upgrades1/10High risk

The contract is designed for upgradeability using the Beacon Proxy pattern, correctly implementing OpenZeppelin's initializer pattern and a __gap storage variable to ensure future compatibility (7.7 Upgrades). This allows for flexible future enhancements and bug fixes. However, the Beacon Proxy pattern centralizes upgrade control with the Beacon owner, meaning a single entity can unilaterally change the contract's logic, posing a significant operational and governance risk (7.7 Upgrades, 7.5 Governance).

Final RecommendationWhat to do about this score

To enhance the security and decentralization posture of the SecuritiesToken, consider implementing a timelock mechanism for all critical administrative functions currently controlled by the DEFAULT_ADMIN_ROLE.

This would introduce a delay for sensitive operations, allowing for community oversight and mitigating the impact of a compromised administrative key. Additionally, thoroughly audit the external ComplianceClient and PauseManagerClient contracts to ensure their security and prevent potential cascading vulnerabilities.

Contract & Record

1 audit on record
TypeBeaconProxy
NetworkBNB Chain
Token age14d
Contract0x5b19…292f
Deployer0x64fd…8d53
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
Tesla, Inc. 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 14, 202696Critical

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

Related Audits

6 more on the recordAll audits
Bless TokenBLESS · BNB Chain97CriticalETHGasGWEI · BNB Chain94CriticalACETokenACE · BNB Chain98CriticalWebKey DAO 2.0WKEYDAO2 · BNB Chain100CriticalPieverse TokenPIEVERSE · BNB Chain100CriticalSnapCoinBNB Chain100Critical

Would You Like a More Detailed Audit of Tesla, Inc. ?

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