Summary

Base native precompile storage writes do not enforce EIP-2200's gasleft <= 2300 SSTORE guard before mutating storage. As a result, low-gas direct calls to stateful native precompiles can perform warm dirty storage writes that the normal EVM SSTORE opcode would halt before executing.

Finding Description

EIP-2200 requires an SSTORE to fail the current call frame with out-of-gas when the frame's remaining gas is less than or equal to the call stipend. The pinned revm opcode implementation applies this sentry before host storage mutation: it checks gas.remaining() <= call_stipend() and halts with ReentrancySentryOOG; CALL_STIPEND is 2300 gas in the same dependency set.

The native precompile wrapper does not mirror that opcode-level guard. The stateful wrapper only rejects non-direct calls, copies calldata, constructs EvmPrecompileStorageProvider, and enters StorageCtx:

if !input.is_direct_call() {    return ::base_precompile_storage::BasePrecompileError::revert(        ::base_precompile_storage::DelegateCallNotAllowed {},    )    .into_precompile_result(0, 0);}
let mut provider = ::base_precompile_storage::EvmPrecompileStorageProvider::new(    input,    ::revm::context_interface::cfg::GasParams::default(),);

crates/common/precompiles/src/macros.rs#L6-L23

ABI dispatchers then deduct calldata gas and forward into the precompile logic without checking the stipend boundary, for example B20 asset dispatch at crates/common/precompiles/src/b20_asset/dispatch.rs#L22-L52, policy dispatch at crates/common/precompiles/src/policy/dispatch.rs#L18-L27, activation dispatch at crates/common/precompiles/src/activation/dispatch.rs#L16-L27, and factory dispatch at crates/common/precompiles/src/b20_factory/dispatch.rs#L15-L19.

The actual native storage provider only blocks static context, calls internals.sstore(address, key, value), and charges SSTORE gas afterward:

fn sstore(&mut self, address: Address, key: U256, value: U256) -> Result<()> {    if self.is_static {        return Err(BasePrecompileError::StaticCallViolation);    }    let s = self        .internals        .sstore(address, key, value)        .map_err(|e| BasePrecompileError::Fatal(e.to_string()))?;
    self.deduct_gas(self.gas_params.sstore_static_gas())?;    self.deduct_gas(self.gas_params.sstore_dynamic_gas(true, &s.data, s.is_cold))?;    self.refund_gas(self.gas_params.sstore_refund(true, &s.data));
    Ok(())}

crates/common/precompile-storage/src/evm.rs#L172-L189

This is reachable through normal direct precompile calls. For example, B20 approve takes ctx.caller() as the allowance owner and calls self.approve(caller, c.spender, c.amount) at crates/common/precompiles/src/b20_asset/dispatch.rs#L191-L194. approve then writes the allowance and emits Approval at crates/common/precompiles/src/common/ops/transferable.rs#L109-L120, and the allowance field is a direct mutable mapping at crates/common/precompiles/src/common/core_storage.rs#L33-L36.

A transaction that first warms and dirties the same allowance slot can later make a low-gas direct call into approve. If the remaining gas is at or below 2300 but still enough for the warm dirty rewrite and subsequent event accounting, the native precompile path can mutate storage where the canonical opcode path would have halted before the write.

Impact Explanation

Impact is Medium. The issue breaks an EVM semantic guarantee that contracts rely on as a reentrancy sentry: stipend-level calls should not be able to perform SSTORE. The affected path is limited to native precompile storage, so this is not arbitrary EVM storage mutation, but it can still allow state changes in Base native precompiles under gas conditions that EIP-2200 intentionally forbids.

Likelihood Explanation

Likelihood is Medium. Attackers need a direct call into a stateful native precompile with a target slot already warm and dirty in the same transaction, because cold or expensive writes are expected to run out of gas after the mutation attempt. Those preconditions are realistic for allowance-style B20 flows and other repeated writes to the same precompile slot, and the outer wrapper does not otherwise reject low-gas direct calls.

Proof of Concept

Recommendation

We recommend enforcing the EIP-2200 stipend sentry before every native precompile sstore mutation. EvmPrecompileStorageProvider::sstore should check the current frame's remaining gas before internals.sstore and return an out-of-gas halt when remaining gas is less than or equal to gas_params.call_stipend(). Add regression coverage for a warm dirty B20 allowance write where a normal SSTORE would halt at the stipend boundary.

Summary

Successful native precompile calls that mutate storage through the generic dispatch result path can drop accumulated EIP-3529 SSTORE refunds, causing callers to overpay gas for otherwise valid refund-producing operations.

Finding Description

The storage context already has a refund-preserving success constructor: storage_ctx.rs builds a PrecompileOutput and then copies self.gas_refunded() into out.gas_refunded. The production EVM storage provider also records refunds for refundable SSTOREs: evm.rs charges storage write gas and calls refund_gas(...), while evm.rs records and exposes the accumulated refund.

However, the generic IntoPrecompileResult success conversion does not preserve that field:

impl<T> IntoPrecompileResult<T> for Result<T> {    fn into_precompile_result(        self,        gas: u64,        state_gas: u64,        encode_ok: impl FnOnce(T) -> Bytes,    ) -> PrecompileResult {        match self {            Ok(res) => Ok(PrecompileOutput::new(gas, encode_ok(res), state_gas)),            Err(err) => err.into_precompile_result(gas, state_gas),        }    }}

This means any accumulated ctx.gas_refunded() is lost when a mutating precompile returns through the generic success arm at error.rs.

This is reachable in current production dispatchers, not just a future API hazard. Affected dispatchers include:

• PolicyRegistryStorage::dispatch, which executes write calls and then returns through result.into_precompile_result(...) at dispatch.rs
• ActivationRegistryStorage::dispatch at dispatch.rs
• B20FactoryStorage::dispatch at dispatch.rs
• B20AssetStorage::dispatch_with_observer at dispatch.rs
• B20StablecoinStorage::dispatch_with_observer at dispatch.rs

Several normal successful operations can clear previously nonzero storage before reaching those generic success returns. Examples include:

• Clearing a pending policy admin in storage.rs
• Deleting the pending admin during finalization or renounce at storage.rs
• Deactivating a feature at storage.rs
• Zeroing balances through B20 transfers at transferable.rs
• Zeroing allowances through B20 approvals at transferable.rs
• Full-balance or full-supply burns at burnable.rs

The broken guarantee is that gas refunds accumulated by the storage provider should be propagated into the precompile output so revm can apply them to transaction-level refund accounting under the EIP-3529 cap. Instead, these successful paths can return gas_refunded == 0 even after the provider recorded a valid refund.

Recommendation

We recommend making the generic success path preserve accumulated refunds. One approach is to replace dispatcher success returns with a StorageCtx-aware constructor equivalent to StorageCtx::success_output, or extend IntoPrecompileResult::into_precompile_result to accept and copy the current refund counter into PrecompileOutput.gas_refunded. Add regression tests for at least one dispatcher call that clears a nonzero storage slot and assert that the returned PrecompileOutput.gas_refunded matches the refund accumulated by the provider.

Summary

set_code mutates account bytecode without checking whether the current precompile execution is static.

Finding Description

The EVM storage provider rejects static execution for ordinary state-changing operations, but set_code does not apply the same guard. The guarded sibling mutators are:

