Skip to main content
Read log mappings describe how assertions can inspect emitted events and use them as signals for state changes during a transaction.

Status

  • Supported
  • Partially Supported
  • Not Supported Yet

Implementation Details

Required Cheatcodes

  • getLogs()

Example Implementation

Protocol:
Assertion:

Implementation Notes

  • Fetching logs:
    • Use getLogs() to retrieve logs
    • Filter for specific events
    • Decode parameters using abi.decode() to reconstruct event arguments
  • State verification:
    • Use explicit ForkId values with loadStateAt() to compare states
    • Validate state changes match expected behavior based on inputs
  • State tracking considerations:
    • Manually track modified storage slots/keys
    • Consider all functions that modify relevant state variables
    • Account for complex state dependencies between function calls
  • State reconstruction considerations:
    • Manual tracking required for parameter-dependent storage slots (i.e. keys of mappings)
    • No direct access to intermediate call frame states
    • Order guarantees only within same function calls, not across different functions

Example Use Cases

  • Transfer events of ERC20 tokens
  • Ownership changes
  • Whenever a log is emitted, which represents a state change, it can be used to reconstruct the expected behavior

Implementation Considerations

  1. Parameter-dependent Storage Access
    • Storage slots that depend on event parameters lack automated tracking
    • Example: Mapping keys derived from event parameters
    • Workaround: Manual tracking required, but introduces overhead
  2. Requirement of events to be emitted
    • If it is not certain that the event is emitted upon state change, the state change is not tracked
    • Might result in false negatives

Future Improvements