Is SK Hynix (SKHYB) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med1 Low1 Info

Critical

Potential Loss of Admin Role During Initialization

C-01The `initialize` function, which sets up the contract's initial state and grants the `DEFAULT_ADMIN_ROLE`, does not validate the `admin_` address parameter. If `address(0)` is passed as `admin_` during the initial deployment and initialization, the `DEFAULT_ADMIN_ROLE` will be granted to the zero address. This would result in a permanent loss of administrative control over the contract, making it unmanageable and potentially un-upgradeable (7.3 Access Control, 7.7 Upgrades, 7.8 Operations).

IssueThe `initialize` function, which sets up the contract's initial state and grants the `DEFAULT_ADMIN_ROLE`, does not validate the `admin_` address parameter. If `address(0)` is passed as `admin_` during the initial deployment and initialization, the `DEFAULT_ADMIN_ROLE` will be granted to the zero address. This would result in a permanent loss of administrative control over the contract, making it unmanageable and potentially un-upgradeable (7.3 Access Control, 7.7 Upgrades, 7.8 Operations).

FixAdd a `require` statement at the beginning of the `initialize` function to ensure that `admin_` is not `address(0)`. For example: `require(admin_ != address(0), "SecuritiesToken: Admin cannot be zero address");`

StatusUnresolved

High

Centralized Control and Single Point of Failure

H-01The `DEFAULT_ADMIN_ROLE` possesses extensive control over critical contract functionalities. This includes the ability to enable/disable minting and burning, change token metadata (name, symbol, identifier), and update the addresses of external `ComplianceClient` and `PauseManagerClient` contracts. This high degree of centralization creates a single point of failure, where a compromise of the admin key could lead to severe consequences, including unauthorized token issuance, manipulation of token properties, or redirection of control to malicious external contracts (7.3 Access Control, 7.4 Economic, 7.8 Operations).

IssueThe `DEFAULT_ADMIN_ROLE` possesses extensive control over critical contract functionalities. This includes the ability to enable/disable minting and burning, change token metadata (name, symbol, identifier), and update the addresses of external `ComplianceClient` and `PauseManagerClient` contracts. This high degree of centralization creates a single point of failure, where a compromise of the admin key could lead to severe consequences, including unauthorized token issuance, manipulation of token properties, or redirection of control to malicious external contracts (7.3 Access Control, 7.4 Economic, 7.8 Operations).

FixConsider implementing a multi-signature wallet for the `DEFAULT_ADMIN_ROLE` to require multiple approvals for critical operations. For highly sensitive actions, a time-lock mechanism could be introduced to allow for community review or emergency intervention before changes take effect.

StatusUnresolved

Medium

Powerful `_uiMultiplier` Mechanism

M-01The `_uiMultiplier` mechanism, controlled by `DEFAULT_ADMIN_ROLE` or `ISSUER_ROLE` via `_authorizeMultiplierUpdate`, allows for changing the effective value of tokens. While the `_validateMultiplier` function enforces bounds (1e9 to 1e27) and `_setUIMultiplier` limits the future effective timestamp to 365 days, this power can still significantly impact token holders. Misuse or compromise of the controlling role could lead to unexpected economic consequences for token value (7.4 Economic, 7.5 Governance).

IssueThe `_uiMultiplier` mechanism, controlled by `DEFAULT_ADMIN_ROLE` or `ISSUER_ROLE` via `_authorizeMultiplierUpdate`, allows for changing the effective value of tokens. While the `_validateMultiplier` function enforces bounds (1e9 to 1e27) and `_setUIMultiplier` limits the future effective timestamp to 365 days, this power can still significantly impact token holders. Misuse or compromise of the controlling role could lead to unexpected economic consequences for token value (7.4 Economic, 7.5 Governance).

FixEnsure that the process for updating the `_uiMultiplier` is subject to strict governance procedures, potentially involving a multi-signature wallet or a time-lock. Clearly communicate the implications of multiplier changes to token holders and provide transparent access to historical and pending multiplier updates.

StatusUnresolved

Low

Lack of Event for Role Revocation

L-01While `_grantRole` emits a `RoleGranted` event, there is no explicit event emitted when a role is revoked using `_revokeRole` or `_renounceRole` (inherited from `AccessControlEnumerableUpgradeable`). This can make it challenging for off-chain systems and auditors to track and verify changes in access control permissions, reducing transparency and auditability (7.2 Code Security, 7.8 Operations).

