Revisit Market Design of Coretime Sales#17
Revisit Market Design of Coretime Sales#17paritytech-rfc-bot[bot] merged 36 commits intopolkadot-fellows:mainfrom
Conversation
text/0015-market-design-revisit.md
Outdated
|
|
||
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
text/0015-market-design-revisit.md
Outdated
|
|
||
| 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) |
There was a problem hiding this comment.
What's the motivation for 14 days of auctioning? What would be the shortest reasonable period for an auction?
There was a problem hiding this comment.
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.
text/0015-market-design-revisit.md
Outdated
| 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
text/0015-market-design-revisit.md
Outdated
| - 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures.
Did you mean instead
This prevents a situation where the market price significantly diverges from renewal prices which allows for core captures.
?
There was a problem hiding this comment.
yes, I'll push a fix.
text/0015-market-design-revisit.md
Outdated
|
|
||
| #### 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I cannot judge whether the stated mechanism exceeds the available storage and computation costs, so I'd leave that assessment to experts like you.
There was a problem hiding this comment.
I don't really get how this should be difficult to implement? The total number of buys is bounded by the total number of cores which will never be infinite.
eskimor
left a comment
eskimor
left a comment
There was a problem hiding this comment.
Nice. I think the auction model makes obvious sense, I do have doubts about renewals though.
text/0015-market-design-revisit.md
Outdated
|
|
||
| #### 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Thanks for your comments, let me address your comments with regard to your stated goals:
- 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. - 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_PRICEevery 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 potentialRENEWAL_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 aBULK_PERIODis capped by thePRICE_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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- 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. - 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.
There was a problem hiding this comment.
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.
text/0015-market-design-revisit.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
text/0015-market-design-revisit.md
Outdated
|
|
||
|
|
||
| ### 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
bkchr
left a comment
bkchr
left a comment
There was a problem hiding this comment.
I'm not an economist, but why not just let the people bid for the price per core? Using a dutch auction again requires that we somehow determine the PREMIUM_PRICE and the RESERVE_PRICE. We could let people bid for what they want to pay. Then we take the minimum bid as price for the renewals. The others are paying the price based on their bid.
What do I miss? :)
text/0015-market-design-revisit.md
Outdated
|
|
||
| #### 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. |
There was a problem hiding this comment.
I don't really get how this should be difficult to implement? The total number of buys is bounded by the total number of cores which will never be infinite.
There's a few reasons for that:
A descending auction would incentivize early bidding, because the clearing price ensures that you won't overpay. The fact that you can't pay more than the price currently is at would additionally prevent sniping. |
Not sure you can talk of "price predictability" when the price can go up by 300%. Generally, we should talk to these teams and find out. I think we should give this up.
I would keep the idea of renewing and getting a guaranteed slot, like you explained in the RFC already. So, snipping could only happen against newcomers and the sniper would need to pay the price for this. The current problem is that if you are snipping all the cores they are too cheap. However, if you need to actually pay for it, you will be forced to pay a reasonable (not really forced, but you would loose the money). |
I totally agree. I am currently playing around with a toy model to test different scenarios of demand & supply and finetune the parameters to somewhat work. Maybe 300% is too much for a single period, but then we would need to scale the reserve price more aggressivley in the next period. I am also rewriting and updating parts of this proposal and will finally move away from the restriction of "price predictability" (which makes my life much easier). At least, the price within one period is bounded upwards, which is something teams can work with.
The problem is not so much about efficiency, i.e., who gets the core. The problem is that sniping leads to the fact that everyone is waiting and not participating in the market. Then, whoever is the successful sniper gets the goods but at a very low price. Current teams would still get the cores but at a too low price. If (and I am discussing this in the updated version for this RFC) we want to just have posted bids without any upward restriction, we should re-introduce the candle auctions, which have proven to solve this pretty well. |
Yeah I get this, I mean I would not do this when I want to have some coretime to produce blocks, but I also did not think about all the consequences.
If that solves the problems from your POV, let's do it :) |
…rve_price adjustment, re-defined MARKET_PRICE to CLEARING_PRICE, added DELTA_MIN to recover quickly from low prices
|
I am not a coretime buyer (not yet), but would like to suggest something simple that works to solve today's problem and is very easy to reason about. Is there a reason why we can't use a simple exponential pricing for the RESERVE_PRICE (the minimum price a buyer has to pay per core) formula like
With the above, as we increase from i=0 to i=340 cores (the Toaster target), the price reaches about 100,000 DOT. Its simple enough that a 5th grader can understand it (which is GOOD for a customer base who just wants something simple and predictable), and solves the present day problem really quickly, in a way that I hope could be implemented tomorrow. To give you the math:
You just pick two numbers to replace 190 and 1.01854 and skip all the market based pricing until the 200th core is actually sold. If you have some alternate formula that works so the last core is 3500 DOT (which I think is very reasonable if its the last core!) for the 50 or 100 cores present day, ok! But the key feature of exponential pricing makes it hard for someone to buy up everything and will fend off an attacker -- it becomes 1.854% more expensive for the next core. Again, something a 5th grader can understand in the sense of "Compound interest is the eighth wonder of the world. He who understands it, earns it … he who doesn’t … pays it." |
|
It will be great if we can run this with some numbers covering from edge cases to expected cases so that we can check the numbers are all looking fine under all the scenarios. In fact, we should make simulation results a requirement for all ecnomic related propsoals |
|
https://jonas-coretime.jedda.eu/ here we have a tool to play with some numbers. |
Please try out my tool that Basti has posted. You can find the code for it here (there could still be bugs). The simulator implements the current version of the RFC (only the market phase, but that's the important one). The parameter We should test this with a lot of scenarios and see how it performs. For now, I tried to keep the mechanism as clean as possible, without too many IF and THENs (the previously mentioned |
|
Thanks for your presentation today, @jonasW3F. As mentioned in the call, I'd like to drop a note about the escrow feature which I think should be an integral part of the "secondary market phase" and it seems quite straight-forward to do. Argumentation: While mutual discovery of potential sellers and buyers can be done off-chain without trust issues, the actual transfer requires trust among the trading parties if there is no atomic way to settle on a price, pay and transfer the core.
|
|
We need to get this situated. Community is very unhappy with the current state. Can I propose it for voting? |
|
The RFC is completed since the last pushes 3 weeks ago. I've presented the design to many parachain team members last Monday and the feedback has been very positive. There is nothing blocking us from proposing it. @bkchr wanted to put it up for vote this week. |
I totally agree that there should be some trustless way to exchange a core between a buyer and seller. It does not primarily affect this RFC, but I'll keep this in mind and try to facilitate its implementation as soon as possible. |
|
Hello, I've opened a parallel discussion at the Polkadot Forum proposing an alternative decentralized pricing mechanism derived from a Pareto-optimal convex optimization model. My intent is to explore if this emergent, non-auction-based method could serve as a fairer and more decentralized alternative to RFC #17’s bidding approach, or at least inform benchmarking efforts. Detailed proposal properties, characteristics and open discussion here: |
|
We should discuss anything like that another time I think, so maybe that chat stays on the forum. In this RFC, we're fixing some some glaring near-term problems. |
The proposed design by RFC#17 has undergone extensive discussions and iterations and was presented in front of the current coretime consumers and has been found as a suitable way forward. I've taken a short look on your posts and I am not quite sure which problems it solves and why it is better than the auction-based mechanism that has been proven countless times to be working. You are, of course, always free to propose your alternative design in its own RFC. For now, I expect RFC17 to be up for vote very soon and I hope that the fellowship will accept it quickly. |
| * One implication of granting the renewal privilege after the `MARKET_PERIOD` is that some bidders, despite bidding above the `clearing_price`, may not receive coretime. We believe this is justified, because the harm of displacing an existing project is bigger than preventing a new project from getting in (if there is no cores available) for a bit. Additionally, this inefficiency is compensated for by the causing entities paying the `PENALTY`. We need, however, additional rules to resolve the allocation issues. These are: | ||
| 1. Bidders who already hold renewable cores cannot be displaced by the renewal decision of another party. | ||
| 2. Among those who *can* be displaced, we begin with the lowest submitted bids. | ||
| * If a current tenant wins cores on the market, they forfeit the right to renew those specific cores. For example, if an entity currently holds three cores and wins two in the market, it may only opt to renew one. The only way to increase the number of cores at the end of a `BULK_PERIOD` is to acquire them entirely through the market. |
There was a problem hiding this comment.
Not sure I understand this. Someone could just buy a core and then gift them to an entity that already has some?
Then they would get around this?
There was a problem hiding this comment.
Sorry logged in with the wrong account. going to propose it now.
There was a problem hiding this comment.
What's important is that an entity that already has some cores at the beginning of the market phase obtains certain "protection" only for the total number of cores that they had. This "protection" might be in the form of not being able to be displaced by a renewer if they won in the auction or, of course, renewing in the renewal phase. What is important, though, and this I tried to explain in 2), is that that entity cannot extend the number of cores using these privileges. If they want additional cores, on these they are subject to the same rules as any first-timer. So, the 2) explains that it is not possible to exploit the two privileges to safely get more cores than the entity had at the beginning.
So, in a sense "someone just buying a core and gifting it to the entity" is basically equivalent of that entity just trying to purchase the core themselves. So, there is neither a problem for the market nor an actual benefit for the entity trying it.
I hope that this answered your question, or maybe I misunderstood.
|
|
||
| ### Details on Some Mechanics | ||
|
|
||
| * The price descends linearly from a `opening_price` to the `reserve_price` over the duration of the `MARKET_PERIOD`. Importantly, each discrete price level should be held for a sufficiently long interval (e.g., 6–12 hours). |
There was a problem hiding this comment.
Does it need to be discrete steps? Why can we not do it continuously and the bidder sets a maximum?
|
/rfc propose |
|
Hey @ggwpez, here is a link you can use to create the referendum aiming to approve this RFC number 0017. Instructions
It is based on commit hash 06f6bcd1aa742b06e7761e398d930b7f5d050419. The proposed remark text is: |
Hi Jonas, thanks for your reply—I fully recognize RFC #17’s extensive review and established advantages. My goal isn’t necessarily to replace it immediately, but rather to offer an alternative mechanism emphasizing decentralization, reduced strategic complexity, and deterministic fairness. My proposal could potentially complement RFC #17 or serve as a benchmarking reference for future refinements. I'll continue gathering detailed feedback and simulations, potentially formalizing this approach as a separate RFC. Good luck with the voting! We can continue the general discussion of my approach proposal at its forum's thread: |
|
Voting for this referenda is ongoing. Vote for it here |
|
PR can be merged. Write the following command to trigger the bot
|
anaelleltd
added
Implementing
|
/rfc process 0x0489dd662487c0ac75345e81a7cb4c8373ea1e3216e53ebb9dcf9d595a743304 |
|
The on-chain referendum has approved the RFC. |
anaelleltd
added
Implemented
19 participants
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.