Is ChainLink Token (LINK) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Low1 Info

Critical

Centralized Control of Token Supply by l2Gateway

C-01The `l2Gateway` address has exclusive control over the `bridgeMint` and `bridgeBurn` functions, allowing it to mint or burn any amount of tokens. This centralized power is fundamental to the Arbitrum bridge's operation but represents a single point of failure. A compromise of the `l2Gateway` address would enable an attacker to arbitrarily inflate or deflate the token supply, leading to a complete loss of trust and value for the token.

IssueThe `l2Gateway` address has exclusive control over the `bridgeMint` and `bridgeBurn` functions, allowing it to mint or burn any amount of tokens. This centralized power is fundamental to the Arbitrum bridge's operation but represents a single point of failure. A compromise of the `l2Gateway` address would enable an attacker to arbitrarily inflate or deflate the token supply, leading to a complete loss of trust and value for the token.

FixImplement the highest level of security for the `l2Gateway` address. This should include robust multi-signature control, hardware security modules (HSMs), strict access policies, and continuous monitoring. Ensure that the operational procedures for managing this address are thoroughly audited and regularly reviewed.

StatusUnresolved

Medium

ERC20 Getters Revert on Parsing Failure

M-01The `name()`, `symbol()`, and `decimals()` functions in `StandardArbERC20` are designed to revert if the initial parsing of `_data` during `bridgeInit` failed for the respective field. This behavior deviates from the standard ERC20 interface, where these functions are typically expected to always return a value (e.g., an empty string or zero for decimals) rather than reverting. This could cause issues for dApps, aggregators, or wallets that do not gracefully handle reverts for these common ERC20 getter functions, potentially leading to integration failures or unexpected user experiences.

IssueThe `name()`, `symbol()`, and `decimals()` functions in `StandardArbERC20` are designed to revert if the initial parsing of `_data` during `bridgeInit` failed for the respective field. This behavior deviates from the standard ERC20 interface, where these functions are typically expected to always return a value (e.g., an empty string or zero for decimals) rather than reverting. This could cause issues for dApps, aggregators, or wallets that do not gracefully handle reverts for these common ERC20 getter functions, potentially leading to integration failures or unexpected user experiences.

FixConsider modifying the `name()`, `symbol()`, and `decimals()` functions to return default or empty values (e.g., an empty string for name/symbol, or 0 for decimals) if `availableGetters.ignoreX` is true, instead of reverting. This would align the contract more closely with standard ERC20 expectations and improve compatibility with various ecosystem tools.

StatusUnresolved

Low

Use of Older Solidity Compiler Version

