Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit Market Design of Coretime Sales #17

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

jonasW3F
Copy link
Contributor

@jonasW3F jonasW3F commented Aug 5, 2023

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.


Blockspace sold through the Instantaneous Market can be viewed as a [substitute good](https://en.wikipedia.org/wiki/Substitute_good) to fixed allocated blockspace. As such, we can expect prices between the Bulk Market and the Instantaneous Market to have a close correlation, aligning closely with the `MARKET_PRICE`. Given the less flexible nature of on-demand blocks, it might be beneficial to introduce a small discount.

A good approach could be to commence the Instantaneous Market with an `INSTANTANOUS_START_PRICE = MARKET_PRICE * INSTANTANOUS_DISCOUNT` (potentially 20%) at the outset of a `BULK_PERIOD`. Under the assumption of a 28-day period, the price for the first block would be set at
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@rphmeier rphmeier Aug 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


The `BULK_PERIOD` has been restructured into two primary segments: the `MARKET_PERIOD` and `RENEWAL_PERIOD`, along with an auxiliary `SETTLEMENT_PERIOD`. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.

#### Market Period (14 days)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

In particular, this proposal introduces the following changes:
- It introduces a `RESERVE_PRICE` that anchors all markets, promoting price synchronicity among it's substitute goods (flexible/renewed/instantanous coretime).
- This reduces complexity.
- This makes sure all tenants pay the same for coretime.
Copy link
Contributor

@rphmeier rphmeier Aug 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- It exposes the renewal prices, while still being beneficial for longterm tenants, more to market forces.
- It removes the LeadIn period and introduces a (from the perspective of the coretime systemchain) passive Settlement Phase, that allows the secondary market to exert it's force.

The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot UC), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority **IF** they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. It must be stated, that potential price increases remain predictable (in the worst-case) but could be higher than in the originally proposed design. The argument remains, however, that we need to allow market forces to affect all prices for an efficient Coretime pricing and allocation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


#### Market Period (14 days)

During the market period, core sales are conducted through a well-established **clearing price Dutch auction** that features a `RESERVE_PRICE`. The price initiates at a premium, designated as `PRICE_PREMIUM` (for instance, 30%) and descends linearly to the `RESERVE_PRICE` throughout the duration of the `MARKET_PERIOD`. Each bidder is expected to submit both their desired price and the quantity (that is, the amount of Coretime) they wish to purchase. To secure these acquisitions, bidders must make a deposit equivalent to their bid multiplied by the chosen quantity, in DOT.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@eskimor eskimor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


#### Renewal Period (7 days)

As the `RENEWAL_PERIOD` commences, all current tenants are granted the opportunity to renew their cores at a slight discount of `MARKET_PRICE * RENEWAL_DISCOUNT` (for instance, 10%). This provision affords marginal benefits to existing tenants, balancing out the non-transferability aspect of renewals.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


As the `RENEWAL_PERIOD` commences, all current tenants are granted the opportunity to renew their cores at a slight discount of `MARKET_PRICE * RENEWAL_DISCOUNT` (for instance, 10%). This provision affords marginal benefits to existing tenants, balancing out the non-transferability aspect of renewals.

At the end of the period, all available cores are allocated to the current tenants who have opted for renewal and the participants who placed bids during the market period. If the demand for cores exceeds supply, the cores left unclaimed from renewals may be awarded to bidders who placed their bids early in the auction, thereby subtly incentivizing early participation. If the supply exceeds the demand, all unsold cores are transferred to the Instantanous Market.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.



### Benefits of this system
- The introduction of a single price, the `RESERVE_PRICE`, provides an anchor for all Coretime markets. This is a preventative measure against the possible divergence and mismatch of prices, which could inadvertently lead to a situation where existing tenants secure cores at significantly below-market rates.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@anaelleltd anaelleltd added the Proposed Is awaiting 3 formal reviews. label Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposed Is awaiting 3 formal reviews.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants