Quantum Audit Logo

Is Prompt Safe?

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

Prompt PROMPT
0x30c7…3452
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The PromptToken contract implements an ERC-20 token with LayerZero OFT capabilities and a Wayfinder gateway mechanism. It utilizes OpenZeppelin's ReentrancyGuard and AccessControl for security. Key findings include centralized control over Wayfinder handler registration, a conditional initial token minting logic, and the inherent risks associated with external calls to untrusted handlers. The contract is not upgradeable via proxy.

1 High1 Medium1 Low2 Informational
Volume 24h
$44.3K
Liquidity
$124.1K
Price
$0.02357
Token Age
1y
Top 10 Holders
78.3%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control over Wayfinder Gateway Configuration

H-01The `INVOKE_WAYFINDER_CONFIGURATION_ROLE`, which is aliased to `DEFAULT_ADMIN_ROLE`, has exclusive control over adding new `WayfinderGateway` contracts via `addWayfinderHandlerContract`. While the function prevents overwriting existing entries, a malicious or compromised administrator could register a harmful handler. If users then interact with this malicious handler through `invokeWayfinder`, it could lead to the loss of their native tokens or PROMPT tokens, as the `PromptToken` contract facilitates transfers to the configured destination addresses and calls the specified handler.
IssueThe `INVOKE_WAYFINDER_CONFIGURATION_ROLE`, which is aliased to `DEFAULT_ADMIN_ROLE`, has exclusive control over adding new `WayfinderGateway` contracts via `addWayfinderHandlerContract`. While the function prevents overwriting existing entries, a malicious or compromised administrator could register a harmful handler. If users then interact with this malicious handler through `invokeWayfinder`, it could lead to the loss of their native tokens or PROMPT tokens, as the `PromptToken` contract facilitates transfers to the configured destination addresses and calls the specified handler.
FixImplement robust multi-signature control for the `DEFAULT_ADMIN_ROLE` with a high threshold to ensure multiple trusted parties must approve critical changes. Consider adding a time-lock mechanism for `addWayfinderHandlerContract` to provide a window for community review or emergency intervention before a new handler becomes active.
StatusUnresolved
Medium

Conditional Initial Token Minting on Mainnet Only

M-01The contract's constructor includes a conditional minting statement: `if (block.chainid == 1) { _mint(msg.sender, SUPPLY); }`. This logic dictates that the initial `SUPPLY` of tokens will only be minted if the contract is deployed on Ethereum mainnet (chain ID 1). If deployed on any other chain, such as Base (chain ID 8453), the initial supply will not be minted, resulting in a token with zero initial supply. While this might be an intentional design for a cross-chain token where supply originates on Ethereum and is bridged, it represents a critical operational detail that could lead to unexpected behavior or a non-functional token if the deployment strategy is misunderstood or misconfigure…
IssueThe contract's constructor includes a conditional minting statement: `if (block.chainid == 1) { _mint(msg.sender, SUPPLY); }`. This logic dictates that the initial `SUPPLY` of tokens will only be minted if the contract is deployed on Ethereum mainnet (chain ID 1). If deployed on any other chain, such as Base (chain ID 8453), the initial supply will not be minted, resulting in a token with zero initial supply. While this might be an intentional design for a cross-chain token where supply originates on Ethereum and is bridged, it represents a critical operational detail that could lead to unexpected behavior or a non-functional token if the deployment strategy is misunderstood or misconfigure…
FixClearly document the intended deployment strategy and initial supply mechanism across all target chains. If an initial supply is desired on non-mainnet chains, adjust the minting condition to include relevant chain IDs or implement a separate, access-controlled minting function for post-deployment initialization on other networks.
StatusUnresolved
Low

Reliance on External Untrusted Handler Logic

