See also EOF Fusaka Options. This proposal aims to improve the EVM by adding valuable functionality while minimizing breakage. It recognizes the most likely outcome that EOF will indefinitely coexist with Legacy EVM, and as a result does not attempt to remove abilities that EOF contracts would nonetheless be able to work around. General Arguments for EOF Structured containers are a better foundation for tooling than unstructured bytecode and unreliable heuristics. Structured control flow is significantly better for static analysis. Stack and code validation at deploy time reduce EVM runtime overhead. Higher level constructs (functions, subcontainers, data), relative jumps, and expanded stack access make compilers simpler and easier to implement. Instructions with immediates can provide rich functionality efficiently. (Some disagree that immediates require EOF.)

EOF introduces new stack instructions with immediate operands: DUPN, SWAPN, and EXCHANGE. The operands determine what elements of the stack will be accessed and manipulated. There's no standard or obvious way in which these operands should be represented in human-readable assembly syntax, and different developers may come up with different solutions. If this ends up being subtly different across different tools (e.g., off by one), an assembly instruction may have different behavior depending on the syntax variant it's read as, and people or tools may be misled, which could be used to conceal malicious behavior in the worst case. Additionally, lack of clarity in communication about these opcodes could result in bugs in various places. Because of this, we should standardize the representation of the operands of each of these instructions. I'll describe three alternative approaches: Verbatim: The operands are written in assembly with the same numerical value that is present in the bytecode, probably as a decimal number. Traditional: The operands are written in a way that matches the numeration used in the original DUP* and SWAP* instructions.

ERC-721 & ERC-1155 need "ISCONTRACT" Token transfers in the two main NFT standards behave differently when the receiver is a contract. In that case, the token invokes a callback on the receiver (e.g., onERC721Received), and unless a specific value is returned from the callback the transfer is reverted. This is mandated by the specifications. The purpose is to prevent the loss of tokens transferred to contracts that are not able to handle them. This is compatible with account abstraction, but smart contract wallets must implement the callback to declare that they're able to handle the token (e.g., see Safe). Status under EOF It's not possible to use EXTCODESIZE or EXTCODEHASH in EOFv1, so there's no "native" way to implement this behavior. The currently proposed solution is to work around the limitation by dispatching to an auxiliary Legacy contract that uses EXTCODESIZE.