Quantum Audit Logo

Is Vestra DAO Safe?

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

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

Vestra DAO VSTR
0x92d5…b434
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The VestraDAO token contract is an ERC20 token with added burnable and permit functionalities, incorporating a blacklist mechanism that relies on an external DAO contract. The contract utilizes well-audited OpenZeppelin libraries, contributing to its foundational security. However, the core blacklist functionality introduces significant centralization and immutability risks, especially given that ownership has been renounced. The reliance on an external, immutable DAO address for blacklisting, coupled with the potential for operational failure if not configured correctly, elevates the overall risk profile to High.

1 High1 Medium1 Low1 Informational
Volume 24h
$45.0K
Liquidity
$928.9K
Price
$0.003455
Token Age
1y
Top 10 Holders
98.6%

Security Findings

1 High1 Med1 Low1 Info
High

Immutable and Critical External Dependency for Blacklist

H-01The `VestraDAO` contract relies on an external `IDAO` contract, specified by the `dao` address, for its core blacklist functionality. The `setDaoAddress` function, which sets this critical dependency, is `onlyOwner`. Given that ownership has been renounced, the `dao` address is now immutable. This means if the external `IDAO` contract at the specified address is compromised, becomes malicious, or requires an update (e.g., due to a vulnerability or change in project governance), the `VestraDAO` token cannot update its dependency. This could lead to permanent fund locks for legitimate users, arbitrary blacklisting, or a complete breakdown of token functionality without any recourse.
IssueThe `VestraDAO` contract relies on an external `IDAO` contract, specified by the `dao` address, for its core blacklist functionality. The `setDaoAddress` function, which sets this critical dependency, is `onlyOwner`. Given that ownership has been renounced, the `dao` address is now immutable. This means if the external `IDAO` contract at the specified address is compromised, becomes malicious, or requires an update (e.g., due to a vulnerability or change in project governance), the `VestraDAO` token cannot update its dependency. This could lead to permanent fund locks for legitimate users, arbitrary blacklisting, or a complete breakdown of token functionality without any recourse.
FixEnsure the `IDAO` contract at the set `dao` address is exceptionally secure, thoroughly audited, and has a robust, decentralized governance model. Since the address is immutable, any future issues with the `IDAO` contract cannot be mitigated by the `VestraDAO` token. Consider a design where the blacklist authority is more resilient or can be updated through a community-governed process, even if the token contract itself is immutable.
StatusUnresolved
Medium

Blacklist Mechanism Operational Risk Post-Renunciation

M-01The `dao` address, which is critical for the blacklist functionality, is initialized to `address(0)` and can only be set once by the `owner` via `setDaoAddress`. If the `owner` renounced ownership *before* calling `setDaoAddress` with a valid `IDAO` contract address, the `dao` variable would remain `address(0)`. Subsequent calls to `isBlackList` would attempt to interact with `IDAO(address(0))`, which will always revert. This would render all core token functions (`transfer`, `approve`, `transferFrom`, `burn`, `burnFrom`) unusable, effectively locking all tokens and making the contract inoperable.
IssueThe `dao` address, which is critical for the blacklist functionality, is initialized to `address(0)` and can only be set once by the `owner` via `setDaoAddress`. If the `owner` renounced ownership *before* calling `setDaoAddress` with a valid `IDAO` contract address, the `dao` variable would remain `address(0)`. Subsequent calls to `isBlackList` would attempt to interact with `IDAO(address(0))`, which will always revert. This would render all core token functions (`transfer`, `approve`, `transferFrom`, `burn`, `burnFrom`) unusable, effectively locking all tokens and making the contract inoperable.
FixVerify that the `dao` address was correctly set to a valid and functional `IDAO` contract address immediately after deployment and *before* ownership was renounced. For future deployments, ensure a strict deployment checklist is followed to prevent such operational failures. If the contract is already deployed and `dao` is `address(0)` with ownership renounced, the contract is effectively broken.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-01The contract lacks a general pause mechanism (e.g., `Pausable` from OpenZeppelin) that could temporarily halt token transfers, approvals, or burns in the event of a critical vulnerability in an integrated DeFi protocol or a widespread exploit. While the blacklist can restrict individual accounts, it cannot provide a global emergency stop. This limits the ability to react swiftly to unforeseen, systemic risks affecting the token or its ecosystem.
IssueThe contract lacks a general pause mechanism (e.g., `Pausable` from OpenZeppelin) that could temporarily halt token transfers, approvals, or burns in the event of a critical vulnerability in an integrated DeFi protocol or a widespread exploit. While the blacklist can restrict individual accounts, it cannot provide a global emergency stop. This limits the ability to react swiftly to unforeseen, systemic risks affecting the token or its ecosystem.
FixConsider implementing a pause functionality, ideally controlled by a multi-signature wallet or a decentralized governance mechanism. This would allow for a rapid response to critical situations, protecting user funds and the protocol's integrity. However, given the contract's immutability, this would require a redeployment.
StatusUnresolved
Info