• sstore at evm.rs
• tstore at evm.rs
• Event emission

In evm.rs, set_code performs gas accounting and then calls internals.set_code(...).

The in-memory provider mirrors the same behavior: hashmap.rs updates code_hash and code without checking is_static. Generated precompile initialization reaches this path through layout.rs, which installs sentinel bytecode through self.storage.set_code(self.address, bytecode)?.

This breaks the EVM guarantee that a STATICCALL context cannot perform state-changing side effects. Any static-context path that reaches code installation can mutate account bytecode even though surrounding callers expect immutable execution.

Relevant code:

fn set_code(&mut self, address: Address, code: Bytecode) -> Result<()> {    let code_len = code.len();    self.deduct_gas(self.gas_params.code_deposit_cost(code_len))?;    // no self.is_static check before mutation    self.internals        .set_code(address, code)        .map_err(|e| BasePrecompileError::Fatal(e.to_string()))}
fn sstore(&mut self, address: Address, key: U256, value: U256) -> Result<()> {    if self.is_static {        return Err(BasePrecompileError::StaticCallViolation);    }    // ...}

Recommendation

We recommend adding the same static-context guard before any gas charging or code mutation in both storage providers. The guard should match the existing behavior for:

• sstore
• tstore
• emit_event

if self.is_static {    return Err(BasePrecompileError::StaticCallViolation);}

Dynamic storage shrink-overwrites leave stale tail slots

Summary

Dynamic storage writers overwrite only the new logical value and do not clear storage slots that belonged to a previous longer Bytes, String, or Vec<T> value.

Finding Description

Dynamic bytes-like values and vectors use a length field to bound normal typed reads, but the storage writers do not clear retired backing slots when a shorter value replaces a longer one. As a result, obsolete chunks or elements remain in raw storage after the overwrite.

This same issue was already fixed upstream in Tempo in PR #3840, fix(storage): cleanup tail in dyn types, which was merged on May 7, 2026. The Tempo PR describes the same root cause: overwriting a dynamic storable (Vec<T>, String, or Bytes) with a shorter value left stale tail slots populated, and the fix clears stale tails on shrinking writes.

For Bytes and String, store_bytes_like() writes the new base slot and only the chunks required by the new byte length. It never loads the previous encoded length and therefore cannot clear old chunks beyond the new payload.

types/bytes_like.rs#L212-L233

fn store_bytes_like<S: StorageOps>(bytes: &[u8], storage: &mut S, base_slot: U256) -> Result<()> {    let length = bytes.len();    if length <= 31 {        storage.store(base_slot, encode_short_string(bytes))    } else {        storage.store(base_slot, encode_long_string_length(length))?;        let slot_start = calc_data_slot(base_slot);        let chunks = calc_chunks(length);
        for i in 0..chunks {            let slot = slot_start + U256::from(i);            /* writes only the new chunks */            storage.store(slot, U256::from_be_bytes(chunk_bytes))?;        }
        Ok(())    }}

The delete path shows that these long-form chunks are part of the value footprint and are expected to be zeroed when removed:

types/bytes_like.rs#L236-L249

fn delete_bytes_like<S: StorageOps>(storage: &mut S, base_slot: U256) -> Result<()> {    let base_value = storage.load(base_slot)?;    let is_long = is_long_string(base_value);
    if is_long {        let length = calc_string_length(base_value, true)?;        let slot_start = calc_data_slot(base_slot);        let chunks = calc_chunks(length);        for i in 0..chunks {            storage.store(slot_start + U256::from(i), U256::ZERO)?;        }    }
    storage.store(base_slot, U256::ZERO)}

The same pattern exists for vectors. Vec<T>::store() updates the length and writes only the new prefix. Packed vectors write only calc_packed_slot_count(new_len) slots, and unpacked vectors iterate only the new elements.

types/vec.rs#L59-L72

fn store<S: StorageOps>(&self, storage: &mut S, len_slot: U256, ctx: LayoutCtx) -> Result<()> {    debug_assert_eq!(ctx, LayoutCtx::FULL, "Dynamic arrays cannot be packed");
    storage.store(len_slot, U256::from(self.len()))?;    if self.is_empty() {        return Ok(());    }
    let data_start = calc_data_slot(len_slot);    if T::BYTES <= 16 {        store_packed_elements(self, storage, data_start, T::BYTES)    } else {        store_unpacked_elements(self, storage, data_start)    }}

By contrast, Vec<T>::delete() loads the existing length and clears every old packed slot or unpacked element, confirming that ordinary overwrite skips cleanup that deletion performs.

types/vec.rs#L75-L98

let length = load_checked_len(storage, len_slot)?;storage.store(len_slot, U256::ZERO)?;
if T::BYTES <= 16 {    let slot_count = calc_packed_slot_count(length, T::BYTES);    for slot_idx in 0..slot_count {        storage.store(data_start + U256::from(slot_idx), U256::ZERO)?;    }} else {    for elem_idx in 0..length {        let elem_slot = data_start + U256::from(elem_idx * T::SLOTS);        T::delete(storage, elem_slot, LayoutCtx::FULL)?;    }}

Typed reads are length-bounded, so the stale tail is masked when callers read the same type normally. However, the obsolete data remains visible through raw storage access and storage inspection, storage refunds for clearing removed values are missed, and future growth or manual slot use can encounter data that callers would reasonably expect to have been removed when assigning a shorter dynamic value.

Recommendation

We recommend making dynamic store() clear any previously used tail when the new value is shorter than the old value. Bytes-like writers should load the prior encoded length before overwrite and zero old chunks beyond the new chunk count, including long-to-short transitions. Vector writers should load the prior length and clear the range new_len..old_len; packed vectors should zero retired packed slots, while unpacked vectors should call T::delete for retired elements. If needed for efficiency, add an explicit zero-initialized storage context so first writes and appends can skip the old-length read safely.

Summary

Runtime storage layout helpers compute mapping and dynamic-data slots with direct keccak256 calls instead of the gas-charging storage-context hash API. These hashes correspond to storage address derivations that Solidity/EVM bytecode would normally execute through the KECCAK256 opcode, so precompile calls can force internal slot-derivation hashes without paying the corresponding runtime keccak gas.

Finding Description

The storage provider exposes a metered hash primitive. The default provider implementation computes the EVM keccak price and deducts gas before hashing:

/// Computes keccak256 and charges the appropriate gas.fn keccak256(&mut self, data: &[u8]) -> Result<B256> {    let num_words =        u64::try_from(data.len().div_ceil(32)).map_err(|_| BasePrecompileError::OutOfGas)?;    let price = KECCAK256WORD        .checked_mul(num_words)        .and_then(|w| w.checked_add(KECCAK256))        .ok_or(BasePrecompileError::OutOfGas)?;    self.deduct_gas(price)?;    Ok(keccak256(data))}

provider.rs

However, the runtime storage-layout helpers bypass that metered API. StorageKey::mapping_slot derives every mapping element slot by calling alloy_primitives::keccak256 directly after building the 64-byte Solidity mapping preimage:

fn mapping_slot(&self, slot: U256) -> U256 {    let key_bytes = self.as_storage_bytes();    let key_bytes = key_bytes.as_ref();    debug_assert!(key_bytes.len() <= 32);
    let mut buf = [0u8; 64];    buf[32 - key_bytes.len()..32].copy_from_slice(key_bytes);    buf[32..].copy_from_slice(&slot.to_be_bytes::<32>());
    U256::from_be_bytes(keccak256(buf).0)}

provider.rs

MappingHandler reaches this helper whenever a key handler is materialized, including mutable access used by write paths:

pub fn at_mut(&mut self, key: &K) -> &mut V::Handler<'a>where    K: StorageKey + Eq + Clone + Ord,{    let (base_slot, address, storage) = (self.base_slot, self.address, self.storage);    self.cache.get_or_insert_mut(key, || {        V::handle(key.mapping_slot(base_slot), LayoutCtx::FULL, address, storage)    })}

mapping.rs

The same pattern exists for dynamic array data bases. VecHandler computes self.data_slot() before pushing or indexing elements, but calc_data_slot directly hashes the length slot and cannot charge gas because it has no storage context:

let mut elem_slot =    Self::compute_handler(self.data_slot(), self.address, self.storage, length);elem_slot.write(value)?;

#[inline]pub(crate) fn calc_data_slot(len_slot: U256) -> U256 {    U256::from_be_bytes(keccak256(len_slot.to_be_bytes::<32>()).0)}

vec.rs and vec.rs

Bytes-like dynamic values and string mapping keys also use direct hashes for their long-data base or string-key mapping preimage:

fn mapping_slot(&self, slot: U256) -> U256 {    let mut buf = Vec::with_capacity(self.len() + 32);    buf.extend_from_slice(self.as_bytes());    buf.extend_from_slice(&slot.to_be_bytes::<32>());    U256::from_be_bytes(keccak256(buf).0)}

fn calc_data_slot(base_slot: U256) -> U256 {    U256::from_be_bytes(keccak256(base_slot.to_be_bytes::<32>()).0)}

bytes_like.rs and bytes_like.rs

This is reachable from externally controlled precompile inputs. For example, policy membership updates accept an address array, cap it at 64 accounts, and then perform two nested mapping derivations for each account: one for policy_id and one for the account under that policy mapping.

Self::require_account_batch_size(accounts)?;for account in accounts {    if add {        self.members.at_mut(&policy_id).at_mut(account).write(true)?;    } else {        self.members.at_mut(&policy_id).at_mut(account).delete()?;    }}

storage.rs

The dispatch wrapper only charges a separate per-calldata-word fee, using a hardcoded G_SHA3WORD = 6; it does not account for the internal mapping or dynamic-data slot hashes performed after ABI decoding:

macro_rules! deduct_calldata_cost {    ($ctx:expr, $calldata:expr $(,)?) => {{        const G_SHA3WORD: u64 = 6;
        let calldata_len = $calldata.len();        let calldata_cost = calldata_len.div_ceil(32).saturating_mul(G_SHA3WORD as usize) as u64;        if let Err(e) = $ctx.deduct_gas(calldata_cost) {            return e.into_precompile_result($ctx.gas_used(), $ctx.state_gas_used());        }    }};}

macros.rs

As a result, validators perform extra host keccak work that is absent from the reported gas usage. Storage access gas still applies to the eventual SLOAD or SSTORE, but these runtime layout hashes are separate computation and the code already contains a metered keccak primitive for that exact class of work. Calls that touch many distinct mapping keys or dynamic elements therefore undercharge CPU work relative to the number of keccak derivations they force.

This issue is limited to runtime hashes that replace storage address derivations a Solidity contract would normally perform with the KECCAK256 opcode. Compile-time macro hashes, such as literal #[slot("...")] or namespace-root derivation performed during procedural macro expansion, are not part of this claim because they do not execute during a precompile call and would not be EVM-metered at runtime.

Recommendation

We recommend routing storage-layout hash derivation through the metered provider path. For example, add context-aware helpers for mapping-slot and dynamic-data-slot derivation that call StorageCtx::keccak256, then use those helpers from MappingHandler, VecHandler, bytes/string storage, and any generated accessors that materialize dynamic handlers.

Where repeated derivations are unavoidable, cache the derived slot after the first charged computation within the handler. Also replace the hardcoded calldata word charge with a value sourced from the active gas parameters, or document and enforce why calldata-copy charging is intentionally independent from EVM keccak pricing.

Summary

VecHandler bounds-checks at(), but its indexing operators derive writable element handlers for any index without checking the vector length.

Finding Description

VecHandler::at() treats the stored vector length as part of the collection boundary: it reads len_slot and returns None when index >= len.

The Index and IndexMut implementations do not enforce that boundary. Both implementations compute and cache an element handler directly from data_slot and the requested index without reading len_slot. A caller can therefore access handler[index] for an index outside the logical vector and then call write() on the returned handler.

That write stores data at the slot derived for the out-of-bounds index, but it does not update the vector length. The value is unreachable through normal vector reads, can later become visible if the vector grows to that index, and violates the expected behavior of Rust's indexing operator, which should not silently provide mutable access outside the collection bounds.

Affected code:

• crates/common/precompile-storage/src/types/vec.rs#L204-L215
• crates/common/precompile-storage/src/types/vec.rs#L257-L278

Impact Explanation

Impact is Low. This is a storage correctness issue that can create unreachable or stale data in contract storage, but no direct asset-loss path was established from the scoped code.

Likelihood Explanation

Likelihood is Medium. The unsafe path is exposed through normal Rust indexing syntax on a public handler type, while the safe at() helper exists but is not enforced by the type system.

Recommendation

We recommend making the indexing operator enforce the same bounds as at(). Since Index cannot return a Result, either make Index and IndexMut panic on out-of-bounds access after reading len_slot, or remove these trait implementations and require callers to use at() and push() APIs that can return storage errors.

Summary

Stateful native precompiles charge EIP-8037 state-gas through regular gas and return it as reservoir gas, so post-EIP-8037 account/code creation through set_code can be overcharged and misaccounted.

Finding Description

EIP-8037 splits gas accounting into regular gas and state gas. State-gas charges should consume the state-gas reservoir first and only spill into regular gas after the reservoir is exhausted. The upstream revm/alloy path already models this separation: precompile results are converted with Gas::new_with_regular_gas_and_reservoir(gas_limit, output.reservoir), and revm's gas model documents that state-gas charges deduct from the reservoir before spilling into regular gas.

The stateful precompile storage provider drops the reservoir before any precompile storage operation can use it. EvmPrecompileStorageProvider::new destructures PrecompileInput with .., discarding input.reservoir, and initializes a regular-only gas tracker:

pub fn new(input: PrecompileInput<'a>, gas_params: GasParams) -> Self {    let PrecompileInput { gas, caller, is_static, internals, .. } = input;
    Self {        internals,        caller,        gas: Gas::new(gas),        gas_params,        is_static,        state_gas_used: 0,        // ...    }}

set_code then applies EIP-8037 state-gas charges when it installs code for a new account:

if is_new_account {    self.deduct_gas(self.gas_params.create_cost())?;    let num_words = code_len.div_ceil(32) as u64;    self.deduct_gas(KECCAK256.saturating_add(KECCAK256WORD.saturating_mul(num_words)))?;    self.deduct_state_gas(self.gas_params.create_state_gas())?;    self.deduct_state_gas(self.gas_params.code_deposit_state_gas(code_len))?;}

However, deduct_state_gas always spends regular gas and never consults a reservoir. The provider also reports that no reservoir exists:

fn deduct_state_gas(&mut self, gas: u64) -> Result<()> {    // No separate reservoir in the precompile context; state gas is drawn from regular gas.    self.deduct_gas(gas)?;    self.state_gas_used = self.state_gas_used.saturating_add(gas);    Ok(())}
fn reservoir(&self) -> u64 {    0}

The B20 factory reaches this path during token creation. It creates a fresh token account and calls self.storage.set_code(token_address, stub)?, so post-EIP-8037 B20 token creation performs account/code state-gas accounting through this regular-gas-only provider.

The return path also swaps the state-gas and reservoir semantics. IntoPrecompileResult passes state_gas as the third argument to PrecompileOutput::new:

Ok(res) => Ok(PrecompileOutput::new(gas, encode_ok(res), state_gas)),

But PrecompileOutput::new(gas_used, bytes, reservoir) interprets that third argument as the remaining reservoir and initializes state_gas_used to zero. Therefore successful stateful precompile calls can return regular gas that already includes state-gas charges, set the returned reservoir to the amount of state gas used, and leave the actual state_gas_used field unset. This is inconsistent with the EIP-8037 reservoir model and with the revm/alloy precompile result contract.

Impact Explanation

Impact is Medium. Affected stateful precompile calls can consume regular gas for costs that should be absorbed by the EIP-8037 state-gas reservoir, which can reject otherwise valid calls with insufficient regular gas or overstate regular gas consumption. The same calls can also underreport state_gas_used while returning the used state gas as remaining reservoir gas, causing block-level regular/state gas accounting to diverge from the intended EIP-8037 model. No direct asset-loss path was established, so the impact is not High.

Likelihood Explanation

Likelihood is Medium. The bug is deterministic for stateful native precompile paths that perform state creation with a nonzero EIP-8037 reservoir. B20 token creation reaches the affected set_code path for fresh token accounts. The condition depends on post-EIP-8037 execution where a nonzero reservoir is available to the precompile call, so it is not assigned High likelihood for all current executions.

Proof of Concept

The issue follows from the existing accounting path:

1. Execute a post-EIP-8037 stateful precompile call with nonzero PrecompileInput.reservoir.
2. Reach B20 token creation, which calls self.storage.set_code(token_address, stub)? for a fresh account.
3. EvmPrecompileStorageProvider::new discards the input reservoir and creates Gas::new(gas).
4. set_code calls deduct_state_gas(create_state_gas) and deduct_state_gas(code_deposit_state_gas(code_len)).
5. Each deduct_state_gas call invokes deduct_gas, reducing regular gas instead of consuming the reservoir first.
6. The successful result is returned through PrecompileOutput::new(gas, bytes, state_gas), which treats state_gas as remaining reservoir and leaves state_gas_used unset.

A correct implementation would leave regular gas unchanged while the reservoir is sufficient, reduce the reservoir by the state-gas cost, and return the consumed amount through PrecompileOutput.state_gas_used.

Recommendation

We recommend preserving the precompile input reservoir in EvmPrecompileStorageProvider and initializing the provider gas tracker with the same regular-gas/reservoir split used by revm. deduct_state_gas should use reservoir-first semantics equivalent to revm's record_state_cost, and reservoir() should return the actual remaining reservoir.

We recommend fixing precompile result construction so regular gas used, state gas used, and remaining reservoir are separate values. Success and revert helpers should pass the remaining reservoir to PrecompileOutput::new or PrecompileOutput::revert, then explicitly assign out.state_gas_used = ctx.state_gas_used() before returning.

Description

Base's precompile storage layer tracks two gas quantities: regular gas for computational cost, and state gas for the EIP-8037 permanent storage burden. State gas is surfaced from every precompile dispatch via state_gas_used() in the returned PrecompileOutput and flows upward into block-level accounting through block_state_gas_used().

The provider charges state gas asymmetrically. The bug location is the sstore method of EvmPrecompileStorageProvider:

set_code, the factory contract-creation path, charges create_state_gas plus code_deposit_state_gas. Sstore, every storage-slot write performed by a B20 precompile, charges no state gas at all. For a cold zero to non-zero write the dropped charge is 230,000 gas, the dominant component of the operation's true cost of roughly 252,200. The existing test suite covers only the set_code state-gas path, so no test exercises or pins SSTORE state gas, and the omission goes undetected.

This leaves a state that is neither fully on nor fully off, and exactly one of two interpretations must be true:

1. If EIP-8037 state metering is meant to be active for B20 precompiles, which requires precompiles to use the same gas path as the EVM, then sstore is wrong. Every precompile-driven storage-slot creation escapes state-gas accounting. If a per-block state-growth limit is enforced using this counter, B20 SSTOREs that create new slots are not counted against it, allowing a block to create more persistent state than the limit intends. This is a state-bloat and underpricing risk.

2. If state metering is meant to be inactive for these precompiles, consistent with Base hardcoding the reservoir to 0 and documenting that state gas is drawn from regular gas, then set_code is wrong. It should not be charging state gas either, and state_gas_used should be uniformly zero.

The evidence leans toward an accidental omission. State gas is charged in set_code but not in sstore, while the state_gas_used counter remains fully wired into block accounting, and no test pins SSTORE state gas.

Recommendation

Make state-gas accounting uniform across sstore and set_code. The half-on, half-off state must not ship. If metering is intended to be on, restore the SSTORE state-gas charge by adding self.deduct_state_gas(self.gas_params.sstore_state_gas(&s.data))? after the dynamic-gas deduction. If metering is intended to be off, remove the deduct_state_gas calls from set_code so state_gas_used is consistently zero.

If the current divergence is intentional, it would be ideal to document it, as an intentional behavioral divergence from the upstream gas model that is invisible in the code is itself a defect.

Summary

set_code only charges EIP-8037 code-deposit state gas when the target account is completely empty. A user can precompute their deterministic B20 token address, send 1 wei to that address before token creation, and then call the factory. The 1 wei transfer makes the future token account existent while leaving its code empty, so the factory still accepts it but the later precompile stub code deposit skips the required L * CPSB state-gas charge.

Finding Description

EIP-8037 separates account-creation state gas from code-deposit state gas. For CREATE/CREATE2 with bytecode size L, it charges L * CPSB when code is deposited into an already existent account, and (STATE_BYTES_PER_NEW_ACCOUNT + L) * CPSB only when the account leaf is new. The EIP also states that an account with nonzero balance but no code and zero nonce is existent, and that contract creation at that address should charge only the code-deposit component.

The B20 factory gives users a direct way to create this condition. A caller controls the factory salt, and the token address is deterministically derived from (caller, variant, salt). Before calling createB20, the caller can compute the future token address and send 1 wei to it. That transfer creates a balance-only account leaf at the future token address. The account still has an empty code hash, so it passes the factory's deployment check, but it is no longer AccountInfo::is_empty().

The production precompile storage provider does not preserve that distinction. It first loads the account and checks AccountInfo::is_empty(), then charges both EIP-8037 state-gas components only inside that single is_new_account branch:

crates/common/precompile-storage/src/evm.rs#L89-L119

let is_new_account = {    let state_load = self        .internals        .load_account(address)        .map_err(|e| BasePrecompileError::Fatal(e.to_string()))?;    state_load.data.info.is_empty()};
if is_new_account {    self.deduct_state_gas(self.gas_params.create_state_gas())?;    self.deduct_state_gas(self.gas_params.code_deposit_state_gas(code_len))?;}

The in-memory provider mirrors the same behavior, so tests built on it also treat every non-empty account leaf as exempt from code-deposit state gas:

crates/common/precompile-storage/src/hashmap.rs#L89-L100

The reachable production path is B20 token creation. B20FactoryStorage::create_b20 computes a deterministic token address, rejects only accounts with non-empty code, and then writes a one-byte 0xef stub through set_code:

crates/common/precompiles/src/b20_factory/storage.rs#L59-L71

let already_deployed =    self.storage.with_account_info(token_address, |info| Ok(!info.is_empty_code_hash()))?;if already_deployed {    return Err(BasePrecompileError::revert(IB20Factory::TokenAlreadyExists {        token: token_address,    }));}
let checkpoint = self.storage.checkpoint();let stub = Bytecode::new_legacy(Bytes::from_static(&[0xef]));self.storage.set_code(token_address, stub)?;

Therefore, a user can save gas on B20 token creation with this sequence:

1. Choose the variant and salt that will be used for createB20.
2. Compute the deterministic token address derived from (caller, variant, salt).
3. Send 1 wei to that future token address before creation.
4. Call createB20 with the same variant and salt.

The factory accepts the address because the account still has no code. However, because the account now has a nonzero balance, AccountInfo::is_empty() is false. EvmPrecompileStorageProvider::set_code then skips both create_state_gas() and code_deposit_state_gas(1). Skipping create_state_gas() is correct for the existing account leaf; skipping code_deposit_state_gas(1) is not.

Impact Explanation

The impact is Low. The issue is a protocol gas-accounting undercharge rather than unauthorized state mutation, asset loss, or corruption of token balances. A caller can intentionally pay 1 wei to the future token address to make creation cheaper by avoiding the EIP-8037 code-deposit state-gas charge. In the currently reachable B20 factory path, the deposited bytecode is the one-byte 0xef marker, so the missed EIP-8037 charge is bounded to one CPSB unit. With the Amsterdam CPSB value used by the local gas parameters, that is 1,530 state gas per affected code deposit.

Likelihood Explanation

The likelihood is Medium. The path is user-reachable through B20 factory creation because callers control the salt and can precompute the resulting token address. Creating the required state only requires sending 1 wei to that address before calling the factory. It is not expected to affect every token creation because fresh, never-touched addresses still take the is_new_account branch and pay both state-gas components.

Proof of Concept

The attack path is:

1. The caller chooses a salt and variant.
2. The caller computes the future token address using the same deterministic derivation as B20Variant::compute_address(caller, salt).
3. The caller transfers 1 wei to that future address, creating an existent account with empty code.
4. The caller invokes createB20 with the chosen salt and variant.
5. create_b20 checks only !info.is_empty_code_hash(), so the prefunded empty-code account passes.
6. set_code sees AccountInfo::is_empty() == false and skips code_deposit_state_gas(1).

The repository already contains focused tests demonstrating the two relevant provider branches:

crates/common/precompile-storage/src/evm.rs#L305-L341

Run:

RUSTFLAGS='' cargo test -p base-precompile-storage set_code_existing_account_skips_state_gas -- --nocaptureRUSTFLAGS='' cargo test -p base-precompile-storage set_code_new_account_charges_create_and_deposit_state_gas -- --nocapture

Both tests pass. The first confirms that the current provider deliberately leaves state_gas_used() unchanged after set_code is called on an already-initialized account. The second confirms that a brand-new account is charged create_state_gas() + code_deposit_state_gas(code_len). Together with the B20 factory's non-empty-code-only guard, this reproduces the missing code-deposit state-gas component for the 1 wei prefunded empty-code account.

Recommendation

We recommend separating the account-leaf creation charge from the code-deposit charge in set_code. Keep create_state_gas() gated on AccountInfo::is_empty(), but charge code_deposit_state_gas(code_len) whenever non-empty code is written to an account whose current code hash is empty, including existent balance-only accounts. The HashMapStorageProvider should mirror the same rule so tests exercise the production accounting model.

Summary

SetHandler<T> transient methods panic even though the handler trait returns Result.

Finding Description

The shared Handler<T> trait defines transient operations as Result-returning methods at provider.rs:

• t_read
• t_write
• t_delete

SetHandler<T> implements those methods with unimplemented!() at set.rs.

A generic caller using the handler trait can therefore trigger a panic instead of receiving a structured BasePrecompileError or unsupported-operation error. Set and SetHandler are publicly exported from the storage library, making this a public API hazard.

Relevant code:

pub trait Handler<T: Storable> {    fn t_read(&self) -> Result<T>;    fn t_write(&mut self, value: T) -> Result<()>;    fn t_delete(&mut self) -> Result<()>;}
fn t_write(&mut self, _: Set<T>) -> Result<()> {    unimplemented!("Set does not support transient storage")}

Recommendation

We recommend replacing the unimplemented!() stubs with explicit structured errors indicating that transient storage is unsupported for Set<T>.

Description

sstore calls internals.sstore() ,which dirties and warms the slot in the revm journal before charging the static and dynamic SSTORE gas. If either deduct_gas returns OutOfGas, the slot is already written and the provider relies entirely on an outer call-frame rollback to undo it. The provider is not locally atomic on the out-of-gas path, and affordability is checked only after the state transition used to derive the cost.

Today this is masked because Base's stateful precompiles run inside a frame that revm reverts on OutOfGas. That protection is incidental and undocumented: any direct StorageProvider use, or any future intrinsic/handler-invoked path without a surrounding frame, would observe a persisted write for an operation that should have failed.

Tempo carried the identical sstore and fixed it:

• tempoxyz/tempo #2321 — labeled C-Bug / C-audit; description: "gas was deducted after mutating state. If an OOG error occurred mid-operation, partial state changes were already committed, leaving the chain in an inconsistent state."
• tempoxyz/tempo #2329 — merged fix (C-Bug / C-audit) for the observed consequence: a transaction that ran out of gas left a key_authorization write persisted — proving the "outer frame always reverts" assumption does not hold for every path.

Recommendation

Charge SSTORE gas before applying the journal mutation, matching the Tempo fix: compute the cold/warm classification, deduct the static cost (and confirm the cold load is affordable), then write. Base is a new chain with no legacy blocks, so this can be done unconditionally. If revm only exposes the classification through a mutating call, wrap the mutation in a StorageCtx checkpoint and revert it before returning OutOfGas. Add a regression test asserting a gas-failed sstore leaves the slot unchanged and unwarmed.

Description

with_account_info calls load_account and clones the resulting AccountInfo into the callback. load_account populates code_hash but leaves code lazy, so the AccountInfo handed to the callback can carry code: None even when the account holds real bytecode.

The upstream tempo implementation hydrates the code with account.load_code() before invoking the callback, so the bytes are always present:

account.load_code()?;
        f(&account.data.account().info);

Upstream reference: tempoxyz/tempo crates/precompiles/src/storage/evm.rs.

The Base implementation omits that load_code call, which is the deviation. The two production callers, is_initialized and the B20 factory existence check, only read is_empty_code_hash, which depends on code_hash and is correctly populated. No current caller dereferences code, so the bug is latent rather than exploitable. Any future caller, or external consumer of this public trait, that reads info.code would silently observe missing or empty bytecode and behave incorrectly. Omitting the load also skips the cold code load gas that upstream charges, so the precompile may undercharge relative to upstream in some cases.

Recommendation

Hydrate the code before reading the info, matching upstream behavior, so code is always present in the callback and the cold code load gas is charged. Force the load on the account before cloning:

let (info, is_cold) = {    let mut state_load = self        .internals        .load_account(address)        .map_err(|e| BasePrecompileError::Fatal(e.to_string()))?;    state_load.data.load_code()?;    (state_load.data.info.clone(), state_load.is_cold)};

Summary

The production EVM storage provider ignores the checkpoint token supplied by CheckpointGuard::commit() and commits whichever checkpoint is currently at the top of the underlying journal stack.

Finding Description

StorageCtx::checkpoint() returns a guard containing a JournalCheckpoint, and CheckpointGuard::commit() passes that saved token back to the storage provider. This makes the public API appear token-based: committing a guard should commit that guard's checkpoint.

In the production EVM provider, however, the checkpoint argument is intentionally ignored. checkpoint_commit() calls internals.checkpoint_commit(), whose behavior is to pop the current top checkpoint rather than the supplied token.

evm.rs#L261-L268

fn checkpoint(&mut self) -> JournalCheckpoint {    self.internals.checkpoint()}
fn checkpoint_commit(&mut self, _checkpoint: JournalCheckpoint) {    // alloy-evm's checkpoint_commit pops the top checkpoint; the arg is unused.    self.internals.checkpoint_commit();}

The test provider enforces the intended LIFO discipline instead. Its checkpoint_commit() asserts that the supplied checkpoint is the latest snapshot before popping it.

hashmap.rs#L211-L218

fn checkpoint_commit(&mut self, checkpoint: JournalCheckpoint) {    assert_eq!(        checkpoint.journal_i,        self.snapshots.len() - 1,        "out-of-order checkpoint commit (expected top of stack)"    );    self.snapshots.pop();}

This creates a backend mismatch. If nested checkpoint guards are resolved out of order, the production backend commits the latest checkpoint even when the caller commits an older guard. The wrong checkpoint can be committed while the older guard remains active, and a later drop/revert can apply to a different state boundary than the caller intended. The HashMap backend catches this misuse, but production EVM execution does not, so tests can only detect the issue when they exercise the HashMap provider directly.

The same LIFO expectation applies to revert. The production backend forwards the token to checkpoint_revert(), but there is no local assertion that the reverted checkpoint is the active top-of-stack checkpoint.

evm.rs#L270-L272

fn checkpoint_revert(&mut self, checkpoint: JournalCheckpoint) {    self.internals.checkpoint_revert(checkpoint);}

Recommendation

We recommend enforcing LIFO checkpoint usage in EvmPrecompileStorageProvider before committing or reverting. A debug-only stack of active checkpoint identifiers is sufficient to catch API misuse during tests and debug builds while preserving release behavior. The guard should track checkpoint creation and assert that each commit or revert resolves the most recently created checkpoint. Alternatively, redesign the checkpoint API so out-of-order guard resolution is unrepresentable.

Summary

The HashMap storage provider snapshots persistent storage slots and events, but omits transient storage and account/code state that should participate in checkpoint rollback.

Finding Description

HashMapStorageProvider::Snapshot currently stores only internals and events at hashmap.rs. The checkpoint implementation snapshots only those fields at hashmap.rs.

Current snapshot coverage:

Public provider methods mutate omitted state:

• set_code updates account bytecode at hashmap.rs
• tstore updates transient storage at hashmap.rs

These state changes are not restored by HashMap checkpoint rollback even though the production EVM journal should roll them back.

Relevant code:

struct Snapshot {    internals: HashMap<(Address, U256), U256>,    events: HashMap<Address, Vec<LogData>>,}
fn checkpoint(&mut self) -> JournalCheckpoint {    self.snapshots        .push(Snapshot { internals: self.internals.clone(), events: self.events.clone() });    // ...}

Recommendation

We recommend expanding Snapshot to include the omitted mutable fields that are expected to participate in checkpoint atomicity:

• Transient storage
• Account/code state

Do not roll back static mode, gas parameters, gas/state-gas accounting, or operation counters. Those fields should remain outside checkpoint atomicity, and the provider API or tests should document that boundary explicitly.

Summary

Several storage handlers derive child slots with unchecked or saturating U256 arithmetic instead of consistently returning SlotOverflow.

Finding Description

The storage helpers derive child storage slots by adding offsets to a base slot. The crate already defines BasePrecompileError::SlotOverflow, and generated struct-array code uses checked_add() and returns that error when slot arithmetic exceeds U256::MAX.

Other scoped type paths do not follow the same rule:

• Slot::new_at_offset() and Slot::new_at_loc() use saturating_add(), so different overflowing offsets can alias to U256::MAX.
• Primitive array code uses unchecked + on U256.
• VecHandler uses unchecked + on U256.
• Bytes-like data chunk loops use unchecked + on U256.
• SetHandler uses unchecked + on U256.
• The default Storable::delete() path uses unchecked + on U256.

The ruint implementation backing Alloy U256 implements Add as wrapping_add, so overflowed slot derivation can wrap to low storage slots instead of being rejected.

This makes slot derivation inconsistent across the storage abstraction. A layout rooted near U256::MAX, whether by explicit slot selection, namespace root, or derived dynamic data slot, can produce wrapped or saturated child slots and potentially read or write a different storage location than intended.

Affected code:

• slot.rs
• array.rs
• vec.rs
• bytes_like.rs
• provider.rs
• storable_primitives.rs

Relevant code:

slot: base_slot.saturating_add(U256::from_limbs([offset_slots as u64, 0, 0, 0])),
let slot = if T::BYTES <= 16 {    data_start + U256::from(location.offset_slots)} else {    data_start + U256::from(index * T::SLOTS)};
for offset in 0..Self::SLOTS {    storage.store(slot + U256::from(offset), U256::ZERO)?;}

Recommendation

We recommend using checked slot arithmetic consistently for every derived storage slot and returning BasePrecompileError::SlotOverflow on failure. This should include:

• Slot::new_at_offset()
• Slot::new_at_loc()
• Array handlers
• Vector handlers
• Bytes-like chunk loops
• Set position base derivation
• The default multi-slot delete path

Summary

The #[precompile] macro allows an install(address = ...) override to register a precompile at one address while generated dispatch still constructs storage bound to the storage type's canonical contract address.

Finding Description

The #[precompile] macro parses install(address = ...) / install(addr = ...) as an arbitrary install address expression. When present, that expression is used as the key inserted into the EVM PrecompilesMap:

let install = config.install.map(|install| {    let address = install        .address        .map_or_else(|| quote! { <#storage>::ADDRESS }, |address| quote! { #address });
    quote! {        pub fn install(            precompiles: &mut ::alloy_evm::precompiles::PrecompilesMap,            #(#install_arg_defs),*        ) {            precompiles.extend_precompiles(::core::iter::once((                #address,                Self::precompile(#(#install_arg_names),*),            )));        }    }});

precompile.rs#L43-L60

The generated runtime wrapper does not pass that install address into the storage object. It always constructs storage through <Storage>::new(ctx):

pub fn precompile(#(#arg_defs),*) -> ::alloy_evm::precompiles::DynPrecompile {    #macro_path!(#id, |ctx, calldata| {        <#storage>::new(ctx).dispatch(ctx, &calldata #(, #arg_names)*)    })}

precompile.rs#L71-L75

The storage constructor generated by #[contract(addr = ...)] binds the contract address into new() and stores it in self.address. Subsequent initialization and event emission use self.address, not the precompile-map key used by install(address = ...):

pub fn new(storage: ::base_precompile_storage::StorageCtx<'a>) -> Self {    Self::__new(#addr, storage)}
fn __initialize(&mut self) -> ::base_precompile_storage::Result<()> {    let bytecode = ::revm::state::Bytecode::new_legacy(::alloy_primitives::Bytes::from_static(&[0xef]));    self.storage.set_code(self.address, bytecode)?;    Ok(())}
fn emit_event(&mut self, event: impl ::alloy_primitives::IntoLogData) -> ::base_precompile_storage::Result<()> {    self.storage.emit_event(self.address, event.into_log_data())}

layout.rs#L150-L191

As a result, a precompile declared with mismatched values such as #[precompile(install(address = A))] and #[contract(addr = B)] can be installed and called at address A, while the generated storage, bytecode marker, and event emission operate under address B.

Current scoped usage did not show a concrete in-repository #[precompile(install(address = ...))] instantiation with divergent addresses. The issue is therefore an integration hazard in the macro API: the macro accepts an unsafe configuration without enforcing that dispatch identity and storage identity remain the same.

Recommendation

We recommend rejecting mismatched install and storage addresses at macro expansion time, or removing the independent install-address override. If an override is still needed, thread the chosen install address into the generated storage constructor so that the precompile-map key, storage address, bytecode marker, and emitted-event address all derive from the same value.

Summary

Contract-level storage namespaces emit fixed metadata constants into the generated slots module, but the #[contract] field parser does not reserve the source field names that normalize to those constants. A contract field named namespace_id or namespace_root therefore makes the macro generate duplicate NAMESPACE_ID or NAMESPACE_ROOT constants and prevents the storage layout from compiling.

This is a Low severity issue: it can block developers from defining otherwise valid namespace-bearing storage layouts, but the observed impact is compile-time denial of use rather than runtime asset loss.

Finding Description

The #[contract] macro rejects only three exact field names: address, storage, and msg_sender. The comparison is performed against the original source identifier string, before the identifier is normalized into the uppercase constant name used in the generated slots module.

crates/common/precompile-macros/src/contract.rs#L37-L37

pub(crate) const RESERVED: &[&str] = &["address", "storage", "msg_sender"];

crates/common/precompile-macros/src/contract.rs#L106-L110

if RESERVED.contains(&name.to_string().as_str()) {    return Err(syn::Error::new_spanned(        name,        format!("Field name '{name}' is reserved"),    ));}

Field slot constants are generated from the field name by uppercasing it. For example, a field named namespace_id becomes NAMESPACE_ID.

crates/common/precompile-macros/src/packing.rs#L40-L42

pub(crate) fn const_name(name: &Ident) -> String {    name.to_string().to_uppercase()}

When a contract-level namespace is present, the macro emits namespace metadata constants and the field constants into the same generated slots module.

crates/common/precompile-macros/src/layout.rs#L243-L250

quote! {    /// Storage slot indices and packing constants for this contract.    pub mod slots {        use super::*;
        #namespace_constants        #constants

crates/common/precompile-macros/src/layout.rs#L259-L265

quote! {    /// ERC-7201 namespace identifier for this contract storage layout.    pub const NAMESPACE_ID: &str = #id;
    /// ERC-7201 namespace root slot for this contract storage layout.    pub const NAMESPACE_ROOT: ::alloy_primitives::U256 =

As a result, this otherwise normal namespace-bearing layout cannot compile:

#[contract(addr = TEST_ADDR)]#[namespace("collision.test")]pub struct NamespaceCollision {    pub namespace_id: U256,}

The field passes the reserved-name check because "namespace_id" is not in RESERVED, but field constant generation then emits pub const NAMESPACE_ID: U256 = ... into the same module that already contains pub const NAMESPACE_ID: &str = ... for the namespace metadata. The same root cause applies to namespace_root, which normalizes to NAMESPACE_ROOT.

During validation, the related case-sensitive AddRess / ADDRESS hypothesis was not reproduced as a collision with a separate macro-generated reserved constant in slots; the confirmed issue is the namespace metadata collision.

Proof of Concept

1. Check out the audited repository at commit 6ee3da6325e7416812065c58358274a086f9f223.

2. From any working directory outside the repository, create a minimal Rust crate that depends on the local macro and storage crates:

export BASE_REPO=/path/to/basemkdir -p base-macro-collision-poc/srccat > base-macro-collision-poc/Cargo.toml <<EOF[package]name = "base-macro-collision-poc"version = "0.1.0"edition = "2024"
[dependencies]alloy-primitives = { version = "1.5.6", default-features = false }base-precompile-macros = { path = "$BASE_REPO/crates/common/precompile-macros" }base-precompile-storage = { path = "$BASE_REPO/crates/common/precompile-storage", features = ["test-utils"] }revm = { version = "38.0.0", default-features = false }EOF

3. Add a namespace-bearing contract layout with a field named namespace_id:

cat > base-macro-collision-poc/src/lib.rs <<'EOF'use alloy_primitives::{Address, U256, address};use base_precompile_macros::contract;
const TEST_ADDR: Address = address!("0000000000000000000000000000000000001234");
#[contract(addr = TEST_ADDR)]#[namespace("collision.test")]pub struct NamespaceCollision {    pub namespace_id: U256,}EOF

4. Compile the reproduction crate:

RUSTFLAGS= CARGO_ENCODED_RUSTFLAGS= cargo check --manifest-path base-macro-collision-poc/Cargo.toml

The command fails with the duplicate generated constant:

error[E0428]: the name `NAMESPACE_ID` is defined multiple times --> src/lib.rs:7:5  |7 |     #[contract(addr = TEST_ADDR)]  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `NAMESPACE_ID` redefined here  |  = note: `NAMESPACE_ID` must be defined only once in the value namespace of this module  = note: this error originates in the attribute macro `contract`

Recommendation

We recommend reserving every generated slots item name before code generation, using the same normalization logic that produces field constant identifiers. At minimum, reject field identifiers whose generated slot constant is NAMESPACE_ID or NAMESPACE_ROOT when a contract-level namespace is present. A more robust fix is to build a set of all generated item identifiers for each field, including slot, offset, debug byte-size, collision-check, and namespace metadata names, and fail early with a clear syn::Error if any generated names collide.

Summary

The precompile storage macros generate slot constant names by uppercasing field identifiers, but they do not reject field names that collide after this normalization. A storage layout containing case-distinct Rust fields such as foo and FOO therefore reaches macro code generation and fails with duplicate generated constants instead of receiving a deterministic validation error.

Finding Description

The macro layer accepts normal Rust field identifiers and later derives generated slot constant identifiers from a lossy uppercase representation of each field name. PackingConstants::new stores const_name(name), and const_name uppercases the original identifier:

crates/common/precompile-macros/src/packing.rs#L16-L42

impl PackingConstants {    pub(crate) fn new(name: &Ident) -> Self {        Self(const_name(name))    }
    pub(crate) fn slot(&self) -> Ident {        format_ident!("{}", &self.0)    }
    pub(crate) fn offset(&self) -> Ident {        let span = proc_macro2::Span::call_site();        Ident::new(&format!("{}_OFFSET", self.0), span)    }}
pub(crate) fn const_name(name: &Ident) -> String {    name.to_string().to_uppercase()}

Those normalized names are then emitted as public slot and offset constants for every allocated field:

crates/common/precompile-macros/src/packing.rs#L117-L153

for field in fields {    let ty = field.ty;    let consts = PackingConstants::new(field.name);    let (loc_const, (slot_const, offset_const)) = (consts.location(), consts.into_tuple());    // ...    constants.extend(quote! {        #[doc = #slot_doc]        pub const #slot_const: ::alloy_primitives::U256 = #slot_expr;        #[doc = #offset_doc]        pub const #offset_const: usize = #offset_expr;    });

The #[contract] parser only rejects exact reserved field names, so it does not catch case-normalized collisions before code generation:

crates/common/precompile-macros/src/contract.rs#L98-L122

named_fields    .into_iter()    .map(|field| {        let name = field            .ident            .as_ref()            .ok_or_else(|| syn::Error::new_spanned(&field, "Fields must have names"))?;
        if RESERVED.contains(&name.to_string().as_str()) {            return Err(syn::Error::new_spanned(                name,                format!("Field name '{name}' is reserved"),            ));        }

The same packing path is also used by #[derive(Storable)], which copies each original field identifier into FieldInfo and then calls packing::allocate_slots before generating the packing module:

crates/common/precompile-macros/src/storable.rs#L75-L97

for field in fields {    let name = field.ident.as_ref().unwrap().clone();    field_infos.push(FieldInfo {        name: name.clone(),        ty: field.ty.clone(),        slot: None,        base_slot: None,        namespace: None,    });    // ...}
let layout_fields = packing::allocate_slots(&field_infos)?;let packing_module = gen_packing_module_from_ir(&layout_fields, &mod_ident);

A minimal validation harness with a #[contract] storage struct containing both foo and FOO reached macro expansion and failed with Rust duplicate-item errors for the generated constants FOO, FOO_OFFSET, and, in debug builds, FOO_BYTES. This is not a Solidity restriction: Solidity identifiers are case-sensitive, and an otherwise equivalent Solidity contract with foo and FOO state variables compiles successfully. The mismatch matters because these Rust macros are intended to mirror Solidity-style storage layouts, but they impose an additional lossy normalization step on generated constant names. The currently inspected in-scope production storage layouts do not contain such a case-normalized duplicate pair, so the practical impact is limited to a future bad layout causing confusing generated-code compilation failures rather than current runtime storage corruption.

Proof of Concept

The following steps are self-contained except for requiring a checkout of base/base at the audited commit. They show that Solidity accepts case-distinct state variables while the Base Rust storage macro rejects the analogous layout only after generating duplicate constants.

First, check out the audited Base commit and install the Rust toolchain used by the workspace:

git clone https://github.com/base/base.git base-case-collisioncd base-case-collisiongit checkout 6ee3da6325e7416812065c58358274a086f9f223rustup toolchain install 1.94.1

Then compile an equivalent Solidity contract. npx downloads the pinned JavaScript solc package, so no global Solidity compiler install is required:

cat >/tmp/CaseCollision.sol <<'EOF'// SPDX-License-Identifier: MITpragma solidity ^0.8.20;
contract CaseCollision {    uint256 public foo;    uint256 public FOO;}EOF
npx --yes [email protected] --bin /tmp/CaseCollision.sol

This command succeeds, demonstrating that Solidity itself allows foo and FOO as distinct identifiers.

Next, create a minimal Rust crate that depends on the local Base macro and storage crates from the checked-out repository:

BASE_REPO="$(pwd)"POC_DIR="/tmp/base-case-slot-collision-poc"rm -rf "$POC_DIR" /tmp/base-case-slot-collision-poc-targetmkdir -p "$POC_DIR/src"
cat >"$POC_DIR/Cargo.toml" <<EOF[package]name = "base-case-slot-collision-poc"version = "0.1.0"edition = "2024"
[workspace]
[dependencies]revm = "38.0.0"alloy-primitives = { version = "1.5.6", default-features = false }base-precompile-macros = { path = "$BASE_REPO/crates/common/precompile-macros" }base-precompile-storage = { path = "$BASE_REPO/crates/common/precompile-storage" }EOF
cat >"$POC_DIR/src/lib.rs" <<'EOF'use base_precompile_macros::contract;
#[contract]pub struct CaseCollisionStorage {    pub foo: u8,    pub FOO: u8,}EOF

Finally, run the Rust compile check from outside the Base repository so Cargo does not load the repository-local linker configuration:

cd /tmpenv -u RUSTFLAGS -u CARGO_ENCODED_RUSTFLAGS CARGO_TARGET_DIR=/tmp/base-case-slot-collision-poc-target \    cargo +1.94.1 check --manifest-path "$POC_DIR/Cargo.toml"

The Rust command fails with duplicate definitions for FOO, FOO_OFFSET, and FOO_BYTES, all originating from the #[contract] attribute macro:

error[E0428]: the name `FOO` is defined multiple times  = note: this error originates in the attribute macro `contract`
error[E0428]: the name `FOO_OFFSET` is defined multiple times  = note: this error originates in the attribute macro `contract`
error[E0428]: the name `FOO_BYTES` is defined multiple times  = note: this error originates in the attribute macro `contract`

Recommendation

We recommend tracking the normalized constant names during macro parsing and returning a syn::Error when two fields map to the same generated constant prefix. Apply the check to both #[contract] field parsing and #[derive(Storable)] struct parsing, and include both original field names plus the colliding generated prefix in the diagnostic. For example, reject foo and FOO before emitting any slots::FOO, FOO_OFFSET, or packing-module constants.

Summary

EvmPrecompileStorageProvider::set_code contains a misleading EIP-3541 comment: the code only charges bytecode deposit gas and does not enforce EIP-3541's 0xef first-byte rejection. The 0xef marker itself is an intentional privileged precompile-factory marker and is not a protocol violation.

Finding Description

Normal EVM contract creation rejects runtime bytecode whose first byte is 0xef after London. The revm create finalization path performs that validation before depositing code:

// EIP-3541: Reject new contract code starting with the 0xEF byteif !is_eip3541_disabled    && spec_id.is_enabled_in(LONDON)    && interpreter_result.output.first() == Some(&0xEF){    journal.checkpoint_revert(checkpoint);    interpreter_result.result = InstructionResult::CreateContractStartingWithEF;    return;}