Paseo Testnet: Relay Downsizing & Sunset

Ecosystem
1

:loudspeaker: Paseo Testnet — Relay Downsizing & Sunset

We are winding down the current Paseo relay chain and moving to a new, right-sized replacement chain launched in parallel.

Start: Thursday 2 July 2026, 12:00 CEST (10:00 UTC). The old relay is fully shut down about 48 hours later — Saturday 4 July, 12:00 CEST. :right_arrow: Migrate to the new chain before then.

TL;DR

  • We shrink the old relay as fast as the network safely allows (one change every 6h) — from 152 validators down to 20 in ~24h — to get back within our infrastructure budget and free capacity for the new chain.
  • Then we hold at a minimal 20 validators for ~24h as a migration window, so teams and users can move over. Parachains keep producing blocks the whole time (just slower).
  • Finally, the old relay is shut down — validators stop their nodes and the chain halts.
  • No surprise downtime. Finality never breaks during the wind-down; the only outage is the planned shutdown at the end.

What it looks like

validator-schedule
validator-schedule880×460 10.9 KB

We drop validators in four steps over the first day, hold at 20, then shut down. Group security is kept constant (5 validators per backing group) at every step, so the chain stays safe the whole way down.

budget-allocation
budget-allocation880×460 9.8 KB

Our total budget is 80 nodes across both chains. The old relay is currently over that on its own, so we downsize it quickly — that pulls the total back under budget and lets the new chain grow into the freed capacity. (New-chain growth shown is illustrative.)

Schedule (all times CEST)

# When Validators Cores What happens
— Thu 2 Jul, 12:00 152 56 Start — normal operation
1 Thu 2 Jul, 18:00 100 20 first cut; consolidation begins
2 Fri 3 Jul, 00:00 60 12 parachain blocks start to slow
3 Fri 3 Jul, 06:00 40 8 further consolidation
4 Fri 3 Jul, 12:00 20 4 floor reached — migration window opens
— Fri 3 Jul → Sat 4 Jul 20 4 grace window — migrate now
5 Sat 4 Jul, 12:00 — — :red_triangle_pointed_down: shutdown — nodes stop, chain halts

The migration window may be extended (shutdown moves to Sunday 5 July) if the community needs more time — we’ll announce any change. The live dashboard always shows the current schedule.

What this means for you

:puzzle_piece: Parachain teams

  • Your chain keeps producing blocks during the wind-down, at a slower cadence (~30–60s between blocks; Asset Hub stays near-normal on its own core).
  • At shutdown (Sat 4 Jul, 12:00 CEST) it stops permanently. Redeploy / register on the new chain before then. Need a bigger core share or more time? Reach out.

:bust_in_silhouette: Users & developers

  • Expect slower confirmations on the old chain during the wind-down.
  • Move your activity and testing to the new chain before shutdown.

:shield: Validators

  • If you’re being offboarded: you’ll be chilled first (no slashing) and rotate out cleanly at an era boundary. Don’t stop your node until we confirm you’ve rotated out.
  • If you’re in the final group of 20: keep running to the end, then stop your node on the coordinated shutdown signal.

:electric_plug: RPC / infra operators

  • Old-chain endpoints serve until shutdown, then can be repointed to the new chain.

FAQ

Why downsize so fast? The old relay is over our 80-node budget on its own. Downsizing quickly frees infrastructure for the replacement chain while still leaving a migration window.

Will finality or block production break? No. Validators are only removed at era boundaries, group security is held at 5, and the schedule auto-pauses if finality health degrades. Parachains slow down but don’t stop until the final shutdown.

What does “shutdown” actually mean — is there a button? No on-chain “stop the network” call exists — a chain runs as long as its validators run. At the shutdown milestone, validator operators stop their nodes in a coordinated way; the chain then stops finalizing and producing blocks. It’s an operational step, announced ahead of time with the exact block/time.

What happens to my funds / state on the old chain? The old chain is a testnet being retired. Move anything you need to the new chain before shutdown; the old chain is unusable afterward.

