Is basedpad.fun (BPAD) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High1 Med2 Info

Critical

Incomplete Code Provided for Audit

C-01The main contract `BasedPadLaunchpad` is truncated, with only interfaces and utility libraries provided. This prevents a comprehensive security audit of the core business logic, state variables, and critical functions (e.g., pool creation, token distribution, fee handling, access control). Without the full code, any security assessment is inherently incomplete and cannot guarantee the safety of the deployed system.

IssueThe main contract `BasedPadLaunchpad` is truncated, with only interfaces and utility libraries provided. This prevents a comprehensive security audit of the core business logic, state variables, and critical functions (e.g., pool creation, token distribution, fee handling, access control). Without the full code, any security assessment is inherently incomplete and cannot guarantee the safety of the deployed system.

FixProvide the complete and final source code for the `BasedPadLaunchpad` contract to enable a full and accurate security assessment. This is a prerequisite for a meaningful audit.

StatusUnresolved

High

High Complexity and Potential for Errors in Custom Math Libraries

H-01The `FullMath`, `TickMath`, and `LaunchMath` libraries contain highly optimized, low-level implementations using assembly and complex bitwise operations (e.g., `mulDiv`, `sqrt`, `getSqrtRatioAtTick`). While potentially efficient, these custom implementations are notoriously difficult to get right and are prone to subtle errors, precision issues, or edge-case vulnerabilities that could lead to incorrect calculations, unexpected behavior, or economic exploits within the Uniswap V3 liquidity management.

IssueThe `FullMath`, `TickMath`, and `LaunchMath` libraries contain highly optimized, low-level implementations using assembly and complex bitwise operations (e.g., `mulDiv`, `sqrt`, `getSqrtRatioAtTick`). While potentially efficient, these custom implementations are notoriously difficult to get right and are prone to subtle errors, precision issues, or edge-case vulnerabilities that could lead to incorrect calculations, unexpected behavior, or economic exploits within the Uniswap V3 liquidity management.

FixConduct extensive unit and integration testing for all custom math functions, covering a wide range of inputs, including edge cases and boundary conditions. Consider using battle-tested libraries where possible or engaging specialists for formal verification of these critical math components to ensure their correctness and robustness.

StatusUnresolved

High

Unverified Access Control Mechanisms

H-02Without the full `BasedPadLaunchpad` contract code, it is impossible to verify the implementation of access control mechanisms. A launchpad contract typically requires robust access control for critical functions such as setting parameters, managing funds, creating pools, or pausing operations. Lack of proper access control could allow unauthorized users to manipulate the contract, steal funds, or disrupt operations, leading to severe financial losses.

IssueWithout the full `BasedPadLaunchpad` contract code, it is impossible to verify the implementation of access control mechanisms. A launchpad contract typically requires robust access control for critical functions such as setting parameters, managing funds, creating pools, or pausing operations. Lack of proper access control could allow unauthorized users to manipulate the contract, steal funds, or disrupt operations, leading to severe financial losses.

