Skip to main content
Function call input mappings describe how assertions can inspect call data for a target function and compare the resulting state transition against expected behavior.

Status

  • Supported
  • Partially Supported
  • Not Supported Yet

Implementation Details

Required Cheatcodes

  • getCallInputs(address aa, bytes4 signature)
  • loadStateAt(address target, bytes32 slot, ForkId fork)

Example Implementation

Protocol:
Assertion:

Implementation Notes

  • Function input reconstruction:
    • Use getCallInputs() to retrieve call data for target function
    • Decode parameters using abi.decode() to reconstruct function 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

  • Balance mappings of tokens or deposits/withdrawals
  • Ownership changes

Implementation Considerations

  1. Parameter-dependent Storage Access
    • Storage slots that depend on function parameters lack automated tracking
    • Example: Mapping keys derived from function parameters
    • Workaround: Manual tracking required, but introduces overhead
  2. Transaction-wide State Verification
    • Complete transaction verification requires:
      • Guaranteed execution order of captured call inputs
      • Accurate reconstruction of expected state changes
      • No direct access to intermediate call frame states
  3. Cross-function Dependencies
    • Call inputs are ordered by execution only within individual functions
    • No guaranteed ordering between different function calls
    • State validation becomes ambiguous when behavior depends on cross-function interaction
      • i.e. (approve() -> transferFrom()) has to be considered as a whole

Future Improvements

  • Provide ordering guarantees between different function selectors
  • Provide direct access to intermediate call frame states (This would allow for partial state verification)
  • Automated tracking of changed slots/keys of mappings