Is Solstice (SLX) Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2361Jul 2378

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The BurnMintERC20 contract provides a standard ERC20 token with controlled minting and burning capabilities, leveraging OpenZeppelin's battle-tested libraries. The contract exhibits good code quality and includes checks against common vulnerabilities like reentrancy and integer overflows. However, the design incorporates significant centralization through the `DEFAULT_ADMIN_ROLE`, which controls token supply and administrative functions, posing a high operational risk if not managed securely. The contract is not upgradeable, ensuring immutability of its logic.

Final Recommendation: It is recommended to secure the `DEFAULT_ADMIN_ROLE` with a robust multi-signature wallet to mitigate the single point of failure risk and enhance operational security. Implement a two-step transfer process for critical administrative roles, if possible, to prevent accidental loss of control. Ensure comprehensive documentation of the `s_ccipAdmin` role's external dependencies and its impact on the broader protocol to avoid misunderstandings and potential misuse.

Category Ratings

TechnicalMedium

6/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)`, demons

GovernanceHigh

1/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 to

UpgradesHigh

3/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

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

9 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (72.7% total → 38.7% effective; 16.0% in EOAs, 56.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($13,303 across 2 pairs — thin market)
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

Security Findings

5 total

2 Medium 1 Low 2 Info

M-01MediumUnresolved

Centralized Control of Token Supply

The `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).

Recommendation: If 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.

M-02MediumUnresolved

Single Point of Failure for DEFAULT_ADMIN_ROLE

The `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).

Recommendation: It 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.

L-01LowUnresolved

Lack of Two-Step Transfer for DEFAULT_ADMIN_ROLE

While `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).

Recommendation: Consider 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.

I-01InformationalUnresolved

Unclear External Implications of s_ccipAdmin Role

The `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).

Recommendation: Provide 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.

I-02InformationalUnresolved

Hardcoded Decimals

The `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).

Recommendation: No 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.

Is Solstice Safe? SLX