L-01The contract is compiled with Solidity `^0.6.11`. While OpenZeppelin contracts mitigate many common issues, newer Solidity versions (e.g., 0.8.x) include built-in overflow and underflow checks by default, reducing the reliance on external libraries like SafeMath (though OpenZeppelin's upgradeable contracts often handle this). Migrating to a newer compiler version can also provide other language improvements and security enhancements.

IssueThe contract is compiled with Solidity `^0.6.11`. While OpenZeppelin contracts mitigate many common issues, newer Solidity versions (e.g., 0.8.x) include built-in overflow and underflow checks by default, reducing the reliance on external libraries like SafeMath (though OpenZeppelin's upgradeable contracts often handle this). Migrating to a newer compiler version can also provide other language improvements and security enhancements.

FixConsider upgrading the Solidity compiler version to 0.8.x or higher. Thoroughly test the contract after the upgrade to ensure no breaking changes or unexpected behaviors are introduced, especially concerning external library interactions and assembly blocks.

StatusUnresolved

Info

`bridgeInit` Front-running for New Clones

I-01For newly deployed `ClonableBeaconProxy` instances, the `bridgeInit` function is public and sets the `l2Gateway` address. While the `ALREADY_INIT` guard prevents re-initialization on an already initialized clone, a malicious actor could potentially front-run the legitimate bridge's initialization transaction for a *newly deployed clone*. If successful, the attacker could set themselves as the `l2Gateway`, gaining control over `bridgeMint` and `bridgeBurn` for that specific token clone.

IssueFor newly deployed `ClonableBeaconProxy` instances, the `bridgeInit` function is public and sets the `l2Gateway` address. While the `ALREADY_INIT` guard prevents re-initialization on an already initialized clone, a malicious actor could potentially front-run the legitimate bridge's initialization transaction for a *newly deployed clone*. If successful, the attacker could set themselves as the `l2Gateway`, gaining control over `bridgeMint` and `bridgeBurn` for that specific token clone.

FixEnsure that the deployment and initialization process for new token clones is atomic and secured against front-running. This typically involves deploying and immediately initializing the proxy within the same transaction or a tightly controlled sequence of transactions, ideally from a trusted and permissioned deployer address.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates sound architectural principles, leveraging OpenZeppelin's upgradeable patterns and custom libraries for byte parsing (7.1 Architecture, 7.2 Code Security). The `onlyGateway` modifier effectively restricts critical `bridgeMint` and `bridgeBurn` functions to the designated `l2Gateway` (7.3 Access Control). However, the `name()`, `symbol()`, and `decimals()` functions can revert if initial parsing fails, which deviates from standard ERC20 expectations and could impact integrations (7.2 Code Security). The use of Solidity `^0.6.11` means the contract does not benefit from newer compiler features like built-in overflow checks (7.2 Code Security).

GovernanceMedium4/10

The `l2Gateway` address holds critical power, being the sole entity capable of minting and burning tokens via `bridgeMint` and `bridgeBurn` (7.4 Economic, 7.5 Governance). This centralized control is inherent to the bridged token design but represents a significant single point of failure; compromise of this address would lead to catastrophic loss of token integrity. The design choice to revert ERC20 getter functions (`name`, `symbol`, `decimals`) upon parsing failure could lead to unexpected behavior for users and dApps, potentially impacting token usability and trust (7.4 Economic).

UpgradesHigh1/10

The contract is designed as an implementation for a `ClonableBeaconProxy`, utilizing the `Cloneable` pattern and the `_initialize` function to prevent re-initialization (7.7 Upgrades). The `isMasterCopy` flag correctly distinguishes between the implementation and cloned proxies, preventing accidental self-destruction of the master copy. No immediate upgrade safety issues or storage slot collisions were identified within the scope of this implementation (7.7 Upgrades).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

44.0% in top 10

8.0% in wallets36.0% in contracts

Effective Concentration22.4%

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

$1.99M across 24 pairs

UniswapWETHanalysed$1.07M UniswapWETH$325.3K Camelot v3WETH$203.5K UniswapUSD₮0$191.0K UniswapWBTC$78.7K UniswapUSDC$42.8K

Show 4 more pairsShow less

SushiswapWETH$35.1K PancakeswapWETH$26.3K UniswapPENDLE$7.2K SwaprWETH$7.0K

The 14 remaining pairs hold $7.4K 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 Holder9.2%

Top-3 Unlocked21.1%

Key Addresses

11 addresses

Deployer

0x3fe3…000f

Unlocked LP Held By

0xf444…1b480xdef5…9c620x60e7…c8410x93ea…84640x0ef2…320a0x56e8…5aac0x538a…ca850xaf0d…63f40x54bc…88170xe1c7…82d2

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 status UNKNOWN (owner could not be resolved)
Proxy contract (upgradeable — admin can replace logic)
Complex proxy pattern (BEACON)
Top-10 concentration > 20% (44.0% total → 22.4% effective; 8.0% in EOAs, 36.0% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
1 Critical 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 ChainLink Token Safe?

Security Findings

Centralized Control of Token Supply by l2Gateway

ERC20 Getters Revert on Parsing Failure

Use of Older Solidity Compiler Version

`bridgeInit` Front-running for New Clones

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of ChainLink Token?