Quantum Audit Logo

Is Moltbook Safe?

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

Moltbook MOLT
0xb695…ab07
Base
Not verifiedThis 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.
Last checked 18d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The ClankerToken contract is an ERC20 token implementation with extensions for burning, permit functionality, and voting, alongside custom cross-chain mint/burn capabilities and administrative controls for metadata. The contract leverages well-audited OpenZeppelin libraries. Key findings include centralized administrative control over critical parameters and a reliance on an external bridge for supply management, which are common patterns but introduce specific risks.

1 High1 Medium2 Low1 Informational
Volume 24h
$3.7K
Liquidity
$157.6K
Price
$0.000003382
Token Age
5mo
Top 10 Holders
50.7%

Security Findings

1 High1 Med2 Low1 Info
High

Centralized Admin Control Over Critical Functions

H-01The `_admin` address has the sole authority to call `updateAdmin()`, `updateImage()`, and `updateMetadata()`. This means a single compromised private key for the `_admin` could lead to the transfer of administrative control to an attacker, or arbitrary changes to the token's image and metadata, potentially impacting its public perception and integration with external platforms. This is a significant centralization risk (7.3 Access Control, 7.8 Operations).
IssueThe `_admin` address has the sole authority to call `updateAdmin()`, `updateImage()`, and `updateMetadata()`. This means a single compromised private key for the `_admin` could lead to the transfer of administrative control to an attacker, or arbitrary changes to the token's image and metadata, potentially impacting its public perception and integration with external platforms. This is a significant centralization risk (7.3 Access Control, 7.8 Operations).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `_admin` role to require multiple approvals for sensitive operations. Alternatively, consider a time-locked governance mechanism for critical changes to allow community oversight and reaction time.
StatusUnresolved
Medium

Reliance on External Superchain Token Bridge for Supply Control

M-01The `crosschainMint()` and `crosschainBurn()` functions, which directly affect the token's supply, are exclusively callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. The security and integrity of the token's total supply across chains are entirely dependent on the correct functioning and security of this external bridge contract. Any vulnerability or compromise in the `SUPERCHAIN_TOKEN_BRIDGE` could lead to unauthorized minting or burning of ClankerTokens (7.4 Economic, 7.6 External).
IssueThe `crosschainMint()` and `crosschainBurn()` functions, which directly affect the token's supply, are exclusively callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. The security and integrity of the token's total supply across chains are entirely dependent on the correct functioning and security of this external bridge contract. Any vulnerability or compromise in the `SUPERCHAIN_TOKEN_BRIDGE` could lead to unauthorized minting or burning of ClankerTokens (7.4 Economic, 7.6 External).
FixEnsure the `SUPERCHAIN_TOKEN_BRIDGE` contract is rigorously audited, continuously monitored, and has robust security measures in place. Transparently communicate this dependency and its implications to token holders. While this is a common pattern for L2 canonical tokens, it's crucial to acknowledge and manage the associated external risk.
StatusUnresolved
Low

Immutability of `_originalAdmin` and One-Time `verify()` Call

