Revisit Market Design of Coretime Sales

[jonasW3F]

In this RFC, I aim to present several suggestions for fostering a closer integration of the different Coretime markets and for enabling a more systematic alignment with market forces.

[rphmeier]

This may be out-of-scope.

I think coordinating Instantaneous prices with bulk prices is difficult to do in practice, although the Coretime chain could periodically send hints for updating the base price for instantaneous cores. These would probably be better as hints, though, and treated as a nudge to the current spot price rather than a reset.

[jonasW3F]

I am only proposing to initiate the instantanous market with a price. It would quickly adapt (block-by-block) by some supply/demand function as proposed in the original RFC (via some queue system). My general assumption is that coretime of the instantanous market is a (non-perfect) substitute, so I expect prices to be somewhat correlated. Therefore, it is reasonable to initiate the market with the market price (and some discount) and then let the price adjust dynamically block by block.

[rphmeier]

That is still a quite strong assumption - even that instantaneous might be discounted. Perhaps instantaneous coretime is more valuable. Forcibly adjusting the sell price rather than allowing it to naturally float towards its market price (which, if it is an imperfect substitute, should be in the neighborhood of the pro-rata bulk-price anyway) seems unnecessary. This is not the main point of the RFC but I would prefer if this were not part of it.

[jonasW3F]

You might be right, I take the argument that the market would drive the price on the instantanous market towards the bulk market prices on its own. I'll remove it from the proposal.

[rphmeier]

What's the motivation for 14 days of auctioning? What would be the shortest reasonable period for an auction?

[jonasW3F]

In the current design, I move all unsold cores to the instantanous market, therefore I wanted to give reasonable time for new-joiners to buy in the primary market. But I have no strong opinion on that, we could reduce the MARKET_PERIOD to 7 days and add the 7 days to the settlement phase.

[rphmeier]

It's unclear what "all tenants" means here, but coretime is likely to change in value based on volatile factors. While it seems reasonable to give the same price to all simultaneous bulk purchasers of coretime, the secondary market should set the price otherwise.

Phrased as broadly as it is here, this is a non-goal of the system

[jonasW3F]

The clearing price dutch auction resolves such that all bidders in that market pay the same price (MARKET_PRICE) at the end. All entities that renew their cores would also pay the same price. Renewal prices differ from the MARKET_PRICE by RENEWAL_DISCOUNT. I'll make that more clear.

[rphmeier]

This is somewhat idealistic. Enshrined renewals are "messy" from a purist perspective, and I would also like to see them go away eventually, but in practice they're a better offering until market infrastructure for renewals matures significantly (so longer-term stable products can be built on top of this mechanism). This has two key parts:

• coretime hedging products
• technology stacks for automated smart-contract bidders in the auction

I would much prefer revisiting a proposal removing enshrined renewals when the coretime market is more mature.

[jonasW3F]

I tried to mitigate the risk of having to change the system later by making it more robust to potential different market situations. In particular, I'd be afraid of core capturing by giving price guarantees to long-term projects, that have a strong interest not to change the system later and give away their privileges. By that time, they might have a large user base and strong influence on governance.

In times of low demand or low competition (i.e., more supply than demand) for coretime, we'd expect little to no bidding in the MARKET_PERIOD. That would lead to a reversal to the RESERVE_PRICE. Then, the system boils down to moving the price up or down, equal to RFC-1, only by making adjustments through capacity (with BULK_TARGET, BULK_LIMIT).

In times of high demand or high competition, we'd allow the price to more closely reflect that within one period. In addition, by requiring current tenants to renew at a (close-to) market price, we allow to translate that competitive power to them. We still guarantee to pay (if they can pay the market price) but avoids core captures of not-so-useful-projects that just made it in earlier and benefit from the static increase in prices.

[rphmeier]

