-
Notifications
You must be signed in to change notification settings - Fork 55
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
Dynamic Pricing for Bulk Coretime Sales #6
Open
Tomen
wants to merge
9
commits into
polkadot-fellows:main
Choose a base branch
from
Tomen:anb-dynamic-bulk-coretime-pricing
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 7 commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
5db6229
begin RFC-6
Tomen b4e0084
add examples
Tomen c349dd5
author
Tomen fdda9a4
explaining the function
Tomen 5b73ad5
rfc-6 formatting
Tomen a601225
make parameters beautiful
Tomen 196f285
polishing
Tomen 38be7d5
Merge branch 'polkadot-fellows:main' into anb-dynamic-bulk-coretime-p…
Tomen ed49724
RFC-6 remove images
Tomen File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,189 @@ | ||
# RFC-0006: Dynamic Pricing for Bulk Coretime Sales | ||
|
||
| | | | ||
| --------------- | ------------------------------------------------------------------------------------------- | | ||
| **Start Date** | July 09, 2023 | | ||
| **Description** | A dynamic pricing model to adapt the regular price for bulk coretime sales | | ||
| **Authors** | Tommi Enenkel (Alice und Bob) | | ||
| **License** | MIT | | ||
|
||
## Summary | ||
|
||
This RFC proposes a dynamic pricing model for the sale of Bulk Coretime on the Polkadot UC. The proposed model updates the regular price of cores for each sale period, by taking into account the number of cores sold in the previous sale, as well as a limit of cores and a target number of cores sold. It ensures a minimum price and limits price growth to a maximum price increase factor, while also giving govenance control over the steepness of the price change curve. It allows governance to address challenges arising from changing market conditions and should offer predictable and controlled price adjustments. | ||
|
||
## Motivation | ||
|
||
RFC-1 proposes periodic Bulk Coretime Sales as a mechanism to sell continouos regions of blockspace (suggested to be 4 weeks in length). A number of Blockspace Regions (compare RFC-1 & RFC-3) are provided for sale to the Broker-Chain each period and shall be sold in a way that provides value-capture for the Polkadot network. The exact pricing mechanism is out of scope for RFC-1 and shall be provided by this RFC. | ||
|
||
A dynamic pricing model is needed. A limited number of Regions are offered for sale each period. The model needs to find the price for a period based on supply and demand of the previous period. | ||
|
||
The model shall give Coretime consumers predictability about upcoming price developments and confidence that Polkadot governance can adapt the pricing model to changing market conditions. | ||
|
||
### Requirements | ||
1. The solution SHOULD provide a dynamic pricing model that increases price with growing demand and reduces price with shrinking demand. | ||
2. The solution SHOULD have a slow rate of change for price if the number of Regions sold is close to a given sales target and increase the rate of change as the number of sales deviates from the target. | ||
3. The solution SHOULD provide the possibility to always have a minimum price per Region. | ||
4. The solution SHOULD provide a maximum factor of price increase should the limit of Regions sold per period be reached. | ||
5. The solution should allow governance to control the steepness of the price function | ||
|
||
## Stakeholders | ||
|
||
The primary stakeholders of this RFC are: | ||
|
||
- Protocol researchers and evelopers | ||
- Polkadot DOT token holders | ||
- Polkadot parachains teams | ||
- Brokers involved in the trade of Bulk Coretime | ||
|
||
## Explanation | ||
|
||
### Overview | ||
|
||
The dynamic pricing model sets the new price based on supply and demand in the previous period. The model is a function of the number of Regions sold, piecewise-defined by two power functions. | ||
- The left side ranges from 0 to the target. It represents situations where demand was lower than the target. | ||
- The right side ranges from the target to limit. It represents situations where demand was higher than the target. | ||
|
||
The curve of the function forms a plateau around the target and then falls off to the left and rises up to the right. The shape of the plateau can be controlled via a scale factor for the left side and right side of the function respectively. | ||
|
||
![An image of the baseline graph. The x-axis being cores sold and the y-axis being price. The curve starts at 0 cores sold a price of 1. It rises up and starts to form a plateau shortly before it reaches a target of 30 cores sold, which is also highlighted as target. It then shortly continues on this plateau before sharply rising up to the limit amount of 45 cores sold.](/assets/0006-baseline.png) | ||
|
||
|
||
### Parameters | ||
From here on, we will also refer to Regions sold as 'cores' to stay congruent with RFC-1. | ||
|
||
| Name | Suggested Value | Description | Constraints | | ||
| -------------------------- | ---------------------------- | ---------------------------------------------------------- | ------------------------------- | | ||
| `BULK_LIMIT` | 45 | The maximum number of cores being sold | `0 < BULK_LIMIT` | | ||
| `BULK_TARGET` | 30 | The target number of cores being sold | `0 < BULK_TARGET <= BULK_LIMIT` | | ||
| `MIN_PRICE` | 1 | The minimum price a core will always cost. | `0 < MIN_PRICE` | | ||
| `MAX_PRICE_INCREASE_FACTOR`| 2 | The maximum factor by which the price can change. | `1 < MAX_PRICE_INCREASE_FACTOR` | | ||
| `SCALE_DOWN` | 2 | The steepness of the left side of the function. | `0 < SCALE_DOWN` | | ||
| `SCALE_UP` | 2 | The steepness of the right side of the function. | `0 < SCALE_UP` | | ||
|
||
|
||
### Function | ||
|
||
```math | ||
P(n) = \begin{cases} | ||
(P_{\text{old}} - P_{\text{min}}) \left(1 - \left(\frac{T - n}{T}\right)^d\right) + P_{\text{min}} & \text{if } n \leq T \\ | ||
((F - 1) \cdot P_{\text{old}} \cdot \left(\frac{n - T}{L - T}\right)^u) + P_{\text{old}} & \text{if } n > T | ||
\end{cases} | ||
``` | ||
|
||
- $P_{\text{old}}$ is the `old_price`, the price of a core in the previous period. | ||
- $P_{\text{min}}$ is the `MIN_PRICE`, the minimum price a core will always cost. | ||
- $F$ is the `MAX_PRICE_INCREASE_FACTOR`, the factor by which the price maximally can change from one period to another. | ||
- $d$ is the `SCALE_DOWN`, the steepness of the left side of the function. | ||
- $u$ is the `SCALE_UP`, the steepness of the right side of the function. | ||
- $T$ is the `BULK_TARGET`, the target number of cores being sold. | ||
- $L$ is the `BULK_LIMIT`, the maximum number of cores being sold. | ||
- $n$ is `cores_sold`, the number of cores being sold. | ||
|
||
#### Left side | ||
The left side is a power function that describes an increasing concave downward curvature that approaches `old_price`. We realize this by using the form $y = a(1 - x^d)$, usually used as a downward sloping curve, but in our case flipped horizontally by letting the argument $x = \frac{T-n}{T}$ decrease with $n$, doubly inversing the curve. | ||
|
||
This approach is chosen over a decaying exponential because it let's us a better control the shape of the plateau, especially allowing us to get a straight line by setting `SCALE_DOWN` to $1$. | ||
|
||
#### Ride side | ||
The right side is a power function of the form $y = a(x^u)$. | ||
|
||
### Pseudo-code | ||
|
||
``` | ||
NEW_PRICE := IF CORES_SOLD <= BULK_TARGET THEN | ||
(OLD_PRICE - MIN_PRICE) * (1 - ((BULK_TARGET - CORES_SOLD)^SCALE_DOWN / BULK_TARGET^SCALE_DOWN)) + MIN_PRICE | ||
ELSE | ||
((MAX_PRICE_INCREASE_FACTOR - 1) * OLD_PRICE * ((CORES_SOLD - BULK_TARGET)^SCALE_UP / (BULK_LIMIT - BULK_TARGET)^SCALE_UP)) + OLD_PRICE | ||
END IF | ||
``` | ||
|
||
### Properties of the Curve | ||
#### Minimum Price | ||
We introduce `MIN_PRICE` to control the minimum price. | ||
|
||
The left side of the function shall be allowed to come close to 0 if cores sold approaches 0. The rationale is that if there are actually 0 cores sold, the previous sale price was too high and the price needs to adapt quickly. | ||
|
||
#### Price forms a plateau around the target | ||
If the number of cores is close to `BULK_TARGET`, less extreme price changes might be sensible. This ensures that a drop in sold cores or an increase doesn’t lead to immediate price changes, but rather slowly adapts. Only if more extreme changes in the number of sold cores occur, does the price slope increase. | ||
|
||
We introduce `SCALE_DOWN` and `SCALE_UP` to control for the steepness of the left and the right side of the function respectively. | ||
|
||
#### Max price increase factor | ||
We introduce `MAX_PRICE_INCREASE_FACTOR` as the factor that controls how much the price may increase from one period to another. | ||
|
||
Introducing this variable gives governance an additional control lever and avoids the necessity for a future runtime upgrade. | ||
|
||
### Example Configurations | ||
|
||
#### Baseline | ||
This example proposes the baseline parameters. If not mentioned otherwise, other examples use these values. | ||
|
||
The minimum price of a core is 1 DOT, the price can double every 4 weeks. Price change around `BULK_TARGET` is dampened slightly. | ||
``` | ||
BULK_TARGET = 30 | ||
BULK_LIMIT = 45 | ||
MIN_PRICE = 1 | ||
MAX_PRICE_INCREASE_FACTOR = 2 | ||
SCALE_DOWN = 2 | ||
SCALE_UP = 2 | ||
OLD_PRICE = 1000 | ||
``` | ||
|
||
![](/assets/0006-baseline.png) | ||
|
||
#### More aggressive pricing | ||
We might want to have a more aggressive price growth, allowing the price to triple every 4 weeks and have a linear increase in price on the right side. | ||
|
||
``` | ||
BULK_TARGET = 30 | ||
BULK_LIMIT = 45 | ||
MIN_PRICE = 1 | ||
MAX_PRICE_INCREASE_FACTOR = 3 | ||
SCALE_DOWN = 2 | ||
SCALE_UP = 1 | ||
OLD_PRICE = 1000 | ||
``` | ||
|
||
![](/assets/0006-aggressive-pricing.png) | ||
|
||
#### Conservative pricing to ensure quick corrections in an affluent market | ||
If governance considers the risk that a sudden surge in DOT price might price chains out from bulk coretime markets, it can ensure the model quickly reacts to a quick drop in demand, by setting 0 < SCALE_DOWN < 1 and setting the max price increase factor more conservatively. | ||
|
||
``` | ||
BULK_TARGET = 30 | ||
BULK_LIMIT = 45 | ||
MIN_PRICE = 1 | ||
MAX_PRICE_INCREASE_FACTOR = 1.5 | ||
SCALE_DOWN = 0.5 | ||
SCALE_UP = 2 | ||
OLD_PRICE = 1000 | ||
``` | ||
|
||
![](/assets/0006-conservative-pricing.png) | ||
|
||
#### Linear pricing | ||
By setting the scaling factors to 1 and potentially adapting the max price increase, we can achieve a linear function | ||
|
||
``` | ||
BULK_TARGET = 30 | ||
BULK_LIMIT = 45 | ||
MIN_PRICE = 1 | ||
MAX_PRICE_INCREASE_FACTOR = 1.5 | ||
SCALE_DOWN = 1 | ||
SCALE_UP = 1 | ||
OLD_PRICE = 1000 | ||
``` | ||
|
||
![](/assets/0006-linear.png) | ||
|
||
|
||
## Drawbacks | ||
None at present. | ||
|
||
## Prior Art and References | ||
|
||
This pricing model is based on the requirements from the basic linear solution proposed in RFC-1, which is a simple dynamic pricing model and only used as proof. The present model adds additional considerations to make the model more adaptable under real conditions. | ||
|
||
## Future Possibilities | ||
|
||
This RFC, if accepted, shall be implemented in conjunction with RFC-1. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RFC-3 is a companion to RFC-1, for underlying improvements to scheduling infrastructure - the goal is for them to communicate via RFC-5. But it's probably out of scope for anything related to pricing/sales
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was that just a comment on the relationship of the RFCs or should I change something?