Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report

Audit name:

[SCA] The Moonpot | The Moonpot Contracts | May2026

Date:

Jun 4, 2026

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the The Moonpot team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The Moonpot is a multi-round token sale platform deployed on Base that mints TMP (ERC-20) and TMPNFT (ERC-721A) in exchange for USDC, assigns each NFT a deterministic redemption value via Chainlink VRF-seeded permutation, and seeds a Uniswap v4 TMP/USDC pool with a custom hook enforcing price-floor defense and dynamic anti-dump taxation.

Document

NameSmart Contract Code Review and Security Analysis Report for The Moonpot
Audited ByOlesia Bilenka, Georgi Krastenov
Approved ByKornel Światłowski
Websitehttps://themoonpot.com/
Changelog27/05/2026 - Preliminary Report
04/06/2026 - Final Report
PlatformBase
LanguageSolidity
TagsToken Sales; Uniswap V4; Non-fungible Token (NFT); Claims; Launchpad; Liquidity Pool; ERC-20; ERC-721A
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for The Moonpot
    Audited By
    Olesia Bilenka, Georgi Krastenov
    Approved By
    Kornel Światłowski
    Changelog
    27/05/2026 - Preliminary Report
    04/06/2026 - Final Report
    Platform
    Base
    Language
    Solidity
    Tags
    Token Sales; Uniswap V4; Non-fungible Token (NFT); Claims; Launchpad; Liquidity Pool; ERC-20; ERC-721A

Review Scope

Repositoryhttps://github.com/themoonpot/contracts
Commitf46914d
Remediation Commit85d34c3

Audit Summary

37Total Findings
26Resolved
7Accepted
4Mitigated

Audit Summary

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • A README.md and a dedicated SCOPE.md handoff document are provided and cover the overall system architecture, lifecycle, trust model, privileged actors, known limitations, and deployment instructions. All eleven contracts under review are listed in the primary audit scope with one-line purpose descriptions.

  • NatSpec documentation is minimal and limited to contract-level @title and @notice tags. Individual function-level specifications are not provided.

Code quality

  • The codebase is clean and follows a consistent structure across all contracts. The implementation follows the Uniswap v4 documentation and conventions for hook integration.

  • The development environment is configured

Test coverage

Code coverage of the project is 60.83% (branch coverage).

  • Deployment and basic user interactions are covered with tests.

  • Negative cases coverage is partial.

  • Interactions by several users are not tested thoroughly.

System Overview

The system is orchestrated by MoonpotManager, which controls up to 28 sequential sale rounds. Each round has a fixed token price, token supply, NFT count, and a reward pool funded by the community share portion of each purchase. When a user calls buyFor, USDC is split three ways: a community share deposited into the round's reward pool, a company share transferred immediately, and a liquidity share queued for periodic injection into the Uniswap v4 pool. The buyer receives TMP tokens, and a Chainlink VRF v2.5 request is issued to seed a Bernoulli-trial NFT allocation performed in processBuy. Once the round sells out and receives its VRF seed, NFT holders may call claimNFT or claimNFTs to redeem USDC; the value is computed deterministically via a TEA-based format-preserving permutation over the round's reward table.

MoonpotHook is a Uniswap v4 hook attached to the TMP/USDC pool. It enforces a price floor by intercepting TMP→USDC swaps: any sell volume that would push the price below the current round's floor tick is burned rather than swapped. A dynamic tax ramps from a base rate (0.3%) at high prices to a maximum (50%) at or below the floor, discouraging aggressive dumps. The hook also manages liquidity injection (triggered by the manager every 2.5% of a round's supply sold) and fee harvesting (owner-only), sending USDC fees to the company and burning collected TMP.

Token contracts follow standard patterns: MoonpotToken implements ERC-20 with Ownable2Step and manager-only minting; MoonpotNFT implements ERC-721A with ERC721AQueryable, storing the round ID in ERC-721A extraData for efficient lookup at claim time. Round logic is abstracted in AbstractMoonpotRound, which holds immutable price/supply/share parameters, tracks lifecycle state, and exposes the valueOf function that combines permutation and reward-table lookup; concrete rounds (MoonpotRound1MoonpotRound5) provide round-specific constants and 16-tier reward tables scaling linearly with pool size.

MoonpotManager.sol — Central orchestrator contract. Manages the round lifecycle via start and setRound, handles purchases via buyFor, dispatches VRF callbacks for purchase and round seeds, performs Bernoulli-trial NFT allocation in processBuy, processes NFT claims, and triggers periodic liquidity injection into the Uniswap v4 pool.

MoonpotHook.sol — Uniswap v4 hook implementing beforeInitialize and beforeSwap. Enforces a price-floor defense by burning excess TMP on sells that would breach the floor, applies a dynamic anti-dump tax ramping with distance from the floor, and provides injectLiquidity and harvestFees for liquidity management.

