Is Lisk (LSK) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Initial Token Distribution

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

IssueThe `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.

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

StatusUnresolved

Medium

Owner's Extensive Control over Burner Role

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

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

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

StatusUnresolved

Low

Unused AccessControl `grantRole`/`revokeRole` for `DEFAULT_ADMIN_ROLE`

L-01The `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.

IssueThe `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.

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

StatusUnresolved

Info

Lack of Emergency Pause Mechanism

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh3/10

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

UpgradesLow7/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

93.7% in top 10

9.0% in wallets84.7% in contracts

Effective Concentration42.9%

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

$272.9K

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0xbfc0…fb58

Unlocked LP Held By

0xb892…485f

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

What Raised This Score

8 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

Is Lisk Safe?

Security Findings

Centralized Initial Token Distribution

Owner's Extensive Control over Burner Role

Unused AccessControl `grantRole`/`revokeRole` for `DEFAULT_ADMIN_ROLE`

Lack of Emergency Pause Mechanism

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Lisk?