[L-1] Inconsistent Yul return() Pattern in Internal Functions in ERC20Internals.sol

Description

• The ERC20Internals contract mixes two different return patterns in its inline assembly:

  Pattern A: Direct Yul return() (Halts Execution)

  Used in:

  • totalSupply_()

  • _balanceOf()

  Example:

Pattern B: Assigning to Solidity Output Variables (Recommended Style)

Used in:

• _approve()

• _allowance()

• _transfer()

• _spendAllowance()

• _mint()

• _burn()

Example:

Both patterns work, but mixing them creates unnecessary inconsistency and introduces a subtle risk:

Risk

Direct Yul return():

1. Halts execution immediately, skipping any future Solidity-level handling.

2. Bypasses Solidity’s ABI encoding, which is safe only as long as function output stays a single 32-byte value.

3. Becomes dangerous if the function is ever modified (e.g., multi-return values, additional logic).

This creates an unnecessary footgun for anyone extending or reusing the internal functions.

Likelihood:

• Medium

  
  

  Impact:

Why This Matters

Internal functions usually follow the same return mechanism. Here, the inconsistency could lead to:

• Misinterpretation of function behavior by future developers

• Silent ABI-breaking changes if function internals are modified

• Harder auditing due to mixed assembly styles

• Unexpected behavior if future logic relies on post-assembly Solidity code

This is not a functional bug today, but it is a maintainability and safety concern.

Proof of Concept

Recommended Mitigation

Refactor the functions using raw Yul return() to use Solidity output variables instead:

Before:

After:

This matches the style used everywhere else and eliminates the execution-halting return().