Quantum Audit Logo
Launch App

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

Is Venice Deity Safe?

VVVEITYBase
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades7/10Checks passed3 of 5Findings1 High · 2 Medium · 1 Low · 2 Info6
SummaryAI Copilot

The DERC20 contract implements an ERC20 token with voting, permit, and Ownable functionalities.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 63.0%
  • LP top3 unlocked holders = 95.6%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (55.8% total → 23.2% effective; 1.5% in EOAs, 54.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 63.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 95.6% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 2 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
54.3%Contracts1.5%44.2%Everyone else
54.3%Contracts44.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
55.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking54.3%
  • Walletsanonymous holders, free to sell1.5%
  • Everyone elsethe rest of the supply44.2%
Effective concentrationwhat the score reads23.2%
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$105.8K across 5 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$105.7KShare of depth99.9%
Top-1 Unlocked Holder63.0%
Top-3 Unlocked95.6%
Unlocked LP held by
0x112b…42b90x0dad…d24e0x8ee4…485a0x47b2…e4d50x3934…82e10xcbbb…58350x170f…7cec0x4bfa…49ef

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

Security Findings

1 High2 Medium1 Low2 Info
High

Centralized Control by Owner

The owner of the DERC20 contract possesses significant control over critical functionalities and economic parameters. The owner can call mintInflation() (which mints to itself), updateMintRate(), burn() tokens, lockPool(), and unlockPool(). This centralized power allows the owner to unilaterally influence the token's supply, inflation schedule, and transfer restrictions, posing a substantial trust assumption for users and potential for misuse if the owner's keys are compromised or acts maliciously. While the owner is a multisig, the inherent centralization of control remains.H-01

Issue

The owner of the DERC20 contract possesses significant control over critical functionalities and economic parameters. The owner can call mintInflation() (which mints to itself), updateMintRate(), burn() tokens, lockPool(), and unlockPool(). This centralized power allows the owner to unilaterally influence the token's supply, inflation schedule, and transfer restrictions, posing a substantial trust assumption for users and potential for misuse if the owner's keys are compromised or acts maliciously. While the owner is a multisig, the inherent centralization of control remains.

Fix

Clearly communicate the extent of owner control to all users and stakeholders. Consider implementing time-locks or multi-signature requirements for highly sensitive functions (e.g., updateMintRate, burn) beyond the existing Ownable pattern, or explore a transition to a community-governed model if decentralization is a long-term objective. Ensure the multisig setup is robust and its key management practices are secure.

Status

Unresolved

Medium

Potential Precision Loss in Inflation Calculation

The mintInflation() function calculates yearMint and partialYearMint using integer arithmetic: (supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days). If the numerator (supply * yearlyMintRate_ * timeLeftInCurrentYear) is smaller than the denominator (1 ether * 365 days), the result of the integer division will be zero, leading to a loss of precision. This could result in smaller-than-expected inflation amounts being minted, especially if the supply or yearlyMintRate_ is low, or the time period is very short. While require(mintableAmount > 0) prevents minting zero, it doesn't recover lost precision.M-01

Issue

The mintInflation() function calculates yearMint and partialYearMint using integer arithmetic: (supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days). If the numerator (supply * yearlyMintRate_ * timeLeftInCurrentYear) is smaller than the denominator (1 ether * 365 days), the result of the integer division will be zero, leading to a loss of precision. This could result in smaller-than-expected inflation amounts being minted, especially if the supply or yearlyMintRate_ is low, or the time period is very short. While require(mintableAmount > 0) prevents minting zero, it doesn't recover lost precision.

Fix

To mitigate precision loss, consider reordering operations to perform division last where possible, or use a well-tested fixed-point math library (e.g., DSMath, PRBMath) for sensitive calculations. Alternatively, ensure that the minimum expected mintable amount is sufficiently large to avoid truncation to zero, or adjust the yearlyMintRate to account for this behavior.

Status

Unresolved

Medium

Vested Tokens Held by Contract

In the constructor, vestedTokens are minted directly to address(this). These tokens are then released to recipients via the release() function, which transfers them from the contract's balance. This design means the DERC20 contract itself holds a significant portion of the total supply (the vestedTotalAmount) until it is fully released. While the _transfer mechanism is standard OpenZeppelin, centralizing these funds within the contract increases the impact if the contract were to be compromised or if an unforeseen vulnerability allowed unauthorized draining of its balance.M-02

Issue

In the constructor, vestedTokens are minted directly to address(this). These tokens are then released to recipients via the release() function, which transfers them from the contract's balance. This design means the DERC20 contract itself holds a significant portion of the total supply (the vestedTotalAmount) until it is fully released. While the _transfer mechanism is standard OpenZeppelin, centralizing these funds within the contract increases the impact if the contract were to be compromised or if an unforeseen vulnerability allowed unauthorized draining of its balance.

Fix

While the current implementation is functional, for enhanced security and decentralization, consider alternative vesting patterns. This could involve using a separate, minimal vesting contract that holds the tokens, or directly minting vested tokens to individual vesting contracts for each recipient. If keeping the current design, ensure the contract's overall security posture is extremely robust, and consider additional safeguards for the contract's balance.

Status

Unresolved

Low

Fixed 365 days for Yearly Calculations

The mintInflation() function uses a fixed constant 365 days for yearly calculations. This approach does not account for leap years, which occur approximately every four years. Consequently, the inflation schedule will be slightly inaccurate, leading to minor discrepancies in the amount of tokens minted over extended periods compared to a precise calendar year calculation.L-01

Issue

The mintInflation() function uses a fixed constant 365 days for yearly calculations. This approach does not account for leap years, which occur approximately every four years. Consequently, the inflation schedule will be slightly inaccurate, leading to minor discrepancies in the amount of tokens minted over extended periods compared to a precise calendar year calculation.

Fix

For most DeFi applications, this level of inaccuracy is acceptable and common. If higher precision is required, consider implementing a more sophisticated time calculation that accounts for leap years, or explicitly state this simplification in the protocol's documentation. Given the context, this is likely an acceptable trade-off for gas efficiency and simplicity.

Status

Unresolved

Info

PERMIT_2 Infinite Allowance Reporting

The allowance() function is overridden to return type(uint256).max when the spender address is PERMIT_2 (0x0000…8BA3). This is a common pattern to facilitate interactions with universal routers like Permit2, allowing them to spend tokens without requiring explicit approve calls for every transaction. While a design choice, users interacting with PERMIT_2 should be aware that this mechanism effectively grants infinite allowance to PERMIT_2 for their tokens, even if they haven't explicitly approved it through a standard ERC20 approve call.I-01

Issue

The allowance() function is overridden to return type(uint256).max when the spender address is PERMIT_2 (). This is a common pattern to facilitate interactions with universal routers like Permit2, allowing them to spend tokens without requiring explicit approve calls for every transaction. While a design choice, users interacting with PERMIT_2 should be aware that this mechanism effectively grants infinite allowance to PERMIT_2 for their tokens, even if they haven't explicitly approved it through a standard ERC20 approve call.

Fix

Ensure that users are fully aware of the implications of interacting with PERMIT_2 and how this allowance override functions. Provide clear documentation explaining that PERMIT_2 will be perceived as having infinite allowance for their tokens, and advise caution when interacting with any third-party protocols that utilize PERMIT_2.

Status

Unresolved

Info

Lack of Event Emission for Critical Actions

Several critical state-changing functions, such as lockPool(), unlockPool(), updateMintRate(), and updateTokenURI(), do not emit corresponding events. Events are crucial for off-chain monitoring, indexing, and providing transparency into the contract's operations. Without events, it is difficult for external systems, users, or auditors to track when these significant parameters or states are changed.I-02

Issue

Several critical state-changing functions, such as lockPool(), unlockPool(), updateMintRate(), and updateTokenURI(), do not emit corresponding events. Events are crucial for off-chain monitoring, indexing, and providing transparency into the contract's operations. Without events, it is difficult for external systems, users, or auditors to track when these significant parameters or states are changed.

Fix

It is recommended to emit events for all critical state changes. For example, event PoolLocked(address indexed pool, bool isLocked);, event MintRateUpdated(uint256 oldRate, uint256 newRate);, and event TokenURIUpdated(string newTokenURI);. This enhances transparency, auditability, and allows for easier integration with off-chain services.

Status

Unresolved

Analysis

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

The DERC20 contract implements an ERC20 token with voting, permit, and Ownable functionalities. It features a vesting mechanism, an inflation minting system, and a pool locking capability. The contract leverages well-audited OpenZeppelin libraries. Key findings include significant centralized control by the owner, potential precision loss in inflation calculations, and the contract holding a substantial amount of vested tokens. The contract is not upgradeable, which eliminates upgrade-related risks but also limits future flexibility.

Technical8/10Low risk

The DERC20 contract is built upon robust OpenZeppelin standards (ERC20, ERC20Votes, ERC20Permit, Ownable), contributing to a solid architectural foundation (7.1 Architecture). The code generally demonstrates good security practices (7.2 Code Security), with no apparent reentrancy vulnerabilities. However, the inflation calculation in mintInflation() may suffer from precision loss due to integer division, potentially leading to minor discrepancies in minted amounts. Additionally, the contract holds all vested tokens, which, while using standard _transfer logic, centralizes a significant asset pool within the contract itself.

Governance4/10Medium risk

The contract exhibits a high degree of centralized control (7.3 Access Control, 7.5 Governance). The owner (a 3/6 multisig) has extensive power, including the ability to mint inflation tokens to itself, update the yearly mint rate, burn tokens, and lock/unlock the designated pool address. This level of control introduces significant economic risk (7.4 Economic) as the owner can directly influence token supply and transfer restrictions. While the use of a multisig mitigates single-point-of-failure risks for the owner, the inherent centralization remains a key governance consideration.

Upgrades7/10Low risk

The DERC20 contract is not designed with any upgradeability mechanism (7.7 Upgrades). Once deployed, its logic is immutable. This eliminates all risks associated with proxy upgrades, such as storage collisions, logic errors in upgrade implementations, or malicious upgrades. However, it also means that any future bug fixes or feature enhancements would require a new contract deployment and token migration.

Final RecommendationWhat to do about this score

It is recommended to thoroughly review the implications of the owner's extensive control over token supply and pool locking, ensuring these powers align with the project's long-term vision and risk tolerance.

Consider implementing more granular access control or time-locks for highly sensitive owner functions if decentralization is a future goal. Additionally, evaluate the precision of the inflation calculation to ensure it meets desired accuracy standards, potentially by using a fixed-point math library or adjusting the order of operations.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2mo
Contract0x8563…eba3
Deployer0xa6ef…e01d
Badge for your website
Venice Deity 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. Aug 16, 202641Medium

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

Frequently Asked Questions

What is the VVVEITY contract address?

The Venice Deity (VVVEITY) contract on Base is 0x85635006d808030e97f3174c8ea1b4aa1f1feba3. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Venice Deity a scam?

Quantum Audit's risk score for Venice Deity is 41/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is VVVEITY liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $105.8K.

Who holds VVVEITY?

As of Sep 4, 2026, the 10 largest holders own 55.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
DeriveDRV · Base41MediumtokenbotCLANKER · Base41MediumKairenceKAI · Base41MediumSPIKEBase41MediumB3Base42MediumHandlPayHANDL · Base40Medium

Would You Like a More Detailed Audit of Venice Deity?

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