FixImplement a robust access control mechanism (e.g., OpenZeppelin's `Ownable` or `AccessControl`) for all sensitive functions. Clearly define roles and permissions, and ensure that only authorized addresses can perform privileged actions. This must be a core component of the main contract.

StatusUnresolved

Medium

Unverified Application of ReentrancyGuard

M-01The `ReentrancyGuard` library is included, which is a positive step towards preventing reentrancy attacks. However, without the full contract code, it cannot be verified if the `nonReentrant` modifier is correctly applied to all functions that perform external calls and modify state, especially those involving token transfers or liquidity operations. Incorrect or missing application could leave the contract vulnerable to reentrancy.

IssueThe `ReentrancyGuard` library is included, which is a positive step towards preventing reentrancy attacks. However, without the full contract code, it cannot be verified if the `nonReentrant` modifier is correctly applied to all functions that perform external calls and modify state, especially those involving token transfers or liquidity operations. Incorrect or missing application could leave the contract vulnerable to reentrancy.

FixEnsure that the `nonReentrant` modifier is applied to all functions that make external calls to untrusted contracts and modify the contract's state. Review all external calls to identify potential reentrancy vectors and confirm the modifier's presence.

StatusUnresolved

Info

Use of `unchecked` Blocks in Math Libraries

I-01The `FullMath` and `TickMath` libraries utilize `unchecked` blocks for arithmetic operations. While this is a common optimization in low-level math libraries to save gas by bypassing Solidity's default overflow/underflow checks, it places the full responsibility on the developer to ensure that overflows or underflows cannot occur in critical contexts, or that they are handled explicitly through other means.

IssueThe `FullMath` and `TickMath` libraries utilize `unchecked` blocks for arithmetic operations. While this is a common optimization in low-level math libraries to save gas by bypassing Solidity's default overflow/underflow checks, it places the full responsibility on the developer to ensure that overflows or underflows cannot occur in critical contexts, or that they are handled explicitly through other means.

FixWhile acceptable for highly optimized math, ensure that all inputs to `unchecked` operations are thoroughly validated or constrained to prevent overflows/underflows from leading to incorrect calculations. Comprehensive testing of these math functions is crucial to cover all possible scenarios.

StatusUnresolved

Info

Custom `SafeTransfer` Implementation

I-02The contract uses a custom `SafeTransfer` library for ERC20 token interactions. This library correctly handles the return values of `transfer` and `transferFrom` calls, which is a good security practice to prevent issues with non-standard ERC20 tokens that might not revert on failure but instead return `false`.

IssueThe contract uses a custom `SafeTransfer` library for ERC20 token interactions. This library correctly handles the return values of `transfer` and `transferFrom` calls, which is a good security practice to prevent issues with non-standard ERC20 tokens that might not revert on failure but instead return `false`.

FixWhile the custom implementation appears robust, consider using battle-tested libraries like OpenZeppelin's `SafeERC20` for consistency and to leverage community-audited code, potentially reducing the surface area for custom implementation bugs and improving maintainability.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

7.1 Architecture: The contract utilizes several custom math libraries (`FullMath`, `TickMath`, `LaunchMath`) for Uniswap V3 calculations, which are highly optimized but introduce significant complexity and potential for subtle errors. 7.2 Code Security: The `SafeTransfer` library correctly handles ERC20 return values, which is a positive. However, the extensive use of `unchecked` blocks in custom math requires extreme care. 7.3 Access Control: No access control mechanisms could be verified due to truncated code, which is a critical omission for a launchpad. 7.6 External: Interactions with Uniswap V3 interfaces are defined, but the full scope of external calls cannot be assessed. The `ReentrancyGuard` is present, but its application to all relevant functions cannot be confirmed.

GovernanceHigh1/10

7.4 Economic: Without the full contract code, the economic model, fee structures, and token distribution mechanisms of the launchpad cannot be assessed for fairness, sustainability, or potential manipulation vectors. 7.5 Governance: The presence or absence of governance mechanisms, including multi-signature controls or decentralized decision-making, cannot be determined. This poses a high risk as critical operational decisions could be centralized and unverified.

UpgradesMedium4/10

7.7 Upgrades: The provided contract is not identified as a proxy, and no upgradeability pattern is evident. Therefore, there are no inherent upgrade safety risks associated with this specific deployment. Changes would require a new deployment.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

52.4% in top 10

17.7% in wallets34.6% in contracts

Effective Concentration31.6%

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

$29.5K across 12 pairs

Uniswap v3USDCanalysed$28.2K Uniswap v4USDC$745 Uniswap v4USDC$279 Uniswap v4USDC$181 Uniswap v4USDC$17 Uniswap v4ETH$11

Show 4 more pairsShow less

Uniswap v4USDC$9 Uniswap v4USDC$6 Uniswap v4USDC$3 Uniswap v4USDC$2

The 2 remaining pairs hold $2 between them and are not listed.

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 Holder98.9%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xe5cf…ab04

Unlocked LP Held By

0xef7a…ae3b0x7973…108a

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

What Raised This Score

10 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (52.4% total → 31.6% effective; 17.7% in EOAs, 34.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($29,456 across 12 pairs — thin market)
LP top1 unlocked holder = 98.9% (independent LP — depth risk, pool = 96% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
Token age < 30 days (still settling)
1 Critical finding(s) from audit
2 High finding(s) from audit
1 Medium 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

Is basedpad.fun Safe?

Security Findings

Incomplete Code Provided for Audit

High Complexity and Potential for Errors in Custom Math Libraries

Unverified Access Control Mechanisms

Unverified Application of ReentrancyGuard

Use of `unchecked` Blocks in Math Libraries

Custom `SafeTransfer` Implementation

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of basedpad.fun?