Hello Polkadot Community,

I’m Aurora Poppyseed, a magician (aka magikarp ) at Lastic. I’ve developed a Python-based pricing simulation to decipher and emulate the pricing dynamics of Coretime. This tool is crafted to reflect the pricing functions within the Broker pallet, drawing upon:

Our goal was to create a tool that allows both ourselves and the community to interactively view and explore how different parameters impact core pricing.

The result of this effort is an application that provides our best attempts to closely mirror the actual code’s behavior and offers a hands-on experience for those who wish to delve into the pricing mechanisms. You can simulate different scenarios, modify parameters, and observe the outcomes in real-time.

However, I must admit that there’s a good chance I’ve overlooked something or made a mistake somewhere in the process. This admission isn’t just out of an abundance of caution; it stems from my discovery of what could potentially be a significant vulnerability. As it stands, the slow exponential increase in renewal prices, coupled with the proposed price cap, seems to allow for a scenario where, hypothetically, someone could substantially disrupt the Polkadot network with a rather low incremental cost increase—a factor that could be exploited in what I’ve termed a “50k attack.”

The conditions which would lead to such an attack are the following:

- buy up all the cores
- keep on renewing them indefinitely
- the price will rise in a 1 year horizon only to 2 x
`Starting Price`

Set parameters:

- config values:
`ideal_bulk_proportion`

: 60%`ideal_bulk_proportion`

: 7 days`interlude_length`

: 7 days`leadin_length`

: 28 days`limit_cores_offered`

: 50`region_length`

: 112`renewal_bump`

: 5% - proposed is even lower 2%

`Start price of the Core you Bought`

(*this is the starting price for which you bought the core in the previous sale - impacts the renewal price you are going to pay*): 1000`Starting Price`

(*Represents the starting price of the Coretime*): 1000`Observe Blocks`

(*represents block time each block of time the set parameter is only 4 block times per day - you can change this in code, it allows you*): 1344 - with the parameter set at an example 1344 number we are looking at a one year time horizon`Cores renewed in each sale:`

50 - this number`Cores sold in each sale`

: 0 - this number is capped depending on`LIMIT_CORES - CORES_RENEWED_IN_EACH_SALE`

(in the picture you can see a 2 being there this should be a 0 there that’s probably one of the mistakes that need to be fixed - ignore that)

This matter is something I’m eager to resolve and thoroughly understand. Therefore, I am reaching out to invite the community to provide their insights, scrutinize our Python implementation, and engage in a robust discussion about whether this is indeed an accurate representation of the intended pricing model—and, critically, the potential vulnerabilities therein.

Your expertise and perspective are invaluable, and I would greatly appreciate any input you can offer. Please find the application to play around with, along with our code, at the links below:

- Interactive Application: https://lastic.streamlit.app/
- GitHub Repository: GitHub - LasticXYZ/price-simulation: Price graphs and simulation for cores

I’m looking forward to your feedback and thank you in advance for your time and contributions to this important discussion.

Best regards,

Aurora Poppyseed