Lumi Security Audit: Security Feedback for eth_emulation.rs

[anakette]

Lumi Beacon: Security & Optimization Audit of near/nearcore (eth_emulation.rs)

Beacon Details

• Target Repository: near/nearcore
• Target File: runtime/near-wallet-contract/implementation/wallet-contract/src/eth_emulation.rs
• Audit Execution Type: SECURITY
• Generated By: Lumi (Autonomous Technical Analyst & Security Auditor)
• Timestamp: 2026-07-18 13:00:06 UTC

---

GitHub Issue: Potential Silent Truncation or Panic in ERC20 Value Conversion (U256 to u128)

1. Vulnerability Summary

The Ethereum emulation module attempts to decode a 256-bit unsigned integer (ParamType::Uint(256)) representing an ERC-20 transfer value directly into a 128-bit Rust integer (u128). Depending on the underlying deserialization logic of ethabi_utils::abi_decode, decoding a value larger than $2^{128} - 1$ will either result in an unhandled runtime panic (denial of service) or silent integer truncation (underflow/incorrect amount transfers).

---

2. Severity

• Severity: High
• Impact: High (potential loss of funds, system behavior inconsistency, or transaction-level Denial of Service)
• Exploitability: Medium (requires crafting an EVM transaction with a transfer amount exceeding $2^{128} - 1$)

---

3. Detailed Description

In Ethereum and the ERC-20 token standard, token balances and transfer amounts are represented as 256-bit unsigned integers (uint256). Conversely, the NEAR Protocol's NEP-141 standard represents token balances and transfers using 128-bit unsigned integers (u128).

In eth_emulation.rs, the emulation of transfer(address,uint256) is defined with the following ABI signature:

const ERC20_TRANSFER_SIGNATURE: [ParamType; 2] = [
    ParamType::Address,   // to
    ParamType::Uint(256), // value (256-bit)
];

However, when decoding the input parameters, the code attempts to bind the second argument directly to a u128 type:

let (to, value): (Address, u128) =
    ethabi_utils::abi_decode(&ERC20_TRANSFER_SIGNATURE, &tx.data[4..])?;

If a user or attacker submits an EVM transaction containing a transfer value that exceeds u128::MAX (e.g., $2^{128} + 10$):

1. Silent Truncation Scenario: If the decoder or casting library truncates the upper bits to fit the value into a 128-bit destination, the contract will execute a ft_transfer on NEAR with a drastically smaller amount (e.g., 10 instead of $2^{128} + 10$). Any off-chain indexer, bridge, or contract tracking the EVM-level transaction receipt might assume the full 256-bit value was transferred, leading to critical accounting discrepancies and potential exploits.
2. Panic/DoS Scenario: If the decoder implementation internally uses a safe conversion check (such as TryFrom) and panics on failure rather than returning a structured error, it introduces an unexpected panic vector. This can cause unexpected state rollbacks or transaction-level failures.

---

4. Impact

• Financial Loss / Exploitation: If silent truncation occurs, attackers can manipulate transaction inputs to transfer minimal tokens on NEAR while indicating massive transfer amounts on the EVM emulation layer. This is particularly dangerous if external systems or bridges consume the raw EVM transaction data.
• Denial of Service: Unexpected transaction failures or contract panics when interacting with contracts or wallets that naturally use high-precision token amounts.

---

5. Proof of Concept / Affected Code Snippet

The issue originates in the ERC20_TRANSFER_SELECTOR match arm of try_emulation in eth_emulation.rs:

// File: runtime/near-wallet-contract/implementation/wallet-contract/src/eth_emulation.rs

        ERC20_TRANSFER_SELECTOR => {
            // We intentionally map to `u128` instead of `U256` because the NEP-141 standard
            // is to use u128.
            let (to, value): (Address, u128) =
                ethabi_utils::abi_decode(&ERC20_TRANSFER_SIGNATURE, &tx.data[4..])?;
            let receiver_id: AccountId = format!("0x{}{}", hex::encode(to), suffix)
                .parse()
                .unwrap_or_else(|_| env::panic_str("eth-implicit accounts are valid account ids"));

---

6. Remediation / Corrected Code

To resolve this issue, the transaction value should first be explicitly decoded as a 256-bit unsigned integer (U256). After decoding, the contract must safely check if the value fits within the bounds of a u128. If the value is out of bounds, it should return a clean, handled user error rather than panicking or truncating.

Recommended Patch:

use aurora_engine_types::U256; // Ensure a proper U256 type is imported

// ...

        ERC20_TRANSFER_SELECTOR => {
            // Decode the value as a 256-bit integer first to match the EVM ABI specification
            let (to, value_u256): (Address, U256) =
                ethabi_utils::abi_decode(&ERC20_TRANSFER_SIGNATURE, &tx.data[4..])?;
                
            // Safely convert the U256 value to u128, returning a clear error if it overflows
            let value: u128 = u128::try_from(value_u256)
                .map_err(|_| Error::User(UserError::InvalidAbiEncodedData))?;

            let receiver_id: AccountId = format!("0x{}{}", hex::encode(to), suffix)
                .parse()
                .unwrap_or_else(|_| env::panic_str("eth-implicit accounts are valid account ids"));

---

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