Quantum Audit Logo
Launch App

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

Is Diem Safe?

DIEMBase
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades3/10Checks passed2 of 5Findings2 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The Diem contract implements an ERC20 token with staking functionalities, including a cooldown period for unstaking.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (94.3% total → 40.5% effective; 4.6% in EOAs, 89.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 High finding(s) from audit
  • 1 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
89.6%Contracts4.6%5.7%Everyone else
89.6%Contracts4.6%5.7%
ContractsWalletsEveryone elseBubble area = share of supply
94.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking89.6%
  • Walletsanonymous holders, free to sell4.6%
  • Everyone elsethe rest of the supply5.7%
Effective concentrationwhat the score reads40.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$11.30M across 14 pairs
Show 4 more pairs

The 4 remaining pairs hold $267 between them and are not listed. 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$6.80MShare of depth60.2%
Top-1 Unlocked Holder31.9%
Top-3 Unlocked62.1%
Unlocked LP held by
0xa076…780f0xf01f…433b0x7d27…fd550xe200…17f80xa376…6ccc0xc02d…1ba30xccc6…94e70xbcff…195e0xfc52…c4870xd746…19a7

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

Security Findings

2 High1 Medium1 Low1 Info
High

Centralized Control by Default Admin Role

The DEFAULT_ADMIN_ROLE in the Diem contract possesses extensive power, including the ability to set the cooldownDuration to any arbitrary value (potentially locking user funds indefinitely) and full management over other roles, such as the critical MINTER_BURNER_ROLE. This high degree of centralization means that the security of the protocol is heavily reliant on the integrity and security of the address holding the DEFAULT_ADMIN_ROLE. A compromise of this single address could lead to severe consequences, including fund locking or unauthorized role assignments.H-01

Issue

The DEFAULT_ADMIN_ROLE in the Diem contract possesses extensive power, including the ability to set the cooldownDuration to any arbitrary value (potentially locking user funds indefinitely) and full management over other roles, such as the critical MINTER_BURNER_ROLE. This high degree of centralization means that the security of the protocol is heavily reliant on the integrity and security of the address holding the DEFAULT_ADMIN_ROLE. A compromise of this single address could lead to severe consequences, including fund locking or unauthorized role assignments.

Fix

Implement a multi-signature wallet for the DEFAULT_ADMIN_ROLE to distribute control and require multiple approvals for sensitive operations. Consider adding a time-lock mechanism for critical administrative actions, such as changing the cooldownDuration or granting/revoking roles, to provide a window for community review or emergency intervention.

Status

Unresolved

High

Critical Dependency on External Minter/Burner Contract

The MINTER_BURNER_ROLE is responsible for controlling the total supply of Diem tokens through the mint and burn functions. The contract's documentation indicates that this role is intended for the StakingV2 contract. This creates a critical external dependency: the economic stability and integrity of the Diem token are directly tied to the security and correct functioning of the StakingV2 contract. Any vulnerability, exploit, or malicious action within StakingV2 could lead to unauthorized minting or burning of Diem, severely impacting its value and the entire ecosystem.H-02

Issue

The MINTER_BURNER_ROLE is responsible for controlling the total supply of Diem tokens through the mint and burn functions. The contract's documentation indicates that this role is intended for the StakingV2 contract. This creates a critical external dependency: the economic stability and integrity of the Diem token are directly tied to the security and correct functioning of the StakingV2 contract. Any vulnerability, exploit, or malicious action within StakingV2 could lead to unauthorized minting or burning of Diem, severely impacting its value and the entire ecosystem.

Fix

Conduct a comprehensive security audit of the StakingV2 contract to identify and mitigate any potential vulnerabilities. Ensure that StakingV2's access control for minting/burning is robust and that its logic is sound. Implement monitoring for mint and burn events to detect anomalous activity quickly. Consider limiting the minting capacity or implementing a rate limit if feasible.

Status

Unresolved

Medium

Cooldown Period Reset on Re-initiation

The initiateUnstake function resets the coolDownEnd timestamp for a user's entire coolDownAmount if they call the function again while an unstake is already pending. While the contract comment notes this behavior ('users can increase amount in cooldown, but have to wait again'), it can lead to an unexpected and potentially frustrating user experience. A user might accidentally or unknowingly reset their cooldown period, forcing them to wait longer for their entire unstaked amount, even if they only intended to add a small additional amount to the cooldown.M-01

Issue

The initiateUnstake function resets the coolDownEnd timestamp for a user's entire coolDownAmount if they call the function again while an unstake is already pending. While the contract comment notes this behavior ('users can increase amount in cooldown, but have to wait again'), it can lead to an unexpected and potentially frustrating user experience. A user might accidentally or unknowingly reset their cooldown period, forcing them to wait longer for their entire unstaked amount, even if they only intended to add a small additional amount to the cooldown.

Fix

Consider modifying the initiateUnstake logic to either: 1) Prevent re-initiating an unstake if one is already pending, or 2) Allow users to add to coolDownAmount without resetting coolDownEnd if the new amount is added before the current cooldown expires. Alternatively, provide clear warnings in the UI about the cooldown reset behavior to prevent accidental delays.

Status

Unresolved

Low

Lack of Maximum Cooldown Duration

