Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7650: Programmable access lists

Add a precompiled contract that add access lists programmatically

Authors Qi Zhou (@qizhou), Zhiqiang Xu (@zhiqiangxu)
Created 2024-03-10
Discussion Link
Requires EIP-2929, EIP-2930


We introduce a new precompiled contract named prefetch, which accepts an accessList.

The accessList specifies a list of addresses and local storage keys; these addresses and local storage keys are added into the accessed_addresses and accessed_storage_keys global sets (introduced in EIP-2929). Similar to EIP-2930, prefetching data through this precompile incurs a gas charge, albeit at a reduced rate compared to accesses made outside of this list.


The primary goal of this EIP is to enhance EIP-2930 by enabling contracts to add access lists programmatically. The advantage of implementing this precompile within a contract is the sustained reduction in gas costs for data access operations, leveraging the concurrent computing and IOs that most nodes have.


The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.


Constant Value

As of FORK_BLOCK_NUMBER, a new precompile is deployed at PREFETCH_PRECOMPILE_ADDRESS. The encoding of the precompile input is the following:

[32 bytes for local storage key length n][n * 32 bytes local storage keys][32 bytes for address length m][m * 32 bytes addresses]

At the beginning of the call, we will charge 2100 * (N + CONCURRENCY - 1) // CONCURRENCY + 2600 * (M + CONCURRENCY - 1) // CONCURRENCY, where // is the integer division operator, N is the number of local storage keys not in accessed_storage_keys global set, and M is the number of addresses not in accessed_addresses global set. The client should concurrently read the keys and addresses and put the keys and addresses into the accessed_addresses and accessed_storage_keys global sets. The following read cost of the storage keys and addresses obeys WARM_STORAGE_READ_COST as defined in EIP-2929.


Using UniswapV2 swap() function as an example:

    // this low-level function should be called from a contract which performs important safety checks
    function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
        prefetch {
        } // add the storage keys `accessed_storage_keys`
        prefetch {
        } // add the contracts of token0 and token1 to `accessed_addresses`


Charging less for accesses in the access list

Similar to EIP-2930, we encourage contract developers to use the prefetch precompile as much as possible, especially assuming the nodes have some decent concurrent capabilities (e.g., some cores and IO bandwidth).

Allowing duplicates

Similar to EIP-2930, we allow duplicates in the list to maximize simplicity.

No storage keys for external contract

Unlike EIP-2930, the prefetch precompile only accepts local storage keys and addresses. Prefetching the data of the storage keys of external contracts assumes that the contract knows the storage layout of an external contract, which may not be a good practice. To better employ the concurrency of a node, the precompile may accept a list of static calls of external contracts together with the calldata. This work may be done in the future EIP.

Backwards Compatibility

If the EIP is not yet implemented, a contract calling the precompile should result in no operation.

Security Considerations

No security considerations were found.

Copyright and related rights waived via CC0.


Please cite this document as:

Qi Zhou (@qizhou), Zhiqiang Xu (@zhiqiangxu), "EIP-7650: Programmable access lists [DRAFT]," Ethereum Improvement Proposals, no. 7650, March 2024. [Online serial]. Available: