Is Solstice (SLX) Safe? Smart Contract Security Analysis

Security Findings

2 Med1 Low2 Info

Medium

Centralized Control of Token Supply

M-01The `DEFAULT_ADMIN_ROLE` has the authority to grant and revoke `MINTER_ROLE` and `BURNER_ROLE`. This means a single entity (or a small group if a multi-sig is used for the admin address) has complete control over the token's total supply through minting and burning capabilities. While this may be an intended design for a managed token, it represents a significant centralization risk (7.3 Access Control, 7.4 Economic).

IssueThe `DEFAULT_ADMIN_ROLE` has the authority to grant and revoke `MINTER_ROLE` and `BURNER_ROLE`. This means a single entity (or a small group if a multi-sig is used for the admin address) has complete control over the token's total supply through minting and burning capabilities. While this may be an intended design for a managed token, it represents a significant centralization risk (7.3 Access Control, 7.4 Economic).

FixIf a centralized token supply is intended, ensure that the `DEFAULT_ADMIN_ROLE` is managed by a highly secure, multi-signature wallet with robust operational procedures. Clearly communicate this centralization to users and stakeholders.

StatusUnresolved

Medium

Single Point of Failure for DEFAULT_ADMIN_ROLE

M-02The `DEFAULT_ADMIN_ROLE`, initially assigned to `msg.sender` during deployment, holds extensive administrative power, including managing minter/burner roles and the `s_ccipAdmin` address. If this single administrative address is compromised, lost, or becomes inaccessible, the entire token's administrative functions could be jeopardized or rendered inoperable (7.3 Access Control, 7.8 Operations).

IssueThe `DEFAULT_ADMIN_ROLE`, initially assigned to `msg.sender` during deployment, holds extensive administrative power, including managing minter/burner roles and the `s_ccipAdmin` address. If this single administrative address is compromised, lost, or becomes inaccessible, the entire token's administrative functions could be jeopardized or rendered inoperable (7.3 Access Control, 7.8 Operations).

FixIt is strongly recommended to assign the `DEFAULT_ADMIN_ROLE` to a robust multi-signature wallet (e.g., Gnosis Safe) rather than a single Externally Owned Account (EOA). Implement strict key management and operational security protocols for this multi-sig wallet.

StatusUnresolved

Low

Lack of Two-Step Transfer for DEFAULT_ADMIN_ROLE

L-01While `AccessControl` allows for granting and revoking roles, there isn't an explicit two-step transfer mechanism for the `DEFAULT_ADMIN_ROLE` itself. Directly granting the `DEFAULT_ADMIN_ROLE` to a new address and then revoking it from the old one in separate transactions carries a risk of accidental loss of administrative control if an incorrect address is provided or if the transaction fails midway (7.3 Access Control, 7.8 Operations).

IssueWhile `AccessControl` allows for granting and revoking roles, there isn't an explicit two-step transfer mechanism for the `DEFAULT_ADMIN_ROLE` itself. Directly granting the `DEFAULT_ADMIN_ROLE` to a new address and then revoking it from the old one in separate transactions carries a risk of accidental loss of administrative control if an incorrect address is provided or if the transaction fails midway (7.3 Access Control, 7.8 Operations).

FixConsider implementing a custom two-step transfer mechanism for the `DEFAULT_ADMIN_ROLE` (e.g., `proposeAdmin` and `acceptAdmin`) to prevent accidental loss of control. This adds an extra layer of security by requiring explicit acceptance from the new administrator.

StatusUnresolved

Info

Unclear External Implications of s_ccipAdmin Role

I-01The `s_ccipAdmin` role is managed by the `DEFAULT_ADMIN_ROLE` and is intended for 'registering with the CCIP token admin registry.' However, the specific powers and implications of this role within the external CCIP protocol are not defined within this contract. This lack of clarity could lead to misunderstandings about its importance or potential misuse if the external system grants significant power to this address (7.1 Architecture, 7.6 External).

IssueThe `s_ccipAdmin` role is managed by the `DEFAULT_ADMIN_ROLE` and is intended for 'registering with the CCIP token admin registry.' However, the specific powers and implications of this role within the external CCIP protocol are not defined within this contract. This lack of clarity could lead to misunderstandings about its importance or potential misuse if the external system grants significant power to this address (7.1 Architecture, 7.6 External).

FixProvide comprehensive documentation detailing the purpose, responsibilities, and external dependencies of the `s_ccipAdmin` role within the broader protocol. This will help users and auditors understand its full security context and potential impact.

StatusUnresolved

Info

Hardcoded Decimals

I-02The `i_decimals` variable is set as an immutable value during contract deployment and cannot be changed thereafter. While this is a common practice for ERC20 tokens, it means the token's decimal precision is permanently fixed and cannot be adjusted to adapt to future protocol requirements or ecosystem standards (7.1 Architecture).

IssueThe `i_decimals` variable is set as an immutable value during contract deployment and cannot be changed thereafter. While this is a common practice for ERC20 tokens, it means the token's decimal precision is permanently fixed and cannot be adjusted to adapt to future protocol requirements or ecosystem standards (7.1 Architecture).

FixNo direct action is required as this is a design choice. However, ensure that the chosen decimal precision (e.g., 18 for most ERC20s) aligns with all current and anticipated future use cases for the token.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract `BurnMintERC20` is built upon battle-tested OpenZeppelin libraries (ERC20, ERC20Burnable, AccessControl v4.8.3), enhancing its security foundation. It correctly implements custom error handling and overrides `_transfer` and `_approve` to prevent interactions with `address(this)`, demonstrating good security practices (7.2 Code Security). The `mint` function includes a `i_maxSupply` check, preventing supply inflation beyond the defined limit (7.4 Economic). No reentrancy or integer overflow vulnerabilities were identified.

GovernanceHigh1/10

The token design exhibits a high degree of centralization, with the `DEFAULT_ADMIN_ROLE` possessing the authority to grant `MINTER_ROLE` and `BURNER_ROLE`, thereby controlling the total token supply (7.3 Access Control, 7.4 Economic). This central control, while potentially intended for a managed token, introduces a significant single point of failure. The `s_ccipAdmin` role's external implications are not fully defined within the contract, requiring careful consideration of its broader protocol impact (7.6 External).

UpgradesHigh3/10

The `BurnMintERC20` contract is not designed as an upgradeable proxy, meaning its logic cannot be modified post-deployment (7.7 Upgrades). This eliminates upgrade-related risks such as proxy storage collisions or incorrect upgrade paths. Any changes to the token's functionality would require a new deployment and migration of assets.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

70.8% in top 10

19.5% in wallets51.3% in contracts

Effective Concentration40.0%

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

$8.9K across 5 pairs

UniswapUSDTanalysed$8.6K UniswapEV$131 Pancakeswap v3USDT$96 UniswapEV$63 Pancakeswap v2Subject 3$3

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

2 addresses

Deployer

0x062f…1316

Unlocked LP Held By

0x4a88…3eb5

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 NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (70.8% total → 40.0% effective; 19.5% in EOAs, 51.3% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $10k ($8,927 across 5 pairs — easily drained)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
2 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

Not Signed In

Is Solstice Safe?

Security Findings

Centralized Control of Token Supply

Single Point of Failure for DEFAULT_ADMIN_ROLE

Lack of Two-Step Transfer for DEFAULT_ADMIN_ROLE

Unclear External Implications of s_ccipAdmin Role

Hardcoded Decimals

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