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:
- The Trigger (Off-Chain): Your bot or script that monitors the chain (e.g., "Is price < X?").
- The Policy (On-Chain): A Matador policy that defines exactly what the bot is allowed to do.
- 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
endPolicy Components
A Keeper Rail policy typically enforces three layers of safety:
1. Scope (The "Where")
Restricts interaction to specific contracts.
- Example: "Only call
UniswapV3Routerat address0xE592...".
2. Constraints (The "How")
Validates the parameters of the function call.
- Example: "The
recipientargument inswap()must beaddress(this)". - Example: "
amountInmust 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
| Feature | Traditional Bot | Bot with Keeper Rails |
|---|---|---|
| Trust Model | Trust the bot key completely. | Trust the on-chain policy. |
| Risk Surface | Infinite (can drain all funds). | Bounded (can only execute specific logic). |
| Upgradeability | Hard (must redeploy bot/contract). | Easy (update policy on-chain). |
| Monitoring | Post-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.