Coretime renewal price is wrong

[xlc]

The renew price suppose to be x% plus last purchase price, which is not happening currently on Polkadot coretime chain. All renews are 100DOT or more and their last purchase prices are well below that.

I think it is caused by this, which overrides the actual price https://github.com/paritytech/polkadot-sdk/blob/b4732add46910370443d092a3f479986060f6df5/substrate/frame/broker/src/tick_impls.rs#L219

[eskimor]

What do you mean their last purchase price? There was no last purchase price for any chain on Polkadot as of now. How it is supposed to work: https://grillapp.net/@eskimor/agile-coretime-renew-pricing-explained-182686?ref=12935

[xlc]

There was no last purchase price for any chain on Polkadot as of now.

I don’t understand. This is the second sale and the renewal price for first sale is wrong.

Can you explain what does the linked code supposed to do? Why it is (over)writing renew price with target price?

[eskimor]

The renewal price is determined well ahead of time, as explained here.

[xlc]

Not sure if I misread or something. but can you explain how is 100 dot renewal price is calculated?

[eskimor]

It was set for initialization for the first sale as the first sale has no previous sale to base this number on. All further sales will use the actual sellout price of the previous sale for lease renewal price.

Calculation is roughly based on this.

[xlc]

can you walk the numbers with me please? I want to know how is the number calculated

core 52 is sold 52.86 DOT

but the renewal price is 103 DOT

the renewal bump is 3%

can you point me out which line of code is writing 103 DOT to the stroage and how is the 103 DOT calculated? what are the inputs and which function does the math?

[eskimor]

That's indeed weird, but I just figured out what is going on. As in your screenshot, you can see that someone bought core 52, but Aventus renewed core 60: https://coretime-polkadot.subscan.io/extrinsic/329458-2

So the renew status is for a different core. This is why you see an renewal entry with the previous renewal (100) bumped.

[SBalaguer]

@xlc I think that the issue here is that we are talking about the same core, but at different moments in time. When a task renews it's core, it's assigned a completely new core, they don't hold the same that in the previous cycle. So in this case we have:

• Core 52 was sold on Cycle1 for 52.86 DOT. Once assigned, this core can then be renewed, and renewing it would cost 3% more.
• Core 60 (Aventus, task 2056) was renewed on Cycle2 for 100 DOT (based on the initial pricing @eskimor shared before). This renewal resulted in the fact that task 2056 will be assigned core 52 in the upcoming cycle (Cycle3).
• Renewing core 52 on Cycle3 will be 103 DOT, which is +3% vs what task 2056 paid to renew core 60. This is what you are seeing today on regionX. That's why it says that the core is valid for 7w, which is the remaining of this cycle, plus the following one.

In the end what's confusing is that renewing a core assigns you to another core for the upcoming cycle, you don't maintain the previous one. So core 52 on Cycle1 has nothing to do with core 52 on Cycle3. The only exception is for leases that always maintain their core.

[xlc]

Thanks for the explanation. I guess the UI need to find some ways to make this bit more obvious.