MoonpotToken.sol — ERC-20 token (TMP) with Ownable2Step. Exposes mint restricted to the one-time-set manager and burn callable by any holder.

MoonpotNFT.sol — ERC-721A token (TMPNFT) with ERC721AQueryable and Ownable2Step. Provides mintTo (manager-only) that stamps the round ID into extraData, and getRound to retrieve it for claim-time reward lookup.

AbstractMoonpotRound.sol — Abstract base for round contracts. Holds immutable pricing and supply parameters, tracks sales and NFT minting state, manages the reward pool, and implements valueOf by delegating permutation and reward-table lookup to subclass overrides.

MoonpotRound1.sol — Concrete round 1 configuration: $1.15 price, 1,000,000 tokens, 99,991 NFTs, $1,000,000 reward pool. Defines a 16-tier reward table and uses TEAPermuter.permute17 for deterministic value assignment.

MoonpotRound2.sol — Concrete round 2 configuration: $1.15 price, 2,000,000 tokens, 99,991 NFTs, $2,000,000 reward pool. Reward tiers scale 2× relative to round 1.

MoonpotRound3.sol — Concrete round 3 configuration: $1.15 price, 3,000,000 tokens, 99,991 NFTs, $3,000,000 reward pool. Reward tiers scale 3× relative to round 1.

MoonpotRound4.sol — Concrete round 4 configuration: $1.15 price, 4,000,000 tokens, 99,991 NFTs, $4,000,000 reward pool. Reward tiers scale 4× relative to round 1.

MoonpotRound5.sol — Concrete round 5 configuration: $1.15 price, 5,000,000 tokens, 99,991 NFTs, $5,000,000 reward pool. Reward tiers scale 5× relative to round 1.

lib/TEAPermuter.sol — Library providing format-preserving permutations via a TEA-style Feistel cipher with cycle-walking. Offers permute9, permute10, permute14, permute17, and permute20 for domains up to ~1M states, enabling deterministic, verifiable NFT-to-reward mapping without per-token storage.

Privileged roles

MoonpotManager.sol

  • owner (inherited from VRFConsumerBaseV2Plus): Controls system initialization, round management, and administrative configuration.

    • Can call init to initialize the Uniswap v4 pool with initial liquidity and set up the protocol.

    • Can call start to start the first round or advance to subsequent rounds.

    • Can call setRound to register a round contract at a specified round ID.

    • Can call retryRoundReveal to retry a failed VRF request for round seed reveal.

    • Can call setVRFParams to update the Chainlink VRF key hash, subscription ID, and callback gas limit.

    • Can call setCompany to change the company address that receives protocol fees.

    • Can call reDrawPurchase to immediately re-request VRF for a purchase (bypasses the 24-hour timeout required for non-owners).

MoonpotHook.sol

  • owner (inherited from Ownable): Controls fee harvesting, manager assignment, and defense mechanism parameters.

    • Can call harvestFees to collect accumulated LP fees (USDC transferred to the company, TMP burned).

    • Can call setManager to set the manager's address (one-time, non-reversible).

    • Can call setDefenseParams to configure the base defense tax, max defense tax, and tax ramp tick parameters.

  • manager: Controls liquidity injection and pool position parameters. Expected to be the MoonpotManager contract.

    • Can call injectLiquidity to add USDC liquidity to the Uniswap v4 position.

    • Can call setPositionId to configure the LP position ID, tick bounds, and initial liquidity.

    • Can call setCurrentFloorTick to update the floor tick and corresponding floor tick bounds.

MoonpotToken.sol

  • owner (inherited from Ownable2Step): Controls manager assignment with two-step ownership transfer capability.

    • Can call setManager to set the manager's address (one-time, non-reversible).

    • Can call transferOwnership to initiate ownership transfer (inherited from Ownable2Step).

    • Can call renounceOwnership to permanently renounce ownership (inherited from Ownable2Step).

  • manager: Controls token minting. Expected to be the MoonpotManager contract.

    • Can call mint to mint TMP tokens to any address.

MoonpotNFT.sol

  • owner (inherited from Ownable2Step): Controls manager assignment, metadata configuration, and ownership with two-step transfer capability.

    • Can call setManager to set the manager's address (one-time, non-reversible).

    • Can call setBaseURI to update the base URI for NFT metadata.

    • Can call freezeBaseURI to permanently freeze the base URI, preventing future changes.

    • Can call transferOwnership to initiate ownership transfer (inherited from Ownable2Step).

    • Can call renounceOwnership to permanently renounce ownership (inherited from Ownable2Step).

  • manager: Controls NFT minting. Expected to be the MoonpotManager contract.

    • Can call mintTo to mint NFTs to any address with a specified quantity and round ID.

