The Revert Compoundor protocol was designed to be trustless and with minimal governance required. It is however not decentralized. As explained in our whitepaper, there are four parameters controlled by a team multisig. Two of them maxTWAPTickDifference and TWAPSeconds relate to the Uniswap pricing oracle, and are a precautionary measure that prevents swapping of collected fees during high volatility periods.

Another pair of variables totalRewardX64 and compounderRewardX64 determine the amount of fees the protocol charges and how much of that the protocol pays to the compoundor bots that execute the auto-compound function. These parameters have not been changed since the contract was deployed and are currently set at 2% for the totalRewardX64 (this parameter can only be reduced and never increased) and 1% for the compounderRewardX64 (this parameter can be decreased or increased, but it can never be greater than totalRewardX64). More clearly, this means that right now when a position is auto-compounded, 1% of the compounded fees go to the Compoundor protocol, and the other 1% goes to the people running the compoundor bots.

When we launched the Compoundor protocol our team was really the only one running auto-compounding bots, but we published and open sourced our bot implementation expecting other people might want to run them, learn from them, and perhaps accrue some profit by auto-compounding positions.

And indeed that did happen, to the point where we just kept our bots running as backstop in case other bots did not compound positions first, but that is a rare occurrence now.

On one hand this is great, we believe the resilience of the protocol is theoretically increased by compoundor bots running independently of ours. On the other hand there are some downsides to this.

First, in full honesty, we (Revert, the company) are leaving some revenue on the table by giving 1% to the bot operators for a task that we have to be prepared to do anyway.

Our stated mission is to build powerful analytics tools for liquidity providers in AMM procools while keeping them open and accessible to everyone, for this reason we have avoided doing things like paywalls and our roadmap includes revenue generating features that are aligned with our mission.

Going back to compoundor bots, a simple way to increase company revenue, without increasing costs for our users, is for us to take over the role of running them exclusively.

Additionally, as explained in our whitepaper, auto-compounding has diminishing returns. This is to say that the APY increase from auto-compounding most positions is not significantly increased if a position is auto-compounded 4000 times per year, instead of 400 times per year. While these excessive compoundings don’t represent an extra cost to the LPs, as the fee is 2% of what is compounded regardless of the compounding frequency, there are some externalities to consider:

• Unnecessary load on chains: as mentioned above, increasing the number of auto-compounds above a certain threshold does not significantly increase the APY for positions, but does result in more transactions being included in the respective network.

• Unnecessary load in tracking positions: every collect and deposit transaction implies additional resources being spent in tracking the positions.

• Excess balances mixed between positions: In some cases, because the uncollected fees and the positions being compounded have different ratios in token0 and token1, excess balances can be left in the contract assigned to the position owner. These balances are there to be used in future compoundings for positions from that same LP account, and if an account has more than one position that share an asset (like ETH), excess balances accrued from one position can be used to compound another position (owned by the same user). This can be avoided if Compoundor bots swap the accrued fees to the correct ratio, but this implies an extra gas cost that compoundor bots can decide to avoid.

• UX confusion: Though the unnecessary compoundings do not imply any additional cost (gas or otherwise) to the LPs, we do get a lot of questions as to why positions are compounded with this seemingly excessive frequency.

We will be leaving totalRewardX64 as is, but will be setting compounderRewardX64 to zero**.** What this means is that external compoundors are not incentivized to run the compoundor bots and that responsibility will be taken over by our team only.

The team will also run the bots so that we maximize APY improvement for positions, but also reducing the negative externalities mentioned above. Additionally, and not to minimize this, the revenue generated by the Compounder bots will be accrued fully by Revert.

Any change to the Compoundor contract parameters requires a 24-hour time-lock to take effect, but we will also be allowing for a few more days, and notifying the folks we know running compoundor bots of these changes so that they can stop their bots, as otherwise they would be only paying gas costs without any revenue to make up for it.

The compoundor protocol is at the moment trustless and with minimal governance required, but it is not decentralized as the parameters, and the protocol revenue, is controlled by the team and not any form of DAO.

As we progress in executing on our roadmap, and a next version of the Compoundor, we will be releasing an additional set of features where it will perhaps become more important to decentralize governance of specific parameters and we will most likely do so.

The changes should be mostly unnoticeable for LPs. The Compounding APY will not be reduced even though they might notice less frequent compoundings for their positions. There are no new or additional costs for Revert users.

We understand this is not great news for folks who have been running Compoundor bots and we did not make this decision lightly. But we believe this change will help in keeping with our stated mission of building powerful tools for LPs in AMM protocols while keeping them open and accessible to everyone. Again, we believe as we execute on our roadmap throughout the year there will be new opportunities for external parties to help in protocol automation.

