Broker: Introduce min price + adjust renewals to lower market.

[eskimor]

This PR provides:

1. The means for the runtime to configure a minimum price for sales.
2. Prevents renewals to get detached too much from current market, by bumping them at least to the end_price of the current sale.

TODO:

• Implement
• Add tests
• Fix runtimes/Make Rococo + Westend use the new price controller.
• prdoc
• Leave configurability to the runtime

[bkchr]

We don't really need this pr? We can just move this to the coretime-chain in the fellowship repo and add the minimum price check?

[eskimor]

Except that we do need some pallet to have the minimum price configurable. Also this PR adjusts renewals if they drop too low compared to current market price.

[bkchr]

No we don't need to. The minimum price could be placed into the parameter pallet for example (if it really needs to be configurable)

[eskimor]

Interesting, wasn't aware of this pallet. Are we talking about this one. If so, it says it should not be used in production?

[bkchr]

Yes this pallet.

If so, it says it should not be used in production?

https://github.com/polkadot-fellows/runtimes/blob/f33a68e0f7240e27df8e5ed6fd7deb8760c094c6/relay/kusama/src/lib.rs#L754

[eskimor]

I'll suggest we go with static values for now. That parameters is not yet on Polkadot and apparently should also not be there (not audited yet), so we could only use it on Kusama anyways.

[eskimor]

/cmd prdoc

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/15272456686
Failed job name: fmt

[Overkillus]

I have no concerns about the code itself. All looks fine and tested.

I have some questions or remarks about the overall behaviour though. As of the sale happening today the current auction max price was 98 DOT. Next cycle as far as I understand the new max price will be around 1000 DOT since all cores are sold out. If we would merge and activate this PR then if there are some cores on sale next month, and if those cores are sold for 1k DOT then all renewals will jump to 1k DOT. Are we ready for that? Do we plan to communicate it? Because I am afraid this will start a nuclear shitstorm in the community. We were promising teams stability and then boom, 1k DOT for a renewal.

I was on stage at Sub0 telling teams that they can expect at most 66% year on year renewal price increase and this is on record. And now we are doing a reverse rugpull here. This HAS to be insanely clearly communicated and it has to be the decision of the token holders and not a random obscure and obfuscated vote.

I know we need to fix the current situation so I don't intend to block it, but just wondering how we can do it with the least amount of damages.

---

If we'd set the minimum to sth like 100 dot then we could keep the old price renewal price scaling model. Wouldn't it be enough of a deterrent to the baron? If he wants to hoard 20 cores -> 20*100DOT = 2k DOT per month just to maintain the attack.

Issue is now the renewals are borderline free but bumping them to clearing price seems very aggressive considering we can go 10x each cycle. This PR changes renewals from max 1.66x per year to max 10^12 = 100_000_000_000x per year 😅

[eskimor]

Where are those 1k Dot coming from? If we add more cores, renewals should be 10 Dot. But even if all cores sold out at 1k, then renewals would still be 100 Dot and not 1k.

Renewals would still be relatively stable - you only get adjusted if the market goes >10x and only if you managed to get a renewal at a bargain. If you bought at current market price, then market needs to go 100x for your price to be affected.

So yes, we are breaking the price stability a bit, but only marginally (biggest change will be the introduction of the minimum price) and we seemed to have broad agreement that this is needed: We need to adjust to current market at least a bit.

[Overkillus]

Didn't know we plan to inject some new cores. This makes me a bit calmer, but the question is how many cores?

We are at cycle N. Max price in cycle N was 100 DOT and that was also the end price. A new auction cycle N+1 is starting in a few days. The maximum in cycle N+1 will be 10x100 = 1k DOT. Renewals in N+1 would be (if this change enacts) 100 dot. If someone buys the remaining cores in N+1 for 1k DOT then N+2 renewals will be 1k DOT.

Imagine we inject a single core at N+1. Then in N+1 the attacker needs to buy a single core for 1k DOT to raise the renewals to 1k in N+2.

