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.