Kian's document is the best resource I've seen for onboarding to Parity and can be found here. Read it and explore everything it links. Recurse through the links that those resources include. There is a backup link to the source here in case he takes it off his website again. Also Shawn gave a great talk at Sub0 in 2024 about being an effective dev in the ecosystem. It's worth a watch. The Polkadot Fellowship Manifesto outlines the expectations and expected mindsets etc, also worth a read. If you want to build the pdf I recommend tectonic which pulls in way fewer dependencies than latexmk and downloads what is needed at the build step, rather than downloading every possible latex module pre-emptively. A bit more in-depth: you can see what developers at different ranks have been working on in the evidence repo which can be useful to calibrate yourself and how you plan to take on complexity. A successful onboarding in Parity should leave you operating around the level of what the manifesto describes at rank 2. General Ramp-Up Expectations

The Asset Hub Migration (AHM) is part of the Plaza project, working towards the next generation of the Polkadot Hub. In practice this means moving functionality off the Relay Chain onto Asset Hub, moving the pallets' state along with them. Overview From My high level talk from the parachains AMA: tl;dr: The main goal is to migrate all the staking, governance and balances functionality from the Relay Chain to Asset Hub at minimal cost and risk to our integrated partners. Average end users should interact only with AH, and be unaware of anything else behind the scenes Migration will not require end user intervention A core objective of Polkadot is to do everything on parachains, but originally things were done directly on the relay chain as we didn't have parachains yet and it removed some complexity to allow Polkadot launch faster. RFC-32 maps out path to a minimal relay to strip this functionality out an

cargo install --locked --force --git https://github.com/joepetrowski/opengov-cli opengov-cli Note: if you already have opengov-cli installed you'll need to update to get the changes from opengov-cli#34 Enactment times We'll schedule these to enact first on Kusama, then on Polkadot a week later. Both scheduled times will be morning UTC on a weekday when most engineers are online. Kusama runtime upgrades usually confirm in about 7 days, Polkadot more like 9 or 10 depending on backing. I'm posting them both on 20250210 (a Monday), so Kusama should be scheduled for 9 days and Polkadot 16 days from now (20250219 and 20250226 respectively). Grabbing some block numbers to make this coincide with roughly 8am UTC on these days gives us: Kusama enactment block: 27155056 Polkadot enactment block: 24899075 Upgrade Kusama to v1.4.0

Overview At a high level, bulk coretime sales are auctions with a periodic sale mechanism which attempts to find a happy medium between effective market-driven pricing and price predictability. The sale period aligns with the length of a region of coretime as it is sold by the system. A region of coretime is in general a commodity representing a varying proportion and pattern of execution on a core for a period of time. At generation it is sold in default lengths with a full mask for a single core, but can be split/interlaced to create any permutation of the length and pattern specified by the mask. A note first about design decisions: Hardcoded parts in the pallet should be as flexible as possible, without becoming overly complicated due to generality. Most of the interesting parts of the pricing and economics should be implemented in the PriceAdapter, allowing the specifics of the design for runtimes in different networks to be disentangled from each other, and to allow easier experimentation without updating broker pallet versions. In RFC-1 the decision was made to go for a periodic dutch auction model for price finding within the sale period. The initial implementation also included enshrined capped renewals, allowing people who had a core to renew indefinitely and partially isolated from external upward pressure on the price.

Overview This document is just a dump of some different usecases for Chopsticks as and when I came across them. My aim was to fill the gap which existed when I first started using Chopsticks where there were no actual demonstrations of how it can be used, or at least none that I could find. I have used it for a lot of other stuff than what is listed here, but this demonstrates enough of the high level workflows such that you can tweak them slightly to cover a lot of normal usecases. This is all just manual poking with PolkadotJS + chopsticks, but you can automate things that will run repeatedly and talk to it/submit transactions/check state any way you want, as it's just a local RPC. This means you can have a nice chopsticks + PAPI setup to automate stuff, or even just using PAPI instead of clicking around in PJS Apps. CI or automated testing suites are probably better suited for the Polkadot Ecosystem tests repo, which Alexandre has written about here. Chopsticks setup First run

