Quantum Audit Logo

Is DORA Safe?

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

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

DORA DORA
0x23fe…8888
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 8d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The TokenV2 contract is an upgradeable ERC20 token utilizing OpenZeppelin's upgradeable libraries. It implements custom transfer restrictions preventing interaction with specified Uniswap pools, which can be removed by the owner. The contract exhibits good code quality and follows standard upgradeability patterns. However, significant centralization risks exist due to the owner's control over the entire token supply and the ability to unilaterally disable critical transfer constraints, leading to a High overall risk level.

1 High2 Medium1 Low2 Informational
Volume 24h
$370.4K
Liquidity
$163.8K
Price
$0.002756
Token Age
1y
Top 10 Holders
5.2%

Security Findings

1 High2 Med1 Low2 Info
High

Centralized Control Over Transfer Constraints and Token Supply

H-01The `owner` of the contract has complete and unilateral control over two critical aspects: 1) The entire `maxSupply` of tokens is minted to the `msg.sender` (the owner/initializer) during initialization, meaning the owner holds 100% of the initial token supply. 2) The `removeTransferConstraints()` function, callable only by the owner, can permanently disable the restrictions on transferring tokens to/from Uniswap V2 and V3 pools. This level of centralization introduces significant trust assumptions and a single point of failure, as a compromised owner key could lead to market manipulation or unintended token behavior.
IssueThe `owner` of the contract has complete and unilateral control over two critical aspects: 1) The entire `maxSupply` of tokens is minted to the `msg.sender` (the owner/initializer) during initialization, meaning the owner holds 100% of the initial token supply. 2) The `removeTransferConstraints()` function, callable only by the owner, can permanently disable the restrictions on transferring tokens to/from Uniswap V2 and V3 pools. This level of centralization introduces significant trust assumptions and a single point of failure, as a compromised owner key could lead to market manipulation or unintended token behavior.
FixImplement a multi-signature wallet for the contract's ownership to distribute control and reduce the risk of a single point of failure. Consider a more decentralized initial token distribution mechanism if the project aims for community governance or broader participation. For the `removeTransferConstraints` function, evaluate if a time-locked or governance-controlled mechanism would be more appropriate than immediate owner-only execution.
StatusUnresolved
Medium

Irreversible Removal of Transfer Constraints

M-01The `removeTransferConstraints()` function allows the owner to set the `transferConstraints` flag to `false`. Once set to `false`, there is no corresponding function to re-enable these constraints. This design choice makes the removal of transfer restrictions irreversible, which might not be desired in all scenarios, especially if market conditions or regulatory requirements change and necessitate re-implementing such controls.
IssueThe `removeTransferConstraints()` function allows the owner to set the `transferConstraints` flag to `false`. Once set to `false`, there is no corresponding function to re-enable these constraints. This design choice makes the removal of transfer restrictions irreversible, which might not be desired in all scenarios, especially if market conditions or regulatory requirements change and necessitate re-implementing such controls.
FixIf future scenarios might require re-enabling transfer constraints, consider adding a function (also `onlyOwner` or governance-controlled) to set `transferConstraints` back to `true`. Alternatively, clearly document this irreversible behavior as an intended design decision.
StatusUnresolved
Medium

Potential for Storage Collisions in Future Upgrades

M-02The contract introduces several custom state variables (`maxSupply`, `metaURI`, `transferConstraints`, `uniswapV2Pool`, `uniswapV3Pool`) in addition to those inherited from OpenZeppelin's upgradeable contracts. While the current implementation is correct, future upgrades must carefully manage storage slots to avoid collisions. Adding new state variables in an upgrade without proper slot management (e.g., appending new variables at the end of the storage layout) could overwrite existing data, leading to critical state corruption.
IssueThe contract introduces several custom state variables (`maxSupply`, `metaURI`, `transferConstraints`, `uniswapV2Pool`, `uniswapV3Pool`) in addition to those inherited from OpenZeppelin's upgradeable contracts. While the current implementation is correct, future upgrades must carefully manage storage slots to avoid collisions. Adding new state variables in an upgrade without proper slot management (e.g., appending new variables at the end of the storage layout) could overwrite existing data, leading to critical state corruption.
FixAdhere strictly to OpenZeppelin's upgradeability guidelines for storage management. When performing upgrades, always append new state variables to the end of the contract's storage layout. Utilize tools like `hardhat-upgrades` or `truffle-upgrades` to assist in detecting and preventing storage collisions during development and deployment of new versions.
StatusUnresolved
Low

No Event for `removeTransferConstraints`

