Announcing Luxor

The Luxor runtime upgrade introduces changes that will enhance the Joystream ecosystem's governance and financial management. With the ability for the council to burn budget capacity, adjust validator  rewards, and allow vested payments directly from the working group budgets, Luxor demonstrates Joystream's commitment to continuous improvement and adaptability based on the network's evolving needs.

Timeline

The Runtime Upgrade Proposal was submitted on April 10th at block #7,000,456 and was approved by Council 31. The proposal is currently in the deciding status, and Council 32 needs to approve it for execution.

What is Luxor?

The most important changes that Luxor brings are outlined in the sections below. For those interested, this Github issue provides a complete list of the runtime changes for Luxor.

Proposal for reducing council budget

Council will be able to burn budget capacity as a way to take future minting off the table. Rather than maintaining the value of $JOY, this change allows the council to manage the risks involved in having a large treasury. By reducing the council budget at any time, the council can effectively mitigate potential risks associated with a substantial treasury balance.

Vested spending from WG budgets

The current system requires WG leads to withdraw funds to a personal account and then send them with a vesting schedule to the recipient. With Luxor, many payments that the council entrusts WGs to make to service providers and similar entities can be made with vesting payments directly from the WG budget, streamlining the process and increasing  transparency.

Proposal for adjusting validator rewards

Council will be able to set the total $JOY reward devoted to validators over a given period of time. This flexibility allows for better incentivization of validators and helps maintain the network's security and stability.

Proposal for adjusting CRT pallet constraints

A proposal will be introduced to update project token pallet storage constants used as constraints, such as the minimum AMM curve slope and  max patronage rate. This change will enable governance to explicitly set values for these constraints, providing a posteriori guidelines for adjusting them based on network usage.

Other changes

• Remove Nara migrations
• Add proxy pallet
• Block AMM operations when revenue split is ongoing
• Q&A

Disclaimer

All forward looking statements, estimates and commitments found in this blog post should be understood  to be highly uncertain, not binding and for which no guarantees of  accuracy or reliability can be provided. To the fullest extent permitted  by law, in no event shall Joystream, Jsgenesis or our affiliates, or any of our directors, employees, contractors, service providers or agents have any liability whatsoever to any person for any direct or indirect loss, liability, cost, claim, expense or damage of any kind, whether in contract or in tort, including negligence, or otherwise, arising out of or related to the use of all or part of this post, or any  links to third party websites.