Coretime training wheels

[bkchr]

RFC#1 introduced agile Coretime. We have it now running since last year on Polkadot and Kusama. From the beginning it was rather obvious that the market dynamics are not going to work with low demand. There was some changes to the price calculation, but without any real impact. I don't think that we can fix low demand with improving the price calculation right now. The price is too low (kind of wanted), but also the demand is not there. If we increase the price too much, it will be more expensive to deploy on Kusama and Polkadot. Clearly an effect that we also don't want to achieve right now. Thus, I propose that we introduce training wheels to the Coretime system. I would propose that an account can be registered by governance that gets a fixed amount of tokens assigned per month. This account should be a small DAO of people to which interested parties can reach out (documented in the Coretime docs in the wiki). This DAO would then do some basic checks if the buyer is a reasonable candidate and if yes, give a Core to them. This should prevent that all cores are sold out when someone actually needs them. Later when the system works as intended, governance can just should down this functionality again and let the market fully decide on the price per core.

Not sure this should be a RFC or we just keep it as an issue. I'm open to suggestions.

[xlc]

Maybe just add a new opengov track for purchase coretime?
We can have say 50% of the cores available on market using current mechanism, and 50% reserved and can only be purchased via a referendum

[bkchr]

Yeah could probably also work.

[seadanda]

Yea I agree with the problem.
In the short term we could solve something like this in either of the two ways described above, or a third option could be:

Introduce a ref track which allows you to add a PotentialRenewal into storage at their suggested price. When the interlude comes, they can pay this price to get a core before the rest of the market can buy anything.

This allows you to beat the competition given that you're willing to pay a certain amount - you can demonstrate that you value coretime above the amount at the start of the lead-in period, something which we're not sensitive to at the minute.
The price they offer doesn't actually need to be more than the start price of the lead-in period, but in the ref the interested party can explain their project and pay a low price but persuade voters that it is worthwhile, or give no details about their project but demonstrate that they're willing to pay a price well above the market price (or anything in between). This also means that the core purchase is fixed on a given para ID to try to ensure people use it for projects, rather than speculation.

The advantage of this (and why I've mentioned some implementation details here) is that it would take relatively few changes to implement, it doesn't need any partitioning of the cores sold or changes to the market dynamics and it would just be another core which can be bought in the interlude before the market opens.

IMO it's fundamentally the same as @bkchr's idea, but implemented in a way that requires few changes and the DAO is just Polkadot governance.

[bkchr]

Sounds like a great idea :)

[eskimor]

Another thing we could do, is to adjust the system to optimize to always have at least some cores for sale.

We define something like:

MAX_CORES = 100,
MIN_CORES_FOR_SALE = 5,

Now at the beginning of a sale, if we would find that we had less than MIN_CORES_FOR_SALE to offer, then we would increase the core count so that we have at least MIN_CORES_FOR_SALE (assuming we still have leeway until MAX_CORES).

On the flipside, to ensure we always have leeway, whenever the price goes down below the target price we linearly remove cores from the sale (and total count) until the floor price, maxing out at removing MIN_CORES_FOR_SALE cores.

So each time the price drops we put some cores aside to have them, in order to automatically add them back when demand goes up again.

This should achieve two things:

1. Prices should drop less, as some cores get removed each time the price drops - there is a bottom.
2. Even if the price still drops a lot, people can no longer censor the system. As each sale another 5 cores will be offered (each time at a higher price).

Sniping would still be possible, but would already be way less "lucrative" as to be effective you would need to snipe at least twice and the second time will already cost 10x from the previous time.

Does not help with people forgetting to renew, but should already help a big deal with new projects starting out. What we could also do against snipers is to limit core sales to one core per block. This way one can not just buy all the cores right at the beginning in one go and the whole sniping process would become more costly as you would need to outbid all honest parties (via tips) on each and every block where cores are still for sale.

[eskimor]

