Propose adding a "reinvestment" feature for pJars

Propose adding a “reinvestment” feature for pJars

Background: Currently, the dev team has a bot to call the “earn/harvest” based on a certain threshold. The objective is that the more frequent the “earn/harvest” are called, the more compounding effect or the higher APY it is for all the pJars.

Future state: I have checked with 0xPenguin that the reinvestment feature is feasible. If this is voted and approved, we will be able to allow anyone to call the “earn/harvest” anytime. To compensate them for the gas fees, we can introduce a “reinvestment bounty” of 0.1%.

This is a win-win situation as the dev team can save on the bot’s gas fees, someone in the community or participant of the pJar can call the earn/harvest more frequently, and ultimately the pJars’ APY will increase due to the frequent compounding.

Happy to discuss any queries that you might have on this.

6 Likes

Great feature, no discernible downside.
Added a poll, we need 20 votes with 75% in favour to move forward to a PIP.
Callers of the Harvest function will get 0.1% of the harvested amount as compensation for gas fees.

  • Introduce Harvest Bounty
  • Do Nothing

0 voters

1 Like

Can you provide some numbers for me in regards to gas used and and how much the 0.1% of the harvest will be ?

On first look this looks like a good feature, but I do not see why we should not have a bot that just does this in more frequent intervals that takes 0,1% of the harvest and turns them into ETH to keep running.

If that theoretical bot can’t sustain itself by taking 0,1%, then there also must be instances where users who call harvest get less then they pay in gas fees, providing a negative experience (granted not many novice users would do this and I am sure you could calculate whether you would earn or loose money, but still, why open this up ?).

If that theoretical bot would in fact be able to sustain itself(by taking 0,1%) and we don’t deploy it I don’t see how we could prevent any third party to just deploy a bot and call harvest functions in any reasonable interval, basically rent seeking from this function. The rent seking bot would net 0,1% of any harvest - gas paid.

I would rather see a bot being paid from treasury to keep calculations clean and not add complexity to an already complex system.

Also if you could provide numbers regarding the increase in APY it would add to the depth of discussion we can have here.
I see how this would work on a theoretical level, but my line of thought is: “is it worth the effort and added complexity to increase APY by 0,0xx% ?”

4 Likes

I prefer something like this to happen with automation BUT if a bot update won’t do, then I’m voting in favor of the “reinvest” feature.

Just had a look at the Jars and the harvest function…
It costs around $5 in gas at 20gwei to call harvest, so there would need to be over 5K harvestable to make a profit. Assuming average gas at 40 I would expect the breakeven to be closer to 10K.

Automation would be great too…however I feel that such a bounty would increase engagement with the platform as users would be keeping an eye on the jars looking for harvest opps. It’s small $$, but it could possible evolve into a contest/leaderboard in the future (maybe with NFT trophies for the Monthly Top Pickle Pirate lol)

Right now, someone could make $3 by harvesting the 7.5K in the ETH/DAI jar.

1 Like

I agree. It might actually make more sense to just fund the bot more aggressively and lower the threshold for the bot to call harvest/earn. It’s simpler because it feeds into the current architecture and does not require any engineering time at all. And the “cost” is shared by the whole community since the money would be coming out of the Treasury (which btw benefits from increased jar profits). Quite an elegant solution IMO.

4 Likes

Thanks for all the wonderful feedback - I think BigBrainBriner is right that we can just tweak the current bot parameter to call the earn/harvest more frequently, with no additional engineering time.

Given the current gas environment, we should call the earn./harvest more frequently and can revisit the parameters in the future.

Not sure how i can close/ end the discussion here - can someone assist?

Maybe BigBrainBriner can advise what is the current threshold, and whats the new threshold going to be? We can then consider this task closed.