# Add a flexible gwei target condition to oven bake criteria to increase minimum bakes per week algorithmically

Proposal: Change Oven bake criteria from (A) AND (B) to (A) AND (B OR C).

( A ) When Oven has 10+ ETH

( B ) When gas is ≤ 100 Gwei

( C ) When gas is ≤ the minimum of the Etherscan 7-day Historical Gas Price: LOW Daily Gas.

At time of writing (April 3rd), coincidentally, the C condition would be 100 Gwei as well (The March 28th LOW Average Gas); but tomorrow the window will lose March 28th and the current low is 112 Gwei (today’s average so far).

This 112 Gwei target would then be the minimum for up to 7 days.

This method is a marginal improvement over 100 Gwei, without being too radical. A constant growth in gas would set new minimums slowly (7 days for a minimum to change at worst) and if we do see “never below 100 Gwei again” it’ll give us a flexible, algorithmically determined benchmark while we do another PIP to change the B condition if needed.

5 Likes

if i understand this correctly, then C would essentially be an undefined variable? what if week X’s 7 day low daily gas average just happen to be 200?
an average would be a step in the right direction but i feel there still needs to be a hard cap. has increasing the frequency of checks on certain days or in general been explored? sunday seems to look very light…

4 Likes

I think increasing the frequency of checks is important too. I’ve checked the gas price maybe 20 times today over a period of several hours. Every time, the price was low enough and still, the oven didn’t bake. Its especially important to get this sorted, because I only forsee the gas price trending higher.

Even if Berlin is supposed to help, it will probably only encourage more activity on the ETH network, thus negating the increased bandwidth.

At the same time. If the gas price goes too high, it wouldn’t really be good if it fires off at 200 gwei either.

I think a hard limit would still be neccessary. I would suggest a new hard limit of 115

1 Like

I think we’re mixing issues. 100% agree on check frequency going to maybe 10mins instead of 15.

The concern right now is that 100 Gwei limit is too low, causing ovens to not bake frequently enough.

The options are:

1. raise the limit to a new number ad-hoc
2. raise the limit algorithmically
3. have an oven overload trigger (e.g. 50ETH).

(1) doesn’t solve the bake frequently enough problem because any new number we pick will increase bake frequency until it doesn’t. (We’d be revoting regularly. Not that big a deal tho honestly).

(2) solves the problem by using a moving window approach to ensure that as long as gas costs are not perfectly rising linearly, we have a recent historically relevant limit (I.e. we should see at least weekly bakes with a 7-day moving window if the curves are upside down U shaped)

(3) is my actual preferred approach.

Worrying about 100 Gwei versus 200 Gwei versus 300 Gwei shouldn’t actually matter if the oven sizes are large enough.

10ETH splitting 200 Gwei is annoying; 50 ETH splitting 200 Gwei is virtually nothing compared to 100 Gwei (gas cost doesn’t grow perfectly linearly with volume on the transaction).

Quibbling over Gwei thresholds can actually lose people money in a growing market because they’re holding ETH in the oven instead of holding the index they prefer to hold which might grow above their marginal gas differential + ETH’s growth.

I mildly disagree with picking a new arbitrary gas target (e.g. 115) because revoting every few months is probably not a great use of our time.

But I would vote for 115 Gwei if you make it a separate proposal, so feel free to.

A point I just want to quickly make too. The benefit of the oven is in the shared transaction pooling, not the gas limit. 97% gas reduction from sharing is great. So is 90%, and even 80% lol.

The risk people are taking when they invest in an oven is the risk of holding an asset they don’t prefer over the one they do prefer, so bakes should be happening very very frequently to meet this risk.

3 Likes

Everyone makes valid points here. I don’t think anyone is ‘Quibbling’ over gas prices per se. I think most would agree increasing the frequency of checks needs to be looked at. The gas issue is a tricky one. I agree that it leaves people frustrated seeing their eth in an oven sitting idle & their pies arent baked yet.

I haven’t put any real thought into this but it suddenly springs to mind. Is it possible to have options when depositing eth into the oven where you would be able to choose:

