Linea - Burn Mechanism

1 Executive Summary

This report presents the results of our engagement with Linea to review the new Linea Revenue Profit Burn Mechanism.

The review was conducted from October 13, 2025 to October 20, 2025, with a total effort of 2 x 5 person-days.

The Linea Burn Mechanism consists of a three-contract system designed to facilitate the systematic burning of LINEA tokens as part of Linea’s rollup revenue management strategy. This operational infrastructure enables the collection of rollup revenues, conversion to LINEA tokens, and their subsequent destruction to reduce token supply.

The burn mechanism operates through a coordinated cross-chain workflow:

• Revenue Collection through RollupRevenueVault which receives ETH from Linea rollup operations and processes invoices for operational expenses
• A Token Conversion where during burn operations, 20% of available ETH is permanently destroyed while the remaining 80% is swapped for LINEA tokens via the V3DexSwap contract
• Acquired LINEA tokens are bridged from L2 to L1 using Linea’s canonical token bridge to the L1LineaTokenBurner contract
• The L1 burner contract processes cross-chain messages and permanently burns all received LINEA tokens, synchronizing the reduced supply back to L2

Remarks on Validated Design Decissions:

In RollupRevenueVault there is only one active receiver at a time. The system does not support multiple simultaneous receivers, as the debt system enforces a single counterparty. Operationally, this receiver is separate from the invoice submitter, who remains a trusted role.

RollupRevenueVault can receive ETH through fallback() and receive() without requiring invoice submission. This ETH becomes immediately available for burning if there are no outstanding arrears, which could bypass standard revenue accounting and invoice workflows. These functions are primarily intended to accept ETH from contributors wishing to fund the burn. Off-chain procedures and timing routines are carefully managed to ensure that invoices are settled first, allowing any excess ETH to be safely burned.

Neither RollupRevenueVault nor V3DexSwap enforce slippage control by themselve, placing critical responsibility on the caller to correctly parameterize burnAndBridge(bytes calldata _swapData) with appropriate slippage settings. The contracts trust the configured DEX router to return at least the caller provided amountOutMinimum, there is no explicit verification. This may be valid, however, the caller should consider implementing additional verification mechanisms to ensure swap outputs meet expected thresholds, as incorrect parameterization could result in excessive slippage or MEV exploitation.

The RollupRevenueVault admin, overseen by a distributed security council including non-Linea and non-CSI members, can adjust arrears via updateInvoiceArrears to correct reporting inaccuracies; this capability is tightly controlled and expected to be used only in rare cases of major reporting errors.

Here’s a more concise and polished version suitable for an executive summary section of an audit report. It keeps all the technical detail but presents it with clearer structure and formal tone:

1.1 Update – October 24 + 30, 2025

All issues identified in this report have been resolved. The final audited codebase is represented by commit efe83ff992b38eda5fd5a58220acb6952c519f75 (tag: contract-audit-2025-10-30), which contains the verified deployment artifacts.

1.2 Update – November 2, 2025

At the request of the Linea team, the deployed contracts have been added and verified as follows.

Deployment Commit: linea-monorepo@contract-audit-2025-10-30 (efe83ff992b38eda5fd5a58220acb6952c519f75)

The listed source files were recompiled from scratch, and the resulting bytecode was compared against the deployed contracts. In cases where an exact match was not observed, the differences were confirmed to correspond to the expected constructor parameters. The findings are as follows:

• RollupRevenueVault@0x84a5ba2c12a15071660b0682b59e665dc2faaedb: Verified on lineascan.build (Nov 2, 2025, 15:45 CET). The deployed bytecode is an exact match to the re-compiled code of contract-audit-2025-10-30@efe83ff and the bytecode artifacts recorded under linea-monorepo:contracts/deployments/bytecode/2025-10-27.

• V3DexSwapAdapter@0x30a20a3a9991c939290f4329cb52daac8e97f353: Verified on lineascan.build (Nov 2, 2025, 15:45 CET). The deployed bytecode matches, with expected constructor argument substitutions. The re-compiled bytecode matches the bytecode artifacts recorded under linea-monorepo:contracts/deployments/bytecode/2025-10-27.