If we injected more cores then this isn't such a big deal as buying all gets expensive.

This ties the price of renewals very heavily to the price of the last core and opens up for some abuse. It is one thing to make new potential customers unhappy when no cores are available (delaying their launch) but skyrocketing renewals might piss off current loyal clientele.

[eskimor]

End price is not the clearing price, it is the lowest price that can be reached in the Dutch auction. If all cores are sold at 1k, then the end price will be raised from 10 Dot to 100, which is what renewals would be adjusted to.

They still have plenty of price stability. In the sense that the market went 100x, while they only suffered a 10x.

[Overkillus]

End price is not the clearing price, it is the lowest price that can be reached in the Dutch auction.

That makes sense. I initially misunderstood the end_price param. This makes it a lot more expensive to manipulate.

Even in the worst possible scenario the attacker has to spend roughly 100x of what the next renewals will be so considering there are around 100 cores being renewed does not lead to an amplification attack.
In fact it is 10x. Attacker can just not buy cores in last cycle but renewals will stil adjust to end_price. So there is a bit of an amplification attack.

Attack gets much harder when there are more that 1 core on sale. Overall I'm slightly worried about an attack here. It is still expensive but possible.

---

Let's assume we bump minimum to 10 DOT.

Cycle N: (current)
start_price = 100 DOT
end_price = 1 DOT

Cycle N+1:
renewals = max(10, 1) = 10 DOT
start_price = 1k DOT
end_price = 10 DOT

Renewals will still be a neglibile cost for the Baron. He can continue hoarding his cores.
The start_price in open market is already quite noticeable should be a major deterrant against attacks sniping all at the start.

Cycle N+2:
renewals = max(10, 10) = 10 DOT
start_price = 10k DOT
end_price = 100 DOT

Hoarding is still very cheap even with 20x cores. Buying on open market got quite expensive. Unlikely someone buys all cores for 10k now. If someone did...

Cycle N+3:
renewals = max(10, 100) = 100 DOT
start_price = 100k DOT
end_price = 1000 DOT

Renewals bump quite a lot and hoarding gets expensive (20*100 = 2k DOT per month). Onboarding gets expensive as well with 1k DOT per core minimum but not unfeasible. Sniping gets borderline impossible with 100k DOT per core.

Getting to this state will take us 3 months.

Cycle N+4:
renewals = max(10, 1000) = 1000 DOT

Just to be clear we can reach this renewal price EVEN if the cores dont sell out in N+3.

---

If we would inject 2 cores per month. Total cost of starting with 20 + buying all each month is:

N: 20x10 + 2x100 = 400
N+1: 22x10 + 2x1k = 2_220
N+2: 24x10 + 2x10k = 20_240
N+3: 26x100 + 2x100k = 202_600

N+3 becomes completely unreasonable to snipe but renewals are still 100 dot which is a sensible price.

N+4 renewals will be 1k DOT even if the cores dont sell out for 100k. This might be a bit of an issue. Assuming we inject 2 cores this will be roughly 23k DOT to bring all renewals to 1k and if there is only a single core it will be 10k ish.

I think a minimum of 10 DOT is a bit too little and renewals don't matter untill we are 3 months in. 50 DOT should be a stronger deterrant while still being cheap for actual teams.

[paritytech-release-backport-bot]

Created backport PR for stable2412:

• [stable2412] Backport #8630 #8712 with remaining conflicts!

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-8630-to-stable2412
git worktree add --checkout .worktree/backport-8630-to-stable2412 backport-8630-to-stable2412
cd .worktree/backport-8630-to-stable2412
git reset --hard HEAD^
git cherry-pick -x 1a8313fb2f88053e931370811973e8ce0394686a
git push --force-with-lease

[paritytech-release-backport-bot]

Successfully created backport PR for stable2503:

• [stable2503] Backport #8630 #8713