Can I follow along live? Yes — a public dashboard shows the current validator count, cores, per-chain block cadence, the step timeline with countdowns, and every action taken. https://paseo-downsizer.r0gue.io/

:white_check_mark: Action required

Migrate to the new Paseo chain before Saturday 4 July 2026, 12:00 CEST.

Questions, a larger core share, or more migration time → reach the Paseo maintainers: https://matrix.to/#/#paseo-testnet-support:parity.io

2

:loudspeaker: A note for parachain teams building on Paseo:

The new relay chain will be ready to onboard all the ecosystem team parachains at the exact block they will stop, however if you’d like to carry your parachain’s history across to the new relay chain, there’s one time-sensitive action on your side:

If your runtime still has the relay-block-number check active — and most runtimes do — you’ll need a runtime upgrade before the old relay chain stops producing blocks, to deactivate it. Without it, the new relay starts from a lower block number and a “strictly increasing” relay-number check will stop your collators from authoring on the new network.

Concretely, we are talking about CheckAssociatedRelayNumber in your cumulus_pallet_parachain_system implementation.

A configuration that will ease carrying the history of your chain across relaychains (if this is interesting to your team), is something like the following:

impl cumulus_pallet_parachain_system::Config for Runtime {
// -- snip --
    type CheckAssociatedRelayNumber = AnyRelayNumber;
// -- snip -- 
}

:backhand_index_pointing_right: You can check this configuration as reference if interested: runtimes/system-parachains/asset-hub-paseo/src/lib.rs at 594391d2a6b7757b800d6bc5adea97f536022cb3 · paseo-network/runtimes · GitHub

If you can’t get this upgrade out before the Paseo relay sunset, don’t panic. An alternative migration path that keeps your full state is still possible. The one caveat is that the history will be lost, but the state carries over as your new genesis state.

We know this is tight, and we’re truly sorry for the rush. Please reach us out if you have any questions or need guidance with this upgrade via our usual support channel: https://matrix.to/#/#paseo-testnet-support:parity.io

3

Moving your parachain to the new relaychain

Teams, be mindful that your chains will be functional until the current relay has completed its sunset and hence this guide will become more relevant at that point in time.

As explained above Paseo is moving to a new relaychain. The important thing to know is that
your parachain does not need to start over: your ParaId and your parachain state can
stay as they are. In most cases, the migration is about preparing one runtime setting,
repointing your collators, and checking that everything is included as expected.

This guide walks through the steps. If anything is unclear, please reach out early to
the Paseo team. We are coordinating the relay-side pieces and will help teams land on
the new Paseo cleanly.

1. Runtime change to make before the cutover

Before the old relay goes away, ship a normal runtime upgrade on your live parachain
with this setting in cumulus_pallet_parachain_system::Config:

type CheckAssociatedRelayNumber = AnyRelayNumber; // temporary, for the cutover

Why this is needed: the new relaychain starts again from a low block number, while your
parachain has already seen Paseo relay block numbers in the millions. If your runtime
still uses RelayNumberMonotonicallyIncreases, the first block built against the new
relaychain can fail because the relay block number appears to have gone backwards.
AnyRelayNumber allows the transition.

After your parachain is stable on the new relaychain, change this back to:

type CheckAssociatedRelayNumber = RelayNumberMonotonicallyIncreases;

A few notes:

  • This should be shipped as a regular runtime upgrade before the old relay ends.
  • Your ParaId, parachain state, DB, history, block number, and collator authorities can
    remain the same.
  • Aura slots do not need to be reset as long as the new relaychain is at or ahead of
    wall-clock time. For a normal reset this is expected to be fine.
  • If your runtime uses RelayParentOffset > 0, please also read section 5. You will
    need the slot-based collator mode.

2. Let the Paseo team know you are migrating

Please contact the Paseo team so we can include your parachain in the new relaychain setup.
You can reach us in either place:

The Paseo team will take care of the relaychain-side migration work needed for parachains to
land on the new Paseo. We do still need to know which teams are coming, because cores
and other relay resources need to be allocated intentionally.