Testing invulnerable referenda July 2024 Referenda were posted on Kusama and Polkadot to correct some community invulnerables and change the number of permissionless slots. Polkadot referendum Kusama referendum Let's test them using Chopsticks. Taking Polkadot first we see it's on the staking admin track and can inspect the call to see what it involves: Screenshot 2024-07-19 at 16.38.31

Change core count to 100 on Kusama Our referendum will send an XCM to the coretime chain with a transact containing request_core_count with 100 cores. This is the call for the referendum (including ~1.5x safety factor), which has the hash: 0x630004000100b50f04082f00000602028c8f84f1551032126400. We can fire up chopsticks and use the scheduler to execute this. bunx --bun @acala-network/chopsticks@latest xcm -r kusama.yml -p ./kusama-people.yml Open the Coretime Chain to watch the events. Go to the Javascript tab on the relay chain, clear the code and add:

Hi, I'm Dónal Murray (seadanda). I've been contributing to Polkadot since I joined the system parachains team at Parity eight months ago. Soon after I started I became involved in the Agile Coretime project, and over time I have developed ownership over the Coretime Chain runtimes and the broker pallet. I have played a key role in preparing and launching the Coretime Chain on Rococo, Westend and Kusama. GitHub: https://github.com/seadanda Polkadot: 142zGifFwRrDbFLJD7LvbyoHQAqDaXeHjkxJbUVwmDYBD7Gf Selected contributions

Overview The Kusama Relay Chain upgrade to v1.2.0 (1002000) included a migration to transition to coretime containing four XCM programs which are sent from the relay chain to the Coretime Chain. Each XCM contained Transact instructions to populate the state of the Coretime Chain. The calls in one of the messages failed to execute as the specified maximum weight was less than what was needed to run the extrinsic. Basically it means that the message announced that it would use less weight than what it would actually use and this made the XCM message fail. This is a security measure to ensure that XCM messages can not stall a chain, but in this case was set too low for it to actually run. The calls in this XCM were to set_lease (an extrinsic in the broker pallet on the coretime chain). This was intended to migrate the parachains who have an active lease from the relay chain to the Coretime Chain to allow the parachains who won auctions to be awarded coretime until their lease ends. The leases were thus not populated due to the failed XCM. There was no immediate downtime or any other impact for parachains, but the absence of leases in state means that parachains with existing leases would have had to buy coretime on the open market or lose their core next month. Background The Kusama Coretime Chain was added in polkadot-fellows/runtimes#212 and the transition to coretime consisted of three steps. These were posted as three referenda with coordinated enactment times:

Monday 11th March, 2024 Bangkok 60 mins Dónal Murray / seadanda Workshop structure Top level slides give an overview, but each section has more depth. This is not a lecture, everybody get involved 😀 Choose your own adventure

Overview The bulk pricing for coretime depends on factors from several sources: Hardcoded in the pallet (implementation) or configurable in the runtime Parametrised configuration items (set through governance) Market forces (the impact of which can be increased or decreased through the configuration set by governance) Ok this might develop in a bit of a wild stream-of-consciousness but I'll go back and edit it at some point. I'll use rococo code to demonstrate any points or reference anything. I don't anticipate any difference in implementation for kusama and polkadot. The only change in governance is that things will be configured via referenda instead of via sudo calls. The change in market forces is pretty profound though, as KSM and DOT have real-world values whereas ROC and WND do not (except in one case where apparently somebody tried to buy Rococo coretime for KSM 😅)

tl;dr: Start sales parameters: initialPrice: ~5 KSM coreCount: 3 Configuration parameters: advanceNotice: 10 (1 min) interludeLength: 50400 (7 days) leadinLength: 50400 (7 days) regionLength: 5040 (28 days)