Linea Token and Airdrop Contracts

1 Executive Summary

This report presents the results of our engagement with the Linea Team to review the Linea Token and Airdrop contracts.

The review was conducted in the week of July 21–25, 2025 by Heiko Fisch and George Kobakhidze.

The audit was conducted over a system of contracts that will facilitate the Linea Token mint, claim, airdrop, and other token functionality. In particular, there were three contracts involved - the token contract on the Ethereum mainnet (L1), the token contract on the Linea rollup (L2), and the airdrop contract that will help distribute the tokens to the eligible recipients on the Linea rollup.

Although the tokens originally get minted on the L1, the primary governance activity using those tokens will happen on the L2. As a result, the L1 token has more functionality relating to its supply and mint mechanics, such as actually being minted by authorized entities as well as having the ability to “sync” its true total supply numbers over to the L2 contract. On the other hand, the L2 token contract has additional governance functionality built in via the ERC20VotesUpgradeable inherited contract. Consequently, the communication between the layers is crucial for correct intended governance functionality of the token, and therefore, other offchain systems – such as the Linea Messaging Service – play a critical role in this setup.

No major issues were identified throughout the audit that would threaten the intended logic of the contracts. Due to the nature of airdrops, additional considerations were analyzed, such as simplicity, clarity of the contracts, and potential burden of unwarranted receipt of an airdrop.

After the review of PRs containing fixes for the issues reported in this audit as well as in audits that were ran in parallel by other teams, the final reviewed commit was 91036daf2331610841796772f8fbb2fcc4a9233f.

The build artifacts provided in the repository’s folder exported-artifacts from the final commit also match the artifacts produced by our build runs with the following configurations:

• Compiler: 0.8.30
• Optimizer runs: 10_000_000
• L1 contract EVM Version: Prague
• L2 contracts EVM Version: London

Moreover, on both Ethereum and Linea, the deployed bytecode at address 0xe03f157de67ac4b2a9a949d64d2a3c64ffa1bc55 matches the deployedBytecode in the corresponding artifact file in exported-artifacts at the final revision 91036daf2331610841796772f8fbb2fcc4a9233f.

2 Scope

This review focused on the repository and code revision: Consensys/linea-tokens, code revision 44640f0965a5c7465b99769a5d241a9a1cb3a2ef.

The detailed list of files in scope can be found in the Appendix.

3 System Overview

In the following, we briefly describe the main contracts.

3.1 LineaToken

• This is the main token contract, an ERC-20 with mint and burn functionality.
• Minting by the MINTER_ROLE, which is managed by the DEFAULT_ADMIN. Both roles will be assigned to the security council, according to the Linea team.
• Will be deployed on L1 (Ethereum).
• Tokens can be bridged to L2 (Linea) and also bridged back.
• Upgradeable contract; proxy admin owner will be the same timelock contract as for other upgradeable Linea contracts, according to the Linea team.

3.2 L2LineaToken

• The corresponding token contract on L2.
• Minting directly on L2 is not possible.
• Burning directly on L2 is currently possible but should be removed. (See here.)
• Contract has a DEFAULT_ADMIN, which currently has no functionality other than managing the role itself, but will likely be utilized at a later point, after an upgrade. The DEFAULT_ADMIN role will be assigned to the security council, according to the Linea team.
• Upgradeable contract; proxy admin owner will be the same timelock contract as for other upgradeable Linea contracts, according to the Linea team.
• Inherits voting functionality from ERC20VotesUpgradeable.

3.3 MessageServiceBase

• L2LineaToken inherits from this contract.
• Taken from a different Linea codebase, with minimal changes only, to avoid code duplication.

3.4 TokenAirdrop

• Non-upgradeable airdrop contract.
• Will be deployed on L2.
• Funds for the airdrop have to be bridged to L2 and then transferred to this contract.
• Has a claim window that is set in the constructor.
• After that, the owner can withdraw all remaining funds.
• Allocation amounts are calculated based on (up to) three SBT ERC-20 contracts, whose balances have to be set accordingly.

4 Security Specification

This section describes, from a security perspective, the expected behavior of the system under review. It is not a substitute for documentation. The purpose of this section is to identify specific security properties that were validated by the review team.

4.1 Actors

The relevant actors are listed below with their respective abilities:

• Proxy Admin Owner. The token contracts on both L1 and L2 are upgradeable. The Proxy Admin Owner is the address that can perform such an upgrade. According to the Linea team, it will be set to the same timelock contract that is also the Proxy Admin Owner of other upgradeable Linea contracts.

• Default Admin. There is a Default Admin assigned to both L1 and L2 contracts of the Linea token. This admin manages all roles in the system, including the Default Admin role itself. According to the Linea team, this role will be assigned to the security council.

