🤖MrSablier & MrSablierStaking (Open Source Keepers)

Adrena switched from its initial Clockwork fork "Sablier" that was too heavy to maintain and not reliable to a new set of gRPC Triton Yellowstone clients.

The code of the open source MrSablier gRPC rust client is available on github at https://github.com/AdrenaFoundation/MrSablier/tree/main

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. (Liquidation, SL, TP...)

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.

Keeper usage related to user facing endpoints (IX)

Jup.ag 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 slight latency that is used as protection against arbitrages.

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, giving that #OPOS speed. The protection against oracle arbitrage is done through using worse price for collateral valuation (not trade prices).

We do not use Keeper for user-facing endpoint operations, such as position opening/closing, for instance. Atomic instructions™️

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.

Keeper usage related to automated orders

Stop loss, take profits (and future other types of limit order and such) are handled by our open source keeper MrSablier.

Keeper usage related to staking

At the end of each staking round, where rewards are distributed, a permissionless instruction is called by MrSablierStaking.

Another example is the locked staking accounts of users, or periodical auto-claim on behalf of users every ~7 days.