EIP-2930 lets transactions predeclare addresses and storage keys. The word access does not make the list an authorisation boundary.

What the source establishes

EIP-2930 introduces a transaction type containing an access list of addresses and storage keys. The specification says that accesses outside the list remain possible, while listed entries are treated according to the defined gas-accounting rules. It sets an initial charge of 2,400 gas per address and 1,900 per storage key. Ethereum Improvement Proposals — EIP-2930 Optional access lists ↗

The specification permits duplicate entries but charges for them repeatedly. These are properties of the access-list transaction format; they do not describe a user-permission or account-authority list. Ethereum Improvement Proposals — EIP-2930 Optional access lists ↗

What the distinction changes

An application that labels an access list as the only contracts this transaction can touch would imply a security guarantee the mechanism does not provide. The list concerns expected state access and charging, while contract code and execution determine the transaction’s actual behaviour.

Likewise, an access list is not automatically a cost saving. Its upfront charges and the actual execution path must be assessed together. A longer list may be redundant or poorly matched to the transaction, even when it is syntactically valid.

Questions for the next review

Distinguish simulation output, access-list entries and granted token approvals in the interface. Evaluate costs against the relevant network rules and execution trace. Any claim about restricted behaviour needs a separate enforcing mechanism; it should not be inferred from the access-list label.