Quantum Audit Logo
Launch App

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

Is Lisk Safe?

LSKEthereum
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
SummaryAI Copilot

The L1LiskToken contract is an ERC20 token implementation utilizing battle-tested OpenZeppelin libraries for its core functionalities, including burnable tokens, permit functionality, two-step ownership transfer, and role-based access control.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (93.7% total → 42.9% effective; 9.0% in EOAs, 84.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
84.7%Contracts9.0%Wallets6.3%
84.7%Contracts9.0%6.3%
ContractsWalletsEveryone elseBubble area = share of supply
93.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking84.7%
  • Walletsanonymous holders, free to sell9.0%
  • Everyone elsethe rest of the supply6.3%
Effective concentrationwhat the score reads42.9%
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$272.9K

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$272.9KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xb892…485f

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Initial Token Distribution

The L1LiskToken contract's constructor mints the entire TOTAL_SUPPLY (400,000,000 LSK) directly to msg.sender (the deployer). This design centralizes the entire token supply under a single address, creating a significant single point of control and trust for all subsequent token distribution and market dynamics. A compromise of this address could have catastrophic consequences for the token's ecosystem.H-01

Issue

The L1LiskToken contract's constructor mints the entire TOTAL_SUPPLY (400,000,000 LSK) directly to msg.sender (the deployer). This design centralizes the entire token supply under a single address, creating a significant single point of control and trust for all subsequent token distribution and market dynamics. A compromise of this address could have catastrophic consequences for the token's ecosystem.

Fix

Implement a more decentralized or transparent initial distribution mechanism. If the deployer's address is intended to be a treasury or distribution wallet, it should ideally be a robust multi-signature wallet with a high threshold. Clearly communicate the distribution plan to the community to manage expectations and trust.

Status

Unresolved

Medium

Owner's Extensive Control over Burner Role

The contract owner has sole authority to grant and revoke the BURNER_ROLE via the addBurner and renounceBurner functions. While Ownable2Step provides a secure mechanism for ownership transfer, a compromised owner key could allow an attacker to grant themselves the BURNER_ROLE and burn tokens, or to revoke legitimate burners, leading to denial of service for burning operations.M-01

Issue

The contract owner has sole authority to grant and revoke the BURNER_ROLE via the addBurner and renounceBurner functions. While Ownable2Step provides a secure mechanism for ownership transfer, a compromised owner key could allow an attacker to grant themselves the BURNER_ROLE and burn tokens, or to revoke legitimate burners, leading to denial of service for burning operations.

Fix

Consider implementing a more decentralized approach for managing critical roles, such as requiring a multi-signature wallet for the owner or introducing a governance mechanism for role management. Alternatively, if the current design is intentional, ensure the owner's private key is secured with the highest possible standards.

Status

Unresolved

Low

Unused AccessControl grantRole/revokeRole for DEFAULT_ADMIN_ROLE

The L1LiskToken contract inherits from OpenZeppelin's AccessControl but does not explicitly grant the DEFAULT_ADMIN_ROLE to any address in its constructor. Consequently, the generic grantRole and revokeRole functions provided by AccessControl are effectively unusable for roles whose admin is DEFAULT_ADMIN_ROLE (which includes BURNER_ROLE by default), as no address possesses the necessary DEFAULT_ADMIN_ROLE to call them. The contract instead uses onlyOwner functions (addBurner, renounceBurner) to manage the BURNER_ROLE directly.L-01

Issue

The L1LiskToken contract inherits from OpenZeppelin's AccessControl but does not explicitly grant the DEFAULT_ADMIN_ROLE to any address in its constructor. Consequently, the generic grantRole and revokeRole functions provided by AccessControl are effectively unusable for roles whose admin is DEFAULT_ADMIN_ROLE (which includes BURNER_ROLE by default), as no address possesses the necessary DEFAULT_ADMIN_ROLE to call them. The contract instead uses onlyOwner functions (addBurner, renounceBurner) to manage the BURNER_ROLE directly.

Fix

This is not a vulnerability but a design inconsistency. If the intent is for the owner to be the sole manager of the BURNER_ROLE, the current implementation is functional. However, to align with AccessControl's intended usage, consider explicitly granting DEFAULT_ADMIN_ROLE to the contract owner in the constructor if generic role management is desired for future roles. Otherwise, consider removing the AccessControl inheritance if its generic functions are not utilized.

Status

Unresolved

Info

Lack of Emergency Pause Mechanism

The contract lacks a mechanism to pause token transfers or burning in emergency situations. In the event of a critical vulnerability discovery, a major exploit in an integrated system, or unforeseen market manipulation, the inability to temporarily halt operations could lead to significant loss of funds or disruption.I-01

Issue

The contract lacks a mechanism to pause token transfers or burning in emergency situations. In the event of a critical vulnerability discovery, a major exploit in an integrated system, or unforeseen market manipulation, the inability to temporarily halt operations could lead to significant loss of funds or disruption.

Fix

Consider integrating an emergency pause mechanism (e.g., using OpenZeppelin's Pausable contract) that can be triggered by a trusted entity (e.g., a multi-signature wallet or governance) to temporarily halt critical operations. This provides a crucial safety switch for unforeseen circumstances.

Status

Unresolved

Analysis

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

The L1LiskToken contract is an ERC20 token implementation utilizing battle-tested OpenZeppelin libraries for its core functionalities, including burnable tokens, permit functionality, two-step ownership transfer, and role-based access control. The contract's technical implementation is robust, leveraging standard patterns. However, significant centralization risks exist regarding the initial token distribution and the extensive control held by the contract owner over critical functions like burner role management. The contract is not upgradeable, which simplifies its architecture but removes flexibility for future enhancements or bug fixes.

Technical8/10Low risk

The technical implementation of the L1LiskToken contract is sound, primarily due to its reliance on well-audited OpenZeppelin contracts (ERC20, ERC20Burnable, ERC20Permit, Ownable2Step, AccessControl). This significantly reduces the likelihood of common vulnerabilities like reentrancy or integer overflows (7.2 Code Security). The contract correctly implements a two-step ownership transfer mechanism (7.3 Access Control) and uses role-based access control for burner functionality, where the owner manages the 'BURNER_ROLE' (7.1 Architecture). A minor inconsistency is the unused generic grantRole/revokeRole functions from AccessControl for the DEFAULT_ADMIN_ROLE (7.1 Architecture).

Governance3/10High risk

The primary economic and governance risk stems from the highly centralized initial token distribution, where the entire 400 million LSK supply is minted to the deployer (7.4 Economic). This places significant trust in the deployer for all subsequent distribution and creates a single point of failure. Furthermore, the contract owner retains extensive control over the BURNER_ROLE, enabling them to add or remove addresses capable of burning tokens (7.3 Access Control, 7.5 Governance). While Ownable2Step enhances ownership transfer security, the owner's broad powers represent a substantial centralization of control (7.8 Operations).

Upgrades7/10Low risk

The L1LiskToken contract is not designed to be upgradeable, as it does not implement any proxy patterns (7.7 Upgrades). This means its logic is immutable once deployed, eliminating upgrade-related risks such as proxy misconfigurations or malicious upgrade capabilities. However, it also means that no future bug fixes or feature enhancements can be applied to the deployed contract.

Final RecommendationWhat to do about this score

It is recommended to carefully plan and communicate the initial token distribution strategy, as the entire supply is minted to a single address.

Consider implementing a multi-signature wallet for the contract owner to manage critical functions like adding/removing burners, thereby distributing control and reducing single points of failure. While the contract is not upgradeable, ensure thorough testing and auditing before deployment to mitigate the risks associated with immutable code.

Contract & Record

1 audit on record
TypeL1LiskToken
NetworkEthereum
Token age1y
Contract0x6033…ae3f
Deployer0xbfc0…fb58
Badge for your website
Lisk 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 13, 202645Medium

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

Would You Like a More Detailed Audit of Lisk?

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