MantleWETH_BVM_ETH_Interface

Solc Version

The contract uses Solidity version pragma `^0.8.15`. This is a relatively recent compiler version. There are no known critical bugs specific to 0.8.15, but newer patch versions (0.8.16+) contain minor bugfixes. Using a floating pragma `^0.8.15` allows compilation with any 0.8.x version >= 0.8.15, which could lead to bytecode differences during deployment or verification if the toolchain picks a different version. Locking the compiler version is recommended for deterministic builds.

Naming Convention

The contract name `MantleWETH_BVM_ETH_Interface` is unusual and poses a naming-convention concern. It incorporates `Interface`, yet the contract contains concrete implementations (state variables, function bodies) and is not an abstract interface. This may mislead auditors and developers into thinking it is a pure interface, when it actually defines storage and logic.

Constable States

State variables `l1Token` and `l2Bridge` are declared as public constants (actually immutable-like) but lack explicit `constant` or `immutable` keywords, and their values are set once in the constructor or at deployment. This can be optimized for gas and clarity by making them `immutable`.

Constable States

State variable `decimals` is declared as a `public uint8` and assigned a constant value `18`. It can be optimized by declaring it as a `constant` to reduce gas costs and prevent potential state changes.

Constable States

The `l1Token` state variable is declared as `public` but is not declared `immutable` or `constant`. If it is intended to be set once during construction and never changed, marking it as `immutable` would enforce that intention and save gas on read. Currently, the code allows potential reassignment in derived or future contracts if not constrained by logic elsewhere.

Constable States

The `remoteToken` state variable is declared as `public` but is not declared `immutable` or `constant`. If it is intended to be set once during construction and never changed, marking it as `immutable` would enforce that intention and save gas on read. Currently, the code allows potential reassignment in derived or future contracts if not constrained by logic elsewhere.

Constable States

The contract declares `name` as a constant-like immutable state variable initialized to "Ether" but does not mark it as `constant` or `immutable`. This wastes gas and prevents the compiler from embedding the literal directly into the bytecode.

Constable States

The contract declares `symbol` as a constant-like immutable state variable initialized to "WETH" but does not mark it as `constant` or `immutable`. This wastes gas and prevents compiler optimization.

Review calldata parameter width

The approve function declares `uint256 amount` as calldata, but the Mantle network uses 32-byte words natively; marking smaller types as calldata does not reduce gas and can make the contract slightly less efficient on Mantle's EVM-compatible execution environment.

Review calldata parameter width

The transfer function declares `uint256 amount` as calldata; similar to approve, reducing the type width to a smaller unsigned integer (if supply permits) could lower calldata costs on Mantle.

Review calldata parameter width

The `transferFrom` function in `MantleWETH_BVM_ETH_Interface.sol` receives `uint256 amount` as calldata. On Mantle, calldata gas costs are sensitive to parameter sizes; using a smaller type like `uint128` or `uint64` (if logically safe) can reduce gas. However, since the internal `balanceOf` mapping uses `uint256`, changing the parameter width would not save storage costs but could reduce calldata overhead per transaction.

Review calldata parameter width

The `mint` function in `MantleWETH_BVM_ETH_Interface.sol` receives `uint256 amount` as calldata. Similar to the `transferFrom` finding, this wastes calldata gas on Mantle if the minted amount never requires a 256-bit range.

Review calldata parameter width

The `burn` function takes a `uint256 amount` parameter that is only used for balance checking and subtraction, but no value larger than the token total supply (which is likely far below 2^256-1) is practical. Using `uint256` for calldata incurs unnecessary gas cost.

Replace long revert string with custom error

The `transfer` function uses a `require` statement with a long revert string `"INSUFFICIENT_BALANCE"`. Replacing this with a custom error reduces deploy and runtime gas costs, as revert strings are stored in the bytecode and their length increases gas consumption upon revert.

Replace long revert string with custom error

The `require` statement uses a string literal as the revert reason. Using custom errors instead reduces gas deployed and gas on revert.

Replace long revert string with custom error

The `require` statement uses a string literal as the revert reason. Using custom errors instead reduces gas deployed and gas on revert.

Replace long revert string with custom error

A long revert string is used in a `require` statement, which increases deployment and execution gas costs. Replacing it with a custom error reduces bytecode size and gas consumption on Mantle, where L2 execution costs are still sensitive.

Cache repeated storage read

The storage variable `balanceOf[msg.sender]` is read twice in the `transfer` function: once in the `require` and again in the deduction. Caching it in a local variable saves an SLOAD operation, which costs gas.

Cache repeated storage read

The function reads `balanceOf[to]` and then immediately adds `amount` to it. Caching the initial value in a local variable before the addition could save gas by avoiding a second SLOAD if the variable is accessed again later, but in this isolated snippet it only has one SLOAD. However, the optimizer may already handle this. The finding suggests caching for repeated reads, though in this snippet there is no repeated read.

Cache repeated storage read

The function reads `balanceOf[from]` in the require statement and later subtracts `amount` from it. The repeated SLOAD can be avoided by caching the balance in a local variable.

Cache repeated storage read

The allowance mapping for the `from`-`msg.sender` pair is read twice on lines 46 and 48, causing an unnecessary second SLOAD that increases gas costs.