The new relaychain spec and endpoints will be made available as soon as possible, and
we will share them through the support channels above once they are ready.

3. Recommended path: you shipped the runtime upgrade in time

If your parachain has already upgraded to AnyRelayNumber, the migration path is
straightforward. You keep your parachain DB, history, block number, and keys. Then you
repoint your collators at the new relaychain.

# 1. Stop your collators.

# 2. Delete only the embedded relay DB.
#    Keep your parachain DB and keystore.
rm -rf <base-path>/polkadot
# Keep: <base-path>/chains/<your-para-id>/...

# 3. Restart pointed at the new relaychain. See section 4.

# 4. Reset your downward-message cursor before DMP reaches you. See section 4b.

# 5. Verify that blocks are produced and included on the new relaychain. See section 6.

Your collator Aura keys carry over automatically. The parachain keeps its own
collator-selection, session, and Aura state, so an authority before the migration
remains an authority after the migration. No key re-injection is needed.

4. Point your collator at the new relaychain

Your parachain chain spec may currently contain:

"relay_chain": "paseo"

For now, that identifier usually resolves to the old Paseo spec bundled into your
polkadot binary: old genesis and old bootnodes. The new relaychain is a different
chain with a new genesis and new bootnodes, even though it is still Paseo. That means
relay_chain: "paseo" may not be enough by itself until the relevant SDK releases have
been updated.

There are two good ways to handle this.

Pass the new relaychain spec explicitly

You can pass the new relaychain spec and bootnode after --:

polkadot-parachain --collator --force-authoring \
  --chain <your-para-spec> --base-path <base-path> \
  -- --chain <relayB-spec.json> --sync fast --bootnodes <relayB-bootnode-multiaddr>

The Paseo team will make the new relaychain spec, bootnodes, and endpoints available
as soon as possible. Once they are ready, we will share them through the onboarding and
support channels.

4b. Reset your downward-message cursor

After your parachain is producing blocks on the new relaychain, and before downward
messages are routed to it, reset:

ParachainSystem::LastProcessedDownwardMessage

This value is part of your parachain’s own state. It still points to a high block
number from the old relay. If left unchanged, your parachain can ignore downward
messages from the new relaychain because they appear older than the last processed relay
message. In logs, this can show up as DMQ head mismatch, and DMP/XCM messages to
your chain may not be processed.

Use whatever root access your parachain normally uses to update this state item. The
Paseo team cannot change parachain state directly, but we can help you confirm the
timing and expected behavior.

5. Collator flags worth checking

  • If your runtime sets RelayParentOffset > 0, run with:

    --authoring slot-based

    This is required for system-parachain-style runtimes. The default lookahead
    collator mode sends zero relay-parent descendants, which can cause a runtime panic
    such as InvalidNumberOfDescendants { expected: N+1, received: 0 }.

  • If your offset is 0, the default authoring mode is fine.

  • Use a polkadot-parachain or polkadot-omni-node binary from
    Release Polkadot stable2603-4 · paritytech/polkadot-sdk · GitHub or
    newer.

  • If your runtime is older than your collator binary, you may see logs such as
    TargetBlockRate... not found or KeyToIncludeInRelayProof... not found. These are
    harmless fallbacks, but upgrading your runtime to the same SDK generation will clear
    them.

6. Verify the migration

Once your collators are running against the new relaychain, check both the parachain side
and the relay side.

On your collator:

  • Blocks are produced without panic.
  • You see new imported blocks.
  • included and finalized advance, not only best.

If best advances but included stays frozen, your collator may be producing
candidates that are not being backed. Tell the Paseo team; this is often a relay-side
configuration issue.

On the new relaychain, using a relay RPC or help from the Paseo team:

  • paras.heads(<your-id>) advances.
  • paraInclusion.CandidateIncluded(<your-id>) events appear.

Finally, send a small test DMP/XCM message and confirm that your parachain emits:

messageQueue.Processed(success=true)

7. If you missed the runtime-upgrade window

