Quantum Audit Logo
Launch App

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

Is Dimitra Token Safe?

DMTREthereum
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
SummaryAI Copilot

This audit focused on the provided OpenZeppelin AccessControl and AccessControlEnumerable contracts.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30%
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • LP claimed locked but only 0.0% actually locked
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30% (51.6% total → 41.5% effective; 34.8% in EOAs, 16.8% in contracts — moderate)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked

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 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
16.8%Contracts34.8%Wallets48.4%Everyone else
16.8%34.8%Wallets48.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
51.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking16.8%
  • Walletsanonymous holders, free to sell34.8%
  • Everyone elsethe rest of the supply48.4%
Effective concentrationwhat the score reads41.5%
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$158.5K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$152.7KShare of depth96.4%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xfc3a…b2c6

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

Security Findings

4 Info
Info

Importance of Securing DEFAULT_ADMIN_ROLE

The DEFAULT_ADMIN_ROLE in the AccessControl contract holds the highest level of privilege, capable of granting and revoking all other roles, including itself. A compromise of an address holding this role would grant an attacker complete control over the contract's access control mechanisms, potentially leading to unauthorized operations or manipulation of the system (7.3 Access Control, 7.8 Operations).I-01

Issue

The DEFAULT_ADMIN_ROLE in the AccessControl contract holds the highest level of privilege, capable of granting and revoking all other roles, including itself. A compromise of an address holding this role would grant an attacker complete control over the contract's access control mechanisms, potentially leading to unauthorized operations or manipulation of the system (7.3 Access Control, 7.8 Operations).

Fix

Ensure that the address(es) assigned the DEFAULT_ADMIN_ROLE are highly secured. Ideally, this role should be controlled by a multi-signature wallet with a sufficient number of signers, or a time-lock contract, to prevent a single point of failure and provide a delay for critical changes.

Status

Unresolved

Info

Recommendation for Multi-signature and Time-lock for Critical Roles

While the AccessControl contract provides robust role management, it does not inherently enforce multi-signature or time-lock mechanisms. For critical roles that control significant protocol functions or assets, relying on a single externally owned account (EOA) or even a simple multi-sig without a time-lock can introduce operational risks (7.3 Access Control, 7.8 Operations).I-02

Issue

While the AccessControl contract provides robust role management, it does not inherently enforce multi-signature or time-lock mechanisms. For critical roles that control significant protocol functions or assets, relying on a single externally owned account (EOA) or even a simple multi-sig without a time-lock can introduce operational risks (7.3 Access Control, 7.8 Operations).

Fix

For any roles that have significant control over the protocol (e.g., pausing, upgrading, managing funds, or the DEFAULT_ADMIN_ROLE), consider implementing a multi-signature wallet (e.g., Gnosis Safe) and/or a time-lock contract. This adds an extra layer of security by requiring multiple approvals and/or a delay period before critical actions can be executed.

Status

Unresolved

Info

Careful Use of _setupRole Function

The _setupRole internal function bypasses the onlyRole modifier, meaning it does not check if the caller has the necessary admin role to grant a new role. The OpenZeppelin documentation explicitly warns that this function 'should only be called from the constructor when setting up the initial roles for the system.' Misuse of this function outside the constructor could lead to unauthorized role grants, circumventing the intended access control hierarchy (7.2 Code Security, 7.3 Access Control).I-03

Issue

The _setupRole internal function bypasses the onlyRole modifier, meaning it does not check if the caller has the necessary admin role to grant a new role. The OpenZeppelin documentation explicitly warns that this function 'should only be called from the constructor when setting up the initial roles for the system.' Misuse of this function outside the constructor could lead to unauthorized role grants, circumventing the intended access control hierarchy (7.2 Code Security, 7.3 Access Control).

Fix

Developers integrating AccessControl should strictly adhere to the documented usage of _setupRole, calling it only within the contract's constructor for initial setup. Any other use should be carefully reviewed and justified, as it effectively bypasses the admin system.