The setCooldownDuration function, callable by the DEFAULT_ADMIN_ROLE, allows setting an arbitrary uint256 value for the cooldown period. There is no upper bound or sanity check implemented for this value. While controlled by a trusted administrative role, the absence of a maximum limit could, in a worst-case scenario of a compromised admin key, lead to setting an extremely long or effectively infinite cooldown duration, thereby locking all staked user funds indefinitely.L-01

Issue

The setCooldownDuration function, callable by the DEFAULT_ADMIN_ROLE, allows setting an arbitrary uint256 value for the cooldown period. There is no upper bound or sanity check implemented for this value. While controlled by a trusted administrative role, the absence of a maximum limit could, in a worst-case scenario of a compromised admin key, lead to setting an extremely long or effectively infinite cooldown duration, thereby locking all staked user funds indefinitely.

Fix

Implement a reasonable maximum limit for the cooldownDuration within the setCooldownDuration function. This would act as a safeguard against accidental misconfiguration or malicious intent by a compromised admin, ensuring that users' funds cannot be locked for an excessively long period.

Status

Unresolved

Info

Non-Upgradeable Contract Design

The Diem contract is deployed as a standard, non-proxy contract and does not incorporate any upgradeability patterns (e.g., UUPS, Transparent proxies). This design choice means that any future bug fixes, feature enhancements, or protocol adjustments would necessitate deploying an entirely new contract. Migrating user funds, token balances, and staking state from the old contract to a new one can be a complex, costly, and potentially risky process, requiring significant coordination and user action.I-01

Issue

The Diem contract is deployed as a standard, non-proxy contract and does not incorporate any upgradeability patterns (e.g., UUPS, Transparent proxies). This design choice means that any future bug fixes, feature enhancements, or protocol adjustments would necessitate deploying an entirely new contract. Migrating user funds, token balances, and staking state from the old contract to a new one can be a complex, costly, and potentially risky process, requiring significant coordination and user action.

Fix

For future iterations or new contracts, consider implementing an upgradeable proxy pattern. This would allow for seamless contract upgrades, enabling the protocol to adapt to evolving requirements, fix bugs, and introduce new features without requiring a full redeployment and migration of user assets.

Status

Unresolved

Analysis

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

The Diem contract implements an ERC20 token with staking functionalities, including a cooldown period for unstaking. The contract leverages OpenZeppelin's ERC20 and AccessControl for robust foundational security. Key risks identified include significant centralization of control under the DEFAULT_ADMIN_ROLE and a critical dependency on an external StakingV2 contract for token minting and burning, which directly impacts the token's supply and value. The staking mechanism's cooldown reset behavior also presents a medium-level risk to user experience and fund accessibility.

Technical6/10Medium risk

The Diem contract demonstrates good technical practices, utilizing OpenZeppelin's battle-tested ERC20 and AccessControl libraries (7.2 Code Security). The Solidity version 0.8.26 mitigates common integer overflow/underflow issues. The staking logic correctly handles token transfers and state updates, preventing reentrancy vulnerabilities. However, the contract's reliance on an external StakingV2 for minting/burning introduces an external dependency risk (7.6 External), and the cooldown reset mechanism in initiateUnstake could lead to unexpected user experience issues (7.4 Economic).

Governance2/10High risk

The economic model for Diem involves staking with a cooldown period, which is a standard mechanism (7.4 Economic). However, the contract exhibits high centralization, with the DEFAULT_ADMIN_ROLE having extensive control, including the ability to set the cooldownDuration to arbitrary values and manage the MINTER_BURNER_ROLE (7.3 Access Control). This central authority poses a significant risk if the admin key is compromised. Furthermore, the MINTER_BURNER_ROLE, intended for the StakingV2 contract, directly controls the token supply, making the economic stability of Diem highly dependent on the security and integrity of this external contract (7.5 Governance, 7.6 External).

Upgrades3/10High risk

The Diem contract is not designed with upgradeability in mind (7.7 Upgrades). It is deployed as a standard, non-proxy contract. This design choice means that any future modifications, bug fixes, or feature enhancements would necessitate deploying an entirely new contract and migrating all existing user funds and state, which can be a complex and resource-intensive process. While not a direct vulnerability, it impacts the long-term flexibility and maintainability of the protocol.

Final RecommendationWhat to do about this score

Prioritize securing the DEFAULT_ADMIN_ROLE and the MINTER_BURNER_ROLE addresses, ideally by implementing multi-signature wallets or time-locked governance mechanisms.

Conduct a thorough audit of the StakingV2 contract, which holds the MINTER_BURNER_ROLE, to ensure its robustness against vulnerabilities that could impact Diem's supply. Consider implementing a maximum limit for the cooldownDuration to prevent potential abuse by a compromised admin. Evaluate the user experience implications of the cooldown reset mechanism and consider alternative designs or clearer warnings to users.

Contract & Record

2 audits on record
TypeStaking, Token
NetworkBase
Token age11mo
Contract0xf4d9…a024
Deployer0xdb78…153a
Badge for your website
Diem 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, 202663Medium
  2. Jul 27, 202649Medium
  3. Jul 26, 202668High

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

Frequently Asked Questions

Is Diem a scam?

Based on automated analysis, Diem scores 68/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Diem safe to buy?

Our scanner flagged a risk score of 68/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Diem been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
VelvetBase63MediumjesseBase63MediumRipe DAO Governance TokenRIPE · Base63MediumUmiaBase63MediumLiskLSK · Base63MediumLotto CoinLOTTO · Base63Medium

Would You Like a More Detailed Audit of Diem?

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