Token Incentives for Keepers

Token Incentivize Keepers

The past few weeks of Solana network degradation has been a tough time for everybody, especially latency sensitive infrastructure like an exchange.

Entropy is currently using 2 RPC nodes, but the flaws are apparent. There are occasional outages that affect reliability of the exchange.


Incentivize a decentralized network of Keepers with token.

Keepers form the backbone of a decentralized orderbook based exchange.

  1. Processing orders from the backend serum market
  2. Updating oracle prices.
  3. Updating Account States

We need more people to be keepers!

Since the future of the exchange relies on robust decentralized community, it makes sense to incentivize it as such.

I propose that at least 2% of the token be reserved for keepers over a period.
More token unlocks at the beginning than towards the end.

We will incentivize people by measuring the amount of confirmed keeper transactions by wallet address.

Each keeper will receive a share of the >2% pool corresponding to their share of total confirmed keeper transactions.

There is a default RPC url provided for people to keep.
This RPC cannot handle much load, so keepers that use a different RPC provider will have a higher transaction throughput, and thus capture more of the rewards.

We want the network to be more decentralized, so everyone using one RPC provider causes a point of failure that defeats the purpose.

Check out the following links on how to become a keeper:
Forum Post: More Keepers for Entropy - #7 by Galileo
How to get started: Deploying Entropy on Google Cloud Platform · GitHub (credit


Which RPC provider is recommended? and any guide on how to switch them?


Genesysgo, solana’s mainnet RPC are available for public use, however it will be hard to get many transactions through without getting rate limited.

Running it on a private RPC, though costly, will increase the # of transactions confirmed and lead to higher rewards!

Sharpieman mentioned that we want to incentive keeper activity in low TPS activities especially.

It would make sense to calculate the average TPS in the past hour or so and scale the rewards inversely on TPS to make up for the fact that it is harder to confirm a transaction in low TPS environments, but it is the most vital.