Status

Unresolved

Info

Role Management Best Practices and Documentation

As the system grows, the number of roles and their interdependencies can become complex. Without clear documentation and strict operational procedures, there is a risk of misconfiguring roles, granting excessive permissions, or failing to revoke roles from compromised or inactive accounts. This can lead to unintended access or operational inefficiencies (7.3 Access Control, 7.8 Operations).I-04

Issue

As the system grows, the number of roles and their interdependencies can become complex. Without clear documentation and strict operational procedures, there is a risk of misconfiguring roles, granting excessive permissions, or failing to revoke roles from compromised or inactive accounts. This can lead to unintended access or operational inefficiencies (7.3 Access Control, 7.8 Operations).

Fix

Maintain comprehensive documentation of all defined roles, their associated permissions, and the addresses assigned to each role. Establish clear operational procedures for granting, revoking, and changing role administrators. Regularly audit assigned roles and permissions to ensure they align with current operational needs and security policies.

Status

Unresolved

Analysis

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

This audit focused on the provided OpenZeppelin AccessControl and AccessControlEnumerable contracts. The source code for the main DimitraToken contract (0x51cb253744189f11241becb29bedd3f1b5384fdb) was not provided, significantly limiting the scope of this security review to the foundational access control mechanisms. The provided OpenZeppelin contracts are well-audited and robust. Findings primarily relate to best practices for deploying and managing roles within an AccessControl system.

Technical8/10Low risk

The provided AccessControl and AccessControlEnumerable contracts are standard OpenZeppelin implementations, which are highly regarded for their security and adherence to best practices (7.2 Code Security). They offer a robust, role-based access control system, allowing granular permissions management. The code is well-structured, uses clear variable names, and includes comprehensive NatSpec documentation. No direct vulnerabilities were identified within these specific contracts (7.1 Architecture).

Governance3/10High risk

Without the DimitraToken contract source, a comprehensive review of economic and governance aspects (7.4 Economic, 7.5 Governance) is not possible. However, the AccessControl module provides a solid foundation for implementing governance by defining roles and permissions. The primary economic risk related to AccessControl is the potential compromise of administrative roles, which could lead to unauthorized actions affecting token supply or functionality.

Upgrades6/10Medium risk

The provided contracts are not proxy implementations (7.7 Upgrades). The prefill indicates is_proxy: false. Therefore, upgradeability concerns are not directly applicable to these specific contracts. If the DimitraToken contract uses a proxy pattern, its upgrade mechanism would require separate review for potential vulnerabilities related to upgrade safety.

Final RecommendationWhat to do about this score

It is strongly recommended to conduct a full security audit of the DimitraToken contract and any other associated contracts that comprise the Dimitra protocol.

This audit was limited to the provided OpenZeppelin AccessControl modules, which are secure by design. For the overall system, ensure that critical administrative roles, particularly the DEFAULT_ADMIN_ROLE, are secured by multi-signature wallets and/or time-locks to mitigate single points of failure and provide a robust governance framework. Implement clear operational procedures for role management and regularly review assigned permissions.

Contract & Record

1 audit on record
TypeDimitraToken
NetworkEthereum
Token age4y
Contract0x51cb…4fdb
Deployer0x7d15…a3bc
Badge for your website
Dimitra Token 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. Sep 4, 202636Medium
  2. Sep 2, 202651Medium

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

Frequently Asked Questions

What is the DMTR contract address?

The Dimitra Token (DMTR) contract on Ethereum is 0x51cb253744189f11241becb29bedd3f1b5384fdb. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Dimitra Token a scam?

Quantum Audit's risk score for Dimitra Token is 36/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is DMTR liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $158.5K.

Who holds DMTR?

As of Sep 4, 2026, the 10 largest holders own 51.6% of the supply. The Holders section on this page shows who they are by holder type.

Would You Like a More Detailed Audit of Dimitra Token?

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