Quantum Audit Logo

Is Lisk Safe?

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

Lisk LSK
0xac48…1a24
Base
Not verifiedThis 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.
Last checked 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The L2LiskToken contract implements an ERC20 token with minting and burning capabilities controlled by a designated bridge address. While leveraging secure OpenZeppelin libraries, a critical vulnerability exists in the initialization process due to the use of `tx.origin` for access control, which could allow an attacker to hijack the bridge address. The token's economic security is highly dependent on the external bridge contract's integrity. Recommendations include addressing the `tx.origin` vulnerability and enhancing bridge security.

1 Critical1 High1 Low
Volume 24h
$1.40M
Liquidity
$340.0K
Price
$0.3882
Token Age
1y
Top 10 Holders
86.9%

Security Findings

1 Crit1 High1 Low
Critical

`tx.origin` Usage for `initialize` Function Access Control

C-01The `initialize` function, which sets the critical `BRIDGE` address, uses `tx.origin` for access control (`require(msg.sender == initializer, ...)`). This is a known anti-pattern and makes the contract vulnerable to phishing attacks. If the `initializer` (an Externally Owned Account, EOA) interacts with a malicious contract, that malicious contract can then call `initialize` on `L2LiskToken` in the same transaction, effectively setting an arbitrary `BRIDGE` address. This would grant the attacker full control over the token's minting and burning capabilities, leading to potential economic collapse.
IssueThe `initialize` function, which sets the critical `BRIDGE` address, uses `tx.origin` for access control (`require(msg.sender == initializer, ...)`). This is a known anti-pattern and makes the contract vulnerable to phishing attacks. If the `initializer` (an Externally Owned Account, EOA) interacts with a malicious contract, that malicious contract can then call `initialize` on `L2LiskToken` in the same transaction, effectively setting an arbitrary `BRIDGE` address. This would grant the attacker full control over the token's minting and burning capabilities, leading to potential economic collapse.
FixReplace `tx.origin` with `msg.sender` for access control in the `initialize` function. Ensure the `initializer` EOA is secure and only calls `initialize` directly. For critical administrative functions like initialization, consider using a multi-signature wallet to enhance security and decentralization.
StatusUnresolved
High

Centralized Control and Critical External Dependency on Bridge Security

H-01The `L2LiskToken` contract's supply is entirely controlled by the `BRIDGE` address, which has exclusive permissions to mint and burn tokens. While this design is standard for L2 bridged tokens, it introduces a critical external dependency. The security and integrity of the token's supply are directly tied to the security of the external `BRIDGE` contract. A compromise of the `BRIDGE` contract would allow an attacker to arbitrarily mint or burn tokens, leading to a loss of the token's peg to its L1 counterpart and potential economic collapse.
IssueThe `L2LiskToken` contract's supply is entirely controlled by the `BRIDGE` address, which has exclusive permissions to mint and burn tokens. While this design is standard for L2 bridged tokens, it introduces a critical external dependency. The security and integrity of the token's supply are directly tied to the security of the external `BRIDGE` contract. A compromise of the `BRIDGE` contract would allow an attacker to arbitrarily mint or burn tokens, leading to a loss of the token's peg to its L1 counterpart and potential economic collapse.
FixImplement robust security measures for the `BRIDGE` contract, including thorough audits, multi-signature control, time-locks for critical operations, and continuous monitoring. Ensure the bridge's design minimizes attack surface and adheres to best security practices for cross-chain communication and asset custody.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-01The `L2LiskToken` contract lacks an emergency pause mechanism. In the event of a critical vulnerability in the bridge, an external dependency, or the token contract itself, there is no way to temporarily halt minting/burning or transfers to prevent further damage or mitigate ongoing exploits. This could lead to irreversible loss of funds or economic instability.
IssueThe `L2LiskToken` contract lacks an emergency pause mechanism. In the event of a critical vulnerability in the bridge, an external dependency, or the token contract itself, there is no way to temporarily halt minting/burning or transfers to prevent further damage or mitigate ongoing exploits. This could lead to irreversible loss of funds or economic instability.
FixConsider implementing a pausable mechanism (e.g., using OpenZeppelin's `Pausable` contract) that can be triggered by a trusted role (e.g., a multi-signature wallet or a governance contract) to temporarily halt critical operations like minting and burning in emergencies. This provides a crucial failsafe for operational security (7.8 Operations).
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The `L2LiskToken` contract provides standard ERC20 functionality with `ERC20Permit` extensions, leveraging battle-tested OpenZeppelin libraries, which contributes to robust code security (7.2 Code Security). The `onlyBridge` modifier correctly restricts `mint` and `burn` operations to a designated bridge address, ensuring controlled supply management. However, a critical vulnerability exists in the `initialize` function, which uses `tx.origin` for access control, making it susceptible to phishing attacks that could allow an attacker to hijack the `BRIDGE` address (7.3 Access Control). This flaw significantly undermines the contract's access control architecture (7.1 Architecture).

GovernanceHigh1/10

The economic model of `L2LiskToken` is based on a centralized bridge mechanism, where the `BRIDGE` contract dictates the total supply through minting and burning (7.4 Economic). This design inherently links the token's economic stability to the security of the external `BRIDGE` contract, making it a critical external dependency (7.6 External). There are no explicit governance mechanisms within this contract; control is primarily administrative via the `BRIDGE` address (7.5 Governance).

UpgradesHigh2/10

The `L2LiskToken` contract is not designed to be upgradeable (7.7 Upgrades). Key addresses like `REMOTE_TOKEN` are immutable, and the `BRIDGE` address is set once during initialization. This design choice eliminates upgrade-related risks such as proxy misconfigurations or upgradeability backdoor vulnerabilities, but it means any future changes to the contract logic would require a new deployment.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

86.9% in top 10
22.9% in wallets64.0% in contracts
Effective Concentration48.5%

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

$340.2K across 3 pairs
AerodromeWETHanalysed$340.0K99.9%Uniswap v4USDC$1820.1%

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
0xb5a6…b002

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

What Raised This Score

9 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (86.9% total → 48.5% effective; 22.9% in EOAs, 64.0% 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 Critical finding(s) from audit
  • 1 High 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

Related Audits

6 more on the record
VelvetHigh RiskDiemHigh RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High RiskUmiaHigh RiskLotto Coin (LOTTO)High Risk

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