Is SHX Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Info

Critical

Immutable Variable in Proxy Implementation Breaks Functionality

C-01The `interchainTokenService_` variable is declared as `internal immutable` and initialized in the constructor. In a proxy pattern, `immutable` variables are embedded in the implementation contract's bytecode and cannot be modified or controlled by the proxy's storage. This means that any call to `interchainTokenService()` through the proxy will always return the address that was set when the *implementation contract itself* was deployed, not an address that can be initialized or changed by the proxy. This fundamentally breaks the proxy's ability to manage its associated interchain service, impacting core functionality and access control (e.g., `_addMinter(interchainTokenService_)` will add…

IssueThe `interchainTokenService_` variable is declared as `internal immutable` and initialized in the constructor. In a proxy pattern, `immutable` variables are embedded in the implementation contract's bytecode and cannot be modified or controlled by the proxy's storage. This means that any call to `interchainTokenService()` through the proxy will always return the address that was set when the *implementation contract itself* was deployed, not an address that can be initialized or changed by the proxy. This fundamentally breaks the proxy's ability to manage its associated interchain service, impacting core functionality and access control (e.g., `_addMinter(interchainTokenService_)` will add…

FixRefactor `interchainTokenService_` to be a regular `internal` (or `public`) storage variable instead of `immutable`. Initialize this variable within the `init` function, which is called through the proxy, ensuring it is stored in the proxy's storage and can be correctly managed by the proxy instance.

StatusUnresolved

Medium

Incomplete Code for Role Management

M-01The provided source code for the `RolesBase` contract truncates the `_addAccountRoles` function. This prevents a complete audit of the role management logic, which is critical for access control (7.3). Without the full implementation, it's impossible to verify the correctness and security of how roles are added and managed within the system.

IssueThe provided source code for the `RolesBase` contract truncates the `_addAccountRoles` function. This prevents a complete audit of the role management logic, which is critical for access control (7.3). Without the full implementation, it's impossible to verify the correctness and security of how roles are added and managed within the system.

FixProvide the complete and untruncated source code for all inherited contracts and libraries, especially `RolesBase`, to allow for a thorough security review of the access control mechanisms.

StatusUnresolved

Info

Use of Assembly for Storage Operations

I-01The contract utilizes inline assembly (`sload`, `sstore`) for custom initialization (`_initialize`, `_isInitialized`) and role management (`_getRoles`, `_setRoles`). While assembly can be efficient, it increases code complexity and the potential for subtle errors compared to high-level Solidity storage access. It requires a higher degree of scrutiny during audits (7.2).

IssueThe contract utilizes inline assembly (`sload`, `sstore`) for custom initialization (`_initialize`, `_isInitialized`) and role management (`_getRoles`, `_setRoles`). While assembly can be efficient, it increases code complexity and the potential for subtle errors compared to high-level Solidity storage access. It requires a higher degree of scrutiny during audits (7.2).

FixEnsure that all assembly blocks are thoroughly tested and formally verified if possible. Document the exact storage slots being accessed and their purpose to maintain clarity and reduce the risk of storage collisions or incorrect state manipulation, especially in upgradeable contracts.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The InterchainToken contract implements ERC-20 functionality with minting and burning capabilities, secured by a role-based access control system (7.3). It utilizes Axelar GMP SDK components for interchain operations. A significant technical risk (7.1, 7.2) is the use of an 'immutable' variable for the 'interchainTokenService_'. This design choice is incompatible with proxy patterns, as the variable's value is fixed at the implementation's deployment and cannot be controlled by the proxy's storage, leading to incorrect service references and potential functional failures.

GovernanceHigh1/10

The contract employs a role-based access control system (7.5) where 'MINTER' roles are assigned to the 'interchainTokenService_' and an initial minter during initialization. This allows controlled minting and burning of tokens, impacting the token's supply (7.4). The governance over these roles, particularly the ability to add/remove minters beyond the initial setup, depends on the complete 'RolesBase' implementation, which was partially unavailable. The critical issue with the 'immutable' 'interchainTokenService_' directly impacts the intended governance and economic control over minting.

UpgradesHigh1/10

The contract is designed as an implementation for a proxy (7.7), utilizing a custom initialization slot (`INITIALIZED_SLOT`) to prevent re-initialization. However, the declaration of `interchainTokenService_` as `immutable` creates a severe incompatibility with the proxy pattern. Immutable variables are embedded in the implementation's bytecode, meaning the proxy cannot control or update this critical service address, effectively breaking the upgradeability and intended functionality of the proxy for this specific variable (7.1). This architectural flaw makes future upgrades or changes to the interchain service address impossible via the proxy.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

72.1% in top 10

53.1% in wallets19.0% in contracts

Effective Concentration60.7%

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

$1.31M

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.

Key Addresses

1 addresses

Deployer

0x51a3…1bd9

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (72.1% total → 60.7% effective; 53.1% in EOAs, 19.0% in contracts — heavy)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
1 Critical 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 SHX Safe?

Security Findings

Immutable Variable in Proxy Implementation Breaks Functionality

Incomplete Code for Role Management

Use of Assembly for Storage Operations

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of SHX?