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

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

Next Steps

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

Read Execution Lifecycle →