2 of 7

EOF abstracts gas

The GAS opcode is disabled
Opcodes with gas params are disabled

CALL
STATICCALL
DELEGATECALL
CALLCODE

3 of 7

G_CALLSTIPEND rationale

Solidity passes 0 gas for transfer() and send()
The call stipend is enough to LOG3 or TSTORE, but not enough to SSTORE or G_CALLVALUE

This protects against unexpected side-effects for simple eth transfers (e.g. re-entrancy)

Gas-restricted transfers are also safe against gas-griefing vectors

“The purpose of the stipend is to have enough gas to emit logs (i.e. perform non-state-changing operations) when a contract wallet is called. The stipend is only added when the CALL instruction is used and the value is non-zero.” - EIP-7069

4 of 7

EXTCALL cannot restrict gas

Currently EXTCALL is the only way to transfer ether in EOF
EOF cannot send ether without allowing griefing and re-entrancy

including Solidity transfer() and send()

The EOF workaround is to proxy the transfer through a legacy contract

5f5f5f5f345f355ff1600f575f5ffd5b00
Please don’t make anyone do this

EOF ether transfers are less secure than EVM ether transfers are today

5 of 7

PAY belongs in the same fork as EOF

Insecure ether transfer could obsolete ether payments in favor of safer alternatives like ERC20
PAY has no gas parameter
PAY recipient supports future Address Space Extension
PAY has the same sender-side security as CALL with 0 gas

G_CALLSTIPEND remains obsolete (no recipient execution context)
Safe against reentrancy
Safe against griefing

Solidity transfer() and send() can be implemented in EOF with PAY

6 of 7

Common Objection: right to reject ether

PAY makes it easy to send ether to an account without its consent
Previous ways to do this:

SELFDESTRUCT

Current ways to do this:

SELFDESTRUCT in the same transaction
Priority fees
Beacon withdrawal

7 of 7

Thank you for your time