Who uses smart contract automation?

DeFi protocols, yield vaults and prediction markets whose contracts need recurring or event-driven calls to keep working.

Goldsky

Smart contract automation and keepers

Talk to our team

What is smart contract automation?

Smart contract automation is making the contract calls a protocol needs on a schedule or in response to an onchain event, such as harvesting yield, rebalancing or settling; the bots that make these calls are called keepers.

DeFi protocols and prediction markets run keepers because a contract can’t call itself, and a missed call leaves a harvest, rebalance or settlement late.

Goldsky Compose runs each keeper as a TypeScript task started by a cron schedule or a watched contract event, and sends the call from a wallet the task controls; what to call, and when, stays with you.

How a keeper wakes up and calls the contract

The diagram follows one keeper run, from the schedule or event that starts it to the call landing onchain, and shows who does each step. Your setup may differ.

Decide what to callContracts, timing and the keeper role

ComposeRun on a scheduleAt each harvest or rebalance time

ComposeRun on an eventWhen a watched contract emits it

ComposeCall the contractSimulated first, then sent

Protocol stays on timeHarvests, rebalances and settlements land

ComposeTrace every runEach call logged with its outcome

Goldsky

Decide what needs calling and when
A contract only acts when something calls it, so every recurring job needs a caller and a rule.
List each function, what makes it due (a time, such as a daily harvest, or an event, such as a new deposit) and the condition that makes the call worth sending. Vague rules produce calls that waste gas or miss their window.
Grant the keeper’s address its role
Many keeper functions are restricted, so the contract has to recognize the keeper’s address.
Grant only the role the keeper needs. A keeper with admin rights turns a bug in its code into a bug that can change anything in the contract.
Run on a schedule
Handled by Goldsky Compose
Harvests, rebalances and settlements often fall due at fixed times.
The schedule has to fire on time, every time. If a run is still going when the next one starts, both can send the same call, so each run should check whether the work is already done.
A Compose cron trigger starts the task from a standard cron expression, and a six-field expression adds seconds when you need them. Moving from Gelato Web3 Functions? Its cron and interval triggers both become cron expressions in Compose.
Set up a cron trigger (opens in a new tab)
Run when a contract emits an event
Handled by Goldsky Compose
Some calls fall due when something happens on a contract, such as a deposit that needs routing.
Acting on an event from a block that’s later replaced means calling for something that never happened. Holding each event until its block is a few blocks deep avoids that, at the cost of a short delay.
With Goldsky, an onchain_event trigger runs the task for each matching log from the contract you name. Setting confirmations holds each event until its block is deep enough; it needs parallel_processing: true, which runs events side by side and gives up block order.
Trigger a task from contract events (opens in a new tab)
Simulate the call, then send it
Handled by Goldsky Compose
A call that would fail still costs gas, so keepers check before sending.
Simulating the call against current state shows whether it would revert. Sending without that check spends gas on calls that were never going to work, and retrying blindly repeats the loss.
Compose wallets have simulate and writeContract. The write waits for the confirmations you set, and onReorg with replay resends it if a reorg removes it later.
Learn about Compose wallets (opens in a new tab)
Land the call onchain
The protocol’s state moves forward once the call is included and final.
Once included, the harvest, rebalance or settlement is visible to everyone. A call that was dropped, or undone when the chain replaced its newest blocks, leaves the protocol behind until a later run catches up.
Trace every run
Handled by Goldsky Compose
When a call is late or fails, you need to see what the keeper saw and did.
Each run’s trigger, reads, simulations and transactions should be kept together. Without them, a missed harvest is a guess about which part failed.
Goldsky logs every context call a task makes, and each call retries on the settings you give it before the task itself retries.
How retries and logging work (opens in a new tab)