Matador Docs
DeFi Automation

What are Keeper Rails?

Understanding the architecture of safe automation.

Concept: Keeper Rails

In traditional DeFi automation, you give a bot a private key with full permissions (or isOperator status). If the bot is hacked or bugs out, it can drain funds or execute bad trades.

Keeper Rails invert this model. Instead of giving the bot authority, you give it a bounded mandate.

The Architecture

A "Keeper Rail" consists of three components working in tandem:

  1. The Trigger (Off-Chain): Your bot or script that monitors the chain (e.g., "Is price < X?").
  2. The Policy (On-Chain): A Matador policy that defines exactly what the bot is allowed to do.
  3. The Interpreter (On-Chain): The Matador contract that enforces the policy during execution.

Visualizing the Flow

sequenceDiagram
    participant Bot as Keeper Bot
    participant Matador as Matador Interpreter
    participant Policy as Policy Module
    participant DeFi as DeFi Protocol (Uniswap/Aave)

    Bot->>Matador: execute(target, data, auth)
    Matador->>Policy: check(Pre-Execution)
    
    alt Policy Denies
        Policy-->>Matador: REVERT "Slippage too high"
        Matador-->>Bot: Tx Fails
    else Policy Allows
        Matador->>DeFi: call(target, data)
        DeFi-->>Matador: return data
        Matador->>Policy: check(Post-Execution)
        
        alt Invariant Violated
            Policy-->>Matador: REVERT "Health Factor < 1.5"
            Matador-->>Bot: Tx Fails
        else Invariant OK
            Matador-->>Bot: Success
        end
    end

Policy Components

A Keeper Rail policy typically enforces three layers of safety:

1. Scope (The "Where")

Restricts interaction to specific contracts.

  • Example: "Only call UniswapV3Router at address 0xE592...".

2. Constraints (The "How")

Validates the parameters of the function call.

  • Example: "The recipient argument in swap() must be address(this)".
  • Example: "amountIn must be < 10 ETH".

3. State Invariants (The "Result")

Checks the outcome of the transaction.

  • Example: "After the swap, my token balance must be > minAmount".
  • Example: "The pool price must not deviate > 1%".

Why This Matters

FeatureTraditional BotBot with Keeper Rails
Trust ModelTrust the bot key completely.Trust the on-chain policy.
Risk SurfaceInfinite (can drain all funds).Bounded (can only execute specific logic).
UpgradeabilityHard (must redeploy bot/contract).Easy (update policy on-chain).
MonitoringPost-mortem (check logs after hack).Preventive (tx reverts before harm).

Next Steps

Now that you understand the concept, let's look at the lifecycle of a transaction.

Read Execution Lifecycle →

On this page