If you did not ship AnyRelayNumber before the old relay ended, you can still preserve
your parachain state. The tradeoff is that you will come across as a fresh genesis on
the new relaychain, so you lose continuous block history and block numbering.

The high-level process is:

  1. Export your current state to a raw chain spec from a synced full node or DB:

    polkadot-parachain export-state --chain <your-para-spec> [<block>] > exported-state.json
# Check exact flags with:
polkadot-parachain export-state --help

  2. Build a new raw chain spec using that exported state as genesis.

  3. In the new spec, override parachainSystem.lastRelayChainBlockNumber so it is lower
    than the current block number of the new relaychain. The storage key is typically:

    0x45323df7cc47150b3930e2666b0aa313a2bca190d36bd834cc73a38fc213ecbd

    This key can differ if your runtime renamed parachainSystem.

  4. Give the Paseo team the new genesis head and validation code so the parachain can be
    registered on the new relaychain.

  5. Start collators from the new spec and point them at the new relaychain as described in
    section 4.

This path is a little more involved, but it is still a workable recovery path. If you
are in this situation, contact the Paseo team and we will coordinate the relay-side
steps with you.

4

Paseo relay chain specs are ready

The relaunched Paseo relay chain is live from a new genesis, starting at block 0.
The chain specifications have been published and are ready for downstream teams,
node operators, wallets, indexers, and light-client integrations.

Network: Paseo
Protocol ID: pad
SS58 prefix: 42
Token: PAS with 10 decimals

Where to find the specs

The chain specs are available in the Paseo chain specs repository:

GitHub - paseo-network/paseo-chain-specs: All chain specs for Paseo Network. · GitHub

File Use
paseo.raw.json Full chain spec for running a node
paseo.raw.smol.json Light-client (smoldot) checkpoint spec

How to download

# Full node spec
wget https://raw.githubusercontent.com/paseo-network/paseo-chain-specs/main/paseo.raw.json

# Light-client spec
wget https://raw.githubusercontent.com/paseo-network/paseo-chain-specs/main/paseo.raw.smol.json

To run a node against the new relay chain:

polkadot --chain ./paseo.raw.json

RPC endpoint

A public RPC endpoint is available now:

wss://paseo-v2.rpc.turboflakes.io
wss://rpc-paseo.stakeworld.io

What to expect next

The network is being expanded in a controlled sequence. Additional bootnodes and RPC
endpoints will be added to the specs as more infrastructure comes online. Please pull
the latest version from main before using the files in production tooling or
redistributing them downstream.

Light-client support through @polkadot-api/known-chains is also being prepared.

Thank you for building on Paseo.

5

Paseo Testnet: Sunset Timeline Extension

We are extending the sunset timeline to give ecosystem teams additional time to prepare their changes and coordinate a single cutover.

This notice refers to two relay chains: V1, the current Paseo relay chain, and V2, the new relay chain that Paseo is transitioning to.

The new cutover time is Monday 6 July 2026, 17:00 CEST (15:00 UTC).

At that time, V1 will stop. Validators will complete the move to V2, parachains will be onboarded there, and core assignments will be made on the new relay. Parachain teams should point collators to V2 at the cutover, not before.

Summary

  • Over the past days, V1 has been downsized from 152 validators / 56 cores to its minimum operating floor of approximately 20 validators / 4 cores. Finality has held throughout this process.
  • The original plan was to stop V1 on Saturday 4 July. Several ecosystem teams asked for more time to prepare, so the cutover is now scheduled for Monday 6 July 2026, 17:00 CEST (15:00 UTC).
  • Until the cutover, V1 remains live at reduced capacity. Parachains continue to produce blocks, although at a slower cadence.
  • At the cutover, V1 stops. The remaining validators, parachains, and core assignments move to V2, and collators should be repointed there.
  • Between now and the cutover, more validators are expected to transition to the new relay. This increases available capacity and brings more cores online ahead of Monday.

Timeline

All times are CEST.