Unfortunately (and this wasn't stated absolutely clearly in RFC-1), dutch auctions are quite difficult to implement correctly in a blockchain environment with bounded storage and computation costs. The "lead-in" period approach of RFC-1 trades off theoretical elegance for implementation elegance.

I tend to agree that auctions for bulk coretime (followed by splitting and trading) should be the natural conclusion for the market mechanism, but it is too early for that.

[jonasW3F]

I cannot judge whether the stated mechanism exceeds the available storage and computation costs, so I'd leave that assessment to experts like you.

[eskimor]

Nice. I think the auction model makes obvious sense, I do have doubts about renewals though.

[eskimor]

I think this is against our original goals. What we want (as far as I understand):

• Maximize core utilization
• Price predictability for projects, because people need to be able to plan.

The automatic renewal based on a continuous lease (no selling of slices) is already against goal 1, as it incentivizes people to not sell block space they actually don't need and will instead just produce empty blocks. This is already not great, but giving them a discount makes it even worse as it then is actually cheap to do that!

So having a guaranteed lease should be more expensive than ordering on the free market - at least on average. We would like for projects to use the free market as much as possible, as this maximizes utilization.

What we want though, is that long term projects don't suddenly have 10x fees, just because there was a spike in demand. It is questionable how big such spikes could even be on that time scale, but let's assume it is an issue. What I would be proposing is that renewals cost something like the average price of the last year's worth of sales plus some x%. This should give projects the required planning certainty, while still making it cheaper (on average) to just buy exactly what you need (and nothing more) on the market.

We then also have the above x as a screw to adjust utilization. If governance considers it too low, we just make x larger.

[jonasW3F]

Thanks for your comments, let me address your comments with regard to your stated goals:

1. Maximizing core utilization: I agree that this sounds like an important goal. But, in my opinion, it is more nuanced than this. While Polkadot UC offers more supply of coretime than demand, this could be true. But in times of higher demand than supply, we need to add some important part to this goal: We want to achieve maximally efficient coreusage. That requires us to put all consumers under constant pressure to pay (at least roughly) the current market price of coretime. My proposed model tries to achieve that. With regard to RENEWAL_DISCOUNT, I was also hesitant to add it. We could set it to 0, of course. My rationale to give some discount was that (correct me if I am wrong), that renewed coretime cannot be sold on the secondary market. That makes them less fungible (and less flexible), therefore allowing for some discount. In addition, it helps to give current tenants more safety, something that I inferred was also part of the goals.
2. Price predictability: This goal is obviously contradictory to a fully functioning market and points raised before. My proposed mechanism, however, still gives some price predictability. The price in a year for a current tenant can be calculated (as higher bound) as follows: Assuming 100% core usage and the resulting increase in price of RESERVE_PRICE every month (the function is still left undetermined, both in my RFC and RFC-1) and a maximum premium of 30% at the end of the last month (minus a potential RENEWAL_DISCOUNT). In my opinion, this still leaves enough certainty, while allowing for more market forces. That means, current tenants are protected from "suddenly paying 10x fees", because the price within a BULK_PERIOD is capped by the PRICE_PREMIUM (say 30%). That means, they are protected from suddenly paying 10x the fees. But they might be over a longer period of time pay 10x the fees, but that means the market and demand for coretime is so high, that they should be paying 10x the fees. Because otherwise very good waiting projects cannot compete and get in.

[eskimor]

I somehow missed the boundedness. In this case we only need to make sure it is reasonably bounded, in order to be able to reasonably plan with the worst case.

For the discount part: I think you should be paying more: In exchange you know exactly (or at least way better) in advance what you are going to pay. Projects then just need to pick what they need: Basically paying an insurance fee against price surges or going cheap and take the risk. You can evaluate your decision based on your requirements from time to time, but there should be no need to re-adjust each month (as there was some concern with a previous proposal).

Ideally we would make it so that we can do away with the no selling of parts of the coretime, as this would benefit utilization, but only let people pay for price stability. In the end, I think it should be some kind of insurance: Where you always pay a premium, but in exchange your price curve is flattened/evened out. This could actually be a service on the secondary market already, but I think we consider this essential enough to put it into the core directly.

[jonasW3F]

thanks for the hint, I'll highlight in the RFC directly that the price is reasonably bounded (and mostly driven by the price adjustment of the reserve price that is identical to RFC-1).

With regard to the discount part:

1. I disagree to have current tenants pay more simply because of the fact that they would rather buy the core (maybe anonymously) in the MARKET_PERIOD, then not renew, and then jump into the new core. This creates unnecessary overhead for Polkdaot UC. Of course you could argue that they face some uncertainty of not getting the core they bought and are left without any, but its just messy. My goal was to create a system where the best strategy of a current tenant is to simply take the offer they get and not needing to participate in the auction again.
2. I tend to agree that we could remove the discount if we make the renewed coretime fully fungible. But I was under the impression that this is somewhat a technical restriction, and given this assumption together with the fact that we like to give some advantage to current tenants, giving a small discount seems reasonable. The "priority right to stay" when you pay exactly the market price is just not that much of a priority.

[eskimor]

I think what matters is that you can be certain to renew your slot. E.g. you not suddenly find yourself outbid and then you don't have a core for the next month. The other thing is just the already mentioned ability to plan ahead .. have some price certainty. I don't think a small discount on the most recent market price does anything to either goal.

[eskimor]

Doesn't this make front running even more profitable? Like I know that someone is going to bid for a lower price, so I can bid at a higher price, taking precedence, but not actually paying that higher price?

[jonasW3F]

I am not sure front running with a higher price could actually be profitable. It seems to me that you are actually making a case for the fact that this is more robust to front running, because you can simply bid early and benefit from a lower price later. I am not sure how mechanisms of front running would be deployed in practice, but I guess you'd need to control a substantial amount of validators / collators, which does not come for free. Given what I said above, I'd even say that it's less likely to see front running.

[eskimor]

What we actually should be aiming for is that renewals are more expensive than participating in the open market, at least eventually. Renewals work against allocation efficiency, so they should also be interesting for teams really really needing that consistent 6s coretime, willing to pay a premium to get it.

[jonasW3F]

If renewals are sufficiently in sync with the market price (at least eventually), I don't see a reason why we should make it necessary to jump to another core. Jumping to another core, i.e., actively participating in the bidding, has some overhead and I'd prefer the situation where a team just has an account full of DOT that automatically calls renewal in every period and the team just has an eye on the price / balance.

The only good thing about the hopping is that that it is not detrimental if the renewal price runs away in the upper direction, but I don't see why it should generally.

I think it is fine to set the renewal price at the current market price or slightly below.