# Registering Bulletin System Parachain (ParaId 1010) on Polkadot + 2 more cores for People Polkadot

A walkthrough of how the referendum to register Bulletin and reserve additional cores for Polkadot People was prepared and validated.

## Summary

This referendum merges **two orthogonal topics** in a single Asset Hub proposal:

1. **Onboards the Bulletin System Parachain (ParaId 1010)** onto Polkadot — registering it with the relay chain's `Registrar` (via the whitelist+preimage pattern, since the ~1 MB runtime WASM exceeds the UMP limit for direct XCM) and reserving **core 97** for it on the Coretime chain, so it can start producing blocks once its collators come online.
2. **Reserves two additional cores (98 and 99) for Polkadot People (ParaId 1004)**, which is unrelated to Bulletin — it is bundled here as a convenience to avoid a separate governance cycle for a small operational change.
3. Referendum calls

Batch to submit on Polkadot Asset Hub:
0x2804080500c90340032802141f00050100050c2f0000060200881700cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c706120001f00050100050c2f0000060200d801044038000000001702cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061480d0e000700e40b5402214e20001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02f2030000610020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec030000620020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec030000630020003e003f0d02e57ff30baecb70d3f0ac5419076f767e3a2b7ca7c74967f4d9b85b0d30176db9f20000000082bfda01

Batch to submit on Polkadot Collectives Chain:
0x2804043d003e0201cc1f0005010100a10f05082f00000603008840005e087dadda060e3bae8e49bb359c006fa93d39bfceff059691e7dd0b13b58104010a000000

Both parts leverage Asset Hub's Root-on-relay status (`LocationAsSuperuser`) to carry the privileged calls via XCM. Mechanically the proposal is a single AH `Utility.batch_all` of five XCM sends:

AH utility.batch_all([
    XCM → Relay:    whitelist.whitelist_call(hash)                        ← Bulletin force_register preimage hash
    XCM → Relay:    Scheduler.schedule_after(14400,                       ← delayed +24h
                      whitelist.dispatch_whitelisted_call(hash))
    XCM → Coretime: broker.force_reserve(Task(1010), core=97)             ← Bulletin
    XCM → Coretime: broker.force_reserve(Task(1004), core=98)             ← Polkadot People (+1 core)
    XCM → Coretime: broker.force_reserve(Task(1004), core=99)             ← Polkadot People (+1 core)
])

  referendum enacts                                     +14,400 blocks (~24h)
        │                                                       │
        ▼                                                       ▼
  whitelist_call marks the                          dispatch_whitelisted_call fires
  preimage hash as "requested"                      → fetches preimage, executes
        │                                             force_register as Root
        ▼                                                       │
  Relay: anyone submits Preimage.note_preimage                  │
        for FREE during the delay window                        ▼
                                                          Bulletin onboards,
                                                          PVF pre-check,
                                                          starts producing blocks

## Key decisions

- **Scope — two unrelated things in one referendum:**
1. Register the **Bulletin System Parachain** (ParaId 1010, shell runtime from Fellowship Runtimes v2.2.1) and reserve one core for it.
2. Additionally (unrelated to Bulletin) reserve **two extra cores** for the existing **Polkadot People** parachain (ParaId 1004).

- **Core indices — 97 (Bulletin), 98 and 99 (People).** Chosen from the top of the broker's unsold range (cores 45–99) to avoid conflict with any core that might be acquired during the referendum voting period. After the next sale rotation these reservations migrate to the next available low indices.

