Yes, that was the intent - migrating would include a commission change to 14% regardless of previous setting.
I think we’re on the same page here, but want to check. If I have 1 minipool, I could immediately migrate it to an LEB8. I would also receive an 8ETH credit, which I could use for another LEB. Using that credit would go through the standard queue, just like doing an actual ETH deposit for a new minipool. The described structure has no easy way to prioritize specific commission pools, so that recommendation (b/c a should is a recommendation, not a requirement) is not being followed.
I like a line per rewards period. What’s the added cost/complexity to that? I assume that would be the reason to do a single line in the sand? I think this is pretty important if indeed credit-created LEBs need to go through the queue. I think we may also get bailed out of this when skimming is implemented, so hopefully it’s for a pretty small number of reward periods. Once skimming is online, we’d just need to skim before migrating. (btw, if tree generation is expensive, we could always do one every other period; there could even be a message telling the NO how much they’d lose in rewards fairly easily and when the next tree is being generated to save rewards)
I like this concept better than a separate distributor both because of lesser complexity now, and b/c it’s easier to adapt if we add, eg, LEB4s at some point.
You’re talking about this as an approximation. What makes this non-exact? Is it mostly luck? Premise: I have a minipool16 and an LEB8. I get 4 proposals on the minipool16 and none on the LEB8; ideally, from those proposals, I would get (0.5 + 0.5 * 0.15) * proposal_rewards = 0.575 * proposal_rewards, but here I’ll get 0.375 + 0.625 * 0.145 * proposal_rewards = 0.466 * proposal_rewards so I get underpaid. Ofc, if the proposals were all on the LEB8, I would ideally get 0.25 + 0.75 * 0.14 * proposal_rewards = .355 * proposal_rewards, so then I’d be getting overpaid. I believe this is the main issue, but please correct me if I’m wrong.
I think the expected value is correct, and I don’t see a way to cheat it. Ie, if I got many LEB8s and few minipool16s to increase my chance of getting overpaid, then the collateralRatio changes so I get less overpaid on the LEB8 proposals and more underpaid on the minipool16 proposals.
The biggest issue I see here is explaining this complexity.
What priority does this get? Can this take from DP even if there’s a queue? Can it take from vault? I think it makes sense to have it take from anywhere and have priority above the minipool queue.