When State Action
Now through Monday 6 July, 17:00 V1 remains live at reduced capacity, with approximately 20 validators and 4 cores. The new relay continues to grow as validators transition. Keep using V1 as usual. Do not repoint collators yet. Prepare your migration.
Monday 6 July, 17:00 Coordinated cutover. V1 stops. Validators complete migration to V2. Parachains and core assignments move to V2. Parachain teams repoint collators now. Maintainers will migrate the relevant parachain state needed for the transition.
After the cutover V2 is the live Paseo relay. Use V2 for all activity, testing, and RPC.

What this means

Parachain teams

  • Do not point collators at V2 before the cutover.
  • Core assignments on V2 are made after 17:00 CEST on Monday 6 July 2026. Repoint collators to V2 at that time.
  • Until then, your chain continues producing blocks on V1 at a slower cadence. It stops producing on V1 permanently at the cutover.
  • If you need a specific core share or additional migration support, contact the Paseo maintainers before Monday.

Validators

  • Validators already offboarded from V1 were removed cleanly at an era boundary. No further action is required on V1.
  • Validators in the final V1 floor set should keep running until the cutover, then migrate to V2 and follow the onboarding steps.
  • V2 is already accepting validators. Earlier transitions increase available capacity and help bring more cores online before the full cutover.

Users and developers

  • Continue using V1 until the cutover.
  • Expect slower confirmations while V1 runs at reduced capacity.
  • After Monday 6 July 2026, 17:00 CEST, move activity, testing, and RPC usage to V2.

RPC and infrastructure operators

FAQ

Why is the timeline being extended?

Several ecosystem teams requested more time to prepare their changes before V1 is retired. Extending the timeline to Monday gives teams a clear, shared cutover point and avoids a rushed migration over the weekend.

Why should collators be repointed at the cutover, not before?

Parachains and their core assignments are established on V2 at the cutover. If collators are repointed earlier, they will be pointing at a relay that is not yet carrying their parachain. Repoint collators at 17:00 CEST on Monday 6 July 2026.

Is V1 still usable until then?

Yes. V1 remains live at its minimum operating floor. Finality is holding, and parachains continue producing blocks at a reduced cadence. V1 becomes unusable after the cutover.

What does it mean that V1 stops?

There is no on-chain action that stops the network. A chain continues while its validators continue running. At the cutover, the remaining V1 validator operators stop their V1 nodes in a coordinated way and move to V2. V1 then stops finalizing.

What happens to funds or state on V1?

V1 is a testnet being retired. Move anything you need before the cutover. V1 will not be usable afterward.

For system parachains, relevant state is being migrated and no loss is expected.

Where are the new relay details?

The V2 chain specification is available at paseo-chain-specs/paseo.raw.json at 134b8bf2fd6680976b3cb719a5a87995b59d1bb5 · paseo-network/paseo-chain-specs · GitHub .

Available RPC endpoints:

  • wss://paseo-v2.rpc.turboflakes.io
  • wss://rpc-paseo.stakeworld.io

Action required

  • Parachain teams: be ready to repoint collators to V2 at Monday 6 July 2026, 17:00 CEST, and not before.
  • Validators: transition to V2. The final V1 floor set migrates at the cutover.
  • Users, developers, RPC operators, and infrastructure teams: continue using V1 until the cutover, then switch to V2.

Questions, requests for a larger core share, or migration help: reach the Paseo maintainers in Matrix at #paseo-testnet-support:parity.io.

6

Do you have any EVM-related addresses? Our smart contracts have been stuck in block production for a long time.

7

Paseo relay migration: legacy relay decommissioned

Hi everyone,

The legacy Paseo relaychain has now been decommissioned. It is no longer producing or finalizing blocks, and it will not be supported going forward.

Please move any infrastructure, wallets, CI, light clients, and dapp configs off the old endpoints and old genesis.

Paseo is now running on a fresh relay chain with a new genesis, starting again from block 0. Validator onboarding is already in progress, and parachain teams are being moved over as part of the same rollout. If you have any questions regarding your parachain re-onboarding, please reach out!