A) Expedited pie - costs more but get baked faster. - (still cheaper than buying directly)
B) Normal rate - slower but costs less.

1 Like

An overload option is a great idea too. I’ve had ETH sitting in the oven even before the last time it baked on friday. But it also says the maximum baking amount is limited to reduce slippage.

Is there actually a problem baking 50 ETH all at once?

And also, the issue is partically relevent for PLAY right now, since realistically its the only way to get some. Its not like BCP or the DEFI pies which I could just swap for or redeem for.

I really like the overload trigger suggestion, looks like the PLAY oven is currently holding 56 ETH, so this is something that could realistically trigger.

We should also consider having a higher but still bounded gas price in the overload condition, as a control to make sure the oven does not overspend on the transaction.

This is great conversation. Maybe we should go ahead and add 2 separate proposals as well.

(1) This one is for adding a 7-day moving window to algorithmically determine an alternative gas price

(2) We can get a proposal to permanently raise the gas target to 115 gwei (and just revote on this as it comes up). @cryptochonkz would you want to post this on discord and see if a proposal makes sense? I’d vote for it.

(3) A proposal to add an overload trigger to pies (e.g. 50 ETH). @Joshuatov would you want to post this on discord and make a new proposal? I’d vote for it.

I personally am against the idea of an “express” versus “normal” pie. I think splintering ovens ends up defeating the point a little bit. I strongly support and overload trigger and would like to see single ovens get lots of investment moreso than split people by preference.

Although if we were to split them, what I’d recommend instead is that people can submit their ETH to an oven (maybe a v3 oven lol) and add in their gas price sensitivity (low - medium - high) so that we could get a cost curve and allow sub-bakes among people with lower price sensitivity for ovens with enough ETH. But that gets complicated fast.

I’d like to keep this specific proposal thread on the topic of an algorithmic alternative gas target, but again, I’d vote for the other proposals we discussed.

1 Like

I don’t know how I would make a proposal on discord. Do I just post on there and add the suggestion to create the overload trigger?

Ok so the overall condition is this:
Oven baked if
(Deposit eth > 10) AND
(Current gwei =< 100 + slope*( deposit Eth -10))
That way we can float the gas threshold based on the deposited ETH, with 30 ETH capped.
It means that the DAO can decide on the gas threshold for 30 ETH.
And based on discussion on Discord, it is best for the devs to improve transparency (so we have #bot-notification), like reporting oven status for a certain period of time etc.

Not sure what this part means. DAO decisions take a long time; the cap on bakes are currently:

• slippage limit
• gas limit

I’m willing to update this proposal as

Condition (A) AND (B OR C)

A - 10+ Eth
B - gwei <= 100
C - gwei <= 90 + ( # ETH in Oven)

Where I condensed the math on C; as it is significantly simpler than what I propose.

Sorry dude. I’ve been a little busy with the day job i forgot to log on here.

You articulated it better than i did. “(maybe a v3 oven lol) and add in their gas price sensitivity (low - medium - high) so that we could get a cost curve and allow sub-bakes among people with lower price sensitivity for ovens with enough ETH. But that gets complicated fast.” - this would be extremely beneficial imo.

perhaps related, posted this to the development channel:

could test/use this AI for better GAS prediction

First of all – want to mention that I have not read the entire thread here. Will come back to do so but want to capture another idea that feels related.

This idea increases complexity but is attractive in my opinion.

I have had multiple people reach out to me with thoughts around lowering the minimum ETH threshold to trigger the bake. I think this could work well with adjusting the gwei acceptance criteria.

The current set up is simple, and easy for new users to understand. There is value in that.

But some familiar users may be interested in flexibility. I am thinking something like…

5 ETH bakes at 50 gwei
10 ETH bakes at 100 gwei
20 ETH bakes at 200 gwei

Obviously those numbers are over simplified and based on the current 10 ETH and 100 gwei acceptance criteria.

Again, sorry to be piggybacking without doing a full dive into the thread of thought here and this can be considered out of scope of this conversation. Happy to create a new thread of discussion around this if there is any interest.