Broker configuration for coretime-kusama

tl;dr:

Start sales parameters:

initialPrice: ~5 KSM
coreCount: 3

Configuration parameters:

advanceNotice: 10 (1 min)
interludeLength: 50400 (7 days)
leadinLength: 50400 (7 days)
regionLength: 5040 (28 days)
idealBulkProportion: 1000000000 (100% for the first few sales)
limitCoresOffered: 3
renewalBump: 30000000 (3% per sale / ~47% annually)
contributionTimeout: 5040 (28 days)

Price adapter behaviour:

leadin_factor_at: linear with a max of 5x
adapt_price: linear with conservative limits, maximum factor not relevant for our ideal bulk proportion settings, but set to 1.2 as a conservative limit in case we want to change config without a runtime upgrade.

Start sales reasoning

This is purely for the first sale, after which the price adapter takes over.
We suggest a starting value between ~4.4 KSM and ~36.8 KSM depending on the figure we assume for the utilisation. These values represent those for the average (mean) of 13% and for maximum utilisation of 100% respectively. We estimate that the true market price lies between these two values, and so we suggest starting from the average (mean) with a lead-in factor of 5.
This lets the market decide between guardrails of ~13%-65% utilisation in the first sale. We then round up the suggestion to 5 KSM to acknowledge the uncertainty around this value.

This is based on the model set out in Erin's proposal and (also Erin's) Kusama tweak to reflect utilisation.

Configuration reasoning

/// The number of Relay-chain blocks in advance which scheduling should be fixed and the
/// `Coretime::assign` API used to inform the Relay-chain.
pub advance_notice: RelayBlockNumber,

advanceNotice: 10 (1 min) - We require ~10 blocks to send notifyCore messages for 100 cores if the max is 10 XCM messages per block. Note 6s blocks

/// The length in blocks of the Interlude Period for forthcoming sales.
pub interlude_length: BlockNumber,

interludeLength: 50400 (7 days) - gives people ample time to renew without reducing sale too much. Note 12s blocks

/// The length in blocks of the Leadin Period for forthcoming sales.
pub leadin_length: BlockNumber,

leadinLength: 50400 (7 days) - price drops for 7 days before becoming fixed, then is fixed for just 14 days before we hit the next region. Note 12s blocks

/// The length in timeslices of Regions which are up for sale in forthcoming sales.
pub region_length: Timeslice,

regionLength: 5040 (28 days) - this is in timeslices, which are set to 80 blocks in the coretime-kusama runtime. These blocks also are relay chain blocks (6s)

/// The proportion of cores available for sale which should be sold in order for the price
/// to remain the same in the next sale.
pub ideal_bulk_proportion: Perbill,

idealBulkProportion: 1000000000 or 400000000 - 100% paired with a small core offering or 40-60% when more people are off their leases and there's a more fluid market with a higher core limit later on - this needs to be modeled before being updated after the first few sales

/// An artificial limit to the number of cores which are allowed to be sold. If `Some` then
/// no more cores will be sold than this.
pub limit_cores_offered: Option<CoreIndex>,

limitCoresOffered: 3 initially - This should replace the auctions that were cancelled (coupled with 100% target means we don't cause price spikes)

/// The amount by which the renewal price increases each sale period.
pub renewal_bump: Perbill,

renewalBump: 30000000 - 3% every 28 days equates to around 47% annually

/// The duration by which rewards for contributions to the InstaPool must be collected.
contribution_timeout: Timeslice,

contributionTimeout: 5040 (28 days) - not much thought behind this one, 1 region to collect seems like a good starting point. This is not relevant until the Coretime Credits are implemented on the relay chain.

Price adapter reasoning

For the price adapter the main goals are to avoid frontrunning, while also minimising volatility in the early sales. The assumption is that the price will take time to stabilise, and with large corrections we end up flip flopping between values far above and far below the true market price, which will take longer to stabilise the higher those values are between sales. We assume few cores per sale and take into consideration the fact that most cores are occupied by a lease.

The decision to go for a higher lead in factor and a very conservative price adapter are due to the expectation that the early sales will be set such that all cores are sold. A high lead-in max factor allows people to buy at the price they feel comfortable, which affects the market price. This in combination with a conservative price adapter (at the start with no upward correction) means that the price that people are willing to pay is used in the next sale when the cores are sold out, and is adjusted downwards if not all cores are sold. In the case where no cores are sold a minimum factor of 0.5 is applied to gradually bring the price down until a price is found, rather than having something symmetrical which snaps up then can rebound right back down in the extreme case.