L-01The `invokeWayfinder` function makes an external call to `InvokeWayfinderHandler(_handlerAddress).handleInvokeWayfinder`. While the `PromptToken` contract itself is protected by `ReentrancyGuard` and its internal state changes occur before the external call, the `_handlerAddress` is configured by an administrator. A malicious or buggy handler contract could lead to unexpected behavior, denial of service, or loss of funds for users interacting with that specific handler, even if the `PromptToken` contract remains secure. Users implicitly trust the logic of the configured handlers.
IssueThe `invokeWayfinder` function makes an external call to `InvokeWayfinderHandler(_handlerAddress).handleInvokeWayfinder`. While the `PromptToken` contract itself is protected by `ReentrancyGuard` and its internal state changes occur before the external call, the `_handlerAddress` is configured by an administrator. A malicious or buggy handler contract could lead to unexpected behavior, denial of service, or loss of funds for users interacting with that specific handler, even if the `PromptToken` contract remains secure. Users implicitly trust the logic of the configured handlers.
FixEmphasize the critical importance of thorough security audits and continuous monitoring for all registered `InvokeWayfinderHandler` contracts. Users should be made aware that interacting with a specific handler implies trust in that handler's logic and security. Consider implementing a 'pause' mechanism for specific handlers in case of detected vulnerabilities.
StatusUnresolved
Info

Irreversible Role Renouncement Prevention

I-01The `renounceRole` and `renounceOwnership` functions are explicitly overridden to `revert("Cannot renounce role")`. This design choice prevents any administrator or owner from accidentally or maliciously renouncing their critical roles, ensuring that administrative control is always maintained within the system. This is a security-conscious decision to prevent loss of control.
IssueThe `renounceRole` and `renounceOwnership` functions are explicitly overridden to `revert("Cannot renounce role")`. This design choice prevents any administrator or owner from accidentally or maliciously renouncing their critical roles, ensuring that administrative control is always maintained within the system. This is a security-conscious decision to prevent loss of control.
FixDocument this design choice clearly within the project's technical specifications, highlighting its role in maintaining consistent administrative oversight and preventing accidental loss of control.
StatusUnresolved
Info

Self-Revocation Prevention for Roles

I-02The `revokeRole` function includes a `require(account != _msgSender(), "Cannot revoke role from self")` check. This prevents an administrator from accidentally or maliciously revoking their own role, which could lead to a loss of administrative control over the contract. This is a good security practice that enhances the robustness of the access control system.
IssueThe `revokeRole` function includes a `require(account != _msgSender(), "Cannot revoke role from self")` check. This prevents an administrator from accidentally or maliciously revoking their own role, which could lead to a loss of administrative control over the contract. This is a good security practice that enhances the robustness of the access control system.
FixDocument this design choice clearly, explaining its purpose in preventing administrative lockout and ensuring continuous operational control.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes OpenZeppelin's `ReentrancyGuard` and `AccessControl` for robust security, including explicit prevention of role renouncement and self-revocation (7.2 Code Security, 7.3 Access Control). The `invokeWayfinder` function is protected against reentrancy. However, the system relies on trusted administrators to configure `WayfinderGateway` contracts, which can make external calls to untrusted handlers, posing a risk if a handler is compromised or malicious (7.6 External).

GovernanceHigh2/10

The contract implements a centralized access control model where the `DEFAULT_ADMIN_ROLE` (also `INVOKE_WAYFINDER_CONFIGURATION_ROLE`) has significant power, including the ability to register new Wayfinder handlers. While the prefill indicates a multisig owner, a compromised or malicious admin could register a harmful handler, impacting user funds (7.5 Governance, 7.4 Economic). Additionally, the initial token minting is conditional on `block.chainid == 1`, which could lead to an unexpected lack of initial supply on other chains like Base (7.8 Operations).

UpgradesLow7/10

The `PromptToken` contract is deployed as a standard implementation and does not utilize a proxy pattern, meaning it is not directly upgradeable. Any future changes to the contract logic would require deploying a new contract and migrating users and/or assets, which is a secure but less flexible approach (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

78.3% in top 10
49.7% in wallets28.6% in contracts
Effective Concentration61.1%

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

$135.2K across 3 pairs
Uniswap v3USDCanalysed$124.1K91.7%Uniswap v3WETH$5.9K4.4%AerodromecbBTC$5.2K3.9%

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

4 addresses
Deployer
0x42aa…2ddf
Unlocked LP Held By
0x3421…22aa0x7234…dece0x5a01…a692

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 — strong Multisig (3-of-6)
  • Top-10 concentration > 50% (78.3% total → 61.1% effective; 49.7% in EOAs, 28.6% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% 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
Ribbita by Virtuals (TIBBIR)High RiskEURCHigh RiskCoinbase Wrapped XRP (CBXRP)High RiskCoinbase Wrapped BTC (CBBTC)High RiskZestHigh RiskDotHigh Risk

Would You Like a More Detailed Audit of Prompt?

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

Get Detailed Audit