Is Sperax (SPA) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Info

High

Unverified Access Control for Critical Functions

H-01The provided code snippets for `Pausable` and `MintPausable` define `internal virtual` functions (`_pause`, `_unpause`, `_mintPause`, `_mintUnpause`, `_mint`, `_burn`). The actual public/external functions that call these, and their associated access control mechanisms (e.g., `onlyOwner`, role-based), are not present in the provided code. Without the full contract, it's impossible to verify if these critical administrative functions are adequately protected. The prefill `ownership_renounced: true` further raises concerns, as it implies that if an `Ownable` pattern was used, these functions might now be uncallable, leading to a denial of service for administrative actions, or, if not properl…

IssueThe provided code snippets for `Pausable` and `MintPausable` define `internal virtual` functions (`_pause`, `_unpause`, `_mintPause`, `_mintUnpause`, `_mint`, `_burn`). The actual public/external functions that call these, and their associated access control mechanisms (e.g., `onlyOwner`, role-based), are not present in the provided code. Without the full contract, it's impossible to verify if these critical administrative functions are adequately protected. The prefill `ownership_renounced: true` further raises concerns, as it implies that if an `Ownable` pattern was used, these functions might now be uncallable, leading to a denial of service for administrative actions, or, if not properl…

FixProvide the complete source code for the contract, including all derived contracts and their access control implementations. Ensure that all administrative functions are protected by appropriate access control (e.g., `onlyOwner`, a multi-signature wallet, or a robust governance mechanism). If ownership has been renounced, confirm that a secure and functional alternative access control or governance system is in place for these critical operations.

StatusUnresolved

High

Incomplete Code Prevents Comprehensive Audit

H-02The provided source code is truncated, specifically for the `MintPausable` contract. This prevents a complete and thorough security assessment of the entire contract's logic, interactions, and potential vulnerabilities. Any findings are based solely on the partial code available, and a full security posture cannot be definitively determined.

IssueThe provided source code is truncated, specifically for the `MintPausable` contract. This prevents a complete and thorough security assessment of the entire contract's logic, interactions, and potential vulnerabilities. Any findings are based solely on the partial code available, and a full security posture cannot be definitively determined.

FixProvide the complete and untruncated source code for all contracts involved in the system to enable a comprehensive security audit. This includes all inherited contracts and any external dependencies.

StatusUnresolved

Medium

Centralization Risk from Administrative Controls

M-01The contract incorporates `Pausable` and `MintPausable` functionalities, along with `_mint` and `_burn` capabilities. These features inherently introduce centralization points, as a privileged entity (or set of entities) can halt token transfers, prevent minting, or adjust the total supply. The security and integrity of the token ecosystem depend heavily on the trustworthiness and security of the controlling address(es).

IssueThe contract incorporates `Pausable` and `MintPausable` functionalities, along with `_mint` and `_burn` capabilities. These features inherently introduce centralization points, as a privileged entity (or set of entities) can halt token transfers, prevent minting, or adjust the total supply. The security and integrity of the token ecosystem depend heavily on the trustworthiness and security of the controlling address(es).

FixClearly document the administrative roles and their associated privileges. Consider implementing a multi-signature wallet or a decentralized governance mechanism to control these critical functions, thereby distributing control and reducing single points of failure. Ensure that the controlling address(es) are highly secured.

StatusUnresolved

Info

Use of Older Solidity Version

I-01The contract uses Solidity versions `0.6.x`. While `SafeMath` is correctly implemented to prevent integer overflows/underflows, Solidity versions 0.8.0 and higher include built-in overflow and underflow checks by default. This means that explicit `SafeMath` library usage is no longer strictly necessary for basic arithmetic operations in newer versions.

IssueThe contract uses Solidity versions `0.6.x`. While `SafeMath` is correctly implemented to prevent integer overflows/underflows, Solidity versions 0.8.0 and higher include built-in overflow and underflow checks by default. This means that explicit `SafeMath` library usage is no longer strictly necessary for basic arithmetic operations in newer versions.

FixConsider migrating to Solidity 0.8.0 or a newer version. This would allow for the removal of the `SafeMath` library, simplifying the codebase and leveraging the compiler's native overflow/underflow protection. Thorough testing would be required after such a migration.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements a standard ERC20 token with `SafeMath` for arithmetic safety (7.2 Code Security). It includes `Pausable` and `MintPausable` features, which are common patterns for administrative control. However, the provided code is truncated, specifically for the `MintPausable` contract, which prevents a full review of its logic and potential vulnerabilities (7.1 Architecture). Crucially, the access control mechanisms for critical administrative functions like pausing, unpausing, minting, and burning are not fully visible, raising significant concerns about who can invoke these powerful operations (7.3 Access Control).

GovernanceMedium4/10

The contract includes `Pausable` and `MintPausable` functionalities, along with `_mint` and `_burn` capabilities, which introduce centralization points (7.4 Economic). A privileged entity or set of entities will have the power to halt transfers, prevent minting, or adjust the total supply. The security of the token's economic model relies heavily on the trustworthiness and security of the controlling address(es). The prefill indicates `ownership_renounced: true`, which, depending on the full implementation, could lead to uncallable administrative functions or reliance on a different, unverified governance model (7.5 Governance).

UpgradesMedium6/10

Based on the provided information and the prefill `is_proxy: false`, the contract does not appear to be upgradeable (7.7 Upgrades). This eliminates risks associated with proxy patterns, such as upgradeability bugs or improper upgrade paths. The contract's logic is immutable once deployed.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

82.8% in top 10

37.2% in wallets45.6% in contracts

Effective Concentration55.5%

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

$115.7K across 15 pairs

UniswapUSDsanalysed$56.0K Camelot v3USDs$30.5K UniswapUSDC$14.2K UniswapWETH$10.0K CamelotUSDs$4.4K UniswapUSDs$264

Show 4 more pairsShow less

UniswapUSDs$190 UniswapWETH$131 CamelotWETH$39 CamelotUSDC$35

The 5 remaining pairs hold $40 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 Holder49.9%

Top-3 Unlocked93.6%

Key Addresses

11 addresses

Deployer

0xc28c…e0a6

Unlocked LP Held By

0x162d…b9e90xb9d9…c2360x052f…7cb60x0547…fc680xef5e…3cb00xaaca…f41e0x6fff…2d740xe617…6ccd0x32de…f4010x425d…e91b

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

What Raised This Score

6 factors

Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (82.8% total → 55.5% effective; 37.2% in EOAs, 45.6% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 93.6% (independent LP — depth risk, pool = 48% of DEX liquidity)
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

Not Signed In

Is Sperax Safe?

Security Findings

Unverified Access Control for Critical Functions

Incomplete Code Prevents Comprehensive Audit

Centralization Risk from Administrative Controls

Use of Older Solidity Version

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 Sperax?