feat(ui): Add --max-fee and --max-fee-per-gas parameters

[yorickdowne]

• Add --max-fee / -x and --max-fee-per-gas / -g as global options. --max-fee defaults to 1wei and --max-fee-per-gas defaults to 15gwei. Values can be given as wei, gwei or eth.
• Do not touch Safe, it has its own gas fee path, the --max-fee-per-gas should not impact it

Implements #60
Closes #33
Closes #9

[yorickdowne]

This protects against wiping out a wallet when sending a lot of requests, resulting in escalating fees

Entirely vibe-coded with opencode's Big Pickle. The resulting code may indeed not be pretty, and no worries if this PR is rejected for it.

Tested on Hoodi while another entity also mass-consolidated.

Example run:

Block 3030349 | Current contract fee 0.2693 gwei exceeds max fee 0.2000 gwei — waiting for next block...
Block 3030350 | Current contract fee 0.2540 gwei exceeds max fee 0.2000 gwei — waiting for next block...
Block 3030351 | Current contract fee 0.2395 gwei exceeds max fee 0.2000 gwei — waiting for next block...
Block 3030352 | Current contract fee 0.2258 gwei exceeds max fee 0.2000 gwei — waiting for next block...
Block 3030353 | Current contract fee 0.2129 gwei exceeds max fee 0.2000 gwei — waiting for next block...
Block 3030354 | Current contract fee 0.2007 gwei exceeds max fee 0.2000 gwei — waiting for next block...
📤 Broadcasting 1 execution layer requests targeting block 3030356 (max fee per gas: 1.965662215 Gwei, contract fee: 0.1893 gwei)...
Broadcasting execution layer request: 0xcec48e42633d4ed80d0eaf740e824dff13a4b031971c1df6c3225ff5a5a5809e ...
Mined execution layer request: 0xcec48e42633d4ed80d0eaf740e824dff13a4b031971c1df6c3225ff5a5a5809e in block 3030356
✅ All execution layer requests processed successfully

[yorickdowne]

Replacement now also logs fees

Broadcasting 1 execution layer requests targeting block 3030359 (max fee per gas: 2.244288823 Gwei, contract fee: 0.1893 gwei)...
Broadcasting execution layer request: 0xebcb129ad34fdbf6b8ab6c4cabe9e274e39590bf9f6bbb0929cdccb21719a773 ...
Replacing 1 pending execution layer requests for block 3030360 (max fee per gas: 2.513603481 Gwei, contract fee: 0.1784 gwei)...
Replaced pending execution layer request 0xebcb...9a773 with 0xd40c9c0718896a7a42974d010570c646efbf41e1dd1a2d6ce2ca9e04e428ce55
Replacing 1 pending execution layer requests for block 3030361 (max fee per gas: 2.815235898 Gwei, contract fee: 0.1683 gwei)...
Replaced pending execution layer request 0xd40c...8ce55 with 0xba7889c8ff09c4a7e8a5bcf1bc1360267e8360e3b07a6f9ce7a1a1678131b983
Nonce 9280 consumed - execution layer request fulfilled by original or competing transaction
✅ All execution layer requests processed successfully

[TobiWo]

Hi @yorickdowne , I might need to close this PR as you do not follow our contribution guidelines. Since we use semantic-release for version determination this is mandatory. Furthermore your code might fail our formatting tests. Did not test yet. So I might use your code as base and adapt where necessary. This way the expected code quality is met. This might be faster as correcting your code, commit messages etc.

[yorickdowne]

Furthermore your code might fail our formatting tests.

That it shouldn't. I've used your CLAUDE.md and the test suite was run

I hear you on CONTRIBUTING.md, I did indeed not follow that. I can take a look at whether I can fix this PR to be more in line.

If you need to close it, no worries. It does what I need it to do over here.

[yorickdowne]

See whether those edits make it work better re your contribution guidelines

if the concern is code quality then yeah, it's likely faster to redo it the way you want it, than to try and fix this thing

[yorickdowne]

One note, I am deliberately not hard-coding 12s slot length here. When you redo, that's worth paying attention to. You have at least one other place in the codebase where 12s is hard-coded. As soon as Hegota, we may see 8s slots. See https://stakemap.org/ and "quick slots". 6s possibly after, and endgame might be 4s. The fewer assumptions the code makes about slot length, the easier down the road.

[TobiWo]

Thanks again for the PR and for testing this on Hoodi. The feature is useful, but after going through the code I think it is cleaner if I implement it in our own structure instead of trying to reshape this PR.

My main concern is the layering. I want fee estimation, request-fee caps, and execution policy to stay separate. Here the fee options are passed through quite a few layers, and EthereumStateService also starts doing wait handling and logging. That will be harder to test and maintain.

I also want to avoid a couple of edge cases: request-fee waits without a bound, --max-fee-per-gas not being a real cap once replacements bump fees, and request fees getting stale after waiting for gas.

I will reuse the ideas that fit well: block-aware waiting, better fee logging, and your point about not hard-coding slot length.

Let me keep the PR open for now until everything is in place from my side.

Edit: I will also not implement --max-fee-per-gas for now. This is a follow-up as I want a clean request fee handling first.

[yorickdowne]

Love it, thank you! A cleaner structure is amazing. I created this so I could consolidate, and it did that. Maintainable code that allows others to do the same is the right move.

[yorickdowne]

request-fee waits without a bound

That was a choice, and it worked great for what I needed.

stakely has a Ledger withdrawal address and would post 400 consolidations at a time. Fee would decay, they'd post another 400. By not having a bound, the tool waited until the fee had decayed to 1 wei and stakely had gone home for the night. No human to press Ledger buttons + fee decay, we got to submit a few. Then fees would be high again in the morning.

After 7 days, all our consolidations were in.

If you want this to abort after a while, the calling script would need to handle that. Maybe create another parameter so people can run indefinitely or with a specific max retry.

The fee will always come back down to 1 wei. There is no such thing as "forever consolidations". This is unlike gas fee, which could stay above a limit forever. That's why "wait until the max fee constraint can be met, however long that is" seemed like good UX to me here.

[TobiWo]

If you want this to abort after a while, the calling script would need to handle that. Maybe create another parameter so people can run indefinitely or with a specific max retry.

I will make --max-request-fee-wait-blocks a global option so that it can be used for safe specific flow (comes from safe feature) but also for the new --max-request-fee setting. So in the end, if you want to run it indefinitely you simply define a huge block number 😉 .

Some users might want more control and only give it a chance for x blocks to conclude, hence the wait blocks feature. But I understand that for your case this was not what you wanted.