Quantum Audit Logo

Is Dolomite Safe?

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

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

Dolomite DOLO
0x0f81…a654
Ethereum Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The DOLOWithOwnable contract is an ERC20Burnable token with an Ownable access control pattern. It includes a centralized minting mechanism controlled by the contract owner, who can designate minter addresses. The contract leverages OpenZeppelin libraries for standard token functionality and access control, along with a custom 'Require' library for assertions. While code quality is generally good, the significant power vested in the owner, particularly regarding token minting, introduces a high economic risk.

1 High3 Informational
Volume 24h
$7.4K
Liquidity
$188.2K
Price
$0.02668
Token Age
1y
Top 10 Holders
79.3%

Security Findings

High

Centralized Unlimited Minting Capability

H-01The `DOLOWithOwnable` contract grants the owner the ability to set and unset minters, and these minters can call the `mint` function to create an arbitrary amount of new tokens. This centralized control over token supply introduces a significant economic risk, as a compromised owner key or a malicious minter could lead to unlimited inflation, devaluing existing tokens.
IssueThe `DOLOWithOwnable` contract grants the owner the ability to set and unset minters, and these minters can call the `mint` function to create an arbitrary amount of new tokens. This centralized control over token supply introduces a significant economic risk, as a compromised owner key or a malicious minter could lead to unlimited inflation, devaluing existing tokens.
FixImplement safeguards to limit the minting capability. This could include a hard cap on the total supply, a maximum mintable amount per period, or requiring a multi-signature approval or a timelock for minting operations. If unlimited minting is a core design choice, ensure the operational security of the owner and minter addresses is exceptionally high.
StatusUnresolved
Info

`renounceOwnership` Function Reverted

I-01The `renounceOwnership` function is explicitly overridden to revert, preventing the owner from ever relinquishing ownership. This design choice ensures that the contract will always have an owner with the associated administrative privileges, including control over minting and setting the CCIP admin.
IssueThe `renounceOwnership` function is explicitly overridden to revert, preventing the owner from ever relinquishing ownership. This design choice ensures that the contract will always have an owner with the associated administrative privileges, including control over minting and setting the CCIP admin.
FixAcknowledge this design choice. If future decentralization or transfer of ownership to a DAO is desired, this design would require a new contract deployment. Ensure the implications of permanent ownership are well understood and documented.
StatusUnresolved
Info

Minter Must Be a Contract

I-02The `_ownerSetMinter` function includes a `Require.that(_minter.isContract(), ...)` check, enforcing that only smart contract addresses can be designated as minters. This prevents Externally Owned Accounts (EOAs) from directly holding minting privileges.
IssueThe `_ownerSetMinter` function includes a `Require.that(_minter.isContract(), ...)` check, enforcing that only smart contract addresses can be designated as minters. This prevents Externally Owned Accounts (EOAs) from directly holding minting privileges.
FixDocument the rationale behind this design choice. Ensure that any contract designated as a minter is thoroughly audited and secured, as its compromise would directly impact the token's supply. This design can be beneficial for integrating with governance or timelock contracts.
StatusUnresolved
Info

Undefined `_ccipAdmin` Role Functionality

I-03The contract defines a `_ccipAdmin` state variable and functions (`ownerSetCCIPAdmin`, `getCCIPAdmin`) to manage it. However, the provided contract code does not implement any logic that utilizes this `_ccipAdmin` role. This suggests that its functionality is intended for external integration or future development.
IssueThe contract defines a `_ccipAdmin` state variable and functions (`ownerSetCCIPAdmin`, `getCCIPAdmin`) to manage it. However, the provided contract code does not implement any logic that utilizes this `_ccipAdmin` role. This suggests that its functionality is intended for external integration or future development.
FixClearly document the intended purpose and responsibilities of the `_ccipAdmin` role. If this role interacts with external systems or contracts, ensure those integrations are secure and that the `_ccipAdmin` address is managed with the highest security standards.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates good code security practices (7.2) by inheriting from battle-tested OpenZeppelin ERC20, ERC20Burnable, and Ownable contracts. It uses Solidity 0.8.9+, mitigating common integer overflow/underflow risks. Custom `Require` library usage is consistent. However, the centralized minting function, accessible via `onlyMinter` modifier, presents a technical risk if the minter's keys are compromised or if the minter contract has vulnerabilities. The `_transfer` and `_approve` functions include checks to prevent tokens from being sent to or approved by the contract itself, which is a good practice.

GovernanceHigh2/10

The economic model (7.4) of the DOLO token is highly centralized, with the contract owner having the ability to grant unlimited minting power to designated minters. This introduces a significant economic risk due to potential for inflation or malicious minting. The initial supply of 1 billion DOLO tokens is minted directly to the owner, concentrating a large portion of the supply. While the owner is a multisig (7.5), which enhances security over a single EOA, the inherent power of the owner role remains substantial. The `renounceOwnership` function is explicitly reverted, meaning ownership cannot be relinquished, permanently vesting control in the current owner.

UpgradesMedium4/10

The DOLOWithOwnable contract is not designed with an upgrade mechanism (7.7), meaning its logic is immutable once deployed. This simplifies the architecture and removes upgrade-related risks such as proxy misconfigurations or malicious upgrade implementations. Any future changes to the token's logic would require a new deployment and migration of assets, which is a common approach for standard ERC20 tokens.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

46.1% in wallets33.2% in contracts
Effective Concentration59.4%

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

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0x4427…9e85
Unlocked LP Held By
0x6e93…f682

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

What Raised This Score

  • Ownership NOT renounced — Multisig (2-of-3)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (79.3% total → 59.4% effective; 46.1% in EOAs, 33.2% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 53% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 53% of DEX liquidity)
  • 1 High 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

SEIHigh RiskRedstone (RED)High RiskPinLink (PIN)High RiskSPACE ID (ID)High RiskHarryPotterObamaSonic10Inu (BITCOIN)High RiskUSDS Stablecoin (USDS)High Risk

Would You Like a More Detailed Audit of Dolomite?

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

Get Detailed Audit