• Minter Role. The Minter is explicitly assigned on the L1 token contract of the Linea token, and they are able to arbitrarily mint tokens to any recipient. It is important to note that they are not able to burn tokens from anyone, only mint. According to the Linea team, this role will also be assigned to the security council.

• Linea Message Service. Though not an entity that is explicitly assigned any roles in the contracts, the Linea Message Service plays a critical role in the system, which facilitates messages between L1 and L2. Specifically, the two main mechanics are bridging between the layers and coordinating the total token supply from L1 to L2.

• Owner of the Airdrop Contract. The Owner can withdraw all unclaimed tokens when the airdrop window has closed. They can also transfer the Owner role to someone else.

• Deployers. The deployers of the contracts control the initial (and sometimes unchangeable) values for many system parameters.

• Users. Regular users of the system can do well-known token operations such as transfers, approvals, and burning of their own tokens. They can also bridge tokens between L1 and L2, and they can vote on L2.

4.2 Trust Model

In any system, it’s important to identify what trust is expected/required between various actors. For this review, we established the following trust model:

• Proxy Admin Owner. The ability to upgrade the token contract gives the Proxy Admin Owner complete control over the code as well as the data stored in the contract. If the Proxy Admin Owner is itself a contract (such as a timelock), the restrictions of this contract can limit the power (e.g., upgrade is only executed after a certain time has passed).

• Default Admin. As addresses with the Default Admin role can manage all roles, they can grant and revoke the Default Admin and the Minter role to/from other addresses (including themself). They are trusted to manage these roles responsibly.

• Minter Role. Though the Minter can not modify any logic explicitly, they are able to create Linea tokens. Therefore, they can financially impact the Linea token by inflating the supply and selling the tokens on the open market if the Minter address is compromised. Similarly, an inflated token supply can be used to sway any ongoing governance votes on the L2, thereby granting some governance power to the Minter indirectly. As such, the Minter is trusted not to abuse such supply mechanics.

• Linea Message Service. The entity responsible for controlling the Linea Message Service is not able to modify or influence the messages being sent. However, they are able to stop any messages from coming if they choose not to execute them, effectively censoring them. In our case, such messages would be bridging the tokens between the layers and communicating the supply numbers – both critical events for effective governance of the Linea token system. Therefore, the Message Service is trusted not to censor any message.

• Owner of the Airdrop Contract. Technically, no special trust is required in the Owner, but there is the assumption that the Owner or someone else will fund the airdrop contract sufficiently for all allocations to be claimable.

• Deployers. No trust is required for the deployers, as the deployment parameters can be verified on-chain.

• Users. Users are only in control of their own balances.

4.3 Additional Notes

• Dependencies. The Linea Token contracts make extensive use of open source libraries, specifically OpenZeppelin contracts and their upgradeable counterparts. In order to effectively secure the system and assess its risks, it is critical that versions of such dependencies are locked and recorded. Due to its specific setup, this wasn’t explicitly mentioned in the repository of the system. However, by the end of the audit, the OpenZeppelin contracts’ version has been fixed at 5.4.0.

5 Findings

Each issue has an assigned severity:

• Critical issues are directly exploitable security vulnerabilities that need to be fixed.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Issues without a severity are general recommendations or optional improvements. They are not related to security or correctness and may be addressed at the discretion of the maintainer.

/**
 * @notice Mints the Linea token.
 * @dev NB: Only the L2 token bridge can call this function.
 * @param _account Account being minted for.
 * @param _amount The amount being minted for the account.
 */
function mint(address _account, uint256 _amount) external {
  require(_msgSender() == lineaCanonicalTokenBridge, CallerIsNotTokenBridge());

  _mint(_account, _amount);
}

/**
 * @notice Burns the Linea token.
 * @dev NB: Only the L2 token bridge can call this function.
 * @dev Approval for the burn amount must be provided before this is invoked.
 * @param _account Account being burned for.
 * @param _value The amount being burned for the account.
 */
function burn(address _account, uint256 _value) external {
  require(_msgSender() == lineaCanonicalTokenBridge, CallerIsNotTokenBridge());

  _spendAllowance(_account, _msgSender(), _value);
  _burn(_account, _value);
}

modifier onlyMessagingService() {
  if (msg.sender != address(messageService)) {
    revert CallerIsNotMessageService();
  }
  _;
}

/**
 * @notice Claims tokens for an account while the claiming is active.
 * @dev Claiming sets claim status pre-transferring avoiding reentry, and all multiplier tokens are soulbound avoiding
 * transfer manipulation.
 * @param _account Account being claimed for.
 */