AbstractMoonpotRound.sol (inherited by MoonpotRound1–MoonpotRound5)

  • manager (set immutably at deployment): Controls all round lifecycle and reward distribution. Expected to be the MoonpotManager contract.

    • Can call start to set the round start time.

    • Can call end to set the round end time.

    • Can call notifyPurchase to record token purchases and update tokensSold.

    • Can call notifyScanned to record scanned tokens and update scannedCount.

    • Can call notifyNFTMinted to record minted NFTs and update nftsMinted.

    • Can call setSeedRequestId to set the VRF request ID for round reveal.

    • Can call setSeed to set the random seed for NFT class determination.

    • Can call depositFunds to add USDC to the reward pool.

    • Can call releaseReward to transfer USDC rewards to recipients from the reward pool.

TEAPermuter.sol

  • No privileged roles. This is a stateless library providing format-preserving permutation functions.

Potential Risks

Partial scope coverage: The audit scope covers 11 of 20 repository source files. The in-scope contracts depend on interfaces (IMoonpotRound, IMoonpotManager, IMoonpotHook) and external implementations that may introduce behavioral assumptions outside the audited boundary. Any deviation in out-of-scope dependencies could affect the security posture of the reviewed contracts.

Chainlink VRF v2Plus integration: MoonpotManager extends VRFConsumerBaseV2Plus and relies on the external s_vrfCoordinator for randomness in buyFor, _maybeEndRound, reDrawPurchase, and retryRoundReveal. The protocol cannot generate NFT assignment seeds or round reveal seeds without a functional VRF coordinator; coordinator unavailability or subscription funding exhaustion would halt core purchase and claim functionality.

Uniswap v4 Core and Periphery reliance: MoonpotManager and MoonpotHook integrate with IPoolManager, IPositionManager, and IPermit2 for liquidity provisioning and swap operations. The contracts invoke poolManager.getSlot0, poolManager.unlock, posm.modifyLiquidities, and posm.modifyLiquiditiesWithoutUnlock with the assumption that these interfaces behave as documented. Uniswap v4 upgrades, pool state corruption, or unexpected revert conditions could disrupt liquidity injection and trading.

Single-key administrative control over critical operations: The owner role inherited from VRFConsumerBaseV2Plus in MoonpotManager can unilaterally call setCompany, setVRFParams, setRound, start, init, and retryRoundReveal without timelock or multi-signature requirements. A compromised owner key could redirect company revenue via setCompany, manipulate VRF parameters, or control round progression.

Unilateral defense parameter modification: The owner of MoonpotHook can invoke setDefenseParams to adjust baseDefenseTax, maxDefenseTax, and taxRampTicks to any values within validation bounds (max tax up to 90%). This could impose confiscatory sell taxes with immediate effect, restricting TMP holders' ability to exit positions.

Fee extraction controlled by owner: The harvestFees function in MoonpotHook transfers accumulated USDC fees to the address returned by IMoonpotManager(manager).company(). Since MoonpotManager's setCompany is owner-controlled, the owner can redirect harvested fees to any address without notice or delay.

Irrevocable manager assignment: The setManager functions in MoonpotToken, MoonpotNFT, and MoonpotHook can only be called once due to CannotResetManager and ManagerAlreadySet guards. While this prevents unauthorized manager replacement, it also means that if an incorrect manager address is set initially, the token or NFT contract cannot be reconfigured and would require redeployment.

VRF-gated user operations: Every purchase in buyFor triggers a VRF request, and users cannot proceed to processBuy until fulfillRandomWords sets isDrawn = true. If VRF delivery is delayed or fails, users must wait 24 hours (defined by VRF_TIMEOUT) before any address can call reDrawPurchase. During this window, purchased tokens are minted but NFT assignment remains pending.

Round reveal blocked without VRF: After a round ends via _maybeEndRound, a VRF request is issued to generate the round seed required for valueOf and claimNFT. If this VRF delivery fails, the owner must call retryRoundReveal. Until a seed is set, all NFT claims for that round revert at the RoundNotSeeded check in claimNFT and claimNFTs, locking user rewards.

Exact-output TMP sells blocked: The _beforeSwap hook in MoonpotHook reverts with ExactOutputTMPSellBlocked when params.amountSpecified > 0 for TMP sell operations. This design choice restricts swap routing options and may cause unexpected failures for users or aggregators attempting exact-output swaps.

TMP excess burning on large sells: When a TMP sell amount exceeds the value computed by _computeMaxTmpSell, MoonpotHook invokes poolManager.take to extract the excess and then calls MoonpotToken.burn. Users selling more TMP than the computed maximum will have a portion of their tokens burned rather than swapped, representing a partial loss of principal.

