Quantum Audit Logo
Launch App

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

Is Dai Stablecoin Safe?

DAIArbitrum
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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance1/10Upgrades2/10Checks passed2 of 5Findings1 Critical · 1 High · 1 Medium · 3 Info6
SummaryAI Copilot

The audit of the Dai Stablecoin contract revealed critical vulnerabilities related to unchecked arithmetic operations, which could lead to incorrect token balances and total supply.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 78.5%
  • LP top3 unlocked holders = 97.8%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (36.2% total → 23.8% effective; 15.6% in EOAs, 20.6% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 78.5% (independent LP — depth risk, pool = 52% of DEX liquidity)
  • LP top3 unlocked holders = 97.8% (independent LP — depth risk, pool = 52% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium 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
20.6%Contracts15.6%Wallets63.8%Everyone else
20.6%Contracts15.6%63.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
36.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking20.6%
  • Walletsanonymous holders, free to sell15.6%
  • Everyone elsethe rest of the supply63.8%
Effective concentrationwhat the score reads23.8%
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$182.4K across 8 pairs
Show 2 more pairs

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$94.6KShare of depth51.8%
Top-1 Unlocked Holder78.5%
Top-3 Unlocked97.8%
Unlocked LP held by
0xea32…010d0x9023…9d700x3750…0d7b0x47c0…596c0xbb96…7da20x671a…8b5e0xdd95…7c630x3086…30980x6c81…f94c0x2cd5…6d4c

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

Security Findings

1 Critical1 High1 Medium3 Info
Critical

Unchecked Arithmetic Operations Leading to Integer Overflow/Underflow

Several critical arithmetic operations within the contract do not utilize the provided safe arithmetic functions (_add, _sub), exposing the contract to integer overflow and underflow vulnerabilities. Specifically: 1. Additions to balanceOf[to] in mint, transfer, and transferFrom (balanceOf[to] = balanceOf[to] + value;) are unchecked and can overflow. 2. Subtraction from totalSupply in burn (totalSupply = totalSupply - value;) is unchecked and can underflow if totalSupply is less than value (even if balanceOf[from] is sufficient). This can lead to incorrect token balances, total supply, and potentially loss of funds or system instability. (7.2 Code Security)C-01

Issue

Several critical arithmetic operations within the contract do not utilize the provided safe arithmetic functions (_add, _sub), exposing the contract to integer overflow and underflow vulnerabilities. Specifically: 1. Additions to balanceOf[to] in mint, transfer, and transferFrom (balanceOf[to] = balanceOf[to] + value;) are unchecked and can overflow. 2. Subtraction from totalSupply in burn (totalSupply = totalSupply - value;) is unchecked and can underflow if totalSupply is less than value (even if balanceOf[from] is sufficient). This can lead to incorrect token balances, total supply, and potentially loss of funds or system instability. (7.2 Code Security)

Fix

All arithmetic operations involving token balances, total supply, and allowances must consistently use the _add and _sub internal functions or a battle-tested SafeMath library to prevent overflows and underflows. Ensure that every addition and subtraction is protected by these safe arithmetic checks.

Status

Unresolved

High

Centralized Ward Can Burn Any User's Tokens Without Approval

The burn function's logic allows an authorized ward (wards[msg.sender] == 1) to bypass the allowance check when burning tokens from any address (from), even if from is not msg.sender. This means a ward can unilaterally burn tokens belonging to any user without their explicit approval, which is a significant centralization risk and deviates from standard ERC-20 burnFrom behavior. (7.3 Access Control, 7.4 Economic)H-01

Issue

The burn function's logic allows an authorized ward (wards[msg.sender] == 1) to bypass the allowance check when burning tokens from any address (from), even if from is not msg.sender. This means a ward can unilaterally burn tokens belonging to any user without their explicit approval, which is a significant centralization risk and deviates from standard ERC-20 burnFrom behavior. (7.3 Access Control, 7.4 Economic)

Fix

Modify the burn function to strictly enforce allowance checks for all burnFrom operations. If the intent is for wards to have privileged burning capabilities, this should be clearly documented, and a more robust governance mechanism (e.g., multi-signature approval) should be implemented for such sensitive actions to mitigate the risk of abuse or compromise.

Status

Unresolved

Medium

Centralized Access Control for Core Token Operations

The contract utilizes a centralized access control mechanism based on a wards mapping and an auth modifier. The deployer is initially the sole ward, with the power to add or remove other wards via rely and deny functions. Critical operations like mint are restricted to these authorized wards. This centralization creates a single point of failure; a compromise of a ward's private key could lead to unauthorized token minting or administrative control. (7.3 Access Control, 7.5 Governance)M-01

Issue

The contract utilizes a centralized access control mechanism based on a wards mapping and an auth modifier. The deployer is initially the sole ward, with the power to add or remove other wards via rely and deny functions. Critical operations like mint are restricted to these authorized wards. This centralization creates a single point of failure; a compromise of a ward's private key could lead to unauthorized token minting or administrative control. (7.3 Access Control, 7.5 Governance)

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the wards addresses to distribute control and reduce the single point of failure risk. For highly sensitive operations like mint, explore adding time-locks or a more decentralized governance mechanism if aligned with the project's long-term vision.

Status

Unresolved

Info

Missing ERC-20 decimals() Function

The contract defines decimals as a public constant uint8, which makes its value accessible. However, it does not implement the decimals() function as explicitly specified in the ERC-20 standard. While functionally equivalent for many applications, some tools or interfaces might expect the function call. (7.1 Architecture)I-01

Issue

The contract defines decimals as a public constant uint8, which makes its value accessible. However, it does not implement the decimals() function as explicitly specified in the ERC-20 standard. While functionally equivalent for many applications, some tools or interfaces might expect the function call. (7.1 Architecture)

Fix

Add a function decimals() external view returns (uint8) that simply returns the decimals constant to ensure full ERC-20 compliance and broader compatibility with ecosystem tools.

Status

Unresolved

Info

Redundant _DOMAIN_SEPARATOR Calculation in permit Function

The permit function recalculates the EIP-712 domain separator using _calculateDomainSeparator(chainId) if the current chainId differs from deploymentChainId. While this handles chain forks correctly, the contract already stores _DOMAIN_SEPARATOR as an immutable variable and provides a public DOMAIN_SEPARATOR() view function that performs the same conditional check. The permit function could potentially reuse the existing DOMAIN_SEPARATOR() function or the stored _DOMAIN_SEPARATOR after its own chainId check, avoiding redundant computation. (7.2 Code Security)I-02

Issue

The permit function recalculates the EIP-712 domain separator using _calculateDomainSeparator(chainId) if the current chainId differs from deploymentChainId. While this handles chain forks correctly, the contract already stores _DOMAIN_SEPARATOR as an immutable variable and provides a public DOMAIN_SEPARATOR() view function that performs the same conditional check. The permit function could potentially reuse the existing DOMAIN_SEPARATOR() function or the stored _DOMAIN_SEPARATOR after its own chainId check, avoiding redundant computation. (7.2 Code Security)

Fix

Optimize the permit function to reuse the DOMAIN_SEPARATOR() function or the stored _DOMAIN_SEPARATOR directly after its chainId == deploymentChainId check, to avoid unnecessary recalculation and improve gas efficiency.

Status

Unresolved

Info

Restrictive transfer and transferFrom to address(this) Check

The transfer and transferFrom functions explicitly prevent transfers to address(this) (the token contract itself) with the check `require(to != address(0) && to != address(this), 'Dai/invalid-address');. While preventing transfers to address(0)` is standard, disallowing transfers to the token contract might be overly restrictive depending on future protocol designs. Some DeFi protocols or token mechanisms might intentionally send tokens to the token contract for specific purposes (e.g., burning, staking, or locking). (7.1 Architecture)I-03

Issue

The transfer and transferFrom functions explicitly prevent transfers to address(this) (the token contract itself) with the check `require(to != address(0) && to != address(this), 'Dai/invalid-address');. While preventing transfers to address(0)` is standard, disallowing transfers to the token contract might be overly restrictive depending on future protocol designs. Some DeFi protocols or token mechanisms might intentionally send tokens to the token contract for specific purposes (e.g., burning, staking, or locking). (7.1 Architecture)

Fix

Review if the restriction to != address(this) is absolutely necessary for all current and anticipated use cases. If there are scenarios where sending tokens to the contract itself is desired or could be beneficial, this check should be removed or made conditional. Otherwise, clearly document this design choice and its implications.

Status

Unresolved

Analysis

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

The audit of the Dai Stablecoin contract revealed critical vulnerabilities related to unchecked arithmetic operations, which could lead to incorrect token balances and total supply. Additionally, significant centralization risks exist due to the 'ward' access control mechanism, particularly concerning the ability of authorized wards to burn any user's tokens without explicit approval. The contract implements standard ERC-20 functionality along with EIP-2612 permit, but inconsistent application of safe arithmetic functions poses a severe threat to the token's integrity. Recommendations focus on addressing these arithmetic flaws and mitigating centralization risks.

Technical5/10Medium risk

The contract implements core ERC-20 functionalities and EIP-2612 permit, including a robust EIP-712 domain separator calculation. It also provides internal _add and _sub functions for safe arithmetic. However, a critical technical flaw is the inconsistent application of these safe arithmetic functions, leading to unchecked additions and subtractions in balanceOf and totalSupply updates (7.2 Code Security). This exposes the contract to integer overflow and underflow vulnerabilities, which can corrupt token balances and total supply. The burn function also contains an unchecked subtraction for totalSupply (7.2 Code Security).

Governance1/10High risk

The contract employs a centralized 'ward' access control system, where the deployer is initially the sole administrator, capable of adding or removing other wards (7.3 Access Control). This centralization extends to critical operations like mint, which is restricted to wards. A significant economic risk is present in the burn function, where an authorized ward can burn tokens from any address without requiring prior allowance, deviating from standard ERC-20 burnFrom behavior and creating a powerful, centralized control point over user funds (7.4 Economic, 7.5 Governance).

Upgrades2/10High risk

The contract is not designed as an upgradeable proxy and does not implement any upgrade mechanisms. Therefore, there are no specific upgrade-related risks inherent in its architecture (7.7 Upgrades). Any future changes would require a new deployment and migration.

Final RecommendationWhat to do about this score

Prioritize the immediate remediation of all unchecked arithmetic operations by consistently applying the provided _add and _sub internal functions or integrating a robust SafeMath library for all balance, total supply, and allowance modifications.

This is crucial to prevent integer overflows and underflows that could compromise the token's integrity and user funds. Additionally, review and revise the burn function's access control to either strictly enforce allowance for all burnFrom operations or clearly document and justify the privileged burning capability of wards, potentially implementing a multi-signature scheme for such sensitive actions. Consider implementing a multi-signature wallet for the 'ward' addresses to enhance security and decentralize administrative control over critical functions like mint and rely/deny.

Contract & Record

1 audit on record
TypeToken
NetworkArbitrum
Token age3y
Contract0xda10…0da1
Deployer0x075d…5250
Badge for your website
Dai Stablecoin 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, 202669High
  2. Aug 12, 202674High

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

Related Audits

6 more on the recordAll audits
Aethir TokenATH · Arbitrum69HighOrthogonalORGOL · Arbitrum69HighOrthogonalORTGO · Arbitrum69HighArbitrum InternINTERN · Arbitrum67HighMonerium EUReEURE · Arbitrum72HighChipArbitrum73High

Would You Like a More Detailed Audit of Dai Stablecoin?

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