I am someone with an informed opinion about this topic, but I do think that if there is any value in doing this on Kusama as an experiment to learn the effects of it, we should do it. I don't see any downsides to this being executed as an experiment to lead to a better decision in Polkadot.

Dear Proposer,

Thank you for your proposal. Our **first** vote on this proposal is **AYE**.

The **Whitelisted Caller** track requires **60% quorum** according to our [voting policy v0.2](https://docs.permanence.io/voting_policy/voting_policy_v0.2.html), and any referendum in which the **majority of members vote abstain receives an abstain vote**. This proposal has received **six aye and one nay** votes from **ten available members**. Below is a summary of our members' comments:

> The voters expressed strong support for the referendum, with most casting their votes in favor, citing ease of approval and potential benefits for the Kusama project. One voter highlighted the positive impact of implementing the RFC on the coretime market, noting the decision might be revisited based on new information. In contrast, one voter opposed the measure, calling for a more comprehensive analysis of the coretime market and clarification on the nature of the proposed experiment.

The full discussion can be found in our [internal voting](https://voting.opensquare.io/space/permanence/proposal/QmYSnpkjvswnfZU9d4c11Ak7VUh2VQKiPjqCRaE7ac4CrE).

Please feel free to contact us through the links below for further discussion.

Kind regards, Permanence DAO Decentralized Voices Cohort IV Delegate 📅 [Book Office Hours](https://cal.com/permanencedao/office-hours) 💬 [Public Telegram](https://t.me/permanencedao) 🌐️ [Web](https://permanence.io) 🐦 [Twitter](https://twitter.com/permanencedao) 🗳️ [Delegate](https://kusama.subsquare.io/user/EicAs5s99x17qZcQzJMiBCfada9rGyEC6njfiBX3j2EPr9W/votes)

This is not a good idea at this point in time. We need to fix Kusama pricing first, otherwise someone will immediately buy all the cores again at no cost and we are in the exact same situation again. Kreivo would only get a core with this if their maintainers are able to write a better bot than the ones in existence and are willing to tip more.

A hot fix I am planning is to introduce a minimum price, which ensures that the dutch auction starts at something where just sniping all the cores at the top is at least very expensive and unlikely to yield to any profit. I would also suggest to change renewal pricing that they are at least as high as the minimum price in the current Dutch auction, so we get some coupling with market price, but still maintain some predictability. 

Effect would be, if someone snipped all the cores at the beginning of the auction, not only would this be very expensive, that person would also need to pay this price every month (+3%) to maintain them.

[@EPkW...5xJT](EPkWXfndzjYmxpZvCdUXhg6Z9RH1WEW2dGDLLE6AxMv5xJT-kusama) [@olanod](EvoLanodoqDsgHb98Ymbu41uXXKfCPDKxeM6dXHyJ2JoVus-kusama) already proposed that (the minimum price part). It was rejected by the community. But since then, I guess the opinion might have changed.

That said, this sounds reasonable.

Which do you think a reasonable price would be? And more importantly, what would be the best strategy to prevent going back to where we are right now? Because let's say we move it to something like 5 KSM per core. And that no one but the current projects acquire/renew the cores at new prices. They'd be able to get guaranteed cores at a reasonable price (60KSM/yr sounds reasonable, given that with current conditions, price estimations for projects which don't have assigned cores are pretty high).

> Note: There's the potential that, by doing this, we might scare away projects from the ecosystem, due to the changing conditions. Some teams already have cost structures that cover for coretime renewal, and increasing the price too much might just make their costs unattainable.

Then, total silence. No one buys new cores. What would happen then? That in a couple months we'll be back to sub 1KSM prices, then sub 0.01KSM prices. Then, the Baron would snipe again, and we'll be getting a similar situation, where new projects —or projects that couldn't renew— won't be getting a core.

The real solution here is to refine the market model ([RFC17](https://github.com/polkadot-fellows/RFCs/pull/17) is on that) for coretime sales with something more acceptable.

And as to getting that core, AFAIK Kreivo is aware of what's necessary to have the chance of getting a core. But I think opening the conversation to getting back to reasonable prices is a good idea to fix this issue short term.

Recently [Ref#511](https://kusama.subsquare.io/referenda/511) increased the validator set size to 700 and it was expected to increase the usable cores to 140, this ref does this.


EDIT: (extra context)
As I've shared in the comments and other channels, my main motivation for more cores to be available besides the correctness of matching the number of active validators is to allow teams missing a core to have a fair chance to purchase one on the next sale period.
Our parachain Kreivo failed to renew and is now dependent on manually producing blocks on-demand which greatly hurts usability for our users. Instead of requesting a direct core assignment like it was [done in Polkadot](https://polkadot.subsquare.io/referenda/1536), I believe this approach is simpler and fairer as it gives anyone an equal chance to get their core.

- A vote (Ref#511) increased the number of validators to 700, which also allows more cores (140) to be used.  
- More cores mean more teams can buy them fairly in the next sale.  
- One team, Kreivo, lost its core and now has to make blocks manually, which is slow.  
- Instead of asking for a special core, this vote makes it fair for everyone to get one.

Increase usable cores to 140