All things JAM in Buenos Aires

We extended the warmup period for more testing to ensure that the data migration will go fine. Will keep you posted 🤘

@Joseptec @carlosala22 @voliva_v We're running some last tests to ensure the staking system is working correctly and doing some double checks before we close out

@Joseptec @carlosala22 @voliva_v We're out of the cool off - migration complete

@Joseptec @carlosala22 @voliva_v Staking is done, and with that we enter the cool off phase until block 28495696 in about an hour https://t.co/0VZ62vFaR8 in the mean time we'll run our final tests to ensure everything went as planned

@Joseptec @carlosala22 @voliva_v When the bagslist hits (RHS)

@Joseptec @carlosala22 @voliva_v Accounts are finally done! Like on Kusama, we should fly through the pallets until we hit staking. Estimating around an hour and a half before we finish migrating and hit the cool down period

@Joseptec @carlosala22 @voliva_v OK now we're running at full speed - all gas no brakes

@Joseptec @carlosala22 @voliva_v Collator operators have been very responsive and performance has actually improved at the higher load. We've now been running at 1600 with a small queue for 10 minutes, but by increasing the queue we can double the rate

We levelled out at 1200 accounts per block where we started to see slow blocks from a few collators. Nothing to worry about, but we didn't want to increase further until that was resolved with the collator operators. We've just increased again

For these offchain multisig calls the ability to copy a subset of the bytes with PAPI is such a great quality of life enhancement over PJS apps. Thx @Joseptec @carlosala22 @voliva_v

And again to 800, times are looking stable

We have now increased from 400 to 600 accounts per block. Our intended is 1600.

Tests all passed, everything is looking good and we have entered the account migration stage

Any astute watchers might have noticed that we extended the warm up period. We have been rate limited by most RPCs due to all the tests we've been doing, so our tests didn't complete in time. This is Polkadot - we want certainty

The upshot of this is that this time we have a range of values for the length of the migration. Our dry runs completed in about 3 hours at full rate, but if we're forced to run at the lowest rate it will take around 8 hours. Including warm up and cool down, this means 5-10 hours

We have a multisig with very constrained special powers around AHM parameters, with which we can gradually raise this number mid migration until we either hit our intended rate or see some small degradation in block times

Since we operate in a decentralised ecosystem (and we're professionals, ofc), we also decreased the number of accounts migrated per block so this flag is not needed. This separately fixes the block slowdown, but extends the length of the migration

Due to the size of the state on Polkadot, we saw some slowdowns in block production in our dry runs. This was due to two factors and led us to ask collators and validators to increase one of the caches

It's AHM day! We've just entered the WarmUp phase, meaning that the call filters are in place while we do our last checks. This is our last time to abort if we see that something has changed in the state. Follow along on