There’s currently about $136,000 remaining in the buyback execution contract for $PONS
I’ve been wondering whether, in protocols that are actually executing buybacks, a more flexible buyback design might be better than mechanical automatic buybacks, @MEADGod
For example, when looking at historical trends, if the current market is identified as being in a downtrend, execute a larger proportion of buybacks.
Conversely, if it’s identified as being in an uptrend, reduce that proportion.
For example, PONS buybacks are currently around 0.46e per hour. This is the hourly baseline for the current cycle.
(1) If the trend formed by the past 20 hourly candles is identified as a downtrend, the buyback amount would be 0.6e/hour (1.3 times the baseline amount).
(2) In an uptrend, the buyback amount would be adjusted to 0.32e/hour (0.7 times the baseline amount).
(3) In a neutral market, the buyback amount would stay at the baseline.
I had AI make a simple chart to help everyone understand.
The key here isn’t to have the protocol allocate more than the budget, but to change how the same budget is allocated across different price ranges.
The amount spent less during an uptrend goes into a separate buyback pool, and then more is drawn from this pool during a downtrend. This way, buybacks can continue as usual, while at lower prices the same amount of money can buy back more PONS and carry out more burns.
Using only the past 20 hourly candles is just an example. The mechanism itself is easy to implement—I could build one with Codex, since I implemented similar trend detection for my market-monitoring bot.
A more sensible approach would be to analyze the price trend of $PONS over the past week before executing each cycle.
There is one issue with this design: if the market remains in a downtrend for a prolonged period, the funds will be depleted faster.
So it would be best to use this flexible mechanism during an uptrend, while keeping the original 30% of the pool in reserve.
It could also be implemented at this stage by adding a condition to the contract: before executing each cycle, check the balance of the reserve pool. If the balance is less than 0.3 × the total funds for the cycle, the buyback for the current cycle defaults to the baseline amount.
➠ In other words, suppose 10E is available for buybacks this cycle. If the reserve pool balance carried over from the previous cycle is less than 3E, then the total buyback amount for this cycle defaults to 10E rather than 13E.
I’ve been wondering whether, in protocols that are actually executing buybacks, a more flexible buyback design might be better than mechanical automatic buybacks, @MEADGod
For example, when looking at historical trends, if the current market is identified as being in a downtrend, execute a larger proportion of buybacks.
Conversely, if it’s identified as being in an uptrend, reduce that proportion.
For example, PONS buybacks are currently around 0.46e per hour. This is the hourly baseline for the current cycle.
(1) If the trend formed by the past 20 hourly candles is identified as a downtrend, the buyback amount would be 0.6e/hour (1.3 times the baseline amount).
(2) In an uptrend, the buyback amount would be adjusted to 0.32e/hour (0.7 times the baseline amount).
(3) In a neutral market, the buyback amount would stay at the baseline.
I had AI make a simple chart to help everyone understand.
The key here isn’t to have the protocol allocate more than the budget, but to change how the same budget is allocated across different price ranges.
The amount spent less during an uptrend goes into a separate buyback pool, and then more is drawn from this pool during a downtrend. This way, buybacks can continue as usual, while at lower prices the same amount of money can buy back more PONS and carry out more burns.
Using only the past 20 hourly candles is just an example. The mechanism itself is easy to implement—I could build one with Codex, since I implemented similar trend detection for my market-monitoring bot.
A more sensible approach would be to analyze the price trend of $PONS over the past week before executing each cycle.
There is one issue with this design: if the market remains in a downtrend for a prolonged period, the funds will be depleted faster.
So it would be best to use this flexible mechanism during an uptrend, while keeping the original 30% of the pool in reserve.
It could also be implemented at this stage by adding a condition to the contract: before executing each cycle, check the balance of the reserve pool. If the balance is less than 0.3 × the total funds for the cycle, the buyback for the current cycle defaults to the baseline amount.
➠ In other words, suppose 10E is available for buybacks this cycle. If the reserve pool balance carried over from the previous cycle is less than 3E, then the total buyback amount for this cycle defaults to 10E rather than 13E.