Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is SK Hynix Safe?

SKHYBBNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The SecuritiesToken contract, an upgradeable ERC-20 implementation, demonstrates a robust architecture leveraging OpenZeppelin's upgradeable patterns and custom compliance/pause functionalities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 74.5%
  • LP top3 unlocked holders = 88.9%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
3.2%94.4%Wallets2.4%
3.2%94.4%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
97.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking3.2%
  • Walletsanonymous holders, free to sell94.4%
  • Everyone elsethe rest of the supply2.4%
Effective concentrationwhat the score reads95.7%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.06M across 15 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.04MShare of depth98.6%
Top-1 Unlocked Holder74.5%
Top-3 Unlocked88.9%
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.

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Potential Loss of Admin Role During Initialization

The 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).C-01

Issue

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

Fix

Add 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");`

Status

Unresolved

High

Centralized Control and Single Point of Failure

The 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).H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Powerful _uiMultiplier Mechanism

The _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).M-01

Issue

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

Fix

Ensure 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.

Status

Unresolved

Low

Lack of Event for Role Revocation

While _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).L-01

Issue

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

Fix

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

Status

Unresolved

Info

Reliance on External Compliance and Pause Manager Contracts

The 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).I-01

Issue

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

Fix

Ensure 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The SecuritiesToken contract, an upgradeable ERC-20 implementation, demonstrates a robust architecture leveraging OpenZeppelin's upgradeable patterns and custom compliance/pause functionalities. While the contract exhibits good code quality and adherence to upgradeability best practices, a critical vulnerability exists in the initialization logic that could lead to a permanent loss of administrative control. Additionally, the highly centralized control by the DEFAULT_ADMIN_ROLE presents a significant single point of failure and economic risk. Recommendations focus on hardening initialization, enhancing access control, and improving transparency.

Technical4/10Medium risk

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

Governance1/10High risk

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

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

Prioritize addressing the critical initialization vulnerability by adding a require check for admin_ != address(0).

Implement robust multi-signature or time-locked mechanisms for the DEFAULT_ADMIN_ROLE to mitigate the risks associated with centralized control over critical functions and the _uiMultiplier. Enhance transparency by emitting events for all significant state changes, including role revocations, to facilitate off-chain monitoring and auditing.

Contract & Record

1 audit on record
TypeBeaconProxy
NetworkBNB Chain
Token age1mo
Contract0xca75…db61
Deployer0x64fd…8d53
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
SK Hynix security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 14, 2026100Critical

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the SKHYB contract address?

The SK Hynix (SKHYB) contract on BNB Chain is 0xca750ef65f295bbecd685abf54e82caf297bdb61. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is SK Hynix a scam?

Quantum Audit's risk score for SK Hynix is 100/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is SKHYB liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.06M.

Who holds SKHYB?

As of Sep 4, 2026, the 10 largest holders own 97.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
WebKey DAO 2.0WKEYDAO2 · BNB Chain100CriticalPieverse TokenPIEVERSE · BNB Chain100CriticalSnapCoinBNB Chain100CriticalGameStopGMEB · BNB Chain100CriticalAppleAAPLB · BNB Chain100CriticalSandisk CorporationSNDKB · BNB Chain100Critical

Would You Like a More Detailed Audit of SK Hynix?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page