Is Venice Deity (VVVEITY) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low2 Info

High

Centralized Control by Owner

H-01The `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.

IssueThe `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.

FixClearly 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.

StatusUnresolved

Medium

Potential Precision Loss in Inflation Calculation

M-01The `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.

IssueThe `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.

FixTo 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.

StatusUnresolved

Medium

Vested Tokens Held by Contract

M-02In 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.

IssueIn 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.

FixWhile 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.

StatusUnresolved

Low

Fixed `365 days` for Yearly Calculations

L-01The `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.

IssueThe `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.

FixFor 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.

StatusUnresolved

Info

`PERMIT_2` Infinite Allowance Reporting

I-01The `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.

IssueThe `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.

FixEnsure 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`.

StatusUnresolved

Info

Lack of Event Emission for Critical Actions

I-02Several 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.

IssueSeveral 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.

FixIt 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.

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium4/10

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.

UpgradesLow7/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

55.8% in top 10

1.5% in wallets54.3% in contracts

Effective Concentration23.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

$105.8K across 5 pairs

Uniswap v4WETHanalysed$105.7K Uniswap v3USDC$83 Uniswap v4USDC$2 Uniswap v4ETH$2 Uniswap v4USDC$2

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 Holder63.0%

Top-3 Unlocked95.6%

Key Addresses

9 addresses

Deployer

0xa6ef…e01d

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.

What Raised This Score

8 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

Is Venice Deity Safe?

Security Findings

Centralized Control by Owner

Potential Precision Loss in Inflation Calculation

Vested Tokens Held by Contract

Fixed `365 days` for Yearly Calculations

`PERMIT_2` Infinite Allowance Reporting

Lack of Event Emission for Critical Actions

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Venice Deity?