> For the complete documentation index, see [llms.txt](https://adrena.gitbook.io/adrena/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://adrena.gitbook.io/adrena/technical-documentation/mrsablier-and-mrsablierstaking-open-source-keepers.md).

# MrSablier & MrSablierStaking (Open Source Keepers)

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**](http://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**](http://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).

{% hint style="info" %}
We do not use Keeper for user-facing endpoint operations, such as position opening/closing, for instance. **Atomic instructions**™️
{% endhint %}

### 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://adrena.gitbook.io/adrena/technical-documentation/mrsablier-and-mrsablierstaking-open-source-keepers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.