microwavedcola1 / keeper Goto Github PK

Background:

1. We want to be able to get keepers to execute a function reliably every 5s: That's the minimum interval for Mango's price cache update. Possibly faster intervals should be supported, but "every 12 slots" seems hard already.
2. We want to pay somewhere between 1-2x tx-fee for running the function: If the keeper executes 17k times per day that's 0.085 SOL in transaction fees.
3. We want have multiple keepers sustainably provide the service, to avoid reliability issues.

Possible approaches:

First

There's a minimum delay between calls. First call after the delay gets the reward.

Keepers who aren't first reliably would quickly be unprofitable due to 2. Being a keeper would be risky and maybe people would stop doing it. Maybe one keeper would be better at timing their tx than the others, driving away competitors.

Stochastic

There's a 60s window and the program provides 20x tx-fee in rewards. The rewards are shared equally among all callers inside the window.

Bad, windows would fill up as they open and then no one would call until the next window.

Queuing (complex version)

There's a window of 1-4 slots after the delay. Every keeper has a "queue number". Order the keepers who called the function inside the window by queue number ascending and then by address ascending. The top one gets the reward and their queue number is incremented.

If no one calls inside the window, the first caller gets the reward.

This decreases pressure to hit exactly the right slot and be first. Keepers can estimate when it'll be their turn to call. There's no benefit to trying to be first from multiple accounts.

I think this leads to a good equilibrium. Example:

there's three keepers, all start with queue number 5 and balance of 20
reward is 2, tx fee is 1
addresses are: keeper A < keeper B < keeper C

keeper A   | keeper B   | keeper C
q 5, b 20  | q 5, b 20  | q 5, b 20
all attempt because they don't know about each other yet, A gets it (lowest address)
q 6, b 21  | q 5, b 19  | q 5, b 19
A skips: the others have lower queue number, C knows about B, so skips too
q 6, b 21  | q 6, b 20  | q 5, b 19
they know it's C's turn
q 6, b 21  | q 6, b 20  | q 6, b 20
all have the same queue number again
since they know about each other now, they'll continue A, B, C
until there's an upset because someone fails to call or a new one comes in

It seems like no keeper would have an incentive to deviate from this cooperative process.

What queue number do new keepers get? Probably the highest-seen queue number, to avoid any advantage from making a new account. Also, if you someone doesn't call in a day, their queue number gets reset to the max.

The main problem with this approach is that everyone has an incentive to make many keeper accounts.

Queuing (simpler version)

As above, but without queue numbers. Just store the address of the keeper that last executed the function and give the reward to the caller with the smallest address difference (not abs) to the old address.

People can still make multiple keeper accounts to gain an advantage. There needs to be some risk per address, like staking funds and being punished if you don't call in too long.