How-to: The Keeper Execution Lifecycle

Understanding the lifecycle of a Matador-guarded transaction is critical for designing effective policies. It differs from standard execution because validation happens twice: before and after the action.

Step 1: Pre-Flight (Intent Validation)

Before any external code runs, Matador validates the intent of the transaction against the policy. This is your first line of defense.

• Authentication: Is msg.sender a recognized Keeper for this policy?
• Target Whitelisting: Is the to address allowed (e.g., Uniswap Router)?
• Selector Whitelisting: Is the function signature allowed (e.g., exactInputSingle)?
• Argument Validation: Do the call arguments meet constraints (e.g., amountIn < cap)?

Outcome: If any check fails, the transaction reverts immediately. No external state is touched.

Step 2: Execution (The Action)

If Pre-Flight passes, the Interpreter performs the actual call to the target protocol using the Smart Account's context.

• Tokens move.
• Swaps happen.
• State changes.

Step 3: Post-Call Review (Integration-Dependent)

Some integrations may bind callable policy checks after a target call returns. When that binding is present, state-aware checks can verify the result. Without that explicit binding, a normal fn main() -> bool policy should be read as the pre-call enforcement path.

• Invariant Verification: Did the vault's balance increase as expected?
• Health Check: Is the collateral ratio safe?
• Oracle Sanity: Did the on-chain price deviate too much during execution?

Outcome: If an integration runs a post-call check and that check fails, the operation should revert atomically. Document the binding explicitly when a policy depends on this phase.

Next Steps

Ready to implement this? Choose a recipe:

• Recipe: Uniswap V3 Delta Rebalance
• Recipe: Aave Health Factor Guard