Quantum Audit Logo

Is Prism Safe?

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

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

Prism PRISM
0xcf4d…e040
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The PrismHookV2 contract serves as a Uniswap V4 hook, an ERC20 token, and manages NFT-like shares for fee distribution. It integrates Solady libraries for efficiency and ReentrancyGuard for security. The contract features a custom NFT-like ownership system and significant owner control over critical operations and fee collection. While robust in its core Uniswap V4 integration and use of established libraries, the custom share management and centralized administrative powers introduce areas of elevated risk.

1 High2 Medium1 Low1 Informational
Volume 24h
$26.0K
Liquidity
$207.2K
Price
$307.7600
Token Age
11d
Top 10 Holders
41.5%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control by Owner

H-01The `Ownable` pattern grants significant power to a single address. Functions such as `seed`, `migrate`, `setForfeitNextCollection`, and `setMirror` are restricted to the owner. Specifically, the `forfeitNextCollection` flag allows the owner to unilaterally prevent the collection of accrued fees, directly impacting user rewards. This centralization introduces a single point of failure and potential for malicious action or compromise of the owner's key.
IssueThe `Ownable` pattern grants significant power to a single address. Functions such as `seed`, `migrate`, `setForfeitNextCollection`, and `setMirror` are restricted to the owner. Specifically, the `forfeitNextCollection` flag allows the owner to unilaterally prevent the collection of accrued fees, directly impacting user rewards. This centralization introduces a single point of failure and potential for malicious action or compromise of the owner's key.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract owner to reduce the risk associated with a single point of compromise. For highly sensitive functions like `setForfeitNextCollection`, explore integrating a time-lock mechanism or a community governance vote to introduce a delay and transparency before execution.
StatusUnresolved
Medium

Custom NFT-like Implementation Complexity

M-01The contract implements a custom system for managing 'NFTs' (shares) using intricate bitwise operations and mapping structures (`_oo`, `_ownedSlots`, `_addressData`). This custom logic, particularly in `_ownedGet`, `_ownedSet`, `_ownedLength`, and `_setOwnedLength`, deviates from standard ERC721 implementations. Such bespoke solutions are prone to subtle bugs, off-by-one errors, or unexpected behavior in edge cases, potentially leading to incorrect ownership tracking or state corruption.
IssueThe contract implements a custom system for managing 'NFTs' (shares) using intricate bitwise operations and mapping structures (`_oo`, `_ownedSlots`, `_addressData`). This custom logic, particularly in `_ownedGet`, `_ownedSet`, `_ownedLength`, and `_setOwnedLength`, deviates from standard ERC721 implementations. Such bespoke solutions are prone to subtle bugs, off-by-one errors, or unexpected behavior in edge cases, potentially leading to incorrect ownership tracking or state corruption.
FixConduct a dedicated, in-depth audit of the custom NFT-like ownership and storage logic, focusing on all bitwise operations, index calculations, and mapping interactions. Consider writing extensive unit tests specifically for these functions to cover all possible edge cases. If the custom logic is not strictly necessary for unique protocol requirements, consider refactoring to use a well-vetted ERC721 library.
StatusUnresolved
Medium

Potential for Fee Forfeiture Abuse

M-02The `forfeitNextCollection` flag, which can be set by the owner via `setForfeitNextCollection`, allows the owner to unilaterally prevent the collection of fees in the subsequent `pokeFees` call. While this might be intended for emergency situations or specific operational adjustments, it gives the owner the power to directly impact the economic incentives of users by denying them their accrued fees without explicit user consent or a transparent process.
IssueThe `forfeitNextCollection` flag, which can be set by the owner via `setForfeitNextCollection`, allows the owner to unilaterally prevent the collection of fees in the subsequent `pokeFees` call. While this might be intended for emergency situations or specific operational adjustments, it gives the owner the power to directly impact the economic incentives of users by denying them their accrued fees without explicit user consent or a transparent process.
FixClearly document the intended use cases and operational procedures for the `forfeitNextCollection` flag. Implement safeguards such as a time-lock for setting this flag, or require a multi-signature confirmation. Consider a mechanism to compensate users for forfeited fees if the forfeiture is not due to a critical security event, or ensure that such an action is subject to governance approval.
StatusUnresolved
Low

Potential Gas Limits in Iterative Functions

