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.

On-chain security analysis — is it a scam or legit?
Is Prism Safe?
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 →The PrismHookV2 contract serves as a Uniswap V4 hook, an ERC20 token, and manages NFT-like shares for fee distribution.
Read the full analysis- Top-10 concentration > 20%
- Liquidity not locked
- LP top1 unlocked holder = 100.0%
- LP top3 unlocked holders = 100.0%
- Token age < 30 days
- 1 High finding(s) from audit
- 2 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking26.4%
- Walletsanonymous holders, free to sell15.1%
- Everyone elsethe rest of the supply58.5%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xcf4d…e0400x4ee6…43260xf4e6…65540xca72…257b0x40b1…d2c00xf297…9ec8Security Findings
HighCentralized Control by Owner
The 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.H-01
Issue
The 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.
Fix
Consider 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.
Status
Unresolved
MediumCustom NFT-like Implementation Complexity
The 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.M-01
Issue
The 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.
Fix
Conduct 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.
Status
Unresolved
MediumPotential for Fee Forfeiture Abuse
The 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.M-02
Issue
The 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.
Fix
Clearly 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.
Status
Unresolved
LowPotential Gas Limits in Iterative Functions
The 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.L-01
Issue
The 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.
Fix
Ensure 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.
Status
Unresolved
InfoDual ERC20 and NFT-like Functionality
The 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.I-01
Issue
The 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.
Fix
Provide 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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).
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).
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.
It is recommended to enhance the security posture by decentralizing critical administrative functions, such as fee forfeiture, through a multi-signature wallet or a governance mechanism.
A thorough, independent audit of the custom NFT-like share management system is crucial to ensure its correctness and resilience against edge cases. Additionally, comprehensive documentation detailing the intended use and implications of all owner-controlled functions, especially those impacting user funds, should be provided.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202659Medium
- Aug 11, 202646Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the PRISM contract address?
The Prism contract on Ethereum is 0xcf4d29f14cc585ddd1167f956092852af844e040. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Prism a scam?
Quantum Audit's risk score for Prism is 59/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; 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 PRISM liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $218.6K.
Who holds PRISM?
As of Sep 4, 2026, the 10 largest holders own 41.5% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page