• L1LineaTokenBurner@0x5Ad9369254F29b724d98F6ce98Cb7bAD729969F3: Verified on lineascan.build (Nov 2, 2025, 15:45 CET). The deployed bytecode matches, with expected constructor argument substitutions. The re-compiled bytecode matches the bytecode artifacts recorded under linea-monorepo:contracts/deployments/bytecode/2025-10-27.

The re-compiled bytecode for V3DexSwapWethDepositAdapter matches the bytecode artifacts recorded under linea-monorepo:contracts/deployments/bytecode/2025-10-27.

2 Scope

This review focused on the following repository and code revision:

• Consensys/linea-monorepo @ contract-freeze-2025-10-12

The following files are in scope:

contracts/src/operational/
├── RollupRevenueVault.sol
├── V3DexSwap.sol
├── L1LineaTokenBurner.sol
└── interfaces/
    ├── IV3DexSwap.sol
    ├── IRollupRevenueVault.sol
    ├── ISwapRouterV3.sol
    ├── IL1LineaToken.sol
    ├── IL1LineaTokenBurner.sol
    └── IWETH9.sol

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

2.1 Objectives

Together with the Linea Team, we identified the following priorities for this review:

1. Correctness of the implementation, consistent with the intended functionality and without unintended edge cases.
2. Identify known vulnerabilities particular to smart contract systems, as outlined in our Smart Contract Best Practices, and the Smart Contract Weakness Classification Registry.
3. Proper Handling of Funds, fee collection, profit burning, and token swaps.
4. Swaps comply with industry standards via the defined Dex interface.
5. Documentation and Transparency, operations are clearly documented and understandable by stakeholders.

3 System Overview

Burn Mechanism

(This image was provided by the Linea Team)

Contract Overview

3.1 Rollup Revenue Vault (Upgradable)

• Handles Sequencer and L2 DDoS fee collection, invoice management, and profit burning.
• Burns 20% as ETH and swaps 80% to Linea tokens, which are bridged to the L1 Token Burner.
• Supports configuration changes (Dex swap address, invoice recipient, L1 Token Burner).

Technical Details:

• Upgradeable Contract: Uses OpenZeppelin’s AccessControlUpgradeable with reinitializer support (version 2)
• Role-Based Access Control:
  • DEFAULT_ADMIN_ROLE: Can update system parameters (dex, invoice receiver, L1 burner, invoice arrears)
  • INVOICE_SUBMITTER_ROLE: Can submit and process invoices for operational expenses
  • BURNER_ROLE: Can execute the burn-and-bridge operations

Revenue Collection & Invoice Management:

• Revenue Reception: Accepts ETH through receive() and fallback() functions, emitting EthReceived events
• Invoice Processing: Strict sequential invoice system requiring _startTimestamp == lastInvoiceDate + 1
• Arrears Handling: Automatically calculates and tracks unpaid amounts when contract balance is insufficient
• Payment Priority: Invoice payments are processed before any burn operations (invoiceArrears == 0 requirement)

Burn-and-Bridge Mechanism:

• Fixed Burn Ratio: Exactly 20% of available ETH (after message fees) is permanently destroyed via address(0).call{value: ethToBurn}("")
• DEX Integration: Remaining 80% is sent to the DEX contract via low-level call with encoded swap data
• Token Bridging: Acquired LINEA tokens are approved and bridged to L1 using the canonical TokenBridge.bridgeToken() function
• Balance Management: Reserves L2MessageService minimum fees before calculating burn amounts

Configuration Management:

• Updateable Components: DEX address, invoice payment receiver, L1 token burner address, and invoice arrears
• Validation: All updates include zero-address checks and existing-address-same prevention

3.2 L1 Linea Token Burner (Non-Upgradable)

• Accepts token bridging messages and burns tokens in a single permissionless transaction.
• Includes safeguards against front-running, duplicate claims, and zero-balance burns.

Technical Details:

• Immutable Design: All addresses (LINEA_TOKEN, MESSAGE_SERVICE) are immutable, preventing configuration changes post-deployment
• Permissionless Operation: Anyone can call claimMessageWithProof() to trigger token burning

Message Claiming & Burning Process:

• Idempotent Message Claiming: Checks IL1MessageManager.isMessageClaimed() before attempting to claim, preventing revert on duplicate claims
• Automatic Token Destruction: Burns entire contract balance in a single transaction using IL1LineaToken.burn(balance)
• Supply Synchronization: Calls IL1LineaToken.syncTotalSupplyToL2() to update L2 total supply after burning
• Zero-Balance Protection: Requires balance > 0 before executing burn operations

Front-Running & Duplicate Claim Safeguards:

• Message Status Check: Prevents claiming already-processed messages
• Balance Validation: Ensures tokens exist before burning
• Atomic Operation: Combines message claiming and token burning in single transaction

3.3 V3 Dex Swap (L2, Non-Upgradable)

• Executes exact-input token swaps, ensuring no residual ETH remains.
• Token receiver is always the caller funding the swap.

Technical Details:

• Immutable Configuration: Router, WETH, LINEA token addresses, and pool tick spacing are set at deployment
• Uniswap V3 Integration: Uses ISwapRouterV3.exactInputSingle() for precise ETH-to-LINEA swaps

Swap Execution Details:

• ETH Handling: Converts incoming ETH to WETH via IWETH9.deposit{value: msg.value}()
• Exact Input Swaps: Guarantees all input ETH is consumed, leaving zero residual balance
• Direct Token Delivery: LINEA tokens are sent directly to msg.sender (the caller), never held by the contract
• Slippage Protection: Enforces minimum output amounts via amountOutMinimum parameter
• Deadline Protection: Prevents transaction execution after specified timestamp

Parameter Validation:

• Input Validation: Requires msg.value > 0, _deadline > block.timestamp, and _minLineaOut > 0
• Price Limit Control: Accepts _sqrtPriceLimitX96 for additional price protection
• Return Value: Returns actual LINEA tokens received from the swap

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

const contractName = "RollupRevenueVault";
const existingContractAddress = await getDeployedContractAddress(contractName, deployments);

const contract = await deployUpgradableFromFactory(contractName, [], {
  initializer: EMPTY_INITIALIZE_SIGNATURE,
  unsafeAllow: ["constructor"],
});