L-01The constant `MAX_REALIGN` suggests the presence of a function (likely `realign`, though not fully provided) that iterates over a collection of NFTs or similar data. If such a function processes a large number of items in a single transaction, it could become gas-expensive or even revert due to exceeding block gas limits, especially as the number of NFTs or users grows. This could lead to denial of service for certain operations.
IssueThe constant `MAX_REALIGN` suggests the presence of a function (likely `realign`, though not fully provided) that iterates over a collection of NFTs or similar data. If such a function processes a large number of items in a single transaction, it could become gas-expensive or even revert due to exceeding block gas limits, especially as the number of NFTs or users grows. This could lead to denial of service for certain operations.
FixEnsure that any iterative functions, particularly those that process user-specific data or a growing list of items, are designed to be gas-efficient. Implement pagination, checkpointing, or a pull-based system where users can process their own data in smaller, manageable chunks to avoid hitting block gas limits.
StatusUnresolved
Info

Dual ERC20 and NFT-like Functionality

I-01The contract functions as both an ERC20 token ('Prism') and manages a system of 'NFTs' (shares) that represent ownership of fee entitlements. While this dual functionality is a core design choice, it can lead to confusion for users and external integrators who might expect a contract to adhere strictly to one token standard. The internal 'NFTs' are not standard ERC721 tokens, which could complicate integration with existing NFT marketplaces or wallets.
IssueThe contract functions as both an ERC20 token ('Prism') and manages a system of 'NFTs' (shares) that represent ownership of fee entitlements. While this dual functionality is a core design choice, it can lead to confusion for users and external integrators who might expect a contract to adhere strictly to one token standard. The internal 'NFTs' are not standard ERC721 tokens, which could complicate integration with existing NFT marketplaces or wallets.
FixProvide comprehensive documentation that clearly distinguishes between the ERC20 token and the internal 'NFT' share system. Explain their respective purposes, how they interact, and any deviations from standard ERC721 behavior. Ensure that events and function names clearly indicate which asset type is being manipulated.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates a strong technical foundation, leveraging Solady libraries for gas efficiency and `ReentrancyGuard` for common attack vectors (7.2 Code Security). Its integration with Uniswap V4 hooks (`_beforeInitialize`, `_afterSwap`) is well-structured, utilizing transient state for specific operations (7.1 Architecture). However, the custom implementation of NFT-like share ownership using bitwise operations and complex mapping structures (`_oo`, `_ownedSlots`, `_addressData`) introduces significant complexity and potential for subtle bugs, which could lead to incorrect ownership or fee distribution (7.2 Code Security).

GovernanceHigh1/10

The contract employs an `Ownable` pattern, granting the deployer significant administrative control over critical functions (7.3 Access Control, 7.5 Governance). The owner can `seed` the pool, `migrate` positions, and crucially, set the `forfeitNextCollection` flag, which allows for the unilateral forfeiture of collected fees (7.4 Economic). While this centralization may be intended for initial deployment or emergency scenarios, it presents a single point of failure and potential for abuse if the owner's key is compromised or acts maliciously. The `PRISM_BURN_BPS` mechanism for burning a portion of PRISM fees is a clear economic design choice (7.4 Economic).

UpgradesLow8/10

The `PrismHookV2` contract is not implemented as an upgradeable proxy, which simplifies its deployment and reduces the attack surface associated with proxy patterns (7.7 Upgrades). The presence of a `migrate` function and `MIGRATION_VAULT` in the constructor suggests a planned migration path from a previous version, allowing for a controlled transition of assets and positions to a new contract (7.7 Upgrades). This approach avoids the complexities and risks inherent in in-place proxy upgrades.

Security Checklist

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

Holder Composition

41.5% in top 10
15.1% in wallets26.4% in contracts
Effective Concentration25.7%

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

$218.6K across 2 pairs
Uniswap v4ETHanalysed$207.2K94.8%Uniswap v3USDC$11.3K5.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

7 addresses
Deployer
0xfe76…f110
Unlocked LP Held By
0xcf4d…e0400x4ee6…43260xf4e6…65540xca72…257b0x40b1…d2c00xf297…9ec8

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

8 factors
  • Top-10 concentration > 20% (41.5% total → 25.7% effective; 15.1% in EOAs, 26.4% in contracts — mild)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 95% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 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

Related Audits

6 more on the record
Token Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskStaked USDe (SUSDE)High RiskGULDHigh RiskDeXeHigh RiskTether Gold (XAUT)High Risk

Would You Like a More Detailed Audit of Prism?

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

Get Detailed Audit