🤖On-chain Automation Instead of Keepers

Adrena automates recurring tasks on-chain rather than using keepers. On chain automation is a glorified Keeper, but with a more robust interface, and a better separation of concerns.

Keepers, position opening and liquidations

First, what do we call a keeper?

To explain this, we can use the Push/Pull analogy for on-chain programs. Each on-chain program has a specific API, and all actions are PULL-based, meaning that someone needs to call an endpoint to trigger the associated logic, which can be either read-only or read-write.

Most of the endpoints (instructions, IX) of an on-chain program are designed to be called by users on demand, with some restricted to specific subgroups of users if permissioned.

However, there are actions that are more related to upkeep than actual user actions. For example, updating the funding rate, cranking the stake epoch, or performing side effects actions after another IX has been called.

This requires periodic or programmed program invocations, where off-chain services run and periodically call specific endpoints at a given interval or depending on specific conditions.

Keepers or on-chain cron?

There are services like Clockwork and Switchboard that allow for on-chain planning and control over "off-chain keeper" services. Essentially, you can use your program to control the creation and define rules for these "cron" to run.

Behind the scenes, these protocols run "Keepers" for their users, often in a more robust and decentralised manner than if the projects themselves were running the keepers. The philosophy behind using these services is to delegate the challenging tasks of uptime and reliability to them, as it is their core competency and mission.

Another benefit is that your program can handle all the setup details itself, without the need for intervention from the team or manual operator work, making it very sturdy and bamboozle-free.

However, the downside is the additional complexity and effort required to implement this approach.

Keeper usage related to user facing endpoints (IX)

Jup.ag (and others) use keepers to process user requests. Users submit a request to open a position, the intent is then picked up by the keeper who process any incoming request, and bundle the necessary tx interacting with Jup.ag swap then perps. This introduces a reliance on off-chain keepers.

In the case of Adrena, we don’t rely on keepers for all users actions, the user interacts directly with the contract without additional middleman.

We do not use Keeper for user-facing endpoint operations, such as position opening, for instance.

Keeper usage related to liquidation engine

Liquidation occurs when the posted collateral becomes insufficient due to a decrease in its price, or if the borrow (funding) slowly erodes it.

A platform that allows leveraging of user positions must consistently monitor these parameters for each position, as well as track all positions. This is necessary to promptly liquidate positions based on the aforementioned conditions. Time is crucial in order to avoid accumulating bad debt for the platform, which would then need to be paid by all participants.

To accomplish this, almost all platforms (including Adrena at launch) utilize keepers, which are off-chain services responsible for monitoring and periodically verifying the status of open positions.

BUT we are working on getting this on-chain by offloading the “keeper” burden to platforms like Clockwork or Switchboard. Our liquidation would then be a clockwork thread opened at position creation, that verify when the liquidation should occur based on borrow_rate and collateral_price.

Currently, we utilise traditional Keeper, which is run and managed off-chain by us. However, our intention is to transition to a fully on-chain system using Clockwork.

Initially, the plan was to make this transition directly. Unfortunately, Clockwork halted their project midway, causing a delay in our progress. We have been actively seeking a highly skilled engineer to maintain the system and coordinate with other projects that recognise the value of Clockwork, in order to synchronise our efforts.

Keeper usage related to staking

To avoid using a cranking mechanism, all automation-related features related to staking (ALP and ADX) are managed using Clockwork threads.

For example, the end of each staking round, where rewards are distributed, is handled by a staking thread on Clockwork. This thread periodically performs the required calculations and commits the results on the chain.

Another example is the locked staking accounts of users. Their state is updated by a single execution clockwork thread at the end of the period. This delayed execution is scheduled at the creation of the locked stake.

All automation related to staking is defined and setup on-chain, in the program. The periodical calls are made on chain by Clockwork thread, making the system robust as long as there are Clockwork validator running.

You can find more granular information about the Clockwork threads on the following page Sablier Automation Threads