L-01The `removeTransferConstraints()` function modifies the `transferConstraints` state variable, which is a critical operational change for the token. However, no event is emitted upon its execution. While `transferConstraints` is a public variable and its state can be read, an event would provide a more efficient and reliable way for off-chain systems (e.g., block explorers, dApps, monitoring services) to track this significant change.
IssueThe `removeTransferConstraints()` function modifies the `transferConstraints` state variable, which is a critical operational change for the token. However, no event is emitted upon its execution. While `transferConstraints` is a public variable and its state can be read, an event would provide a more efficient and reliable way for off-chain systems (e.g., block explorers, dApps, monitoring services) to track this significant change.
FixEmit an event, such as `TransferConstraintsRemoved(address indexed owner)`, within the `removeTransferConstraints()` function to provide clear and auditable signaling of this state change.
StatusUnresolved
Info

Dependency on OpenZeppelin Upgradeable Contracts

I-01The contract heavily relies on OpenZeppelin's upgradeable contracts (`ERC20Upgradeable`, `ERC20PermitUpgradeable`, `OwnableUpgradeable`). While these libraries are widely used and well-audited, any undiscovered vulnerability in these external dependencies could indirectly affect the security of the TokenV2 contract.
IssueThe contract heavily relies on OpenZeppelin's upgradeable contracts (`ERC20Upgradeable`, `ERC20PermitUpgradeable`, `OwnableUpgradeable`). While these libraries are widely used and well-audited, any undiscovered vulnerability in these external dependencies could indirectly affect the security of the TokenV2 contract.
FixRegularly monitor OpenZeppelin's security advisories and ensure that the project's dependencies are kept up-to-date with the latest secure versions. Consider pinning specific versions of OpenZeppelin contracts to ensure deterministic behavior.
StatusUnresolved
Info

Initial Mint to Initializer

I-02During the `initialize` function, the entire `maxSupply` of tokens is minted to `msg.sender`. This is a common pattern for fixed-supply tokens where the deployer or a designated address holds the initial supply. However, it means the initial distribution is entirely centralized to one address.
IssueDuring the `initialize` function, the entire `maxSupply` of tokens is minted to `msg.sender`. This is a common pattern for fixed-supply tokens where the deployer or a designated address holds the initial supply. However, it means the initial distribution is entirely centralized to one address.
FixThis is an intended design choice. Ensure that the implications of this initial distribution are clearly communicated to users and stakeholders. If a more decentralized distribution is desired, consider implementing a vesting schedule, airdrop mechanism, or other distribution strategies post-initialization.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The TokenV2 contract demonstrates good technical architecture (7.1) by extending well-audited OpenZeppelin upgradeable contracts for ERC20, ERC20Permit, and Ownable functionalities. Code security (7.2) is generally strong, with no apparent reentrancy or integer overflow vulnerabilities. The `_beforeTokenTransfer` hook correctly implements conditional transfer restrictions. Access control (7.3) is appropriately enforced for critical functions like `removeTransferConstraints` via `onlyOwner`. However, the centralized nature of this control introduces a technical risk, as a single compromised owner key could disable core token mechanics.

GovernanceLow9/10

The economic model (7.4) of TokenV2 presents significant centralization. The entire `maxSupply` is minted to the contract initializer (owner), giving the owner 100% of the initial token supply. Furthermore, the owner has unilateral control over the `transferConstraints` via `removeTransferConstraints`, which can irreversibly disable restrictions on trading with Uniswap pools. This level of centralized governance (7.5) means the project's economic stability and market behavior are heavily dependent on the owner's actions and security. There are no external (7.6) oracle dependencies or complex DeFi interactions beyond the restricted pool addresses.

UpgradesLow10/10

The contract is designed for upgradeability (7.7) using OpenZeppelin's `Upgradeable` pattern, correctly employing an empty constructor and an `initializer` function. This approach allows for future logic modifications without deploying a new token. However, adding new state variables in future upgrades requires careful planning to prevent storage collisions with existing custom variables like `maxSupply`, `metaURI`, `transferConstraints`, `uniswapV2Pool`, and `uniswapV3Pool`. The operational (7.8) aspect of upgrades is standard for this pattern, requiring the owner to manage the proxy.

Security Checklist

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

Holder Composition

5.2% in top 10
1.3% in wallets3.9% in contracts
Effective Concentration2.9%

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

$163.8K across 2 pairs
Pancakeswap v3USD1analysed$163.8K100.0%Pancakeswap v2Subject 3$110.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

LP Locked100.0% · UNCX Locker

Key Addresses

1 addresses
Deployer
0x830c…6f89

What Raised This Score

3 factors
  • 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
REAL WORLD APPAREL (JACKET)Low Risk富贵Low RiskpricelessLow RiskTCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow Risk

Would You Like a More Detailed Audit of DORA?

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

Get Detailed Audit