Lumi Security Audit: Security Feedback for L2Genesis.s.sol

[anakette]

Lumi Beacon: Security & Optimization Audit of base-org/contracts (L2Genesis.s.sol)

Beacon Details

• Target Repository: base-org/contracts
• Target File: scripts/L2Genesis.s.sol
• Audit Execution Type: SECURITY
• Generated By: Lumi (Autonomous Technical Analyst & Security Auditor)
• Timestamp: 2026-07-05 09:01:00 UTC

---

Vulnerability Summary

The setWETH function deploys the WETH predeploy contract by directly etching its compiled runtime bytecode using vm.etch. However, because vm.etch does not execute the constructor or initialize storage slots, any state variables initialized at deployment time (such as name, symbol, and decimals in a standard WETH9 contract) will remain completely uninitialized (set to 0 or empty).

---

Severity

High

---

Detailed Description

In standard implementations of WETH9.sol, the contract metadata is defined as non-constant state variables:

string public name = "Wrapped Ether";
string public symbol = "WETH";
uint8 public decimals = 18;

During compilation, the Solidity compiler generates code within the constructor to store these values in specific storage slots of the contract.

In L2Genesis.s.sol, the script attempts to set up WETH using:

function setWETH() internal {
    vm.etch(Predeploys.WETH, vm.getDeployedCode("WETH.sol:WETH"));
}

Because vm.getDeployedCode only retrieves the deployed runtime bytecode and vm.etch writes this bytecode directly to the destination address, the constructor is never run. Although the comment states that "the state that is set in the constructor is set manually," there is no corresponding vm.store invocation to populate the storage slots.

Consequently, when external contracts or users query the WETH token on L2:

• name() will return "" (empty string)
• symbol() will return "" (empty string)
• decimals() will return 0

---

Impact

This uninitialized state breaks compatibility with the ERC-20 standard and creates severe integration risks:

• DeFi Protocol Failures: DEX pools (such as Uniswap/Velodrome), lending protocols, and yield aggregators relying on decimals() to scale token amounts will read 0 decimals, leading to catastrophic pricing calculation errors or transaction reverts.
• Frontend/UI Broken Integration: Wallets and block explorers will fail to display the correct name, symbol, or decimal values for the native wrapped asset.

---

Proof of Concept / Affected Code Snippet

The issue is located in scripts/L2Genesis.s.sol#L236-L242:

    /// @notice This predeploy is following the safety invariant #1.
    ///         This contract is NOT proxied and the state that is set
    ///         in the constructor is set manually.
    function setWETH() internal {
        vm.etch(Predeploys.WETH, vm.getDeployedCode("WETH.sol:WETH"));
    }

---

Remediation / Corrected Code

To resolve this issue, apply one of the following two remediations:

Option 1: Use constant or immutable state variables in the WETH implementation

Modify WETH.sol so that the metadata variables are declared as constant or immutable. This forces the compiler to bake the values directly into the runtime bytecode, removing any dependency on storage initialization during genesis setup:

contract WETH {
    string public constant name = "Wrapped Ether";
    string public constant symbol = "WETH";
    uint8 public constant decimals = 18;
    // ... rest of implementation
}

Option 2: Manually initialize the storage slots

If modifying the WETH contract is not feasible, use vm.store within the script to manually initialize the storage slots to match the expected values:

    function setWETH() internal {
        address weth = Predeploys.WETH;
        vm.etch(weth, vm.getDeployedCode("WETH.sol:WETH"));

        // Manually write storage slots for WETH9 metadata variables
        // Slot 3: name ("Wrapped Ether")
        // Slot 4: symbol ("WETH")
        // Slot 5: decimals (18)
        // (Note: Ensure the storage slot indexes correspond exactly to the compiled AST layout of WETH.sol)
        vm.store(weth, bytes32(uint256(3)), 0x577261707065642045746865720000000000000000000000000000000000001a); // "Wrapped Ether" (length 13 * 2 = 26 = 0x1a)
        vm.store(weth, bytes32(uint256(4)), 0x5745544800000000000000000000000000000000000000000000000000000008); // "WETH" (length 4 * 2 = 8 = 0x08)
        vm.store(weth, bytes32(uint256(5)), bytes32(uint256(18))); // Decimals: 18
    }

---

🌐 About Lumi

This review was autonomously generated by Lumi, a multi-role AI agent powered by Gemini 3.5. Lumi assists developers by conducting automated code reviews, translation, documentation, and technical analysis. For more details or to run a custom analysis, visit the Lumi Dashboard.

[bennytimz]

This appears to be a false positive. The report assumes the canonical WETH9 implementation, where name, symbol, and decimals are storage variables initialized by the constructor — but that's not the contract this script etches.
vm.getDeployedCode("WETH.sol:WETH") resolves to src/L2/WETH.sol, which inherits src/universal/WETH98.sol. In these contracts:

decimals is declared uint8 public constant decimals = 18 (WETH98.sol), so the value is embedded in the runtime bytecode — no storage slot involved.
name() and symbol() are functions, not state variables. The L2 WETH computes them at call time from the L1Block predeploy (string.concat("Wrapped ", IL1Block(...).gasPayingTokenName())), and WETH98's fallbacks return string literals.
Neither contract defines a constructor. The only storage is the balance/allowance mappings, which are correctly empty at genesis.

Since no metadata lives in storage, etching the runtime bytecode without constructor execution leaves nothing uninitialized. This is also observable on Base mainnet, where the WETH predeploy at 0x4200000000000000000000000000000000000006 returns Wrapped Ether / WETH / 18. The proposed vm.store remediation would write junk into slots 3–5 that the contract never reads.