What deploying a parachain involves.

You have a scaffold that compiles. That's table stakes — it means the runtime code is well-formed, but it doesn't yet mean a chain is producing blocks. To get there, four things have to happen:

1. A chain spec describes what your chain looks like at block zero — who has tokens, what it's called, what network it joins.
2. The runtime — your Rust code — compiles to a WASM blob the relay chain can store and execute.
3. A collator (a node running your chain's runtime) registers on the Vitreus relay chain and starts building blocks.
4. The relay validates and finalises those blocks; your chain is live.

Sections 2–4 cover the concepts. Section 5 lays out the current-state walkthrough — what you actually run, today, to get from cargo-check-passes to a block on testnet.

Every scaffold ships a chain_spec.rs file at the project root. A chain spec is the configuration your chain starts with — who has tokens at block zero, what the chain calls itself, what network it joins. Genesis is the formal name for that “block zero” state; the chain spec is the file that produces it.

The shipped file is a development chain spec: single-node, Alice as sudo, a seeded balance so you can sign transactions immediately. The shape is real — the same ChainSpec::builder() API you'd use for a production deploy. The genesis patch in the shipped file seeds Alice's native balance; for marketplace projects it deliberately leaves the asset registry empty (you create assets post-launch via pallet_assets::create).

The relay chain doesn't run your Rust code. It runs the WASM that your Rust code compiles to. WASM is WebAssembly — a portable, sandboxed bytecode format. Your runtime — the code in runtime/src/lib.rs — compiles to a WASM blob the relay chain stores and executes.

One consequence of this shape worth knowing: Substrate runtimes are upgradable by replacing the WASM blob in storage. A runtime upgrade is a transaction, not a redeploy. You can ship new logic to a live chain by submitting an extrinsic that swaps the blob; the next block runs the new code. (Storage layouts have to migrate forward — that's the spec_version bump and the OnRuntimeUpgrade impl from building §6.)

You've already met the term parachain on the FAQ: a chain that lives inside a larger network. ChainForge projects target the Vitreus relay, the larger network in that pairing. The relay handles the heavy-duty pieces — security, finality, validator economics — so your chain doesn't have to.

Two node roles you'll see referenced here and in reference material:

• ▸A validator is a node running the relay chain itself. Validators secure the relay; they don't run your chain.
• ▸A collator is the node software that runs your chain and submits its blocks to the relay. You provide collators; the Vitreus Foundation provides validators.

The mechanics of parachain slot leases, slot auctions, and slot mechanics on Vitreus — what determines whether your chain gets a continuously-included slot or has to share a throughput-limited one — are Foundation-coordinated. When the Foundation publishes the slot economics for Vitreus testnet, this section will name the specifics. Today the testnet path is open to projects in development; the mainnet path is a real-money decision and well outside this guide's scope.

Five steps from compiled-scaffold to block-on-testnet. Each step names what the future automation will do, then the current-state command you run today.

Every extrinsic costs gas. Step 5.4 — the registration — is signed by an account that has to pay for it. On testnet, that gas comes from a faucet: a service that hands out test tokens for free.

The manual-path steps in §5 each fail with their own error surface: cargo build errors at the CLI, polkadot.js apps surfaces dispatch errors in its UI when an extrinsic fails to apply.