Quantum Audit Logo

Is Tesla, Inc. Safe?

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

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

Tesla, Inc. TSLAB
0x5b19…292f
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High4 Medium1 Informational
Volume 24h
$590.2K
Liquidity
$227.2K
Price
$369.3800
Token Age
14d
Top 10 Holders
93.0%

Security Findings

1 High4 Med1 Info
High

Centralized Control over Token Supply and Critical Parameters

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Issuers Can Update UI Multiplier

M-01The `_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.
IssueThe `_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.
FixRe-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.
StatusUnresolved
Medium

Reliance on External Client Contracts for Core Logic

M-02The `_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.
IssueThe `_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.
FixConduct 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.
StatusUnresolved
Medium

Beacon Proxy Centralization Risk

M-03The 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).
IssueThe 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).
FixImplement 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.
StatusUnresolved
Medium

Lack of Timelock for Critical Administrative Operations

M-04Several 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.
IssueSeveral 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.
FixIntegrate 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.
StatusUnresolved
Info

`_checkAdminOrIssuer` is Private

I-01The `_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.
IssueThe `_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.
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

93.0% in top 10
86.6% in wallets6.4% in contracts
Effective Concentration89.1%

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

$375.5K across 8 pairs
Pancakeswap v3USDTanalysed$227.2K60.5%Pancakeswap v3USDT$86.9K23.1%UniswapUSDT$55.9K14.9%Pancakeswap v3WBNB$3.7K1.0%Pancakeswap v2WBNB$9840.3%Pancakeswap v3BTCB$8630.2%
Show 2 more pairsShow less
Pancakeswap v2USDT$20.0%Pancakeswap v3SPCXB$00.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 Holder34.6%
Top-3 Unlocked70.4%

Key Addresses

11 addresses
Deployer
0x64fd…8d53
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.

What Raised This Score

9 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

Related Audits

6 more on the record
Bless Token (BLESS)Critical RiskETHGas (GWEI)Critical RiskACEToken (ACE)Critical RiskWebKey DAO 2.0 (WKEYDAO2)Critical RiskPieverse Token (PIEVERSE)Critical RiskSnapCoinCritical Risk

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