Quantum Audit Logo

Is WebKey DAO 2.0 Safe?

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

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

WebKey DAO 2.0 WKEYDAO2
0xe0a2…b82e
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The wkeyDAO2 contract implements an ERC20 token with EIP-2612 permit functionality and OpenZeppelin's AccessControl. While it utilizes SafeMath for arithmetic operations and correctly implements the permit mechanism, a critical vulnerability exists due to a truncated access control modifier. Additionally, the contract uses an outdated Solidity compiler version and lacks an upgrade mechanism, posing further risks. Centralized control over administrative roles is also noted.

1 Critical3 Medium1 Low1 Informational
Volume 24h
$320.0K
Liquidity
$12.40M
Price
$1.0100
Token Age
6mo
Top 10 Holders
99.0%

Security Findings

1 Crit3 Med1 Low1 Info
Critical

Incomplete `onlyVault` Modifier Leads to Critical Access Control Flaw

C-01The `onlyVault` modifier in the `VaultOwned` contract is truncated (`require(ha...`). This incomplete code will either cause any function using this modifier to permanently revert upon deployment (if 'ha' is an undeclared variable or invalid expression) or, more critically, could be interpreted by the compiler in a way that bypasses the intended access control entirely, allowing unauthorized execution of restricted functions. This represents a severe vulnerability, compromising the integrity of any function it protects.
IssueThe `onlyVault` modifier in the `VaultOwned` contract is truncated (`require(ha...`). This incomplete code will either cause any function using this modifier to permanently revert upon deployment (if 'ha' is an undeclared variable or invalid expression) or, more critically, could be interpreted by the compiler in a way that bypasses the intended access control entirely, allowing unauthorized execution of restricted functions. This represents a severe vulnerability, compromising the integrity of any function it protects.
FixComplete the `onlyVault` modifier with its intended logic. Ensure the `require` statement correctly validates the caller's address against a designated vault address or role. If this modifier is not intended for use, it should be removed to prevent unexpected behavior.
StatusUnresolved
Medium

Outdated Solidity Compiler Version

M-01The contract is compiled with Solidity version 0.7.5. While `SafeMath` is used to prevent integer overflows/underflows, newer compiler versions (0.8.x and above) include native overflow/underflow checks, which can simplify code and potentially reduce gas costs by removing the need for `SafeMath` library calls. Additionally, older compiler versions may have undiscovered bugs or lack optimizations and security features present in more recent releases.
IssueThe contract is compiled with Solidity version 0.7.5. While `SafeMath` is used to prevent integer overflows/underflows, newer compiler versions (0.8.x and above) include native overflow/underflow checks, which can simplify code and potentially reduce gas costs by removing the need for `SafeMath` library calls. Additionally, older compiler versions may have undiscovered bugs or lack optimizations and security features present in more recent releases.
FixConsider upgrading the Solidity compiler to a more recent stable version (e.g., 0.8.x or higher). This would allow for the removal of `SafeMath` and benefit from native overflow checks, improving code readability and potentially security. Thoroughly test the contract after any compiler upgrade.
StatusUnresolved
Medium

Centralized Control Over Critical Roles

M-02The `DEFAULT_ADMIN_ROLE` is assigned to the contract deployer in the `VaultOwned` constructor. This grants the deployer significant control over the contract's access control, including the ability to grant and revoke other roles. A `MINT` role is defined but not explicitly used in the provided `ERC20` snippet to restrict the `_mint` function. If minting is intended to be restricted, this centralization of administrative power, especially if the `MINT` role is also controlled by a single entity, introduces a single point of failure and a high degree of trust in the deployer.
IssueThe `DEFAULT_ADMIN_ROLE` is assigned to the contract deployer in the `VaultOwned` constructor. This grants the deployer significant control over the contract's access control, including the ability to grant and revoke other roles. A `MINT` role is defined but not explicitly used in the provided `ERC20` snippet to restrict the `_mint` function. If minting is intended to be restricted, this centralization of administrative power, especially if the `MINT` role is also controlled by a single entity, introduces a single point of failure and a high degree of trust in the deployer.
FixImplement a multi-signature wallet or a more decentralized governance mechanism for managing critical roles like `DEFAULT_ADMIN_ROLE` and `MINT`. If the `MINT` role is intended to restrict token minting, ensure it is properly applied to the `_mint` function. Clearly document the responsibilities and powers associated with each role.
StatusUnresolved
Medium

Lack of Upgradeability

M-03The contract is deployed as a standard, non-upgradeable contract. This design choice means that the contract's logic is immutable once deployed. Any future bug fixes, security patches, or desired feature enhancements would require deploying an entirely new contract and migrating all existing users and assets, which is a complex, costly, and risky operation. This lack of flexibility can hinder long-term maintenance and responsiveness to unforeseen issues.
IssueThe contract is deployed as a standard, non-upgradeable contract. This design choice means that the contract's logic is immutable once deployed. Any future bug fixes, security patches, or desired feature enhancements would require deploying an entirely new contract and migrating all existing users and assets, which is a complex, costly, and risky operation. This lack of flexibility can hinder long-term maintenance and responsiveness to unforeseen issues.
FixFor long-lived protocols, consider implementing an upgradeability pattern (e.g., UUPS or Transparent Proxy) to allow for future contract logic updates. If upgradeability is not desired, ensure the contract is thoroughly audited and tested to minimize the risk of needing a redeployment. Clearly communicate the immutability to users.
StatusUnresolved
Low

