Summary

With this proposal, we are looking to develop a free notification service related to Coretime.

We are aware of applications like Web3alert. However, after looking into our proposal, there should be a clear distinction between the two services.

The tool we are looking to build has three main purposes:

• Provide notifications for parachain teams.

  • This can serve as a reminder for the team to renew Coretime; however, it can also be used for other purposes.

    Some parachains may want to self-host such a service. Because of this, we are making the notifier tool open source and well-documented. To facilitate self-hosting, we are also making the frontend open source and providing an option for users to select the notifier API that the frontend will communicate with. This way, parachain teams do not need to host the frontend themselves but can simply reuse what we provide.

    On top of such a notifier, programs can be implemented to renew, fund the sovereign account, or purchase Coretime when notified that only a few remain.

• Provide notifications for token holders.

  • The notification service can also be used to warn token holders if the parachain isn’t allocated Coretime and is about to stop block production.

    When tracking a parachain, the notifier will also alert users about other potential issues. For example, if a parachain is allocated Coretime with provisional finality, the account that allocated Coretime can unallocate it at any time. This could cause the parachain to immediately stop block production.

• Provide notifications Coretime traders

  • In a bulk sale, Coretime can be purchased in two phases: the lead-in phase or the fixed price phase.

    Ideally, Coretime is purchased in the fixed price phase since it has the lowest price. The lead-in phase functions like a Dutch auction, where the price starts high and gradually drops to the fixed price phase by the end. The later Coretime is purchased during the lead-in phase, the better the price; however, the longer users wait, the higher the risk that someone else will acquire the Coretime.

    Such processes should be automated, rather than requiring someone to monitor the sale manually. The notifier will also be useful in these cases, as it allows for the development of programs that can respond to specific notifications (e.g., when only 5 cores are remaining on sale) and automatically purchase Coretime.

The full proposal can be found here: https://docs.google.com/document/d/1z-lBu5LhqUghgDfb8qykwyZHS1rXIbS2d8m7IFpoby0/edit?usp=sharing

EDIT; For those who might be unaware of how the current reminder procedure works, We are sharing this forum post: https://forum.polkadot.network/t/kusama-coretime-renewal/8219/31?u=santi. Here, teams are notified to renew, and even then, some teams miss the renewal. There is no reason why this process shouldn't be automated to prevent human errors.

Additionally, many teams are not fully aware of how the Coretime model works, leading to misunderstandings about when to renew. We know this because we have already experienced people reaching out, unsure about how things work. We don't blame them; deployment on Polkadot should be as easy as possible, without requiring teams to understand every detail. Currently, with the transition to Agile Coretime, we have complicated this process, and this proposal aims to fix the issue.

A notifier that clearly indicates when to renew would solve these problems. This can be easily automated, reducing the risk of missed renewals and preventing some chains from stalling. 

Additionally, such a tool would also be focused on regular users who hold tokens on parachains. Token holders should not need to monitor whether a parachain is about to stall due to a no Coretime allocation. This should be abstracted away from them, and they should receive warnings on time if there is no Coretime allocation.