Token-0x

Description:

The internal view helpers totalSupply_ and _balanceOf use Yul’s return opcode:

These functions are declared internal but use return(...) at the EVM level, which aborts execution of the entire call, not just the internal function. In the current codebase they are only used as direct return expressions in the public view wrappers:

Here, the pattern works because totalSupply_ and _balanceOf are effectively acting as fully inlined implementations of the public functions. However, any future attempt to reuse these internal helpers in more complex logic (e.g., uint256 s = totalSupply_(); uint256 x = s + 1;) would silently break: the return in the assembly would exit the entire call before executing subsequent code.

Impact:

• Currently low, because the functions are only used as direct return targets.

• Future maintainers might treat totalSupply_ / _balanceOf as “normal” internal helpers and call them in more complex functions, leading to:

  • Unexpected early returns.

  • ABI decoding errors (if the outer function expects multiple return values but return sends only one).

  • Very subtle bugs that are hard to diagnose.

Proof of Concept:

You can create a derived token that tries to use totalSupply_ in additional logic:

Any call to buggy() will actually return only the 32 bytes written by totalSupply_ and then stop execution. The ABI decoder on the caller side will expect two uint256 values (64 bytes) and likely revert or misinterpret the data.

Mitigation:

• Avoid using low‑level return in internal helpers. Instead, write them in normal Solidity or restrict the pattern to external/public functions where you fully implement the ABI in assembly.

• For example, implement totalSupply and balanceOf directly as assembly in the public functions, and make the internal helpers pure-Solidity:

• If you keep the current pattern, clearly document (in comments) that totalSupply_ and _balanceOf must only be used as direct return targets and are not safe as general internal helpers.