Permit Function Susceptible to Front-Running

L-01The `permit` function, while correctly implemented according to EIP-2612, is inherently susceptible to front-running. A malicious actor could observe a pending `permit` transaction and front-run it. For example, if the `owner` has an existing allowance for the `spender`, the `spender` could front-run with a `transferFrom` call to drain funds before the `permit` transaction updates the allowance. While the `nonces` mechanism prevents replay attacks, it does not fully mitigate front-running risks related to allowance manipulation.
IssueThe `permit` function, while correctly implemented according to EIP-2612, is inherently susceptible to front-running. A malicious actor could observe a pending `permit` transaction and front-run it. For example, if the `owner` has an existing allowance for the `spender`, the `spender` could front-run with a `transferFrom` call to drain funds before the `permit` transaction updates the allowance. While the `nonces` mechanism prevents replay attacks, it does not fully mitigate front-running risks related to allowance manipulation.
FixEducate users about the potential for front-running when using the `permit` function. While this is a known characteristic of EIP-2612 and not a specific implementation flaw, users should be aware of the risks, especially when interacting with untrusted or high-latency networks. Consider using transaction relays that can help mitigate some front-running vectors.
StatusUnresolved
Info

Unused `MINT` Role Definition

I-01The `MINT` role is defined in the `VaultOwned` contract (`bytes32 public constant MINT = keccak256("MINT");`) but is not utilized in the provided `ERC20` contract snippet to restrict the `_mint` function. If the intention is to control who can mint tokens, this role should be enforced on the `_mint` function or a wrapper around it.
IssueThe `MINT` role is defined in the `VaultOwned` contract (`bytes32 public constant MINT = keccak256("MINT");`) but is not utilized in the provided `ERC20` contract snippet to restrict the `_mint` function. If the intention is to control who can mint tokens, this role should be enforced on the `_mint` function or a wrapper around it.
FixIf the `MINT` role is intended to restrict token minting, ensure it is applied to the `_mint` function (or a public/external function that calls `_mint`) using `onlyRole(MINT)`. If the role is not intended for use, consider removing its definition to avoid confusion and unnecessary code.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates a foundational understanding of ERC20 standards and integrates OpenZeppelin's AccessControl and SafeMath libraries, mitigating common integer overflow/underflow risks (7.2 Code Security). The EIP-2612 permit functionality is correctly implemented, enhancing user experience. However, a critical flaw exists in the `onlyVault` modifier, which is truncated and renders its intended access control ineffective or causes permanent reverts (7.3 Access Control). The use of Solidity 0.7.5 is outdated, missing native overflow checks and potential security enhancements of newer versions (7.2 Code Security).

GovernanceHigh1/10

The contract utilizes OpenZeppelin's AccessControl, with the deployer assigned the `DEFAULT_ADMIN_ROLE` in the `VaultOwned` constructor, centralizing significant administrative power (7.5 Governance). A `MINT` role is defined, suggesting potential for centralized token issuance, though its application is not shown in the provided snippet. The contract name 'wkeyDAO2' implies a decentralized autonomous organization, but the provided code lacks explicit DAO governance mechanisms like voting or proposal systems (7.5 Governance). This centralization introduces a single point of failure and trust assumption for critical operations (7.4 Economic).

UpgradesHigh3/10

The contract is deployed as a standard, non-upgradeable contract (7.7 Upgrades). This means that once deployed, its logic cannot be modified. Any discovered vulnerabilities, bugs, or desired feature enhancements would necessitate a complete redeployment of the contract and a complex migration of user funds and data, posing a significant operational risk (7.8 Operations).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedPass
Not a ProxyPass

Holder Composition

99.0% in top 10
39.3% in wallets59.8% in contracts
Effective Concentration63.2%

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

$12.40M

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

4 addresses
Deployer
0x1473…24a8
Unlocked LP Held By
0xaa20…1dec0x0ed9…97060x1473…24a8

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (99.0% total → 63.2% effective; 39.3% in EOAs, 59.8% in contracts — heavy)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk)
  • LP claimed locked but only 0.0% actually locked
  • 1 Critical finding(s) from audit
  • 3 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

Related Audits

6 more on the record
Pieverse Token (PIEVERSE)Critical RiskSnapCoinCritical RiskSK Hynix (SKHYB)Critical RiskGameStop (GMEB)Critical RiskApple (AAPLB)Critical RiskSandisk Corporation (SNDKB)Critical Risk

Would You Like a More Detailed Audit of WebKey DAO 2.0?

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

Get Detailed Audit