The Revert Compoundor protocol was designed to be trustless and with minimal governance required. It is however not decentralized. As explained in our whitepaper, there are four parameters controlled by a team multisig. Two of them maxTWAPTickDifference and TWAPSeconds relate to the Uniswap pricing oracle, and are a precautionary measure that prevents swapping of collected fees during high volatility periods.

Another pair of variables totalRewardX64 and compounderRewardX64 determine the amount of fees the protocol charges and how much of that the protocol pays to the compoundor bots that execute the auto-compound function. These parameters have not been changed since the contract was deployed and are currently set at 2% for the totalRewardX64 (this parameter can only be reduced and never increased) and 1% for the compounderRewardX64 (this parameter can be decreased or increased, but it can never be greater than totalRewardX64). More clearly, this means that right now when a position is auto-compounded, 1% of the compounded fees go to the Compoundor protocol, and the other 1% goes to the people running the compoundor bots.

When we launched the Compoundor protocol our team was really the only one running auto-compounding bots, but we published and open sourced our bot implementation expecting other people might want to run them, learn from them, and perhaps accrue some profit by auto-compounding positions.

And indeed that did happen, to the point where we just kept our bots running as backstop in case other bots did not compound positions first, but that is a rare occurrence now.

On one hand this is great, we believe the resilience of the protocol is theoretically increased by compoundor bots running independently of ours. On the other hand there are some downsides to this.

First, in full honesty, we (Revert, the company) are leaving some revenue on the table by giving 1% to the bot operators for a task that we have to be prepared to do anyway.

Our stated mission is to build powerful analytics tools for liquidity providers in AMM procools while keeping them open and accessible to everyone, for this reason we have avoided doing things like paywalls and our roadmap includes revenue generating features that are aligned with our mission.

Going back to compoundor bots, a simple way to increase company revenue, without increasing costs for our users, is for us to take over the role of running them exclusively.

Additionally, as explained in our whitepaper, auto-compounding has diminishing returns. This is to say that the APY increase from auto-compounding most positions is not significantly increased if a position is auto-compounded 4000 times per year, instead of 400 times per year. While these excessive compoundings don’t represent an extra cost to the LPs, as the fee is 2% of what is compounded regardless of the compounding frequency, there are some externalities to consider:

• Unnecessary load on chains: as mentioned above, increasing the number of auto-compounds above a certain threshold does not significantly increase the APY for positions, but does result in more transactions being included in the respective network.

• Unnecessary load in tracking positions: every collect and deposit transaction implies additional resources being spent in tracking the positions.

• Excess balances mixed between positions: In some cases, because the uncollected fees and the positions being compounded have different ratios in token0 and token1, excess balances can be left in the contract assigned to the position owner. These balances are there to be used in future compoundings for positions from that same LP account, and if an account has more than one position that share an asset (like ETH), excess balances accrued from one position can be used to compound another position (owned by the same user). This can be avoided if Compoundor bots swap the accrued fees to the correct ratio, but this implies an extra gas cost that compoundor bots can decide to avoid.

• UX confusion: Though the unnecessary compoundings do not imply any additional cost (gas or otherwise) to the LPs, we do get a lot of questions as to why positions are compounded with this seemingly excessive frequency.

We will be leaving totalRewardX64 as is, but will be setting compounderRewardX64 to zero**.** What this means is that external compoundors are not incentivized to run the compoundor bots and that responsibility will be taken over by our team only.

The team will also run the bots so that we maximize APY improvement for positions, but also reducing the negative externalities mentioned above. Additionally, and not to minimize this, the revenue generated by the Compounder bots will be accrued fully by Revert.

Any change to the Compoundor contract parameters requires a 24-hour time-lock to take effect, but we will also be allowing for a few more days, and notifying the folks we know running compoundor bots of these changes so that they can stop their bots, as otherwise they would be only paying gas costs without any revenue to make up for it.

The compoundor protocol is at the moment trustless and with minimal governance required, but it is not decentralized as the parameters, and the protocol revenue, is controlled by the team and not any form of DAO.

As we progress in executing on our roadmap, and a next version of the Compoundor, we will be releasing an additional set of features where it will perhaps become more important to decentralize governance of specific parameters and we will most likely do so.

The changes should be mostly unnoticeable for LPs. The Compounding APY will not be reduced even though they might notice less frequent compoundings for their positions. There are no new or additional costs for Revert users.

We understand this is not great news for folks who have been running Compoundor bots and we did not make this decision lightly. But we believe this change will help in keeping with our stated mission of building powerful tools for LPs in AMM protocols while keeping them open and accessible to everyone. Again, we believe as we execute on our roadmap throughout the year there will be new opportunities for external parties to help in protocol automation.