Quantum Audit Logo

Is ChainLink Token Safe?

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

ChainLink Token LINK
0x88fb…e196
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of the LinkToken contract, an ERC677-compliant token with burn and mint capabilities, reveals a well-structured and robust implementation. The contract leverages OpenZeppelin libraries and incorporates secure access control mechanisms, including a two-step ownership transfer process and role-based permissions for minting and burning. A maximum supply limit is enforced, and the owner is identified as a Timelock, significantly mitigating centralization risks. Minor informational and low-severity findings were identified, primarily related to inherent design choices and potential gas considerations for administrative functions.

2 Low1 Informational
Volume 24h
$141.0K
Liquidity
$345.2K
Price
$11.8900
Token Age
1y
Top 10 Holders
20.8%

Security Findings

2 Low1 Info
Low

Potential Gas Costs for Role Enumeration

L-01The `getMinters()` and `getBurners()` functions iterate over an `EnumerableSet` to return an array of all addresses holding the respective roles. If the number of minters or burners grows excessively large, calling these functions could become expensive in terms of gas, potentially leading to transaction failures if the gas limit is exceeded. While `EnumerableSet` is efficient for add/remove/contains, enumerating all values can be costly.
IssueThe `getMinters()` and `getBurners()` functions iterate over an `EnumerableSet` to return an array of all addresses holding the respective roles. If the number of minters or burners grows excessively large, calling these functions could become expensive in terms of gas, potentially leading to transaction failures if the gas limit is exceeded. While `EnumerableSet` is efficient for add/remove/contains, enumerating all values can be costly.
FixMonitor the number of minters and burners. If the number is expected to grow significantly, consider alternative approaches for retrieving roles, such as paginated access or only allowing retrieval of individual role status (`isMinter`, `isBurner`). For typical administrative use cases with a limited number of roles, the current implementation is acceptable.
StatusUnresolved
Low

ERC677 `transferAndCall` Reentrancy Consideration

L-02The `transferAndCall` function, part of the ERC677 standard, performs an external call to the recipient's `onTokenTransfer` function after transferring tokens. While the `ERC677` implementation from OpenZeppelin is designed to prevent reentrancy vulnerabilities within the token contract itself (by completing the `super.transfer` before the external call), it's crucial for any contract receiving tokens via `transferAndCall` to be aware of potential reentrancy vectors if they perform state-changing operations based on the incoming token transfer. A malicious recipient could attempt to re-enter the calling contract if not properly secured.
IssueThe `transferAndCall` function, part of the ERC677 standard, performs an external call to the recipient's `onTokenTransfer` function after transferring tokens. While the `ERC677` implementation from OpenZeppelin is designed to prevent reentrancy vulnerabilities within the token contract itself (by completing the `super.transfer` before the external call), it's crucial for any contract receiving tokens via `transferAndCall` to be aware of potential reentrancy vectors if they perform state-changing operations based on the incoming token transfer. A malicious recipient could attempt to re-enter the calling contract if not properly secured.
FixThe `LinkToken` contract itself is not vulnerable to reentrancy through its `transferAndCall` implementation. However, it is a general best practice for any contract interacting with external contracts, especially after an external call, to follow the Checks-Effects-Interactions pattern. Recipients of `transferAndCall` should implement reentrancy guards if their `onTokenTransfer` function performs critical state changes or external calls.
StatusUnresolved
Info

Centralized Control of Token Supply

I-01The contract owner has the exclusive ability to grant and revoke minter and burner roles. This means the owner effectively controls the token supply (within the `maxSupply` limit) and the ability to remove tokens from circulation. While this is a common design for certain types of tokens, it introduces a centralization risk where the owner's compromise or malicious intent could impact the token's integrity. This is an inherent design choice.
IssueThe contract owner has the exclusive ability to grant and revoke minter and burner roles. This means the owner effectively controls the token supply (within the `maxSupply` limit) and the ability to remove tokens from circulation. While this is a common design for certain types of tokens, it introduces a centralization risk where the owner's compromise or malicious intent could impact the token's integrity. This is an inherent design choice.
FixAcknowledge this centralization as a design decision. The current mitigation, where the owner is a Timelock, significantly reduces the immediate risk. Ensure the Timelock is robustly configured and managed. For future iterations, consider exploring multi-signature wallets or decentralized autonomous organization (DAO) governance for ownership if greater decentralization is desired.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is sound, utilizing battle-tested OpenZeppelin libraries for ERC20, ERC677, and burnable token functionalities. Code security (7.2) is high, with Solidity 0.8+ preventing integer overflows/underflows by default, and a `validAddress` modifier preventing tokens from being locked in the contract. Access control (7.3) is robust, employing `onlyOwner`, `onlyMinter`, and `onlyBurner` modifiers, alongside a secure two-step ownership transfer mechanism. The `transferAndCall` function, while an external call, is implemented in a standard, generally safe manner for token transfers.

GovernanceMedium5/10

The economic model (7.4) includes a configurable `maxSupply` (1e27 tokens), preventing unbounded inflation. The owner has significant control over minting and burning roles, which is a centralization point. However, the governance structure (7.5) indicates the owner is a Timelock with a 3-hour delay, significantly mitigating risks associated with a single point of control. This setup enhances security by introducing a delay for critical administrative actions, allowing for potential intervention or community oversight.

UpgradesMedium5/10

The LinkToken contract is not designed as an upgradeable proxy (7.7). It is a standard, non-upgradeable implementation. Therefore, upgrade safety concerns are not applicable to this specific contract. Any future changes would require a new deployment and migration.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

20.8% in top 10
11.3% in wallets9.5% in contracts
Effective Concentration15.1%

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

$539.2K across 15 pairs
AerodromeWETHanalysed$345.2K64.0%Uniswap v3USDC$125.8K23.3%Quickswap v4WETH$36.8K6.8%Uniswap v3WETH$17.7K3.3%Uniswap v4ETH$4.9K0.9%AerodromeAERO$3.4K0.6%
Show 4 more pairsShow less
Uniswap v4USDC$2.6K0.5%Uniswap v3WETH$1.4K0.3%TrebleWETH$6360.1%0x829c…4aEEWETH$4450.1%

The 5 remaining pairs hold $313 between them and are not listed.

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 Holder85.2%
Top-3 Unlocked90.0%

Key Addresses

11 addresses
Deployer
0x9830…bbca
Unlocked LP Held By
0x7d27…fd550x4486…d46d0x893e…fbe20x0cae…46ab0x2e33…47cf0xce7e…1ad20x8b45…114b0x1ec3…4f110xe16f…0f920xcc7c…4851

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

What Raised This Score

6 factors
  • Ownership NOT renounced — Timelock, short 3h delay
  • Mintable supply, nominal cap 518558%/year — effectively unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 85.2% (independent LP — depth risk, pool = 64% of DEX liquidity)
  • LP top3 unlocked holders = 90.0% (independent LP — depth risk, pool = 64% of DEX liquidity)
  • 2 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
OpenGradient (OPG)Medium RiskZoraMedium RisknoiceMedium Riskthe sleeping giant (TSG)Medium RiskAave Token (AAVE)Medium RiskPlayMedium Risk

Would You Like a More Detailed Audit of ChainLink Token?

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

Get Detailed Audit