Is Sport.fun (FUN) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Low

High

Centralized Control of Token Supply

H-01The `initialize` function mints the entire `MAX_SUPPLY` (1,000,000,000 * 1e18 tokens) to the `owner` address. This grants the initial `owner` complete control over the token's distribution and market dynamics, posing a significant centralization risk. A single entity holds all tokens, which could lead to market manipulation or a lack of trust from the community (7.4 Economic).

IssueThe `initialize` function mints the entire `MAX_SUPPLY` (1,000,000,000 * 1e18 tokens) to the `owner` address. This grants the initial `owner` complete control over the token's distribution and market dynamics, posing a significant centralization risk. A single entity holds all tokens, which could lead to market manipulation or a lack of trust from the community (7.4 Economic).

FixImplement a more decentralized token distribution strategy. Consider vesting schedules, community airdrops, or a gradual release mechanism instead of minting the entire supply to a single address. If the current design is intentional, clearly communicate this centralization to users.

StatusUnresolved

High

Single Point of Failure for Administrative and Upgrade Roles

H-02During initialization, the `owner` address is granted both `DEFAULT_ADMIN_ROLE` and `GOVERNOR_ROLE`. The `DEFAULT_ADMIN_ROLE` can manage all other roles, including `GOVERNOR_ROLE`, which is responsible for authorizing contract upgrades. This setup creates a single point of failure: if the `owner`'s private key is compromised, an attacker would gain full administrative control over the contract, including the ability to upgrade it to malicious code and manage all roles (7.3 Access Control, 7.5 Governance, 7.7 Upgrades).

IssueDuring initialization, the `owner` address is granted both `DEFAULT_ADMIN_ROLE` and `GOVERNOR_ROLE`. The `DEFAULT_ADMIN_ROLE` can manage all other roles, including `GOVERNOR_ROLE`, which is responsible for authorizing contract upgrades. This setup creates a single point of failure: if the `owner`'s private key is compromised, an attacker would gain full administrative control over the contract, including the ability to upgrade it to malicious code and manage all roles (7.3 Access Control, 7.5 Governance, 7.7 Upgrades).

FixTransfer `DEFAULT_ADMIN_ROLE` and `GOVERNOR_ROLE` to a multi-signature wallet or a DAO governance system. This decentralizes control and requires multiple approvals for critical operations, significantly reducing the risk associated with a single compromised key.

StatusUnresolved

Medium

Lack of Explicit Token Burn Mechanism

M-01The contract does not provide an explicit function for burning tokens. While `_mint` is used once during initialization, there is no corresponding `_burn` function or a mechanism to reduce the total supply after initial minting. This might be an intentional design choice, but it limits flexibility for supply management, such as implementing deflationary mechanisms or burning tokens from a treasury (7.4 Economic).

IssueThe contract does not provide an explicit function for burning tokens. While `_mint` is used once during initialization, there is no corresponding `_burn` function or a mechanism to reduce the total supply after initial minting. This might be an intentional design choice, but it limits flexibility for supply management, such as implementing deflationary mechanisms or burning tokens from a treasury (7.4 Economic).

FixIf a burn mechanism is desired for future tokenomics or supply management, consider adding a `burn` function, potentially restricted by a role (e.g., `GOVERNOR_ROLE`), that calls `_burn` from the ERC20Upgradeable base contract. If not desired, document this design choice.

StatusUnresolved

Low

Absence of Pause Mechanism

L-01The contract does not include a pause mechanism (e.g., `PausableUpgradeable`) to halt token transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market disruption. While not always strictly necessary, a pause function can be a valuable tool for mitigating risks in a centralized token system (7.8 Operations).

IssueThe contract does not include a pause mechanism (e.g., `PausableUpgradeable`) to halt token transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market disruption. While not always strictly necessary, a pause function can be a valuable tool for mitigating risks in a centralized token system (7.8 Operations).

FixConsider integrating OpenZeppelin's `PausableUpgradeable` module. This would allow a designated role (e.g., `GOVERNOR_ROLE` or a new `PAUSER_ROLE`) to temporarily pause and unpause contract functionality, providing an emergency stop-gap measure.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract is built upon well-audited OpenZeppelin Upgradeable libraries for ERC20, AccessControl, and UUPS, contributing to high code security and architectural soundness (7.1 Architecture, 7.2 Code Security). The `initialize` function correctly sets up the token and roles, and `_disableInitializers` prevents re-initialization. A key technical concern is the single point of failure for critical administrative functions and upgrades, as the `owner` address initially controls all roles (7.3 Access Control).

GovernanceHigh1/10

The contract utilizes OpenZeppelin's AccessControlUpgradeable for robust role-based access management, defining `DEFAULT_ADMIN_ROLE` and `GOVERNOR_ROLE`. However, a significant economic risk exists as the entire `MAX_SUPPLY` of tokens is minted to a single `owner` address during initialization (7.4 Economic). Furthermore, this `owner` address initially holds both `DEFAULT_ADMIN_ROLE` and `GOVERNOR_ROLE`, creating a single point of failure for all administrative and governance actions (7.5 Governance).

UpgradesHigh1/10

The contract correctly implements the UUPS upgradeability pattern using OpenZeppelin's `UUPSUpgradeable` module, ensuring a secure and standard upgrade path. The `_authorizeUpgrade` function is appropriately restricted to the `GOVERNOR_ROLE`. However, the initial assignment of the `GOVERNOR_ROLE` to a single `owner` address presents a centralization risk for future upgrades (7.7 Upgrades), as compromise of this address would allow unauthorized contract modifications.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

75.9% in top 10

75.9% in wallets0.0% in contracts

Effective Concentration75.9%

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

$369.2K across 6 pairs

AerodromeUSDCanalysed$339.9K Uniswap v4USDC$21.6K Uniswap v3USDC$7.4K Uniswap v3USDC$242 AerodromeAERO$25 AerodromeUSDC$2

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.8%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x1c58…30ae

Unlocked LP Held By

0x8815…288b0xe24d…c94a

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

What Raised This Score

9 factors

Ownership status UNKNOWN (owner could not be resolved)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 70% (75.9% total → 75.9% effective; 75.9% in EOAs, 0.0% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 98.8% (independent LP — depth risk, pool = 92% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
2 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

Is Sport.fun Safe?

Security Findings

Centralized Control of Token Supply

Single Point of Failure for Administrative and Upgrade Roles

Lack of Explicit Token Burn Mechanism

Absence of Pause Mechanism

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

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