IssueWhile `_grantRole` emits a `RoleGranted` event, there is no explicit event emitted when a role is revoked using `_revokeRole` or `_renounceRole` (inherited from `AccessControlEnumerableUpgradeable`). This can make it challenging for off-chain systems and auditors to track and verify changes in access control permissions, reducing transparency and auditability (7.2 Code Security, 7.8 Operations).

FixConsider overriding the `_revokeRole` and `_renounceRole` functions to emit a custom event, such as `RoleRevoked(bytes32 role, address account, address sender)`, to provide a complete audit trail of access control changes.

StatusUnresolved

Info

Reliance on External Compliance and Pause Manager Contracts

I-01The `SecuritiesToken` contract integrates with external `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts. These external contracts are critical for enforcing compliance rules and managing the token's paused state. The security and integrity of the `SecuritiesToken` are directly dependent on the correct functioning and security of these external dependencies (7.6 External, 7.1 Architecture).

IssueThe `SecuritiesToken` contract integrates with external `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts. These external contracts are critical for enforcing compliance rules and managing the token's paused state. The security and integrity of the `SecuritiesToken` are directly dependent on the correct functioning and security of these external dependencies (7.6 External, 7.1 Architecture).

FixEnsure that the external `ComplianceClient` and `PauseManagerClient` contracts are thoroughly audited, well-maintained, and deployed with robust security practices. Implement monitoring for these external contracts to detect any unexpected behavior or compromises.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates strong technical foundations, leveraging OpenZeppelin's upgradeable patterns and robust error handling with custom revert messages (e.g., `EmptyString()`, `ZeroAddress()`). The `_update` function correctly integrates compliance and pause checks (7.2 Code Security). However, a critical vulnerability exists in the `initialize` function, where passing `address(0)` for `admin_` can lead to a permanent loss of the `DEFAULT_ADMIN_ROLE` (7.3 Access Control, 7.8 Operations). Additionally, the `DEFAULT_ADMIN_ROLE` holds extensive control over critical token parameters and external contract addresses, posing a significant centralization risk (7.3 Access Control).

GovernanceHigh1/10

The contract's economic model is based on a controlled 'securities token' with explicit roles for `DEFAULT_ADMIN_ROLE` and `ISSUER_ROLE`, which is appropriate for its stated purpose. The `_uiMultiplier` mechanism includes validation checks for bounds and future effective timestamps, enhancing control (7.4 Economic). However, the high degree of centralized control by the `DEFAULT_ADMIN_ROLE` over minting/burning enablement and the powerful `_uiMultiplier` mechanism introduces significant economic risk if the admin key is compromised or misused (7.4 Economic, 7.5 Governance).

UpgradesHigh1/10

The contract is designed for upgradeability using OpenZeppelin's `initializer` pattern and `__gap` storage, deployed behind a BeaconProxy, which is a standard and secure upgrade mechanism (7.7 Upgrades, 7.1 Architecture). The `_disableInitializers()` in the constructor prevents re-initialization. Despite these strengths, the `initialize` function's failure to validate the `admin_` address can lead to a critical deployment error where the `DEFAULT_ADMIN_ROLE` is lost, making future upgrades or management impossible (7.7 Upgrades, 7.8 Operations).

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon

ImplementationVerified source

Holder Composition

97.6% in top 10

94.4% in wallets3.2% in contracts

Effective Concentration95.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.06M across 15 pairs

Pancakeswap v3USDTanalysed$1.04M Pancakeswap v3WBNB$14.3K Pancakeswap v2SPCXB$21 Pancakeswap v2WBNB$4 Pancakeswap v2BTCBR$0

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 Holder74.5%

Top-3 Unlocked88.9%

Key Addresses

11 addresses

Deployer

0x64fd…8d53

Unlocked LP Held By

0x556b…d59e0xd0bb…235e0x4450…185e0x4673…fff10x18fb…51b00xb41e…84a70x9b1a…827f0x30f7…d2bc0x1d8e…33ad0x94ec…b3a4

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

What Raised This Score

12 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Complex proxy pattern (BEACON)
Top-10 concentration > 70% (97.6% total → 95.7% effective; 94.4% in EOAs, 3.2% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 74.5% (independent LP — depth risk, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 88.9% (independent LP — depth risk, pool = 99% of DEX liquidity)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 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

Is SK Hynix Safe?

Security Findings

Potential Loss of Admin Role During Initialization

Centralized Control and Single Point of Failure

Powerful `_uiMultiplier` Mechanism

Lack of Event for Role Revocation

Reliance on External Compliance and Pause Manager Contracts

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of SK Hynix?