As a stop gap for Polkadot, given that prices go 10x already, we can just manually add 5 more cores for now to mitigate the situation in the next sale. (Won't help teams that forgot to renew)

[bkchr]

Another thing we could do, is to adjust the system to optimize to always have at least some cores for sale.

If someone wanted to buy all the cores, they could still do this via multiple sale rounds. So, this doesn't really prevent someone doing "bad things".

[eskimor]

But each time, price goes 10x. You can only do this so often - and especially if we don't flood the system with cores (as we did on Kusama) to begin with, prices should never go that crazy low. If you start with reasonable prices, 10x is already a lot, 100x ... well.

It does not prevent someone with big pockets to mess with the system just for the fun of it (for a while) - for this the governance approach is the only way. Nevertheless, I think it would be a good improvement on top.

[web3gautam]

I think we could make the system similar to domain name sales. The interlude period could be extended till the end of the lease + 1 week, and if the core is not renewed until then, it can be purchased by another party. Something like a small grace period similar to how domain names can't be purchased by a new party during this time after expiry.

Current renewal mechanics of 1 week interlude period at the beginning of the lease (if I understand correctly) is not ideal. At the end of the day, it is a tradeoff between maximum efficiency of coretime sales and safety net for production parachains that should keep producing blocks. We can aim for some middle ground with this grace period approach.

[jonasW3F]

I want to add two things to this discussion. One, more general about coretime sales, and another that is about this topic:

1. I've also shared in the forum post that we should eventually subject renewals to market forces and stray away from the idea of providing predictable prices in the future, because it prevents the market to properly function. While my RFC from 2023 might need some additional revisions, harnessing some ideas could improve the current situation. Ultimately, we need to shift away from the idea that we can give predictable price increases in the future under all circumstances.

In a situation with real demand, it would prevent an entity of holding on to unproductive cores for too long.

2. An adjustment as mentioned above might not solve the problem discussed here, because in the absence of much demand it might still cheap enough to occupy all the cores. I might miss something (just catching up after being ooo), but would it be possible to credibly lend a core for a month to another account and transfer the right to use it (but not the right to sell it) for that duration? The "original owner" of the account would be responsible for renewing. That would basically allow a DAO (or a collective organized by a bounty) to hold on to a few cores and lend them to people that make their case (off-chain). We wouldn't need any whitelisting through governance, because they'd renew on their own costs. This "program" would only work as long as funding is high enough through Treasury. But not being able to pay the market price for that collectivewould be a good problem to have.

[burdges]

A "low but not too low" minimum price solve one of the original issues raised here.

Assuming we've too much usage eventually, and not yet ready to do multiple realy chains, then we'd still need some stability in the product offerings. In practice, an important but not-so-busy and not-designed-profitably parachain would be being outbid, but the community would demand they remain active, and they would not wish to give up their token to transition to a system parachain. This is (hopefully) going to happen. We'd solve this in governance more than code, but we need the time for governance to react somehow.

Step 1: We should record, display, and retain staistics about parachain block utilisation over time, not simply as something you can sync each parachain to discover, but as actual running statistics for all parachains. This means that when we have a conversation about a parachain getting into trouble, then we can discuss their

Step 2: We should make it relatively easy, and efficent in terms of messages etc, for parachains to add a DOT fee on top of their own internal fee structure. In this way, if a parachain gets dropped down into pay-to-go, and pay-to-go seems high for them, then they can easily make their pay-to-go not lose money. This would be pretty easy with SPREE, but reasonably approximations make some sense, assuming nobody pumpt too many DOTs into the parachains' approximation for local DOTs.

[HermanSchoenfeld]

To solve the issue of CoreTime hoarding in-protocol, the supply of CoreTime supply should be offered in batches and permit only 1 batch per time-period to be sold. For example, if there's now 66 Cores available, then create 11 batches of 6 Cores and only offer 1 batch per day. This allows the market to catch up and price discovery to unfold.

In real-estate, this is how apartments are sold when a new residential building is constructed. They don't flood market with 200 apartments for sale all at once, they sell them in batches to control the supply and achieve maximal price.

[ordian]

I was wondering if instead of making coretime assignment permissioned for all cores, we could instead allocate some of the core the polkadot technical fellowship, which could act as a reserve (need to returned back still after a period of two) in case of hostile cores acquisitions like we have witnessed, but also for community events like spammening.
@sandreim wasn't the plan to increase the number of available cores anyway?

[jonasW3F]

I was wondering if instead of making coretime assignment permissioned for all cores, we could instead allocate some of the core the polkadot technical fellowship, which could act as a reserve (need to returned back still after a period of two) in case of hostile cores acquisitions like we have witnessed, but also for community events like spammening. @sandreim wasn't the plan to increase the number of available cores anyway?

that's essentially what I am proposing above.

[sandreim]

I was wondering if instead of making coretime assignment permissioned for all cores, we could instead allocate some of the core the polkadot technical fellowship, which could act as a reserve (need to returned back still after a period of two) in case of hostile cores acquisitions like we have witnessed, but also for community events like spammening.

Yes, having a bag of cores allocated to the technical fellowship sounds like a good idea but only for the purpose of spammening. For the general case, I think it depends on the way we want to go forward, but I do like the DAO approach.

@sandreim wasn't the plan to increase the number of available cores anyway?

It was, but we decided to not increase for the time being due to low price issues. I would suggest we decouple the coretime training wheels from the spammening needs.