Is Jito Staked SOL (JITOSOL) 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 2257Jul 2362

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

Audit Summary

The CrossChainERC20 contract implements a standard ERC20 token with specialized cross-chain functionality, allowing a designated bridge contract to mint and burn tokens. The contract leverages Solady for optimized ERC20 functionality and includes the Initializable pattern. Key findings highlight the significant centralization risk associated with the bridge contract and a design choice that limits upgradeability flexibility if used with a proxy.

Final Recommendation: Prioritize the security and operational robustness of the `_BRIDGE` contract, as it represents the primary point of control and risk for the token supply. Implement robust monitoring, multi-signature controls, and emergency response procedures for the bridge to mitigate the high centralization risk. If upgradeability is a future requirement, consider refactoring the `_BRIDGE` variable to be a storage variable managed by the `initialize` function, allowing it to be updated via proxy upgrades. If the current immutable design is intentional, ensure all stakeholders understand the implications of a permanently fixed bridge address.

Category Ratings

TechnicalLow

7/10

The contract is well-structured, inheriting from Solady's optimized ERC20 and Initializable contracts. It uses Solidity 0.8.28, benefiting from built-in overflow/underflow protection. Access control for minting and burning is correctly enforced via an `onlyBridge` modifier, ensuring only the de

GovernanceHigh

1/10

The economic model of this token is highly centralized, as a single `_BRIDGE` address holds exclusive privileges to mint and burn tokens. This design introduces a significant single point of failure; a compromise of the bridge contract would directly impact the token's supply integrity and valu

UpgradesHigh

3/10

The contract incorporates the `Initializable` pattern and correctly calls `_disableInitializers()` in its constructor, indicating an intent for use as an upgradeable implementation. However, the `_BRIDGE` address is declared as `immutable` and set in the constructor. This design choice means that if

LP Distribution

Top-1 Unlocked Holder50.5%

Top-3 Unlocked100.0%

What Raised This Score

8 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (100.0% total → 42.0% effective; 3.3% in EOAs, 96.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 50.5% (independent LP — depth risk, pool = 95% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
1 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

Security Findings

4 total

1 High 1 Medium 2 Info

H-01HighUnresolved

Centralization Risk of Bridge Contract

The `CrossChainERC20` contract grants exclusive minting and burning privileges to a single `_BRIDGE` address. This design creates a significant centralization risk, as the security and integrity of the entire token supply are dependent on the security of this single bridge contract. A compromise of the `_BRIDGE` contract could lead to unauthorized minting, burning, or manipulation of the token supply, resulting in severe economic damage to the protocol and its users. This is an inherent design choice for cross-chain tokens but represents a critical operational and economic risk (7.3 Access Control, 7.4 Economic, 7.8 Operations).

Recommendation: Implement robust security measures for the `_BRIDGE` contract, including multi-signature control, time-locks for critical operations, and comprehensive monitoring. Consider a decentralized bridge architecture or a mechanism for community governance over the bridge in the long term. Establish clear emergency procedures for potential bridge exploits.

M-01MediumUnresolved

Incompatible Design for Upgradeability (Immutable Bridge in Initializable Contract)

The contract imports `Initializable` and uses the `initializer` modifier, indicating an intent for upgradeability via a proxy pattern. However, the `_BRIDGE` address is declared as `immutable` and set in the constructor. In an upgradeable proxy setup, the constructor of the implementation contract runs only once upon its initial deployment, not when the proxy is initialized or upgraded. This means the `_BRIDGE` address is permanently fixed for this specific implementation contract and cannot be changed through proxy upgrades. This design choice restricts the flexibility of the system, as the critical bridge contract itself cannot be upgraded or replaced without deploying an entirely new pro…

Recommendation: If upgradeability of the bridge address is desired, refactor `_BRIDGE` to be a regular storage variable. It should then be set during the `initialize` function call, allowing it to be updated via proxy upgrades. If the immutable nature of the bridge is an intentional design constraint, ensure this limitation is clearly documented and understood by all stakeholders.

I-01InformationalUnresolved

Lack of Emergency Pause Mechanism

The contract lacks a mechanism to pause critical operations (e.g., minting, burning, or even transfers) in the event of an emergency, such as a detected vulnerability in the bridge contract or a major exploit. While the `onlyBridge` modifier centralizes control, a broader pause functionality can be crucial for damage control (7.8 Operations).

Recommendation: Consider implementing a pause mechanism, potentially controlled by a multi-signature wallet or a governance contract. This would allow the protocol to temporarily halt operations to mitigate damage during an incident or to perform necessary upgrades/fixes.

I-02InformationalUnresolved

`_remoteToken` Interpretation is External

The `_remoteToken` variable, a `bytes32` identifier, is intended to represent the corresponding token on a remote chain. Its meaning, uniqueness, and enforcement are entirely external to this contract and depend on the logic implemented within the `_BRIDGE` contract and the remote chain's system. The `CrossChainERC20` contract itself does not validate or interpret this identifier beyond ensuring it's not zero (7.6 External).

Recommendation: Ensure that the `_BRIDGE` contract has robust logic for managing and validating `_remoteToken` identifiers to prevent collisions or misinterpretations across chains. Clear documentation should be provided for how `_remoteToken` values are generated and used within the broader cross-chain ecosystem.

Is Jito Staked SOL Safe? JITOSOL