New relay endpoints

  • wss://paseo-v2.rpc.turboflakes.io
  • wss://rpc-paseo.stakeworld.io

more to come

Chain specs

The Paseo chain specs repo is the source of truth for raw and light-client (.smol) specs:

The new relay spec is published at the top level:

  • paseo.raw.json
  • paseo.raw.smol.json

All pre-migration specs have been archived under paseo-legacy/.

For light-client and dapp consumers, the updated specs are also being picked up by polkadot-api known-chains.

Action for teams

  • Repoint nodes, light clients, wallets, and dapps to the new relay endpoint and specs above.
  • Regenerate anything that pins genesis or caches chain specs, including .papi descriptors and Chopsticks configs.
  • Check for hardcoded genesis hashes. Anything still pinned to the old genesis will fail.

Questions or onboarding requests: the best place to reach the Paseo maintainers is the Paseo Testnet Support.

8

We are Hosting a public eth rpc for paseo assethub, feel free to use it:

https://paseo-assethub-rpc.laissez-faire.trade

Example:

$ cast balance 0x7D489E3cE5a90dDD37AEE0ccB33D34A41a2D1633  --rpc-url https://paseo-assethub-rpc.laissez-faire.trade
4999990000000000000000
9

The backends for both

https://blockscout-testnet.polkadot.io/

and

https://assethub-paseo.subscan.io/

have not been synced to the latest runtime/upgrades.

We need the latest, fully synced Asset Hub (Paseo / Passet Hub) WSS + RPC endpoints to unblock our contracts, which have been stuck for a long time.

10

We’ve been integrating ComputeFlux with Paseo as part of our work to bring AI compute infrastructure closer to the Polkadot ecosystem.

With the recent relay downsizing, some of our testing has been interrupted while we update our integration.

Is there a recommended migration timeline or any best practices we should follow beyond the published guide?

We’re also interested in collaborating more closely with the ecosystem as we continue building. ComputeFlux is working on decentralized AI compute infrastructure, and we’d love to make sure we’re aligned with upcoming infrastructure changes.

Looking forward to hearing your thoughts, and thanks to everyone involved in maintaining Paseo.

11

Migration Status

New Relay Status

We wanted to let you know that we are close to completing the migration to the new relay chain. At the time of writing, we have successfully onboarded 51 of the 60 validators that we are targeting as part of the network resizing.

For live updates on the validator onboarding progress, please refer to the dashboard used by the Paseo team to monitor the migration:

System Chains

Asset Hub, People, and Bulletin Chain have been successfully onboarded, and the state from Asset Hub and People was carried out from the previous Paseo network.

End users should experience improved stability as we continue onboarding additional RPC nodes. We are currently targeting 3 RPC nodes per system chain.

RPCs

The updated list of RPC endpoints can be found here:

Parachain Teams Status

Several parachain teams have already migrated to the new network under the new operating model, and additional migrations are currently in progress.

Governance Proposal

Lastly, we would like to share that the governance proposal covering H2 operations under the new model is now open for voting:

We appreciate your support and feedback.

Thanks,

The Paseo Testnet Team

12

Hello @ahjxcrz,

Could you please log an issue in the following repo with the Parachain onboarding issue template? We will try to upload it as soon as possible.

Thank you

13

Are you guys still looking for RPC providers? We could take either Paseo Assethub or Assethub ETH

14

Hello @SAXEMBERG,

Thank you very much for your offer. Additional RPC nodes are always welcome, as they improve the overall user experience. However, at this point we only have budget for the RPCs included in the recently launched proposal.

Based on our previous experience relying on other bounties and initiatives to cover Paseo RPCs, we decided that having the RPCs funded directly through the Paseo bounty is the best way to ensure long-term stability. Those RPC allocations have already been assigned to the current Paseo providers.

If you’re interested in operating additional RPCs through your own governance proposal or a similar initiative, we would be happy to support that proposal.

Thanks,

The Paseo Team

15

No worries if there is no room for more. Just a confusion since you guys mentioned you were aiming for 3 RPCs and those have one and two respectively.

That was never the intention so nevermind.