function initialize(
  uint256 _lastInvoiceDate,
  address _defaultAdmin,
  address _invoiceSubmitter,
  address _burner,
  address _invoicePaymentReceiver,
  address _tokenBridge,
  address _messageService,
  address _l1LineaTokenBurner,
  address _lineaToken,
  address _dex
) external initializer {
  __AccessControl_init();
  __RollupRevenueVault_init(
    _lastInvoiceDate,
    _defaultAdmin,
    _invoiceSubmitter,

/**
 * @notice Fallback function - Receives Funds.
 */
fallback() external payable {
  emit EthReceived(msg.value);
}

it("Should revert when reinitializing twice", async () => {
  const txPromise = rollupRevenueVault.initializeRolesAndStorageVariables(
    await time.latest(),
    admin.address,
    invoiceSubmitter.address,
    burner.address,
    invoicePaymentReceiver.address,
    await tokenBridge.getAddress(),
    await messageService.getAddress(),
    l1LineaTokenBurner.address,
    await l2LineaToken.getAddress(),
    await dex.getAddress(),
  );

) external initializer {
  __AccessControl_init();
  __RollupRevenueVault_init(

) external reinitializer(2) {
  __AccessControl_init();
  __RollupRevenueVault_init(

_grantRole(DEFAULT_ADMIN_ROLE, _defaultAdmin);
_grantRole(INVOICE_SUBMITTER_ROLE, _invoiceSubmitter);
_grantRole(BURNER_ROLE, _burner);

describe("Initialization", () => {
  it("should revert if lastInvoiceDate is zero", async () => {
    const deployCall = deployUpgradableFromFactory(
      "RollupRevenueVault",
      [
        0n,
        admin.address,
        invoiceSubmitter.address,
        burner.address,
        invoicePaymentReceiver.address,
        await tokenBridge.getAddress(),
        await messageService.getAddress(),
        l1LineaTokenBurner.address,
        await l2LineaToken.getAddress(),
        await dex.getAddress(),
      ],
      {
        initializer: ROLLUP_REVENUE_VAULT_INITIALIZE_SIGNATURE,
        unsafeAllow: ["constructor"],
      },

/**
 * @notice Initializes the contract state.
 * @param _lastInvoiceDate Timestamp of the last invoice.
 * @param _defaultAdmin Address to be granted the default admin role.
 * @param _invoiceSubmitter Address to be granted the invoice submitter role.
 * @param _burner Address to be granted the burner role.
 * @param _invoicePaymentReceiver Address to receive invoice payments.
 * @param _tokenBridge Address of the token bridge contract.
 * @param _messageService Address of the L2 message service contract.
 * @param _l1LineaTokenBurner Address of the L1 LINEA token burner contract.
 * @param _lineaToken Address of the LINEA token contract.
 * @param _dex Address of the DEX contract.
 */
function initialize(
  uint256 _lastInvoiceDate,
  address _defaultAdmin,
  address _invoiceSubmitter,
  address _burner,
  address _invoicePaymentReceiver,
  address _tokenBridge,
  address _messageService,
  address _l1LineaTokenBurner,
  address _lineaToken,
  address _dex
) external initializer {
  __AccessControl_init();
  __RollupRevenueVault_init(
    _lastInvoiceDate,
    _defaultAdmin,
    _invoiceSubmitter,
    _burner,
    _invoicePaymentReceiver,
    _tokenBridge,
    _messageService,
    _l1LineaTokenBurner,
    _lineaToken,
    _dex
  );
}

/**
 * @notice Reinitializes the contract state for upgrade.
 * @param _lastInvoiceDate Timestamp of the last invoice.
 * @param _defaultAdmin Address to be granted the default admin role.
 * @param _invoiceSubmitter Address to be granted the invoice submitter role.
 * @param _burner Address to be granted the burner role.
 * @param _invoicePaymentReceiver Address to receive invoice payments.
 * @param _tokenBridge Address of the token bridge contract.
 * @param _messageService Address of the L2 message service contract.
 * @param _l1LineaTokenBurner Address of the L1 LINEA token burner contract.
 * @param _lineaToken Address of the LINEA token contract.
 * @param _dex Address of the DEX contract.
 */
function initializeRolesAndStorageVariables(
  uint256 _lastInvoiceDate,
  address _defaultAdmin,
  address _invoiceSubmitter,
  address _burner,
  address _invoicePaymentReceiver,
  address _tokenBridge,
  address _messageService,
  address _l1LineaTokenBurner,
  address _lineaToken,
  address _dex
) external reinitializer(2) {
  __AccessControl_init();
  __RollupRevenueVault_init(
    _lastInvoiceDate,
    _defaultAdmin,
    _invoiceSubmitter,
    _burner,
    _invoicePaymentReceiver,
    _tokenBridge,
    _messageService,
    _l1LineaTokenBurner,
    _lineaToken,
    _dex
  );
}

function __RollupRevenueVault_init(
  uint256 _lastInvoiceDate,
  address _defaultAdmin,
  address _invoiceSubmitter,
  address _burner,
  address _invoicePaymentReceiver,
  address _tokenBridge,
  address _messageService,
  address _l1LineaTokenBurner,
  address _lineaToken,
  address _dex
) internal onlyInitializing {
  require(_lastInvoiceDate != 0, ZeroTimestampNotAllowed());
  require(_defaultAdmin != address(0), ZeroAddressNotAllowed());
  require(_invoiceSubmitter != address(0), ZeroAddressNotAllowed());
  require(_burner != address(0), ZeroAddressNotAllowed());
  require(_invoicePaymentReceiver != address(0), ZeroAddressNotAllowed());
  require(_tokenBridge != address(0), ZeroAddressNotAllowed());
  require(_messageService != address(0), ZeroAddressNotAllowed());
  require(_l1LineaTokenBurner != address(0), ZeroAddressNotAllowed());
  require(_lineaToken != address(0), ZeroAddressNotAllowed());
  require(_dex != address(0), ZeroAddressNotAllowed());

  _grantRole(DEFAULT_ADMIN_ROLE, _defaultAdmin);
  _grantRole(INVOICE_SUBMITTER_ROLE, _invoiceSubmitter);
  _grantRole(BURNER_ROLE, _burner);

  lastInvoiceDate = _lastInvoiceDate;

  invoicePaymentReceiver = _invoicePaymentReceiver;
  tokenBridge = TokenBridge(_tokenBridge);
  messageService = L2MessageService(_messageService);
  l1LineaTokenBurner = _l1LineaTokenBurner;
  lineaToken = _lineaToken;
  dex = _dex;
}

/**
 * @notice Submit invoice to pay to the designated receiver.
 * @param _startTimestamp Start of the period the invoice is covering.
 * @param _endTimestamp End of the period the invoice is covering.
 * @param _invoiceAmount New invoice amount.
 */
function submitInvoice(
  uint256 _startTimestamp,
  uint256 _endTimestamp,
  uint256 _invoiceAmount
) external payable onlyRole(INVOICE_SUBMITTER_ROLE) {
  require(_startTimestamp == lastInvoiceDate + 1, TimestampsNotInSequence());
  require(_endTimestamp > _startTimestamp, EndTimestampMustBeGreaterThanStartTimestamp());
  require(_invoiceAmount != 0, ZeroInvoiceAmount());

  address payable receiver = payable(invoicePaymentReceiver);
  uint256 balanceAvailable = address(this).balance;

  uint256 totalAmountOwing = invoiceArrears + _invoiceAmount;
  uint256 amountToPay = (balanceAvailable < totalAmountOwing) ? balanceAvailable : totalAmountOwing;

  invoiceArrears = totalAmountOwing - amountToPay;
  lastInvoiceDate = _endTimestamp;

function __RollupRevenueVault_init(
  uint256 _lastInvoiceDate,
  address _defaultAdmin,
  address _invoiceSubmitter,
  address _burner,
  address _invoicePaymentReceiver,
  address _tokenBridge,
  address _messageService,
  address _l1LineaTokenBurner,
  address _lineaToken,
  address _dex
) internal onlyInitializing {
  require(_lastInvoiceDate != 0, ZeroTimestampNotAllowed());
  require(_defaultAdmin != address(0), ZeroAddressNotAllowed());
  require(_invoiceSubmitter != address(0), ZeroAddressNotAllowed());
  require(_burner != address(0), ZeroAddressNotAllowed());
  require(_invoicePaymentReceiver != address(0), ZeroAddressNotAllowed());
  require(_tokenBridge != address(0), ZeroAddressNotAllowed());
  require(_messageService != address(0), ZeroAddressNotAllowed());
  require(_l1LineaTokenBurner != address(0), ZeroAddressNotAllowed());
  require(_lineaToken != address(0), ZeroAddressNotAllowed());
  require(_dex != address(0), ZeroAddressNotAllowed());

  _grantRole(DEFAULT_ADMIN_ROLE, _defaultAdmin);
  _grantRole(INVOICE_SUBMITTER_ROLE, _invoiceSubmitter);
  _grantRole(BURNER_ROLE, _burner);

  lastInvoiceDate = _lastInvoiceDate;

/**
 * @notice Update the invoice arrears.
 * @param _newInvoiceArrears New invoice arrears value.
 * @param _lastInvoiceDate Timestamp of the last invoice.
 */
function updateInvoiceArrears(
  uint256 _newInvoiceArrears,
  uint256 _lastInvoiceDate
) external onlyRole(DEFAULT_ADMIN_ROLE) {
  require(_lastInvoiceDate >= lastInvoiceDate, InvoiceDateTooOld());

  invoiceArrears = _newInvoiceArrears;
  lastInvoiceDate = _lastInvoiceDate;
  emit InvoiceArrearsUpdated(_newInvoiceArrears, _lastInvoiceDate);
}

/**
 * @notice Update the invoice arrears.
 * @param _newInvoiceArrears New invoice arrears value.
 * @param _lastInvoiceDate Timestamp of the last invoice.
 */
function updateInvoiceArrears(
  uint256 _newInvoiceArrears,
  uint256 _lastInvoiceDate
) external onlyRole(DEFAULT_ADMIN_ROLE) {
  require(_lastInvoiceDate >= lastInvoiceDate, InvoiceDateTooOld());

  invoiceArrears = _newInvoiceArrears;
  lastInvoiceDate = _lastInvoiceDate;
  emit InvoiceArrearsUpdated(_newInvoiceArrears, _lastInvoiceDate);
}

5 Document Change Log

Appendix 1 - Files in Scope

This review covered the following files:

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.