Cron Keeper¶

A cron keeper is the simplest example of time-based automation.

The important boundary is that the chain does not produce ticks by itself. Something off-chain has to watch the clock and submit each tick as a wallet-funded transaction.

Contract and service split¶

Contract¶

• stores the schedule or job configuration
• decides what each tick means
• records whether a tick has already been handled
• applies the durable state change once the response is accepted

Service¶

• receives the tick request
• checks what action should happen for that tick
• emits the contract call that should be executed
• uses ordinary service response consensus before anything lands on-chain

How it works¶

1. A bot, backend, cron job, or operator process watches the clock.
2. When the scheduled time arrives, it submits a transaction that requests the cron keeper service.
3. Validators execute the service and compare its response.
4. Once quorum agrees, the target contract executes and records the result.

Concepts introduced¶

External scheduler¶

Something outside the chain has to watch the clock and submit each tick request.

That could be:

• an application backend
• a simple cron job
• a dedicated keeper bot
• a user-run automation process

This document does not assume protocol-native timers.

Repeated requests¶

Cron-like automation naturally produces many requests over time. The default (service, request-id) aggregation usually works well here because each tick is distinct.

Exact-match consensus¶

A cron keeper often uses exact-match because validators should agree on the same contract payload for a given tick.

Contract-owned state¶

The contract owns the durable schedule state and decides whether a tick is still valid.