function claim(address _account) external {
  require(block.timestamp < CLAIM_END, ClaimFinished());
  require(!hasClaimed[_account], AlreadyClaimed());

  uint256 tokenAmount = calculateAllocation(_account);

  require(tokenAmount != 0, ClaimAmountIsZero());

  hasClaimed[_account] = true;
  emit Claimed(_account, tokenAmount);

  TOKEN.safeTransfer(_account, tokenAmount);
}

  /**
   * @notice Synchronizes the total supply of the L1 token to the L2 token.
   * @dev This function sends a message to the L2 token contract to sync the total supply.
   * @dev NB: This function is permissionless on purpose, allowing anyone to trigger the sync.
   * @dev This function can only be called after the L2 token address has been set.
   */
  function syncTotalSupplyToL2() external {
    uint256 totalSupply = totalSupply();

    /// @dev Fee is set to 0 and should be automatically claimed on Linea.
    IMessageService(l1MessageService).sendMessage(l2TokenAddress, 0, abi.encodeCall(IL2LineaToken.syncTotalSupplyFromL1, (block.timestamp, totalSupply)));

    emit L1TotalSupplySyncStarted(block.timestamp, totalSupply);
  }
}

/**
 * @notice Synchronizes the total supply of the L1 Linea token from L1 Ethereum.
 * @dev NB: This function can only be called by the Linea Message Service.
 * @dev NB: This function must have originated from the Linea token on L1 Ethereum.
 * @param _l1LineaTokenTotalSupplySyncTime The L1 block.timestamp when the Linea token on L1 total supply was
 * computed.
 * @param _l1LineaTokenSupply The total supply of the L1 Linea token.
 */
function syncTotalSupplyFromL1(uint256 _l1LineaTokenTotalSupplySyncTime, uint256 _l1LineaTokenSupply) external onlyMessagingService onlyAuthorizedRemoteSender {
  require(l1LineaTokenTotalSupplySyncTime < _l1LineaTokenTotalSupplySyncTime, LastSyncMoreRecent());

  l1LineaTokenSupply = _l1LineaTokenSupply;
  l1LineaTokenTotalSupplySyncTime = _l1LineaTokenTotalSupplySyncTime;

  emit L1LineaTokenTotalSupplySynced(_l1LineaTokenTotalSupplySyncTime, _l1LineaTokenSupply);
}

/**
 * @notice Owner withdraws unclaimed tokens from the contract post claim end and self destructs.
 * @dev The selfdestruct only applies for pre EIP-6780 forks.
 */
function withdraw() external onlyOwner {
  require(CLAIM_END <= block.timestamp, ClaimNotFinished());

  uint256 balance = TOKEN.balanceOf(address(this));

  emit TokenBalanceWithdrawn(msg.sender, balance);
  TOKEN.safeTransfer(msg.sender, balance);

  selfdestruct(payable(msg.sender));
}

function calculateAllocation(address _account) public view returns (uint256 tokenAllocation) {
  if (address(PRIMARY_FACTOR_ADDRESS) != address(0) && address(PRIMARY_CONDITIONAL_MULTIPLIER_ADDRESS) != address(0)) {
    tokenAllocation = (PRIMARY_FACTOR_ADDRESS.balanceOf(_account) * PRIMARY_CONDITIONAL_MULTIPLIER_ADDRESS.balanceOf(_account)) / DENOMINATOR;
  }

require(_primaryFactorAddress != address(0) || _primaryConditionalMultiplierAddress == address(0), ZeroAddressNotAllowed());

require(_primaryFactorAddress == address(0) || _primaryConditionalMultiplierAddress != address(0), ZeroAddressNotAllowed());

address(PRIMARY_FACTOR_ADDRESS) != address(0) && address(PRIMARY_CONDITIONAL_MULTIPLIER_ADDRESS) != address(0)

address(PRIMARY_FACTOR_ADDRESS) != address(0)

Appendix 1 - Files in Scope

This review covered the following files.

Initial version at revision 44640f0965a5c7465b99769a5d241a9a1cb3a2ef:

Final version at revision 91036daf2331610841796772f8fbb2fcc4a9233f:

Appendix 2 - Disclosure

Consensys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via Consensys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any third party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any third party by virtue of publishing these Reports.

A.2.1 Purpose of Reports

The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of code and only the code we note as being within the scope of our review within this report. Any Solidity code itself presents unique and unquantifiable risks as the Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond specified code that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. In some instances, we may perform penetration testing or infrastructure assessments depending on the scope of the particular engagement.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

A.2.2 Links to Other Web Sites from This Web Site

You may, through hypertext or other computer links, gain access to web sites operated by persons other than Consensys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that Consensys and CD are not responsible for the content or operation of such Web sites, and that Consensys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that Consensys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. Consensys and CD assumes no responsibility for the use of third-party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

A.2.3 Timeliness of Content

The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice unless indicated otherwise, by Consensys and CD.