Keeper

An automated off-chain agent that watches a protocol for pending order requests and submits the on-chain transaction that executes them once the conditions are met.

Definition

A keeper is the party that presses the button a smart contract cannot press for itself. Contracts do not run on a schedule and cannot react to a price on their own; something outside has to notice the condition and send a transaction. Keepers do that, and are compensated for it.

Why the design exists

It splits an order into a request and an execution. You submit an intent, and a keeper executes it once the price qualifies, often against an oracle price fixed at execution rather than at submission.

That structure is what makes limit orders, stop-losses and delayed execution possible on protocols that have no order book to hold a resting order.

What it means for you as a trader

Execution is not instant. There is a delay between your request and the transaction landing, and the price used is the one at execution.

It also introduces a dependency. If keepers are offline, congested, or the network is busy, orders sit unexecuted precisely when markets are moving fastest. Protocols run redundant keepers for exactly this reason, but the dependency does not disappear.

And it is not free. Keeper compensation is part of the execution cost of the order, alongside the trading fee and any price impact.

What a keeper cannot do

A keeper acts only within what the contract permits: it executes requests you have already signed, at conditions the contract checks. It cannot invent an order, and it cannot move funds outside those rules.

Where you will run into it

On pool-based perpetual protocols with a two-step order model, in the execution fee line of an order ticket, and in the delay between confirming a trade and seeing the position appear.