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.

On-chain security analysis — is it a scam or legit?
Is Dimitra Token Safe?
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 →This audit focused on the provided OpenZeppelin AccessControl and AccessControlEnumerable contracts.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking16.8%
- Walletsanonymous holders, free to sell34.8%
- Everyone elsethe rest of the supply48.4%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xfc3a…b2c6No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
InfoImportance 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
DEFAULT_ADMIN_ROLEIssue
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
InfoRecommendation 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
InfoCareful 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
_setupRole FunctionIssue
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
InfoRole 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 4The 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).
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.
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202636Medium
- 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