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.

On-chain security analysis — is it a scam or legit?
Is Lisk Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking84.7%
- Walletsanonymous holders, free to sell9.0%
- Everyone elsethe rest of the supply6.3%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xb892…485fNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized 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
MediumOwner'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
LowUnused 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
grantRole/revokeRole for DEFAULT_ADMIN_ROLEIssue
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
InfoLack 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 4The 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).
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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