Update EIP-5920: PAY Opcode Recipient Address

Merged by EIP-Bot.

EIPS/eip-5920.md

@@ -43,8 +43,10 @@ Currently, to send ether to an address requires you to call into that address, w
 A new opcode is introduced: `PAY` (`0xfc`), which:
 
 - Pops two values from the stack: `addr` then `val`.
+- Charges the gas cost detailed below.
+- Exceptionally halts if `addr` has any of the high 12 bytes set to a non-zero value (i.e. it does not contain a 20-byte address).
 - Transfers `val` wei from the current target address to the address `addr`.
-- Marks `addr` as warm (adding `addr` to `accessed_addresses`.)
+- Marks `addr` as warm (adding `addr` to `accessed_addresses`).
 
 ### Gas Cost
 
@@ -60,14 +62,22 @@ The gas cost for `PAY` is the sum of the following:
     - If yes, zero;
     - Otherwise, `GAS_CALL_VALUE`.
 
-`PAY` cannot be implemented on networks with empty accounts (see [EIP-7523](./eip-7523.md).)
+`PAY` cannot be implemented on networks with empty accounts (see [EIP-7523](./eip-7523.md)).
 
 ## Rationale
 
 ### Argument order
 
 The order of arguments mimics that of `CALL`, which pops `addr` before `val`. Beyond consistency, though, this ordering aids validators pattern-matching MEV opportunities, so `PAY` always appears immediately after `COINBASE`.
 
+### Halting for invalid address
+
+The halting behavior is designed to allow for Address Space Extension.
+If the high bytes were truncated, as in `CALL`, contracts could depend on the truncating behavior.
+If the address space were extended beyond 20 bytes, `PAY` would either not be able to target those accounts, or code expecting truncation could send ether to the wrong address.
+
+Because this behavior may be changed, contracts should not rely on this halting behavior and use other methods to intentionally halt (like the cheaper `INVALID` opcode).
+
 ## Backwards Compatibility
 
 This change requires a hard fork.