Is Chainlink (LINK) Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2342

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The ChainLink Token contract implements ERC-20 and ERC-677 standards, utilizing SafeMath for arithmetic safety. However, the audit identified a critical issue where the public `totalSupply()` function incorrectly returns zero due to variable shadowing, significantly impacting ERC-20 compliance and integrations. Inconsistent `Transfer` event signatures between standard transfers and `transferAndCall` also pose integration challenges. Additionally, the `approve` function is susceptible to a known race condition, and the `validRecipient` modifier's implementation is incomplete in the provided source. The contract uses an outdated Solidity compiler version.

Final Recommendation: It is strongly recommended to address the critical `totalSupply` shadowing issue immediately to ensure ERC-20 compliance and proper integration with external systems. The inconsistent `Transfer` event signatures should also be harmonized to prevent indexing and application errors. Implement a robust `validRecipient` modifier, ensuring it prevents transfers to the zero address. Consider migrating to a newer Solidity compiler version to benefit from security improvements and optimizations. While `increaseApproval` and `decreaseApproval` mitigate the `approve` race condition, developers should be aware of the base `approve` function's vulnerability.

Category Ratings

TechnicalLow

7/10

The contract architecture (7.1) is a standard ERC-20 and ERC-677 token implementation, leveraging the SafeMath library for robust integer overflow/underflow protection in arithmetic operations. This is a significant strength for code security (7.2). However, a critical flaw exists where the public `

GovernanceHigh

2/10

The economic model (7.4) of the LinkToken is straightforward, featuring a fixed total supply minted to the deployer. There are no complex fee structures, staking, or governance mechanisms (7.5) within this contract. However, the critical technical issue regarding the `totalSupply()` function returni

UpgradesMedium

5/10

The contract is not designed with any upgradeability patterns (7.7) such as UUPS or Transparent proxies. Therefore, there are no specific upgrade-related risks. Any changes to the token's logic would require a new deployment and migration of assets, which is a standard approach for non-upgradea

LP Distribution

Top-1 Unlocked Holder59.5%

Top-3 Unlocked73.2%

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 59.5% (independent LP — depth risk, pool = 47% of DEX liquidity)
1 Critical finding(s) from audit
1 High finding(s) from audit
2 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 Findings

6 total

1 Critical 1 High 2 Medium 1 Low 1 Info

C-01CriticalUnresolved

Incorrect ERC-20 `totalSupply` Implementation

The `LinkToken` contract declares `uint public constant totalSupply = 10**27;`, which shadows the `uint256 public totalSupply;` state variable inherited from `ERC20Basic`. While the constructor correctly uses the constant `totalSupply` to assign initial balances, the public getter function `totalSupply()` (which refers to the state variable) will always return 0. This violates the ERC-20 standard and will cause any external application or exchange relying on this function to misinterpret the token's total supply.

Recommendation: Remove the `constant` keyword from `LinkToken`'s `totalSupply` declaration and ensure the inherited `totalSupply` state variable is correctly initialized in the constructor, or explicitly set to the desired value. For example, `ERC20Basic.totalSupply = 10**27;` (if `ERC20Basic.totalSupply` was not `public` but `internal` or `protected` and accessible, or if `LinkToken` directly managed it). A common pattern is to set `_totalSupply = initialSupply;` in the constructor of the base token contract.

H-01HighUnresolved

Inconsistent ERC-677 `Transfer` Event Signatures

The `ERC677Token` contract defines a `Transfer` event with an additional `bytes data` parameter, which conflicts with the standard `ERC20Basic` `Transfer` event signature. Consequently, `transferAndCall` emits the `ERC677` specific `Transfer` event, while standard `transfer` and `transferFrom` functions (inherited from `BasicToken` and `StandardToken`) emit the `ERC20Basic` `Transfer` event. This inconsistency can lead to issues for block explorers, indexers, and applications that expect a single, consistent `Transfer` event signature for all token movements.

Recommendation: To maintain full ERC-20 compatibility while supporting ERC-677, consider emitting both the ERC-20 `Transfer` event and the ERC-677 `Transfer` event (with `data`) for `transferAndCall` operations, or ensure that the `ERC677` event is emitted for all transfers, potentially with empty `data` for standard transfers, if the consuming applications can handle it. The most robust solution for full compatibility is often to emit the ERC-20 event for all transfers, and a separate, distinct event for `tra…

M-01MediumUnresolved

ERC-20 `approve` Race Condition Vulnerability

The `approve` function is susceptible to a known front-running attack. If a user attempts to change an allowance from amount X to amount Y, a malicious spender could front-run the transaction, spend X tokens, and then allow the original `approve` transaction to proceed, resulting in the spender having an allowance of Y tokens in addition to the X tokens already spent. While `increaseApproval` and `decreaseApproval` functions are provided to mitigate this, the base `approve` function remains callable and vulnerable.

Recommendation: Educate users to primarily use `increaseApproval` and `decreaseApproval` instead of `approve` when modifying existing allowances. For new allowances, `approve` is generally safe. Consider deprecating or adding a warning to the `approve` function if `allowed[msg.sender][_spender]` is not zero, forcing users to use the safer `increaseApproval`/`decreaseApproval` pattern.

M-02MediumUnresolved

Truncated `validRecipient` Modifier Implementation

The provided source code for the `validRecipient` modifier is truncated. This prevents a full security assessment of its intended checks. Without the complete implementation, it's impossible to verify if critical checks, such as preventing transfers to `address(0)` (the zero address), are correctly enforced. A missing `address(0)` check could lead to tokens being permanently locked if sent to the zero address.

Recommendation: Provide the complete and correct implementation of the `validRecipient` modifier. Ensure it includes checks to prevent transfers to `address(0)` and any other necessary recipient validations to prevent loss of funds or unexpected behavior.

L-01LowUnresolved

Outdated Solidity Compiler Version

The contract uses `pragma solidity ^0.4.16;`. This is an outdated compiler version. Newer Solidity versions include numerous bug fixes, security enhancements, and gas optimizations. Using older versions may expose the contract to known compiler-related vulnerabilities or result in less efficient bytecode.

Recommendation: Consider upgrading the contract to a more recent and stable Solidity compiler version (e.g., `^0.8.x`). This would require thorough re-auditing and testing to ensure compatibility and prevent new issues introduced by syntax changes or new compiler behaviors.

I-01InformationalUnresolved

Potential DoS via `onTokenTransfer` Revert

The `transferAndCall` function calls the `onTokenTransfer` function on the recipient contract. If a malicious recipient contract implements `onTokenTransfer` to always revert, it could prevent successful `transferAndCall` operations to that specific contract. While this is standard behavior for external calls and not a vulnerability in the token contract itself, it's a consideration for users interacting with potentially untrusted recipient contracts.

Recommendation: Users should be aware that `transferAndCall` operations to untrusted or poorly implemented contracts might fail if the recipient's `onTokenTransfer` function reverts. This is an inherent risk when interacting with external contracts. No direct change is needed in the token contract, but documentation could highlight this behavior.

Is Chainlink Safe? LINK