L-01The `_originalAdmin` address is immutable and is the only address capable of calling the `verify()` function, which sets the `_verified` boolean to true. If the private key for `_originalAdmin` is lost or becomes inaccessible before `verify()` is called, this function can never be executed. While the impact of `_verified` is not immediately clear from the contract, this represents a minor operational inflexibility (7.8 Operations).
IssueThe `_originalAdmin` address is immutable and is the only address capable of calling the `verify()` function, which sets the `_verified` boolean to true. If the private key for `_originalAdmin` is lost or becomes inaccessible before `verify()` is called, this function can never be executed. While the impact of `_verified` is not immediately clear from the contract, this represents a minor operational inflexibility (7.8 Operations).
FixEnsure the `_originalAdmin` key is securely managed and backed up. Clearly document the purpose and importance of the `verify()` function and the `_originalAdmin` role within the protocol's overall design.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-02The contract does not include a mechanism to pause token transfers or other critical operations in an emergency. In the event of a critical vulnerability discovery (e.g., in an external dependency or the token itself), the protocol would lack the ability to temporarily halt operations to prevent further damage or exploit (7.8 Operations).
IssueThe contract does not include a mechanism to pause token transfers or other critical operations in an emergency. In the event of a critical vulnerability discovery (e.g., in an external dependency or the token itself), the protocol would lack the ability to temporarily halt operations to prevent further damage or exploit (7.8 Operations).
FixConsider integrating a pausable mechanism (e.g., OpenZeppelin's `Pausable` contract) controlled by the `_admin` (preferably a multisig) to allow for emergency halts of token transfers. This adds a layer of protection against unforeseen circumstances.
StatusUnresolved
Info

Centralized Control Over Token Metadata

I-01The `_admin` address has the ability to unilaterally update the token's `_image` and `_metadata` strings via `updateImage()` and `updateMetadata()`. While this provides flexibility for branding and information updates, it means the token's public representation can be changed by a single entity without broader community consensus. This is a design choice that centralizes control over external perception (7.4 Economic, 7.5 Governance).
IssueThe `_admin` address has the ability to unilaterally update the token's `_image` and `_metadata` strings via `updateImage()` and `updateMetadata()`. While this provides flexibility for branding and information updates, it means the token's public representation can be changed by a single entity without broader community consensus. This is a design choice that centralizes control over external perception (7.4 Economic, 7.5 Governance).
FixClearly communicate the centralized nature of metadata updates to the community. If decentralization is a long-term goal, consider transitioning metadata updates to a governance-controlled mechanism, perhaps with a time-lock, to ensure community input and transparency.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract demonstrates a solid technical foundation, inheriting from battle-tested OpenZeppelin ERC20 and its extensions (ERC20Permit, ERC20Votes, ERC20Burnable). The implementation of `_update` override and `supportsInterface` is correct (7.2 Code Security). Cross-chain mint/burn functions are appropriately restricted to the `SUPERCHAIN_TOKEN_BRIDGE` (7.3 Access Control). However, the mutable `_admin` role, which can update itself and token metadata, represents a single point of failure if compromised (7.3 Access Control).

GovernanceMedium5/10

The token incorporates `ERC20Votes`, indicating an intention for governance participation (7.5 Governance). The initial supply is minted on a specific chain, and cross-chain supply adjustments are managed by the `SUPERCHAIN_TOKEN_BRIDGE` (7.4 Economic). This design centralizes control over the total supply across chains to the bridge, making its security a critical external dependency (7.6 External). The `_admin` role has significant power over token metadata and can transfer its own authority, which could impact the token's perceived value or integration with external systems (7.4 Economic, 7.8 Operations).

UpgradesLow9/10

The ClankerToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard implementation contract. Therefore, there are no specific upgrade-related risks inherent in its architecture. Any future changes would require a new deployment and a migration strategy.

Security Checklist

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

Holder Composition

50.7% in top 10
20.2% in wallets30.5% in contracts
Effective Concentration32.4%

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

$163.4K across 9 pairs
Uniswap v4WETHanalysed$157.6K96.4%Uniswap v3WETH$3.1K1.9%AerodromeWETH$9440.6%Uniswap v4ETH$8860.5%Uniswap v3USDC$8550.5%Uniswap v4USDT$260.0%
Show 3 more pairsShow less
Uniswap v4USDC$80.0%Uniswap v2特朗普$20.0%Uniswap v3CLAWNCH$20.0%

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
0x2112…f3f9
Unlocked LP Held By
0x63d2…34960x3a42…29320xeb31…ef37

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

What Raised This Score

7 factors
  • Top-10 concentration > 30% (50.7% total → 32.4% effective; 20.2% in EOAs, 30.5% in contracts — moderate)
  • 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 = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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

Frequently Asked Questions

Is Moltbook a scam?

Based on automated analysis, Moltbook scores 20/100 (Low Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Moltbook safe to buy?

Our scanner flagged a risk score of 20/100. Ownership is renounced which reduces rug-pull risk. DYOR before purchasing any token.

Has Moltbook been audited?

The contract is open-source and verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
KellyClaudeMedium RiskElonRWAMedium RiskOWBMedium RiskVirtual Protocol (VIRTUAL)Medium RiskFlowerMedium RiskCookieMedium Risk

Would You Like a More Detailed Audit of Moltbook?

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

Get Detailed Audit