Quantum Audit Logo
Launch App

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

Is ChainLink Token Safe?

LINKBase
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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades5/10Checks passed2 of 5Findings2 Low · 1 Info3
SummaryAI Copilot

The audit of the LinkToken contract, an ERC677-compliant token with burn and mint capabilities, reveals a well-structured and robust implementation.

Read the full analysis
What raised the score
  • 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%
  • LP top3 unlocked holders = 90.0%
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
9.5%Contracts11.3%Wallets79.2%Everyone else
9.5%11.3%79.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
20.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking9.5%
  • Walletsanonymous holders, free to sell11.3%
  • Everyone elsethe rest of the supply79.2%
Effective concentrationwhat the score reads15.1%
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$539.2K across 15 pairs
Show 4 more pairs

The 5 remaining pairs hold $313 between them and are not listed. 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$345.2KShare of depth64.0%
Top-1 Unlocked Holder85.2%
Top-3 Unlocked90.0%
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.

Security Findings

2 Low1 Info
Low

Potential Gas Costs for Role Enumeration

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

Issue

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

Fix

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

Status

Unresolved

Low

ERC677 transferAndCall Reentrancy Consideration

The 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.L-02

Issue

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

Fix

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

Status

Unresolved

Info

Centralized Control of Token Supply

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance5/10Medium risk

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.

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to maintain the Timelock ownership for critical administrative roles to preserve the current level of security and decentralization.

Ensure the Timelock's parameters (e.g., minimum delay) are appropriate for the project's risk tolerance and governance model. Additionally, consider monitoring the number of granted minter/burner roles to manage potential gas costs for enumeration functions, although this is a minor concern for typical administrative usage.

Contract & Record

1 audit on record
TypeLinkToken
NetworkBase
Token age1y
Contract0x88fb…e196
Deployer0x9830…bbca
Badge for your website
ChainLink Token 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. Sep 4, 202637Medium
  2. Aug 15, 202639Medium

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

Related Audits

6 more on the recordAll audits
OpenGradientOPG · Base37MediumZoraBase37MediumnoiceBase37Mediumthe sleeping giantTSG · Base37MediumMUSWORLDMUSEWORLD · Base37MediumAave TokenAAVE · Base38Medium

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 Is this your token? Publish your own audit on this page