Dynamic tax up to 90% on sells: The _calculateTax function in MoonpotHook returns maxDefenseTax (default 500,000 basis points or 50%) when ticksAboveFloor <= 0. This tax is applied as a Uniswap v4 dynamic LP fee. Users selling TMP near or below the floor tick face significant value extraction, which may disproportionately affect uninformed participants.

Protocol liquidity constraints limit sell capacity: The _computeMaxTmpSell function in MoonpotHook caps the swappable TMP amount based on protocolLiquidity and the floor tick boundaries. If protocol liquidity is low or the price is at the floor, maxTmpSell approaches zero, effectively preventing TMP sales and creating illiquidity.

Contract immutability without upgrade path: All in-scope contracts lack proxy or upgrade mechanisms. MoonpotManager, MoonpotHook, MoonpotToken, MoonpotNFT, and round contracts are deployed as final implementations. Any discovered vulnerability or required feature change would necessitate redeployment and migration of state, balances, and positions.

No pause functionality: MoonpotManager and MoonpotHook do not implement pause mechanisms. In the event of an exploit or critical bug discovery, there is no on-chain method to halt purchases via buyFor, claims via claimNFT and claimNFTs, or swaps, potentially allowing continued value extraction before off-chain intervention.

Round configuration is append-only: The setRound function in MoonpotManager enforces RoundExists when a round ID already has an address. Once a round contract is registered, it cannot be replaced or removed. Misconfigured rounds persist permanently in the rounds mapping.

Deterministic NFT value once seed revealed: After fulfillRandomWords sets a purchase seed, the NFT assignment outcome is fully determined by the loop in processBuy over keccak256(abi.encodePacked(p.seed, i)). External observers can precompute which indices win NFTs before processBuy is called, enabling informed secondary market positioning.

Round prize distribution predictable post-reveal: Once a round's seed is set via setSeed, the valueOf function in AbstractMoonpotRound deterministically maps each tokenId to a prize class via permute. Before all NFTs are claimed, observers can compute the value distribution across all minted NFTs, creating information asymmetry between sophisticated and casual participants.

Mutable metadata before freeze: The owner of MoonpotNFT can call setBaseURI to change the base URI for all token metadata until freezeBaseURI is invoked. If the owner never freezes the URI or delays freezing, NFT metadata can be altered post-mint, potentially affecting perceived value or marketplace presentation.

Findings

Code
Title
Status
Severity
F-2026-1705Defense Tax Calculation Inverted When USDC Is Token0
fixed

High
F-2026-1705Stale Snapshot in processBuy Enables NFT Overminting Beyond Round Limit
mitigated

High
F-2026-1721NFT Transfers Reset Stored Round Data Due to Missing _extraData Override
fixed

High
F-2026-1706Round Seed Can Be Overwritten by Duplicate VRF Responses
fixed

Medium
F-2026-1707pendingLiquidityUsdc is Cleared Even When Liquidity Injection Does Not Consume all USDC
fixed

Medium
F-2026-1706Liquidity Injection Vulnerable to Sandwich Attacks Due to Missing Slippage Protection
mitigated

Medium
F-2026-1747quoteBuy Returns Zero TMP Output When USDC is currency0
fixed

Medium
F-2026-1714Users May Become Unable to Claim NFT Rewards If a Round Never Sells Out
accepted

Medium
F-2026-1708Users May Unintentionally Purchase in a Different Round Due to Race Condition
accepted

Low
F-2026-1717No Emergency Pause Mechanism in MoonpotManager
accepted

Low
1-10 of 37 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/themoonpot/contracts
Commitf46914ddbedea2556d0606763c28a15bbe0a6a12
Remediation commit85d34c3816bfd497d5e4d3fdb42e9663dcf5daeb
Whitepaper-
Requirementshttps://github.com/hknio/themoonpot___contracts/blob/master/README.md
Technical Requirementshttps://github.com/hknio/themoonpot___contracts/blob/master/README.md

Assets in Scope

AbstractMoonpotRound.sol - AbstractMoonpotRound.sol
MoonpotHook.sol - MoonpotHook.sol
MoonpotManager.sol - MoonpotManager.sol
MoonpotNFT.sol - MoonpotNFT.sol
MoonpotRound1.sol - MoonpotRound1.sol
MoonpotRound2.sol - MoonpotRound2.sol
MoonpotRound3.sol - MoonpotRound3.sol
MoonpotRound4.sol - MoonpotRound4.sol
MoonpotRound5.sol - MoonpotRound5.sol
MoonpotToken.sol - MoonpotToken.sol
TEAPermuter.sol - TEAPermuter.sol

Appendix 3. Additional Valuables

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment , and the Penetration Testing Execution Standard (PTES) , These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer