Adjust to new Broker pallet. #334
Conversation
eskimor
commented
May 29, 2024
eskimor
commented
- Does not require a CHANGELOG entry
|
@eskimor is it still draft or ready for review? also some required CIs are falling |
|
@muharem so far draft. The polkadot-sdk release this PR relies on does not exist yet. |
Related to #4521 and #4656 This allows a release of the Broker pallet so the new price adapter can be tested on Kusama ASAP (polkadot-fellows/runtimes#334).
eskimor
changed the title
Co-authored-by: Dónal Murray <donalm@seadanda.dev>
|
Test is fixed. For adjusting the base price, I was thinking about writing a migration, but we could equally well let the price controller do its thing: It should adjust downwards itself in the next cycle. Only "downside" would be that the minimum price stays the same for another cycle. |
…rk-new-broker-price-adapter
|
If this enacts before If no cores are sold it will be 2300 down to 23 and we'll lose a month of info about the new pricing model. Currently we're in the fixed price stage and sellout price is still None, so that's quite likely IMO. If it enacts after After weighing that up I would say a migration for the base price makes sense, but only if we are sure we can enact and perform the runtime upgrade in time before the sale is rotated, otherwise I would say we schedule it for the interlude and add a migration for the renewal prices for those coming off their leases the next month who have high prices since 12 KSM isn't an awful minimum. WDYT? |
Yep, this scenario would be fine. But the same would be true if no core would be sold as we then take the current base price as target price.
Indeed the renewal price would then be 128 KSM, which is a bit much. They could go down and wait for the market, but then losing their renewal guarantee. So yeah, a migration adjusting the renewal price to the current price makes sense. We should also adjust periods - the fix price length can be much shorter. |
Ah great, knew I was missing something - this makes more sense. I was mixing up the target price and base/min/regular/fixed price (🫠).
I agree. However in general this is the minimum time that the secondary markets have to operate within, so we don't want to go too short on it. Maybe roughly 1:1 primary:secondary? Or what were you thinking? I suppose it could even be 2:1 if we expect the target price to be usually correct long term. |
|
Good point on secondary markets! I was thinking 2:1. 2 weeks leadin, 1 week fixed, but we can also leave it as is, because price wise we are actually fine: If the migration hits before rotate sale - we already concluded that we are fine, if it hits after then the price for renewals is already determined by the old controller - so we are good as well. On the next sale the prices will be adjusted already. So lease renewal price will be 12.8 not 128. |
|
@muharem ready for review. |
| #[cfg(feature = "runtime-benchmarks")] | ||
| type PriceAdapter = pallet_broker::Linear; | ||
| #[cfg(not(feature = "runtime-benchmarks"))] | ||
| type PriceAdapter = PriceAdapter; |
There was a problem hiding this comment.
for my education: are benchmarks updated in a separate PR? what is the current process? #324?
|
/merge |
fellowship-merge-bot
bot
merged commit 2539cb5
into
polkadot-fellows:main
|
Enabled Available commands
For more information see the documentation |
