# Agile Coretime FAQ :::info :bulb: This was the working document containing some FAQ on Agile Coretime. The published, up-to-date version is to be found under [Agile Coretime FAQ](https://polkadot.network/features/blockspace/agile-coretime/). ::: ## :question: FAQ ### Basics * Q: What is coretime? * A: Coretime is the unit through which blockspace is allocated. In computing terms, it's the data availability and execution time of a core. Agile Coretime is the option to provide coretime in a more dynamic way on a block-by-block basis. * Q: What do the on-demand and bulk Coretime models look like? * A: Coretime is the allocation mechanism for blockspace. It can be either purchased in bulk (for up to 28 days in advance) or on-demand, where the purchased Coretime has to be used immediately. * Q: Why is Agile Coretime special? * A: Agile Coretime is a game changer for Web3, bringing the utilization of resources, and thus the economic flexibility for builders to the next level. It enables scale and agility for better UX, without compromising security or decentralization. On-demand coretime allows builders to only pay for the resources they need, e.g. to spin up a proof of concept quickly with full access to Polkadot’s entire ecosystem. Bulk coretime enables strategic resource planning and price predictability. By securing bulk coretime at a fixed price, spiking fees during high demand can be prevented. ### Roadmap * Q: What are the features / functionality that are part of the Q1 '24 launch? * A: At the minimum, bulk & on-demand. * Q: Where can we see the progress? * A: [This Github page](https://github.com/orgs/paritytech/projects/119/views/20). * Q: Is all of RFC-1 coming at once or in parts? * A: We might hold back a bit on lease splitting and especially getting rewards for putting your bought lease on on-demand. This will be ready with the initial launch on Kusama. * Q: What is currently being developed in the ecosystem? * A: There are several ecosystem projects in the making, such as the secondary markets for coretime, [Lastic](https://lastic.xyz) (focusing on frontend) and [Region X](https://regionx.tech/) (focusing on backend). No project is endorsed, always do your own research. If you feel like your project should be listed, please reach out to support@polkadot.network. * Q: Will all the current lease holder parachains migrate and when? * A: They will migrate when the runtime upgrade is performed. This will happen automatically. * Q: When will the auction mechanism be deprecated? * A: There won’t be any new auctions after bulk coretime works as intended. Current leases will be migrated to bulk coretime automatically. * Q: Are parachains now abstracted away from direct core interaction? * A: No, that might come later. ### Product * Q: Is the Broker Chain the same as the Coretime Chain? * A: Yes. The broker pallet runs on the Coretime Chain. * Q: Can cores be shared at the same time? * A: Currently not. Cores can be shared, but only in time, e.g. you get the core at block X, another one gets it at block Y. We don't yet have anything like we share the core at block X. * Q: What limits are there to the number of cores? * A: Both the validators and the messaging overhead by the approval checkers. Each core has a validator group assigned, currently 5 on Polkadot and 3 on Kusama. Thus, the validator count limits the number of cores, if we want to maintain those numbers. Also, scaling validators does not linearly improve the load they can perform, as there is an overhead due to the messaging between them. Similarly, we expect 30 approval checkers for each core. The fewer validators there are, the more load will be on each approval checker. * Q: Is there a UI for the Coretime Chain? * A: Teams in the ecosystem are working on a UI. Region X has released (End of Jan) an app for testing on Rococo: https://app.regionx.tech/. Without the UI, this would be automated from the parachains’ runtimes or manually with Coretime Chain extrinsics via polkadot.js. ### Pricing & Purchasing :::success Pricing is currently still under discussion, e.g. [here](https://forum.polkadot.network/t/initial-coretime-pricing/5187) in the Polkadot Forum. ::: * Q: How can I purchase coretime? * A: Coretime can be purchased directly through the Coretime Chain. There will be guides and technical walkthroughs on the wiki or on the landing pages. You can also go to a secondary marketplace (currently under development) and purchase coretime through their interface. * Q: How do the pricing models look like? * A: On-demand coretime will always be at market conditions, as well as new bulk coretime. However, bulk renewals are capped within a percentage of the previous purchase price. * Q: If you purchase in bulk, do you then have “one core” or one bucket of coretime that you can use in your own time? Or is there a specific slot? * A: You have a specific core for the duration of an entire month and have the ability to split that up. * Q: What happens to purchased coretime if I don't use it? * A: Unused coretime can't be taken over to another slot. If you don't need previously-purchased coretime though, you will soon be able to sell it on secondary markets. * Q: Can I buy coretime in advance and start using it when I'm ready? * A: You can only purchase coretime up to 28 days in advance. In the future, "futures" to hedge against price fluctuations could be a possible solution to increase predictability further. ### Concepts * Q: Is it “On-demand coretime” or “Instantaneous coretime”? * A: We have decided to stick with the previously-discussed term "on-demand". * Q: What's the correct spelling? * Other than Agile Coretime and the Coretime Chain, we don't capitalise coretime or blockspace. * Q: What’s the connection between blockspace and coretime? * A: (Secure) blockspace is the resource Polkadot provides, which is measured in / allocated through coretime. ### Value Prop * Q: What are the benefits of Agile Coretime, as well as the on-demand and bulk models? * Broader Web3 impact: * On a high level, Agile Coretime brings a new era of scaling to Web3 with optimal resource allocation across the entire network. * The on-demand model democratises blockchain access by opening the door to everyone building a custom, sovereign Web3 application; while the bulk model brings a new level of business- and cost-predictability to teams and projects. * Specific benefits for decision makers and developers: * Agile Coretime brings efficient utilisation of resources, enabling scale and agility for better UX - without compromising security or decentralisation. * The more flexible economic models for every stage of growth enables builders to innovate without boundaries. * Developers benefit from streamlined development through simplified resource management, as well as from a consistent development environment through flexible and predictable cost modelling over time. * On-demand coretime removes barriers to entry: Spin up your proof of concept quickly with full access to Polkadot’s entire ecosystem. * Cost-effectiveness: Remove inefficiencies by buying coretime on-demand only, or selling access coretime on secondary marketplaces. * With elastic scaling (not supported yet) projects can scale seamlessly: Don’t be limited by previously- allocated resources. With elastic scaling, add on-demand coretime to increase your bandwidth seamlessly. * Bulk coretime enables strategic resource planning: Secure bulk coretime at a fixed price to prevent spiking fees during high demand. This allows to future-proof your projects: Bulk coretime provides a solid foundation for your long-term business plans, allowing for sustainable growth. * Q: What makes the coretime model on Polkadot competitive? * A: The on-demand option removes barriers to entry and enables builders to start and innovate quickly. Combined with the bulk model, builders also mitigate risks of spiking fees during times of high demand. * However, as compared to running on an L1 or a scaling solution, builders still have the benefits of running on a purpose-made parachain, which is more efficient and thus cheaper than running a smart contract on a generic L1, in addition to being connected to and secured by the entire Polkadot network. * Polkadot can thus offer all the benefits of building high-performing, purpose-made, and composable Appchains, combined with the most flexible economics. * Q: How close do we get to Web2 scale for Web3? * A: Agile Coretime mainly improves allocation efficiency. With elastic scaling, we take a big step towards enabling Web2 scale in Web3. ### Implementation * Q: What do I need to do for my parachain to continue working in the switch to coretime? * Current parachain slots will be converted to legacy leases automatically in the runtime upgrade through a migration, with no intervention needed. The lease will grant your parachain a core until the end of the region in which its slot would have expired. * Q: When and how can I renew my legacy lease? * A: The lease runs until the slot that it replaces would have expired. This can be converted into bulk coretime at the start of the interlude in that sale period by calling `renew` on the lease's core. The price will be charged to the caller and will be equal to the market price of a bulk core in that sale. * Q: How is the coretime price determined in practice? * A: The starting price is configured by a referendum, then in subsequent sales it depends on the number of cores which were sold vs those which were for sale. If the ideal ratio was sold (the ratio is configured by referendum, too), then the price remains the same; if fewer cores than the ideal were sold, then the price decreases; if more cores are sold than ideal, then the price increases. In this way the price is sensitive to the market conditions, initial configuration, and number of cores offered in the sales. * Q: How is coretime measured and allocated technically? * A: The Coretime Chain is a proposed new system parachain within the Polkadot network that is responsible for the management of coretime. It is designed to handle the allocation of bulk coretime and track ownership of coretime as non-fungible assets (NFTs). The Coretime Chain provides information to the Relay Chain regarding the number of cores available, the tasks running on each core, and accounting information for on-demand coretime credit. Additionally, it processes renewals and allows for various manipulations of bulk coretime, such as transfers, partitioning, interlacing, assignment to tasks, and pooling for on-demand coretime. * Q: Why are sales of on-demand coretime happening on the Relay Chain? * A: In the beginning, sales are executed on the Relay Chain, but they could move to the Coretime Chain. Latency is the only drawback: At low demand, the buyer would receive the coretime instantly when via the Relay Chain, but there’ll be a delay when executed on the Coretime Chain. At high demand, there will be a queue anyway and this delay matters less. ## :exclamation: Key Concepts **Core**: A core is a numbered container within the relay chain’s state. This container is either empty or full. When empty, a new candidate may be placed inside it by the relay chain block author. It stays full until that candidate’s data is available or a timeout is reached. The process repeats. Behind the scenes, validators use the core index to determine which candidates to validate in approval checking. **Coretime**: Data availability and execution time of a core. The unit in which blockspace is allocated. **Bulk coretime**: Coretime acquired for a fixed duration of time for a bulk amount of blockspace. It is represented by an NFT(asset) and can be manipulated in multiple ways. **On-demand (f.k.a. Instantaneous) coretime**: Coretime acquired in near real time for a single unit of blockspace (block production) and is represented as a redeemable, non-transferable credit on the Relay Chain. **On-demand coretime pool**: The capacity of available on-demand coretime as maintained by the Coretime Chain. **Coretime Chain**: A system parachain responsible for the sale and manipulation of bulk coretime and the purchase of on-demand coretime credits. It also communicates to the Relay Chain the number of cores which should be made available and which tasks should be running on which cores. The repo and roadmap are [here](https://github.com/paritytech/polkadot-sdk/pull/1479). **Region**: An asset representing a period of bulk coretime. It can: * Be transferred to a different owner than the original purchaser. * Be split (partitioned) into multiple segments that are all assigned the the region owner * Interlaced into multiple regions over the same period whose eventual assignments take turns to be scheduled * Assigned to a single, specific task (currently for parachain block production) * Sold to the on-demand coretime pool ## :bulb: Further Resources - [RFC-0001](https://github.com/polkadot-fellows/RFCs/pull/1/commits/c94858e099a19839a135a8b5c41ad38470d430ee) - [Decoded Talk](https://www.youtube.com/watch?v=GIB1WeVuJD0)