EEVM.Handler.PostExecution (eevm v0.1.0)

Copy Markdown View Source

Steps 9-11 of the transaction pipeline:

  • Settle gas refund — the sender was debited gas_limit * effective_price upfront. They actually owe gas_used * effective_price. Refund the difference. On a successful tx the refund lands in the EVM-side db (which already reflects every side effect); on revert / out-of-gas / invalid it lands in the post-upfront, post-nonce-bump db, which also holds any EIP-7702 delegations (since EVM mutations are dropped).

  • Coinbase reward — credit the block proposer (effective_price - basefee) * gas_used.

  • Build receipt + result — produce the EEVM.TransactionResult struct that callers consume.

Summary

Functions

Maps the interpreter's final machine status to the public status of EEVM.CallResult and EEVM.TransactionResult.

Functions

finalize(final_state, contract_address, tx, sender, db_nonce_bumped, block, gas_paid)

Settle gas, credit the coinbase, and build the EEVM.TransactionResult.

The database argument is the state after upfront charging, the nonce bump, and EIP-7702 authorizations; settlement starts from it when execution failed.

gas_paid is the wei the sender actually paid upfront for gas, without the blob fee. The refund of unused gas, and then the coinbase's tip, are capped by it, so settlement never pays out more than was paid in. For a transaction under consensus rules it is gas_limit * effective_price and the caps never bind; under the disable_balance_check simulation switch the sender may have paid less.

status(arg1)

Maps the interpreter's final machine status to the public status of EEVM.CallResult and EEVM.TransactionResult.

Examples

iex> EEVM.Handler.PostExecution.status(:stopped)
:success
iex> EEVM.Handler.PostExecution.status(:invalid)
{:halt, :invalid_opcode}