- **Prerequisite: Fellowship Runtimes v2.2.1 must enact first.** Two separate blockers require v2.2.1:
1. **Relay** — the current live runtime filters `Preimage.note_preimage` (inherited from the AHM call-filter logic and not restored post-AHM). v2.2.1 re-enables it ([fix commit](https://github.com/polkadot-fellows/runtimes/pull/1131/commits/d3033803315b50827a9f12de2b5ad301fdd94df1)).
2. **Coretime** — the live runtime caps the broker's reservation list at 10 entries. Cores 0–8 are already reserved (9 entries), so adding three more (97, 98, 99) would overflow with `TooManyReservations`. [Fellows PR #1147](https://github.com/polkadot-fellows/runtimes/pull/1147) raises this cap to 50, landing in v2.2.1.

v2.2.1 is the ongoing [referendum #1883](https://polkadot.subsquare.io/referenda/1883). This referendum is therefore scheduled to enact **at block [31,113,090](https://polkadot.subscan.io/block/31113090)** (~6 May 2026, 10:00 CEST), giving the runtime upgrade time to land first on both chains.

- **Delayed dispatch — 14,400 relay blocks (~24 h) between enactment and `force_register`.** On enactment the AH XCMs fire immediately (`whitelist.whitelist_call`, the scheduler entry, and the three `broker.force_reserve`s). Because `whitelist_call` marks the Bulletin preimage hash as system-requested, anyone can submit the ~1 MB `Preimage.note_preimage` on the relay during this window **without locking the ~1000 DOT preimage deposit** — The account to submit the preimage is required to have ~100DOT on their account which is a possible tx fee cost, but it is not consumed by the succesfull call.

- **Manager account — the Asset Hub sovereign account on the relay (`13YMK2edbuhwMBxeUWm9c643A2wyYHwSVh1bCM7tShtg7Dtk`).** Derived via `LocationToAccountApi.convert_location({ parents: 0, interior: X1(Parachain(1000)) })`. This differs from the existing system parachains, which use a Parity-owned account as manager. In practice the manager is largely symbolic — the para auto-locks on its first block via `OnNewHead`, after which only Root or the parachain itself can modify it.

- **Referendum track — `whitelistedcaller` on Asset Hub.** Preimage is whitelisted by the Fellowship on Collectives; the proposal itself is dispatched by a public vote on Asset Hub.

## Background

`Registrar.force_register` requires the full WASM runtime (~1 MB) as a parameter, which exceeds the 128 KB UMP message limit — so it can't be sent directly via XCM from Asset Hub to the relay chain.

The live Polkadot relay chain currently has `Preimage.note_preimage` disabled (AHM introduced call-filtering logic applied before/during/after AHM, and the Preimage pallet remained disabled post-AHM). Enabling the Preimage pallet was shipped in the v2.2.0 release via [this commit](https://github.com/polkadot-fellows/runtimes/pull/1131/commits/d3033803315b50827a9f12de2b5ad301fdd94df1).

The workaround uses the **whitelist + preimage** pattern with **delayed dispatch**: AH governance sends a small XCM batch that whitelists the preimage hash and schedules its dispatch after a delay. AH has Root on the relay via `LocationAsSuperuser`. The delay creates a window during which the ~1 MB preimage can be submitted to the relay for free, because `whitelist_call` marks the hash as system-requested before anyone notes it.

Alternatives considered and not pursued (for now):

- **Embed the Bulletin WASM into the relay chain runtime** — not researched further.
- **`authorize_force_register` / `apply_authorized_force_register` pattern** — analogous to `system.authorize_upgrade` / `apply_authorized_upgrade`: governance would store only the hashes of the WASM and genesis head (tiny), then anyone could permissionlessly submit the actual bytes in a follow-up extrinsic. This would eliminate the whitelist+preimage workaround entirely but requires a runtime change to the `paras_registrar` pallet.

---

## How the referendum was prepared

All artifacts land in a single working directory referenced as `$WORKDIR` throughout.

export WORKDIR="$HOME/bulletin-registration"
mkdir -p "$WORKDIR"
cd "$WORKDIR"

### Runtime WASM was downloaded and verified

The Bulletin runtime WASM was pulled from the Fellowship Runtimes v2.2.1 release and checked against its published Blake2-256 hash.

cd "$WORKDIR"

curl -L -o bulletin_runtime.wasm \
  https://github.com/polkadot-fellows/runtimes/releases/download/v2.2.1/bulletin-polkadot_runtime-v2002001.compact.compressed.wasm

b2sum -l256 bulletin_runtime.wasm

ad57082d2d342a06f487fd0d7f2d21e0e03b8a48432a2d9cc8b876fa27c43967  bulletin_runtime.wasm

`polkadot-omni-node` (`chain-spec-builder` and genesis head export) was pulled from the `polkadot-stable2603` release and verified against its published sha256:

cd "$WORKDIR"

curl -L -o polkadot-omni-node \
  https://github.com/paritytech/polkadot-sdk/releases/download/polkadot-stable2603/polkadot-omni-node-aarch64-apple-darwin
curl -L -o polkadot-omni-node.sha256 \
  https://github.com/paritytech/polkadot-sdk/releases/download/polkadot-stable2603/polkadot-omni-node-aarch64-apple-darwin.sha256

echo "$(awk '{print $1}' polkadot-omni-node.sha256)  polkadot-omni-node" | shasum -a 256 -c -
chmod +x polkadot-omni-node

polkadot-omni-node: OK

### Chainspec was built from the Fellows preset with the verified WASM swapped in

A plain chain spec was generated from the Fellows v2.2.1 `chain-spec-generator` (so the genesis preset — collators, session keys, etc. — matches the published release). The `:code` entry was then replaced with the verified release WASM via `chain-spec-builder update-code`, the result verified by hash, and finally converted to raw so the genesis storage is rebuilt by executing *that* WASM's `genesis_build` over the preset.

**1. Clone the Fellows runtimes repo at v2.2.1 and build the generator** (first build ≈15 min):

cd "$WORKDIR"
git clone https://github.com/polkadot-fellows/runtimes.git fellows-runtimes
(cd fellows-runtimes && git checkout v2.2.1 \
  && cargo build --release -p chain-spec-generator --features bulletin-polkadot)

**2. Emit the plain `bulletin-polkadot` chain spec**:

cd "$WORKDIR"
./fellows-runtimes/target/release/chain-spec-generator bulletin-polkadot \
  > bulletin-polkadot-chainspec.plain.json

**3. Swap the embedded WASM with the verified release WASM**:

cd "$WORKDIR"
./polkadot-omni-node chain-spec-builder \
  -c bulletin-polkadot-chainspec.patched.json \
  update-code \
    bulletin-polkadot-chainspec.plain.json \
    bulletin_runtime.wasm

**4. Verify the patched chainspec carries exactly `bulletin_runtime.wasm`**:

cd "$WORKDIR"
jq -r '.genesis.runtimeGenesis.code' bulletin-polkadot-chainspec.patched.json \
  | sed 's/^0x//' | xxd -r -p > patched_code.wasm
diff -q bulletin_runtime.wasm patched_code.wasm && rm patched_code.wasm

Expected output (nothing if identical, because `diff -q` is silent on match):

**5. Convert to raw.** `update-code` only swapped the WASM bytes; the plain spec still carries `runtimeGenesis.patch` (JSON preset values for each pallet — collators, session keys, etc.) that has not yet been materialised into storage. `convert-to-raw` loads the WASM, runs its `sp_genesis_builder::GenesisBuilder::build_config(patch)`, and emits the resulting key/value pairs into `genesis.raw.top`. So the raw storage is whatever the release WASM produces from the Fellows preset — not a copy of what the locally-built generator WASM previously produced.

cd "$WORKDIR"
./polkadot-omni-node chain-spec-builder \
  -c bulletin-polkadot-chainspec.json \
  convert-to-raw bulletin-polkadot-chainspec.patched.json

**6. Re-verify the raw chainspec's `:code` still matches**:

cd "$WORKDIR"
jq -r '.genesis.raw.top["0x3a636f6465"]' bulletin-polkadot-chainspec.json \
  | sed 's/^0x//' | xxd -r -p > raw_code.wasm
diff -q bulletin_runtime.wasm raw_code.wasm && rm raw_code.wasm

Again silent on success.

`bulletin-polkadot-chainspec.json` — the final raw spec — now has `:code` byte-identical to the verified release WASM, with genesis storage derived from the Fellows preset running under that WASM. Both the genesis head export and the Bulletin collator startup later consume this file.

### Genesis head was exported

cd "$WORKDIR"
./polkadot-omni-node export-genesis-head --chain bulletin-polkadot-chainspec.json > genesis-head.hex

### Referendum calls were composed from opengov-cli primitives

`opengov-cli` (from the [karolk91 fork](https://github.com/karolk91/opengov-cli)) exposes three composable primitives used to assemble the proposal:

- **`xcm-force-register`** — whitelist+preimage pattern for a relay `Registrar.force_register`; outputs `preimage.hex`, `xcm_whitelist.hex`, `xcm_dispatch.hex`.
- **`xcm-force-reserve`** — a single AH XCM send wrapping `Broker.force_reserve(para_id, core)` for the Coretime chain.
- **`batch-ah`** — combines hex-encoded AH calls into a single `Utility.batch_all` proposal.

Clone and build once:

cd "$WORKDIR"
git clone [e-mail]:karolk91/opengov-cli.git
(cd opengov-cli && git checkout kk/register-system-para && cargo build --release)

**1. Bulletin registration artifacts** (preimage + whitelist + scheduled dispatch) were generated with the manager set to the Asset Hub sovereign account:

cd "$WORKDIR"
./opengov-cli/target/release/opengov-cli xcm-force-register \
  --wasm bulletin_runtime.wasm \
  --genesis-head genesis-head.hex \
  --para-id 1010 \
  --manager 13YMK2edbuhwMBxeUWm9c643A2wyYHwSVh1bCM7tShtg7Dtk \
  --delay-whitelist-dispatch-relay 14400 \
  --output reg_1010/

Para ID: 1010
  Manager: 13YMK2edbuhwMBxeUWm9c643A2wyYHwSVh1bCM7tShtg7Dtk
  Preimage (relay force_register): 920904 bytes, hash 0xcd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061
    → reg_1010/preimage.hex
  XCM whitelist_call: 50 bytes → reg_1010/xcm_whitelist.hex
  XCM dispatch (scheduled +14400 blocks): 70 bytes → reg_1010/xcm_dispatch.hex

**2. Core reservations** — Bulletin on core 97, plus two additional cores (98, 99) for Polkadot People — were generated as separate XCM primitives:

cd "$WORKDIR"
./opengov-cli/target/release/opengov-cli xcm-force-reserve --para-id 1010 --core 97 --output reserve_1010_97.hex
./opengov-cli/target/release/opengov-cli xcm-force-reserve --para-id 1004 --core 98 --output reserve_1004_98.hex
./opengov-cli/target/release/opengov-cli xcm-force-reserve --para-id 1004 --core 99 --output reserve_1004_99.hex

XCM force_reserve (AH → Coretime):
  Para ID: 1010
  Core: 97
  Inner call (Broker.force_reserve) size: 20 bytes
  XCM send size: 39 bytes
  Written to: reserve_1010_97.hex
XCM force_reserve (AH → Coretime):
  Para ID: 1004
  Core: 98
  Inner call (Broker.force_reserve) size: 20 bytes
  XCM send size: 39 bytes
  Written to: reserve_1004_98.hex
XCM force_reserve (AH → Coretime):
  Para ID: 1004
  Core: 99
  Inner call (Broker.force_reserve) size: 20 bytes
  XCM send size: 39 bytes
  Written to: reserve_1004_99.hex

Each outputs a 39-byte AH XCM send wrapping `Broker.force_reserve` destined for the Coretime chain (parachain 1005).

**3. Everything was batched into a single AH proposal**:

cd "$WORKDIR"
./opengov-cli/target/release/opengov-cli batch-ah --output register-and-reserve.call \
  reg_1010/xcm_whitelist.hex \
  reg_1010/xcm_dispatch.hex \
  reserve_1010_97.hex \
  reserve_1004_98.hex \
  reserve_1004_99.hex

Batched Asset Hub proposal:
  Inner calls: 5
    - reg_1010/xcm_whitelist.hex
    - reg_1010/xcm_dispatch.hex
    - reserve_1010_97.hex
    - reserve_1004_98.hex
    - reserve_1004_99.hex
  Proposal size: 240 bytes
  Written to: register-and-reserve.call

### Fellowship + public referendum calls were generated

The batched AH proposal was fed into `submit-referendum` on the `whitelistedcaller` track to produce the Fellowship whitelisting call (on Collectives) and the public referendum calls (on Asset Hub). The `--at 31113090` flag pins enactment to block **31,113,090** (~6 May 2026, 10:00 CEST) — the estimated block at which [referendum #1883](https://polkadot.subsquare.io/referenda/1883) (Fellowship Runtimes v2.2.1) will already have enacted and re-enabled `Preimage.note_preimage`:

cd "$WORKDIR"
./opengov-cli/target/release/opengov-cli submit-referendum \
  --proposal register-and-reserve.call \
  --network polkadot \
  --track whitelistedcaller \
  --at 31113090 \
  --output calldata

Open a Fellowship referendum to whitelist the call:
0x3d003e0201cc1f0005010100a10f05082f00000603008840005e087dadda060e3bae8e49bb359c006fa93d39bfceff059691e7dd0b13b58104010a000000

Submit the preimage for the public referendum:
0x0500c90340032802141f00050100050c2f0000060200881700cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c706120001f00050100050c2f0000060200d801044038000000001702cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061480d0e000700e40b5402214e20001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02f2030000610020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec030000620020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec03000063002000

Open a public referendum to dispatch the call:
0x3e003f0d02e57ff30baecb70d3f0ac5419076f767e3a2b7ca7c74967f4d9b85b0d30176db9f20000000082bfda01

Batch to submit on Polkadot Asset Hub:
0x2804080500c90340032802141f00050100050c2f0000060200881700cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c706120001f00050100050c2f0000060200d801044038000000001702cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061480d0e000700e40b5402214e20001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02f2030000610020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec030000620020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec030000630020003e003f0d02e57ff30baecb70d3f0ac5419076f767e3a2b7ca7c74967f4d9b85b0d30176db9f20000000082bfda01

Batch to submit on Polkadot Collectives Chain:
0x2804043d003e0201cc1f0005010100a10f05082f00000603008840005e087dadda060e3bae8e49bb359c006fa93d39bfceff059691e7dd0b13b58104010a000000

(The tool also prints convenience batches for submitting all AH- or Collectives-side calls in one transaction.)

The three calls above plus `reg_1010/preimage.hex` on the relay (free, during the delay window) are everything needed to execute the referendum end-to-end.

## Validation against forked chains

The full end-to-end flow was validated using [`polkadot-referenda-tester`](https://github.com/karolk91/polkadot-referenda-tester) running against forked chains.

Two chains needed to be forked with the v2.2.1 runtimes:

- **Relay** — the live runtime filters `Preimage.note_preimage`; v2.2.1 re-enables it.
- **Coretime** — the live runtime caps the broker's reservation list at 10 entries. Cores 0–8 are already reserved (9 entries), so adding three more (97, 98, 99) would overflow with `TooManyReservations`. [Fellows PR #1147](https://github.com/polkadot-fellows/runtimes/pull/1147) raises this cap to 50 and is included in v2.2.1, so the fork must run that runtime for the three new reservations to succeed.

Asset Hub and Collectives are forked without WASM override — they just need a live copy of the current runtime.

**Download the v2.2.1 WASMs** (both differ from `bulletin_runtime.wasm`):

cd "$WORKDIR"

curl -L -o polkadot_runtime.wasm \
  https://github.com/polkadot-fellows/runtimes/releases/download/v2.2.1/polkadot_runtime-v2002001.compact.compressed.wasm

curl -L -o coretime_polkadot_runtime.wasm \
  https://github.com/polkadot-fellows/runtimes/releases/download/v2.2.1/coretime-polkadot_runtime-v2002001.compact.compressed.wasm

**Write the two Chopsticks configs** (unquoted `EOF` so `$WORKDIR` expands into the absolute WASM paths):

cd "$WORKDIR"

cat > polkadot-override.yaml <<EOF
endpoint:
  - wss://polkadot-rpc.n.dwellir.com
mock-signature-host: true
wasm-override: $WORKDIR/polkadot_runtime.wasm
import-storage:
  System:
    Account:
      - - - 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
        - providers: 1
          data:
            free: '10000000000000000'
EOF

cat > coretime-override.yaml <<EOF
endpoint:
  - wss://coretime-polkadot-rpc.n.dwellir.com
mock-signature-host: true
wasm-override: $WORKDIR/coretime_polkadot_runtime.wasm
port: 8001
EOF

**Start both forks**, each in its own terminal. Default Chopsticks port is 8000 (relay); the coretime config above overrides to 8001 so both can run concurrently:

# terminal 1 — relay fork (port 8000)
npx @acala-network/chopsticks@latest -c polkadot-override.yaml

# terminal 2 — coretime fork (port 8001)
npx @acala-network/chopsticks@latest -c coretime-override.yaml

**Run the referenda tester in a third terminal**, pointing Asset Hub and Collectives at their live endpoints, and `--additional-chains` at the two local Chopsticks forks so the tester drives relay + coretime through the fork:

npx github:karolk91/polkadot-referenda-tester test \
  --governance-chain-url wss://asset-hub-polkadot-rpc.n.dwellir.com \
  --fellowship-chain-url wss://polkadot-collectives-rpc.polkadot.io \
  --call-to-create-fellowship-referendum 0x3d003e0201cc1f0005010100a10f05082f00000603008840005e087dadda060e3bae8e49bb359c006fa93d39bfceff059691e7dd0b13b58104010a000000 \
  --call-to-note-preimage-for-governance-referendum 0x0500c90340032802141f00050100050c2f0000060200881700cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c706120001f00050100050c2f0000060200d801044038000000001702cd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061480d0e000700e40b5402214e20001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02f2030000610020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec030000620020001f0005010100b50f050c2f000006020050321704ffffffffffffffffffff02ec03000063002000 \
  --call-to-create-governance-referendum 0x3e003f0d02e57ff30baecb70d3f0ac5419076f767e3a2b7ca7c74967f4d9b85b0d30176db9f20000000082bfda01 \
  -v --additional-chains ws://localhost:8000,ws://localhost:8001 \
  --no-cleanup

After both referenda were enacted by the tester, the expected events were observed:

**Relay chain** — the call was whitelisted and the dispatch scheduled:

ℹ   • Preimage.Requested
▸     Data: {
  "hash": "0xcd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061"
}
ℹ   • Whitelist.CallWhitelisted
▸     Data: {
  "call_hash": "0xcd2e09d4eff32118607390b8346b2e38561bea181ebd36ad2a8798c3d38c7061"
}
ℹ   • Scheduler.Scheduled
▸     Data: {
  "when": 30903979,
  "index": 0
}


**Coretime chain** — one `Broker.ReservationMade` event per `force_reserve` (three in total, one for Bulletin, two for Polkadot People).

ℹ   • Broker.ReservationMade
▸     Data: {
  "index": 8,
  "workload": [
    {
      "mask": "0xffffffffffffffffffff",
      "assignment": {
        "type": "Task",
        "value": 1010
      }
    }
  ]
}
ℹ   • Broker.ReservationMade
▸     Data: {
  "index": 9,
  "workload": [
    {
      "mask": "0xffffffffffffffffffff",
      "assignment": {
        "type": "Task",
        "value": 1004
      }
    }
  ]
}
ℹ   • Broker.ReservationMade
▸     Data: {
  "index": 10,
  "workload": [
    {
      "mask": "0xffffffffffffffffffff",
      "assignment": {
        "type": "Task",
        "value": 1004
      }
    }
  ]
}


With `whitelist_call` having marked the hash as requested, the ~1 MB `Preimage.note_preimage` on the forked relay was submittable for **0 DOT**:



To avoid waiting 14,400 blocks for the scheduled dispatch, the agenda entry was rescheduled to the next block in Chopsticks via `dev_setStorage`:

const current = (await api.rpc.chain.getHeader()).number.toNumber();
const entries = await api.query.scheduler.agenda.entries();
let scheduledBlock = null, agendaValue = null;
for (const [key, value] of entries) {
  const block = key.args[0].toNumber();
  const tasks = value.toJSON();
  if (block > current && tasks.some(t => t !== null)) {
    scheduledBlock = block;
    agendaValue = tasks;
  }
}
if (scheduledBlock) {
  const nextBlock = current + 1;
  await api.rpc('dev_setStorage', {
    Scheduler: { Agenda: [[[scheduledBlock], null], [[nextBlock], agendaValue]] }
  });
  await api.rpc('dev_newBlock');
}

After producing the next block, `dispatch_whitelisted_call` fired, fetched the preimage, and executed `force_register` with Root origin — Bulletin was registered.


After execution of the PJS JS script, it was noted that the call has been dispatched properly registering the chain id 1010 with WASM hash `0xad57082d2d342a06f487fd0d7f2d21e0e03b8a48432a2d9cc8b876fa27c43967`

More confirmations:

Additional checks done with separate run (missed these on the first try):

Coretime chain broker assigned cores:

Relay chain accepting XCM from Coretime and assigning core (to not yet existing Para 1010):


## Open questions

1. **Manager account.** The manager is currently set to `13YMK2edbuhwMBxeUWm9c643A2wyYHwSVh1bCM7tShtg7Dtk`, the sovereign account of Asset Hub on the relay. This diverges from the convention used by other system parachains (Parity-owned account). Is the AH sovereign account the right choice? In practice the manager is largely symbolic — the para auto-locks after its first block, after which only Root or the parachain itself can modify it.