Pinger incentive updates

Pinger incentive updates

TLDR: Update gasPriceOracle (dsValue) from 1000gwei to 200gwei.

The system rewards module is explained here in detail.

Rewards are auto adjusted, but in the absence of a reliable gas price twap feed, we use a fixed gas price, currently set at 1000gwei.

The treasury currently contains 189k RAI, but has been contracting in recent months.

The gas price since early this year has lowered considerably from when the system was first setup, remaining lower than 200gwei for the most part, with the exception of a couple of short lived peaks: Ethereum Average Gas Price Chart | Etherscan

This proposal entails setting the oracle at 200gwei, resulting in an 80% reduction spent in incentives.

risks: Contracts pay the call cost + 30% (debt popper rewards) and an increasing reward that goes from cost to 2x the cost (all other contracts).

After EIP 1559, gas price peaks last shorter, and price goes back to normal quickly. Brief peaks over the gas price set in the oracle do not affect the system negatively.

The rewards for popping debt on the accounting engine are profitable up to a gas price of 260gwei, and do not present risk to the system if delayed.

The increasing rewards are profitable for callers up to 400gwei gas price. This includes several critical calls (relayRate on the rate setter relayer, updateResult on the ETH OSM for example). This only becomes a problem to the system if the gas price is sustained above 400gwei for long periods. For some of the calls, there are external incentives that will make participants call them even if unprofitable (calling updateResult on the OSM to liquidate a SAFE, for example).

Poll:

  • Set gas price oracle to 200gwei
  • Set gas price oracle to a different value (comment below)
  • Do not change gas price oracle value

0 voters

Updates on the plan above. It’s not the easy win that was described, as the gas oracle used for rewards is actually set at 150gwei. Updating the proposal and bringing in other ways of saving with the incentivized calls:

Pinger incentive updates

The system rewards module is explained here in detail.

The treasury currently contains 183k RAI, but has been contracting in recent months. The usage of the treasury is increasing due to competition between keepers, and calls that were previously done by Reflexer’s team’s bots only when necessary, are now performed as often as they are incentivized.

  • The spike on ~8/15 is due to several liquidations taking place.

With the current spending, if no liquidations happen in the system the runway for the automated calls is approximately 8 months.

To make the system fully sustainable from stability fees alone, at the current global debt, the incentives for pinger calls would have to be reduced by ~90%.

I will describe below several actions that together can reduce the treasury consumption considerably. The goal is to discuss with the community, and implement the ones that become the consensus.

1. Adjust gas price oracle to 100 gwei.

Rewards are auto adjusted, but in the absence of a reliable gas price twap feed, we use a fixed gas price, currently set at 150gwei.

After EIP 1559, gas price peaks last shorter, and price goes back to normal quickly. Brief peaks over the gas price set in the oracle do not affect the system negatively.

The rewards for popping debt on the accounting engine are profitable up to a gas price of 130gwei, and do not present risk to the system if delayed.

The increasing rewards are profitable for callers up to 400gwei gas price. This includes several critical calls (relayRate on the rate setter relayer, updateResult on the ETH OSM for example). This only becomes a problem to the system if the gas price is sustained above 200gwei for long periods. For some of the calls, there are external incentives that will make participants call them even if unprofitable (calling updateResult on the OSM to liquidate a SAFE, for example).

2. Adjust ETH OSM’s gas amount for execution

Below a breakdown of rewards paid per contract/call (last two months):

Average and sum of rewards paid per contract:

The Rate setter, RAI TWAP and ETH OSM together comprise 98% of the treasury consumption. They are both the most expensive and the most frequent calls that are incentivized.

Proposal #2 comprises adjusting the gas amount for execution of the ETH OSM updatePrice() call to 180k from 265k. 180k gas is the actual value, and the change will result in 30% saving on all calls updating the OSM (That comprise over 75% of the rewarded calls).

3. Change RAI TWAP to longer period. Use Uni V3 TWAP (RAI-ETH, ETH-USDC?)

Currently the RAI TWAP is updated every 8 hours (and returns a 24h twap), increasing the window to 1 day would reduce the number of calls by two thirds, resulting in a twap of 3 days.

Another alternative would be to use the Uni V3 native TWAP. Since it does not require a pinger it would result in 14% savings.

Conclusion

I believe all the proposals above should be implemented in the long run. From the 3 suggested the first two could be implemented right away, with low risk for the system. The both of them will result in ~50% savings.

#3 is riskier and could affect the controller, so it should be discussed properly before implementation.

I’ve talked with a number of members in the community, and the final proposal will look like this:

  1. Set all rewards to start at 10% of their set gas cost. Right now they start at 100% of the cost, with gas price at 150gwei and scale up to 200%. After the proposal it will start at 10% of the cost at 150gwei gas price and will increase up to 200% in 45 minutes. The contracts will effectively start with the cost of the call at 15gwei gas price, and scale up to the cost at 300gwei linearly in 45 minutes. This alone should reduce the spending considerably for all calls with increasing rewards (all of them, except for calls to debt popper rewards).

  2. Reduce gasAmountForExecution for the calls to the OSM to 190k from 265k gas. The calls to the OSM are 75% of the spending, this will save ~30% on them. The actual cost when called from an EOA is 182k, this reward was setup when a different oracle was used, and is currently larger than the fair value.

After the proposal is in production we will wait for the keepers to adapt to the new rewards and reassess if there are any other ways to reduce spending. We are not yet touching the TWAP as previously mentioned, because with the liquidity incentives change to Uniswap V3 we can deploy a pingerless TWAP, effectively reducing RAI TWAP cost to 0 (with no need to change the TWAP length).

If no objections I will propose this on-chain in 24h.