Initial Token Distribution Centralization

I-01The constructor mints the entire initial supply of 50,000,000,000 tokens (adjusted for decimals) directly to the `initialOwner`. This results in a highly centralized initial distribution, granting significant control and influence over the token's ecosystem to a single address. While not a direct vulnerability, this centralization can pose governance and market manipulation risks.
IssueThe constructor mints the entire initial supply of 50,000,000,000 tokens (adjusted for decimals) directly to the `initialOwner`. This results in a highly centralized initial distribution, granting significant control and influence over the token's ecosystem to a single address. While not a direct vulnerability, this centralization can pose governance and market manipulation risks.
FixFor future token designs, consider a more distributed initial token allocation strategy, potentially involving vesting schedules, community airdrops, or multi-signature controlled treasuries to mitigate centralization risks and foster broader participation.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The VestraDAO contract is built upon robust OpenZeppelin ERC20, ERC20Burnable, Ownable, and ERC20Permit implementations, ensuring a solid foundation for standard token operations (7.2 Code Security). Custom logic primarily involves adding blacklist checks to transfer, approve, and burn functions, which are straightforward and do not introduce complex arithmetic or reentrancy vectors. However, the contract's architecture (7.1 Architecture) introduces a critical external dependency on an `IDAO` contract for blacklisting, which is called in every restricted transaction. This dependency, combined with the immutability of the `dao` address after ownership renunciation, presents a significant technical risk if the external contract is compromised or misconfigured.

GovernanceHigh1/10

The economic model centers around an ERC20 token with a blacklist feature. A significant economic risk (7.4 Economic) stems from the initial minting of 50 billion tokens to the `initialOwner`, granting substantial control to a single entity. The blacklist mechanism, while intended for security, introduces a high degree of centralization. With ownership renounced, the `dao` address (which controls blacklisting) becomes immutable. This means there is no governance (7.5 Governance) mechanism to update or change the blacklist authority if it becomes compromised or malicious, potentially leading to permanent fund locks for blacklisted users without recourse. This immutability also means the project cannot adapt to changes in the external `IDAO` contract's functionality or address.

UpgradesLow8/10

The VestraDAO contract is not designed with an upgrade mechanism (7.7 Upgrades). It is a standard, non-proxy contract, meaning its logic is immutable once deployed. This eliminates risks associated with upgradeability patterns (e.g., proxy storage collisions, upgrade path vulnerabilities) but also means that any discovered vulnerabilities or desired feature enhancements cannot be implemented without a complete redeployment and migration.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

98.6% in top 10
0.0% in wallets98.6% in contracts
Effective Concentration39.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

$930.0K across 2 pairs
Uniswap v3WETHanalysed$928.9K99.9%Uniswap v4USDT$1.1K0.1%

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

2 addresses
Deployer
0x7339…ae81
Unlocked LP Held By
0x7339…ae81

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

7 factors
  • Top-10 concentration > 30% (98.6% total → 39.4% effective; 0.0% in EOAs, 98.6% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 100% of DEX liquidity)
  • 1 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

Related Audits

6 more on the record
Safe Token (SAFE)High RiskLQTYHigh RiskMOMOHigh RiskDog Food Token (OISHII)High RiskCapHigh Riskc8ntinuum (CTM)High Risk

Would You Like a More Detailed Audit of Vestra DAO?

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

Get Detailed Audit