Configuring Rollup

Runtime Selection

The runtime of your Polkadot Native Rollup defines its initial functionality. It forms the foundation of your rollup and is a crucial decision for kickstarting development. While Polkadot-SDK allows runtimes to evolve and be modified over time, starting with a solid base can accelerate your project's progress.

The PDP currently offers two main runtime options, both developed by the OpenZeppelin team:

1. Generic Runtime: This runtime provides basic functionality to kickstart operations. It is ideal for projects aiming to customize their runtime with specific functionalities. This option offers a robust base that can later be extended with additional pallets, either developed in-house or sourced from the ecosystem.
2. EVM Runtime: This runtime includes basic functionality and adds support for the Ethereum Virtual Machine (EVM). It is an excellent choice for projects looking to enable others to deploy logic on their chain. Additional logic can be integrated into the runtime and accessed via precompiles in the EVM.

Both runtimes are equipped with:

• Native integration with the Polkadot Cloud ecosystem via its native bridges.
• Ethereum interoperability through Snowfork and Hyperbridge, ready to be activated as needed.

Environment and Chain Selection

After selecting a runtime, you must choose the network where your Polkadot Native Rollup will operate. The available options include production and test networks:

1. Production Networks:
   • Polkadot
   • Kusama
2. Test Networks:
   • Westend
   • Paseo

Each network has distinct characteristics. It is highly recommended to maintain both a staging environment on a test network and a production environment. This setup allows for safe rollout of new features in line with best practices.

Schedule to Run Selection

Once the runtime and network are determined, the next step is resource allocation for your Polkadot Native Rollup. This is managed through Coretime and simplified as "Scheduled to Run" in the PDP. There are two main options:

1. Right Now: This option enables your Polkadot Native Rollup to start producing blocks immediately after registration. It is the fastest way to launch.
2. Next Cycle: This option provides a dedicated Polkadot Cloud core for your rollup, allowing for predictable renewals over time.

You can switch between these options cycle by cycle, managed directly from the Rollups page. Starting with the "Right Now" option is recommended, with the option to upgrade to a dedicated core in the next cycle.

Other Configurations

Token Name

This defines the name of your rollup's token. For example, Polkadot uses "DOT." The name must be no longer than four characters and cannot be changed later.

SUDO Account

All runtimes on the PDP start with SUDO enabled, providing flexibility during the initial stages. The specified account will have SUDO privileges, which can be transferred later. Ensure the selected account is secure and solely under your control.

Chain Decimals

The number of decimals determines the divisibility of your token. For example:

• Polkadot (DOT): 10 decimals
• Kusama (KSM): 12 decimals
• Ethereum (ETH): 18 decimals

Choose a decimal setting that aligns with your primary use case and facilitates interoperability with other systems.

Price Breakdown

Deploying on the Polkadot Cloud involves two types of costs:

1. Reserved Funds: Tokens temporarily locked during specific operations and released upon completion.
2. Non-Recoverable Funds: Tokens consumed as fees or for coretime purchases.

Reserved Funds

Operations that require reserved funds include:

• ParaID reservation
• Genesis files registration
• Proxy creation

Funds are released upon deregistration of the Polkadot Native Rollup or removal of the proxy. The table below provides an estimate of reserved funds by chain:

(*) Proxy costs depend on existing proxies for the account. More details here.

Non-Recoverable Funds

These costs cover:

• Fees: Dynamic and depend on network activity.
• Coretime purchases: Also dynamic and estimated during deployment.

The PDP Rollup Form provides real-time cost estimates to ensure transparency and accuracy.

Detailed fee breakdown

Please note that a lot of the non-recoverable fees are dynamic and depend on network activity, so the numbers may vary. Reserved fees might also change.

Estimated Reserved Funds

Deposit for wasm creation

constants.Registrar.DataDepositPerByte * query.Configuration.ActiveConfig.maxCodeSize

WASM is the compiled code of your parachain's runtime. It defines all the logic — how blocks are processed, how accounts work, what transactions are allowed, etc. Polkadot uses WASM because it runs safely in a virtual machine, the same across all nodes, and is platform-independent.

Deposit for wasm creation used the maximum possible code size, to allow chains to increase wasm at no extra cost.

The values below can change. It is always the best to query the chain directly.

Deposit for head creation

constants.Registrar.DataDepositPerByte * query.Configuration.ActiveConfig.max_head_data_size

The head refers to the current state root or the latest block’s hash and its metadata. It’s like the "tip" of your parachain’s chain — it tells the relay chain what the parachain looks like right now. Validators check the state transition from the previous head → new head using the WASM runtime.

ParaDeposit

constants.Registrar.ParaDeposit

Deposit for registration of para id (rollup id).

Proxy deposit fees

In the process we create an ANY proxy + a pure proxy (the parachain owner account, that the user becomes an owner of).

The required deposit amount for n proxies is equal to: ProxyDepositBase + ProxyDepositFactor * n Learn more about Proxies here

ProxyDepositBase is the required amount to be reserved for an account to have a proxy list (creates one new item in storage). For every proxy the account has, an additional amount defined by the ProxyDepositFactor is reserved as well (appends 33 bytes to storage location).

Estimated Non-Recoverable Funds

Proxy fees

• add PDP account as NonTransfer proxy for pure proxy - fees for tx.Proxy.add_proxy
• add user account as ANY proxy for pure proxy - fees for tx.Proxy.add_proxy
• Adding pure proxy (buying pure proxy in the first place for the user) - fees for tx.Proxy.create_pure
• Remove proxy (remove PDP account as proxy) - fees for tx.Proxy.remove_proxy

The fees below are dynamic and depend on network activity, so the numbers may vary.

Coretime fees

• Fee for purchasing a core fees for tx.Broker.purchase. You can check current coretime sale price on RegionX or Polkadot-js Apps
• Fee for assigning a task to a core fees for tx.Broker.Assign

Other fees

• Reserve para id fees for tx.Registrar.Reserve
• Register parachain - tx.Registrar.Register