Is Diem Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Low1 Info

High

Centralized Control by Default Admin Role

H-01The `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.

IssueThe `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.

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

StatusUnresolved

High

Critical Dependency on External Minter/Burner Contract

H-02The `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.

IssueThe `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.

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

StatusUnresolved

Medium

Cooldown Period Reset on Re-initiation

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Lack of Maximum Cooldown Duration

L-01The `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.

IssueThe `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.

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

StatusUnresolved

Info

Non-Upgradeable Contract Design

I-01The `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.

IssueThe `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.

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh2/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

94.3% in top 10

4.6% in wallets89.6% in contracts

Effective Concentration40.5%

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

$11.30M across 14 pairs

AerodromeVVVanalysed$6.80M AerodromeVVV$4.03M Uniswap v3WETH$271.7K AerodromeUSDC$136.2K Uniswap v4cbBTC$57.4K AerodromeVVV$3.6K

Show 4 more pairsShow less

0x7Ca1…1C40VVV$2.5K Uniswap v4kDIEM$1.8K AerodromeUSDC$163 AerodromeAERO$130

The 4 remaining pairs hold $267 between them and are not listed.

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 Holder31.9%

Top-3 Unlocked62.1%

Key Addresses

11 addresses

Deployer

0xdb78…153a

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.

What Raised This Score

7 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeStaking, Token

Audit History

2 audits on record

Jul 2668Jul 2749Sep 463

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

Is Diem Safe?

Security Findings

Centralized Control by Default Admin Role

Critical Dependency on External Minter/Burner Contract

Cooldown Period Reset on Re-initiation

Lack of Maximum Cooldown Duration

Non-Upgradeable Contract Design

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Diem?