A First Look at the Polkadot SDK — From an Ethereum Dev

Introduction and Motivation

When I first tried to understand Polkadot, I got totally confused.

I came from the Ethereum world, where building smart contracts feels pretty straightforward. But with Polkadot, everything seemed flipped—relay chains, parachains, runtimes, WASM… none of it made sense at first. I kept asking myself, Why is this so different?

Like most people, I started digging around—reading docs, watching videos, and asking AI to explain it to me like I was five. Slowly, it started to make sense. Eventually, it clicked.

Now that I can see the big picture, I want to share it with you—so you don’t feel as lost as I did in the beginning.

This post isn’t meant to go deep into the technical details. It’s more of a big-picture overview of Polkadot’s architecture and SDK, especially if you’re coming from Ethereum or another smart contract platform. My motivation here is to help you hit that first “aha” moment and save you some time.

Just a quick heads-up: this is my attempt to explain Polkadot in a simplified way. Some parts might be oversimplified or not fully exhaustive—but the goal here is clarity, not completeness.

Polkadot vs Ethereum — aka Layer 0 vs Layer 1

Before we talk about Polkadot and Ethereum, let’s rewind and ask: What actually makes a blockchain... a blockchain?

At its core, a blockchain is a decentralized network of machines (nodes) that all agree on a shared state. Transactions come in, they get executed, and all nodes eventually agree on what’s true with some cryptography magic—that’s consensus.

To pull that off, every blockchain needs a few key components:

• Consensus mechanism – how nodes agree on state
• Execution layer – how transactions change state
• Communication layer – how nodes talk to each other
• Storage layer – where data lives, on-chain and off-chain

The Ethereum Way

In Ethereum, all these components are locked in:

• Proof of Stake (PoS) for consensus
• EVM (Ethereum Virtual Machine) for execution
• P2P networking for node communication
• RocksDB for off-chain storage, with Merkle proofs for on-chain verification

As a dev, you just write smart contracts and deploy them. You don’t get to change or customize the underlying system.

The Polkadot Way

Polkadot takes a different approach.

Instead of handing you a ready-made blockchain, it gives you the tools to build your own. It’s not a Layer 1 like Ethereum—it’s a Layer 0. A base layer. And the main tool you’ll use is the Polkadot SDK.

With the SDK, you’re not just writing smart contracts. You’re building an entire blockchain from scratch. You decide what kind of chain it is, how it works, and which parts it uses.

Here’s the key difference: with Polkadot SDK, you’re building a real blockchain, just like Ethereum. But this time, you get to choose how it works and where it fits into the network.

When you build using the Polkadot SDK, you usually go down one of two main options: solochain and parachain

Option 1: Solochain

A solochain is a fully independent blockchain. You control everything, including:

• Your own consensus mechanism
• Your own validator set
• Your own security setup
• Your own governance rules

The good part? You get full control.

The hard part? You’re responsible for running and securing the whole thing. That means you have to set up and manage your own validator network—nodes that check and finalize every block on your chain.

Think of a validator set like your chain’s immune system. It keeps the network honest, blocks bad behavior, and helps make sure every transaction is legit. Without a solid validator set, your chain can get slow, unstable, or even open to attacks.

Solochains are often used in more closed or specialized environments, like governments, enterprises, or large corporations—basically any group that wants a private blockchain with complete control over how it works and who runs it.

Option 2: Parachain

A parachain is a blockchain that connects to Polkadot’s relay chain. By doing that, you get a few big benefits right away:

• Shared security
• Finality
• Cross-chain messaging

Instead of building and securing everything from scratch, you plug into the Polkadot network. Your chain gets to use the same validator set that already secures Polkadot. These validators are responsible for checking and finalizing blocks across all parachains.

So what does that actually mean for you?

• You don’t need to create or manage your own validator set.
• You don’t need to worry about building a consensus system.
• You get strong, battle-tested security from day one.

And here’s one of the biggest reasons people choose the parachain route:

You can talk to other parachains directly.

That’s a big deal.

When your chain is plugged into the relay chain, it can send and receive messages from other parachains without bridges or custom glue code. This works through a system called XCMP (Cross-Chain Message Passing), and it’s built into the core of the Polkadot network.

When people say “Polkadot,” they’re usually talking about more than just the relay chain. They’re referring to the whole ecosystem—the relay chain, the parachains connected to it, plus special-purpose system chains and governance modules.

The relay chain is the backbone of the network. It doesn’t run smart contracts or manage user assets. Instead, it focuses on consensus, security, and making sure every parachain stays connected and in sync.

Alongside it, there are system chains—special parachains maintained by the Polkadot core team that provide essential network services. For example, Asset Hub manages DOT balances and NFTs (and will soon support smart contracts via PolkaVM). Other system chains like Collective and Referenda handle governance, voting, and proposals.

So while your parachain can be fully custom, it doesn’t have to reinvent the wheel. Through XCM, you can integrate with these system chains and share features instead of rebuilding them.

And here’s a fun detail:

The relay chain itself—the thing that connects all the parachains—is also built using the Polkadot SDK.

That shows just how flexible the SDK really is. If it can build the foundation of Polkadot itself, it can definitely handle your chain.

You can picture the relay chain as the center of a wheel, and all the parachains as spokes. Each one can be totally different and serve its own purpose—but they’re all connected and protected by the same core system.

And one last note:

When you build a parachain, you don’t bring your own consensus. Your chain will follow Polkadot’s consensus rules—specifically Nominated Proof of Stake and GRANDPA finality. That part is fixed.

Solochain vs Parachain — A Practical Difference

Here’s one last way to think about it, especially if you’re planning out features like tokenomics, governance, or asset handling.

Let’s say your blockchain needs a native token system—minting, transfers, balances, maybe even staking.

If you’re building a solochain, that’s entirely on you. You’ll need to either:

• Add a prebuilt balances pallet to your runtime, or
• Build a custom tokenomics pallet from scratch

You also have to maintain all the accounting, on-chain logic, and validator rules yourself. It’s your chain. Your responsibility.

But if you’re building a parachain, things get more flexible.

Instead of implementing everything from zero, you can tap into the existing Polkadot ecosystem via XCM (Cross-Consensus Messaging).

For example:

• You can interact with Asset Hub—a system parachain managed by the Polkadot team that handles DOT balances, NFTs, and soon, smart contracts via PolkaVM.
• Your chain can query user balances, move tokens, or integrate shared assets—without duplicating the logic.
• Need to build staking or reward mechanisms? You might be able to leverage other parachains for that too, using XCM to coordinate logic across chains.

This is what makes the parachain model so powerful:

You're not just building a blockchain—you’re plugging into an entire network of specialized chains that can work together.

With solochains, you're fully sovereign.

With parachains, you're collaborative by design.

👉 We’ll go deeper into what a pallet is, and how XCM actually works, later in this blog.

That’s when it really starts to come together.

Why This Matters (The Ethereum Problem)

Ethereum has always struggled with scalability. In its original design, everything happens on the same chain, which leads to congestion and high gas fees.

Ethereum’s early plan was sharding—splitting the network into separate “shards” that could process data in parallel. But that plan evolved, and now Ethereum is leaning more on Layer 2 solutions like rollups, which handle execution off-chain and settle back on Ethereum.

Polkadot took a different path from the beginning.

It introduced execution sharding as a first-class feature through its parachain model. And not just any sharding—heterogeneous sharding.

That means each parachain isn’t just a copy of the same shard—they can each be totally different blockchains, optimized for totally different things.

One might be a DeFi platform. Another might be built for gaming. A third could handle identity or NFTs. They can each have different runtimes, consensus setups, transaction models—you name it. But they all plug into the same relay chain for shared security and trust.

Parachains are what heterogeneous sharding looks like in practice.

Instead of bolting on scalability later, Polkadot made it the foundation from day one.

Scalability has always been one of Ethereum’s biggest challenges. In its original design, everything happens on the same chain—every smart contract, every token transfer, every DeFi app—all fighting for space in a single block. That’s why gas fees spike during peak usage.

Early on, Ethereum planned to solve this through sharding—splitting the network into smaller parts (or “shards”) that could process data in parallel. But over time, that plan shifted toward Layer 2 solutions like rollups, which move execution off-chain and settle results back on Ethereum.

Polkadot, on the other hand, took a very different route from the start.

Instead of patching scalability in later, Polkadot made it the foundation. It introduced execution sharding as a core feature—through its parachain model.

And not just basic sharding.

Polkadot uses heterogeneous sharding.

That means each parachain can be completely different. One might focus on DeFi, another on gaming, another on identity or NFTs. Each chain can have its own runtime, its own logic, and its own transaction model. But they all plug into the same relay chain—and share the same security model.

This is what heterogeneous sharding looks like in practice. It’s not 100 copies of the same chain—it’s 100 specialized blockchains, all working together.

And the result?

Massive parallelization.

Because each parachain can process transactions independently, Polkadot’s overall throughput isn’t measured by a single chain’s TPS—it’s the total across all active parachains. According to recent benchmarks, that number can scale up to 143,343 transactions per second across the network.

Polkadot Spammening Report, 2024

So while Ethereum is still working to scale through rollups and upgrades, Polkadot built scalability into its DNA—right from day one.

Now that we understand why Polkadot chose this architecture, you might be wondering: "Okay, cool—but where do I actually deploy my smart contracts?"

It's a totally fair question. If you're used to Ethereum, you probably just want to write some Solidity, hit deploy, and call it a day. But in Polkadot, things work a bit differently.

But Wait—What About Smart Contracts?

If you’re coming from Ethereum, one of the first questions you’ll probably ask is:

“Where do I deploy my smart contracts in Polkadot?”

And here’s the important thing to know:

The Polkadot SDK isn’t for deploying smart contracts—it’s for building blockchains.

More specifically, it’s used to build parachains—custom blockchains that connect to the Polkadot relay chain.

Smart contracts don’t run on the relay chain itself.

Instead, smart contracts live on top of parachains.

So if your goal is to just write and deploy smart contracts, you don’t need to build your own chain.

You need to find a parachain that already supports smart contract execution.

Let’s break that down:

Asset Hub + PolkaVM

Polkadot’s Asset Hub is a system parachain managed by the core team. At first, it was mainly used for handling system-level assets like DOT, NFTs, and balances.

But now it’s starting to evolve.

The Polkadot team is working on something called PolkaVM—a new virtual machine that will let developers deploy Solidity smart contracts directly to Asset Hub. It’s still in the early stages, but the goal is clear:

Bring native EVM-style smart contract support to a parachain that’s fully managed within the Polkadot network.

Other EVM-Compatible Parachains

Want to deploy smart contracts today? Good news—there are already parachains that support it:

• Moonbeam
• Astar
• Acala

These chains are built using the Polkadot SDK, but they’re designed to be EVM-compatible. That means you can write contracts in Solidity, use familiar Ethereum tools, and deploy with very little adjustment.

Just remember:

These contracts run on the parachain, not on the relay chain—and not directly through the SDK.

One thing that might catch you off guard: transaction fees work differently across parachains.

On Ethereum, you always pay gas fees in ETH, no matter what you’re doing. But in the Polkadot ecosystem, each parachain can define its own fee structure. Some might use their own native token, others might let you pay in DOT, and a few are even experimenting with fee-less transactions.

As for the relay chain itself—it uses DOT for basic operations. But most of your day-to-day development will happen on parachains, and that’s where the fee rules can vary a lot.

I won’t go deep into tokenomics here (that’s a rabbit hole for another day), but just keep this in mind:

If you’re planning to deploy on a specific parachain, make sure you check how they handle fees. It might not work like Ethereum.

Ink! and pallet-contracts

Polkadot also supports smart contracts written in Ink!—a Rust-based language built specifically for WASM.

If you're building your own parachain with the Polkadot SDK and want it to support Ink! contracts, all you need to do is include a runtime module called pallet-contracts.

This module adds smart contract functionality to your chain, so others can deploy and run Ink! contracts right on top of it—just like deploying to Ethereum, but on your own chain.

We’ll talk about pallet later in this blog

So Here’s the Bottom Line, ****The Polkadot SDK is for **building a blockchain**, not for deploying contracts.

If all you want is to write and deploy smart contracts:

• Use a parachain like Moonbeam or Astar
• Or wait for PolkaVM to land on Asset Hub

But if you want to build the chain that runs contracts—or customize every layer of your blockchain—that’s where the SDK comes in.

Getting to Know the Polkadot SDK

Now that we’ve talked about what Polkadot is and how it compares to Ethereum, it’s time to look at the actual tools: the Polkadot SDK.

If you go check out the official GitHub repo or dive into the SDK docs, you’ll start seeing a bunch of unfamiliar terms. Don’t worry—this is totally normal. I went through the same thing.

Here are just a few of the concepts you’ll run into:

• Substrate
• Runtime
• FRAME
• Pallet
• WASM
• Cumulus
• XCM …and a bunch more.

At first glance, it might feel like alphabet soup. But each of these terms has a specific role in the system, and once you understand what they do—and how they fit together—it gets way easier to navigate.

So here’s what I recommend:

Pause. Go explore the GitHub and docs. Click around. Read a bit. When things stop making sense (and they will), come back here.

This section is your map. I’ll break each of these terms down and show how they connect into the bigger picture of building a blockchain with the Polkadot SDK.

We’re still just scratching the surface—but this is the point where it starts coming together.

Substrate: The Foundation

Let’s start with a term you’ll see everywhere: Substrate.

In simple terms, Substrate is the framework used to build blockchains.

So when someone says “Substrate-based blockchain,” they’re talking about a chain built using this framework. It’s the engine behind the scenes. If you’re running a node on a Substrate chain, you’re running a Substrate node. And if you’re using the Polkadot SDK? You’re already working with Substrate—just with extra tools on top.

But Substrate isn’t just a code library—it’s a full toolkit. It gives you:

• A modular setup to define how your chain works
• A networking layer so nodes can sync and talk to each other
• A runtime system where your chain’s logic lives
• A reliable, production-ready node implementation
• Helpful dev tools like templates, testing tools, and even front-end scaffolding

💡 Fun fact: The Polkadot SDK used to be called Substrate. The name changed to make it clearer that the SDK now includes more than just the core framework—it also comes with tools for building parachains, like Cumulus, XCMP helpers, and more.

A question I ran into early on—and maybe you’ve asked it too—is:

“Is Substrate the same thing as Polkadot?”

Short answer: No.

Polkadot is a blockchain network built using Substrate. Substrate is the framework. Polkadot is one implementation of that framework.

Of course, Substrate isn’t completely open-ended—it’s opinionated. It gives you a set of tools and patterns to follow. But most of those pieces are modular and interoperable. You can swap things in or out, or build your own.

Think of it like Next.js in the web world. Next gives you a structure for server components, routing, and rendering—but you’re still building your own app. Same with Substrate: it defines things like how runtimes work, how to manage storage, and how nodes sync—but what you build with it is up to you.

So no—Substrate isn’t Polkadot.

But Polkadot is built with Substrate—just like your chain could be.

Once you finish building your chain using the Polkadot SDK (aka Substrate), you don’t just have a bunch of Rust code—you compile it into an executable binary.

That binary is what runs on each validator machine. It’s called a Substrate node, and it includes everything (in the illustration above) your chain needs to operate.

Runtime: Where Blockchain Logic Lives (But Not Like What I Thought at First)

When I first heard the word “runtime,” I immediately thought of something like a JavaScript runtime—like Node.js, where your code runs inside an environment that gives you access to things like the file system, timers, and so on.

But in Polkadot and Substrate, that idea doesn’t really apply.

The runtime isn’t the environment.

The runtime is the logic.

It’s the brain of your blockchain—the part that defines how everything works. It controls how accounts behave, how balances move, how transactions get processed, and how blocks are validated. All the core rules of your chain live here. The runtime is written in Rust, but it’s compiled to WASM (WebAssembly).

Why WASM?

There are a bunch of virtual machine formats out there—JVM (Java Virtual Machine), EVM (Ethereum Virtual Machine), native binaries, and more. But Polkadot (and Substrate) specifically chose WebAssembly (WASM) as the execution format for the runtime. Here's why—and why the others didn’t make the cut.

1. Sandboxed Execution

WASM runs in a fully sandboxed environment. That means your runtime code can’t touch the host machine’s filesystem, network, system clock, or anything else unless explicitly allowed.

This is absolutely critical in a decentralized blockchain. Every node on the network needs to be able to run your logic and trust that it won’t do anything sneaky or unpredictable.

Compare that to:

• Native binaries (compiled Rust, C, etc.) → Super fast, but can access everything, including disk and network. Total security nightmare for validator nodes.
• JVM → Offers some sandboxing, but it’s heavy and harder to fully restrict. Also includes features like garbage collection and threads that can introduce unexpected behavior.
• EVM → EVM is sandboxed and purpose-built for smart contracts, but it’s tightly coupled to Ethereum’s architecture and much more limited in capability and tooling.

2. Determinism

Blockchain runtimes must be 100% deterministic.

That means: given the same input, every validator node must produce the exact same output, byte-for-byte. If one node disagrees, the whole network could fork.

WASM is designed for deterministic execution—especially when compiled from strict, statically typed languages like Rust.

Why not others?

• JVM introduces non-determinism through features like threads, GC timing, floating-point math differences across platforms, etc.
• Native binaries depend heavily on the machine and OS. Even compiling the same code on different systems can result in different behavior.
• EVM is mostly deterministic—but has quirks and limitations, especially when handling more complex computation, and isn't as broadly supported or optimized as WASM.

3. Portability

WASM is platform-neutral and built to run the same way across all environments—browsers, servers, blockchains, embedded devices. It's lightweight, compact, and doesn’t care if you're running on Linux, Windows, ARM, or x86.

That’s a huge win for blockchain networks with validators around the world running on different hardware setups.

Now compare:

• JVM needs a full-blown Java runtime installed, and behavior can still vary slightly across platforms.
• Native code is highly optimized—but also platform-dependent. You'd need to recompile for each target OS/architecture.
• EVM is not designed for portability beyond Ethereum and chains that explicitly mimic its architecture.

4. Performance

WASM is fast. It was originally designed to run high-performance applications in the browser (like games and video editors). It compiles down to near-native speed and runs with very little overhead.

Compared to:

• JVM → Slower startup times, heavier memory usage, GC pauses.
• EVM → Designed for security over speed, so it’s intentionally limited.
• Native code → Fastest, but unsafe and insecure for untrusted execution environments.

So... How Does the Runtime Do Anything Useful?

WASM is great—but it’s also locked down. It runs in a sandbox, which means it can’t access your machine’s file system, system clock, or network on its own.

So... how does it actually do anything?

How does it read from storage? Or get the current time? Or write logs?

That’s where host functions come in.

Host functions work kind of like system calls. The runtime doesn’t implement them—it just knows the interface exists. It says, “Hey, I need this,” and the host (your Substrate node) takes care of the details.

A simple way to picture it:

The runtime says: “I need to read from storage.”

The host replies: “Got it. Let me handle that for you.”

During the build process, these host functions are wired in—but the runtime stays agnostic. It doesn’t know how they work, only that they will work when it runs inside a node.

This separation is super important. It keeps the runtime deterministic while still allowing it to interact with the real world.

Here are some examples of common host functions:

• storage_set / storage_get – for reading and writing chain state
• timestamp_now – for accessing the current block timestamp
• ext_crypto_* – for doing cryptographic operations
• log – for debug output during runtime execution

One more thing worth noting: functions like http_get—which would make external API calls—are not allowed in the runtime. That’s because they’re non-deterministic. Different nodes could get different results from the same request, and that would break the whole consensus model.

The runtime must be pure—same input, same output, every time.

Host functions give it power, without breaking that rule.

Common Host Functions

Here are a few key ones you’ll see in action:

| Function | Purpose | | --------------------------- | ------------------------------------------------------------------- | | storage_set / storage_get | Read/write runtime state | | timestamp_now | Get the current time (host-managed) | | http_get | External data fetch (not used in runtime—only in off-chain workers) | | log | Output logs for debugging | | blake2_256 | Hashing utility | | ext_crypto_* | Cryptographic functions |

Again: the runtime does not implement these. It just calls them like, “I trust you’ll be there.”

You can even implement your own custom host functions if you need to extend the node in specific ways.

Runtime APIs: Getting Info Out

In addition to executing logic, your runtime also needs a way to share information with the outside world.

Things like:

• What’s the current block number?
• What’s a user’s balance?
• What’s the chain’s current state?

That’s where Runtime APIs come in.

These are read-only functions exposed by the runtime. Other parts of the node—or external tools like block explorers, wallets, and frontends—can call them to query on-chain data.

It’s basically how you poke into the runtime from the outside—without affecting the state.

The Polkadot SDK provides some built-in runtime APIs, but you can also define your own custom runtime APIs.

For example, let’s say your chain has a custom staking system. You could create a runtime API that returns a user’s current rewards, or their staking tier—so your frontend can display it without needing to re-calculate anything client-side.

It’s a clean way to surface useful info, without exposing internal storage details or writing full RPC extensions.

What About Storage?

A common point of confusion—at least for me—was how storage actually works in a blockchain like Polkadot.

Here’s where a lot of people (including me) get tripped up at first.

When your runtime writes to storage—say, updating an account balance—it’s not directly writing data into the blockchain itself. The blockchain doesn’t store all that data.

What it actually stores is just the Merkle root hash—a fingerprint of the current state.

So if you’re wondering:

$$ hash(database) = ?? $$

That’s the core challenge in blockchain design:

How do you compute a hash of a massive, constantly changing database efficiently, quickly, and in a way that all nodes will agree on?

The answer is the Merkle Trie.

A Merkle Trie combines the structure of a Merkle trie (great for verifiable state proofs) with a key-value trie (great for fast lookups and inserts). Every storage item—like a balance or a block header—is stored under a key. Each change only touches part of the trie, so the rest can stay the same. The end result is a new Merkle root hash that summarizes the entire state. This blog will not cover how merkle trie works.

This root hash is what gets saved in the block—not the full state.

This keeps block sizes small while still letting validators verify that everyone is working from the exact same global state. And this isn’t just a Polkadot thing. Ethereum uses a similar approach—storing a state root in each block, while the actual data lives off-chain in a Merkle Patricia Trie (MPT) structure.

Polkadot does it slightly differently, but the idea is the same: don’t dump the whole database into every block—just store a compact hash that proves the state is valid.

Substrate uses RocksDB as the actual storage engine to persist this trie structure to disk. It’s a high-performance key-value store that’s perfect for fast reads, writes, and trie-based updates.

So when your runtime uses something like #[pallet::storage], it’s not managing the data itself. It’s calling a host function, which passes the write operation to the underlying RocksDB instance.

The runtime stays clean, deterministic, and abstracted. The database stays fast and scalable. And the blockchain only records what it has to: the state root.

FRAME and Pallets: Building the Brain of Your Blockchain

So far, we’ve talked about Substrate as the foundation for building your blockchain.

Now it’s time to zoom in on the part that handles your actual business logic—how your chain behaves and what it can do.

What is FRAME?

FRAME stands for Framework for Runtime Aggregation of Modularized Entities.

Yeah—it’s a long name. But here’s what it really means:

FRAME is the part of Substrate that helps you build your runtime.

Your runtime is written in Rust, and FRAME gives you the tools, macros, and structure to make that process easier and more modular.

It’s what takes your Rust code and turns it into a WASM runtime that actually runs on-chain.

Without FRAME, you’d be writing all the low-level state machine logic yourself—handling storage access, lifecycle hooks, and logic by hand. With FRAME, you just plug in the pieces and focus on what your chain is supposed to do.

And here’s something important to keep in mind:

This is where most of your development time will go.

When you're building a blockchain with the Polkadot SDK, you’ll spend most of your time working inside FRAME—customizing settings, configuring behavior, and writing or modifying pallets to define how your chain works.

What’s a Pallet?

At the heart of FRAME is the concept of pallets.

A pallet is like a plug-and-play module that adds specific features to your blockchain.

Need balances and token transfers? Add the Balances pallet.

Want to enable governance? Drop in the Democracy pallet.

Planning to support staking or validators? Use the Staking pallet.

Want smart contracts? Yep—there’s a Contracts pallet for that too.

Pallets are reusable, composable, and configurable. You can use the built-in ones that come with Substrate, or you can write your own from scratch.

FRAME gives you the tools to connect them all into a single runtime.

Common Pallets You’ll See in Most Chains

• pallet_balances – Manages user accounts and token balances
• pallet_timestamp – Tracks the current block timestamp
• pallet_sudo – Superuser access (great for testing/dev chains)
• pallet_democracy – Voting, referenda, and governance proposals
• pallet_session – Handles validator session keys
• pallet_staking – Proof-of-Stake logic and validator rewards
• pallet_contracts – Runs WASM smart contracts written in Ink!

👆 This is the same pallet_contracts I mentioned earlier in the smart contract section.

If you’re building a parachain and want to support Ink! smart contracts, this is the pallet you’ll use. It lets others deploy and run contracts on top of your chain.

• pallet_assets – Lets you create and manage custom assets or tokens

Each pallet focuses on a specific job. Most define their own storage, expose public calls (called extrinsics), and hook into runtime lifecycle events like block initialization or finalization.

In most cases, you’ll start by combining a few core pallets, and then layer on your own logic with custom ones.

So How Does FRAME Fit In?

Here’s a simple way to look at it:

• Substrate gives you the base layer—node logic, networking, storage, and the database.
• FRAME gives you the structure and tools to define your runtime—the part that holds your chain’s business logic.
• Pallets are the actual building blocks FRAME uses to shape that logic.

When you compile your chain, FRAME takes all your configured pallets, wires them together, and outputs a single WASM binary.

That binary is your runtime—the logic that every validator will execute to keep the chain in sync.

Cumulus: Turning Your Blockchain Into a Parachain

So—you’ve built your own blockchain using Substrate. You’ve written your logic in FRAME, added the right pallets, and compiled everything into a WASM runtime.

But if you want your chain to connect to Polkadot, you’re not quite done.

That’s where Cumulus comes in.

Cumulus is the toolkit that transforms your Substrate-based blockchain into a parachain—a chain that can plug into the Polkadot relay chain and work as part of the larger ecosystem.

Why do you need it?

Because Polkadot has rules. To become a parachain, your blockchain has to:

• Give up its own consensus mechanism
• Sync with the relay chain’s block schedule
• Support shared security
• Enable cross-chain messaging (XCM)

You don’t get any of that just by building with Substrate. That’s why Cumulus exists—to fill in the missing pieces and make your chain relay-chain compatible.

What Does Cumulus Actually Do?

When you add Cumulus to your chain, it upgrades your node with the features needed to behave like a proper parachain.

Specifically, it adds:

• A parachain consensus layer, so your chain syncs with the relay chain’s schedule instead of running its own
• Support for XCM (cross-chain messaging), so your chain can talk to other parachains and system chains
• A collation system, so your chain can submit blocks to the relay chain for validation

All your original logic and pallets stay intact. Cumulus just makes your node relay chain-aware.

Collators vs Validators: Who Does What?

Once your chain becomes a parachain, the roles change. You’re no longer using Aura or BABE for consensus. You don’t have your own validators. Here’s how it works:

Collators

Collators are nodes that build parachain blocks. They:

• Run your parachain node
• Collect transactions
• Execute the runtime
• Produce blocks
• Submit those blocks to the relay chain

Collators are usually maintained by the parachain team—that means you, the developer.

You’re responsible for keeping them online, incentivizing them, and making sure your chain keeps producing blocks.

Validators

Validators are part of the Polkadot relay chain. Their job is to:

• Verify that the block from your collator is valid
• Confirm that the state root matches what your runtime would produce
• Finalize it using GRANDPA consensus

These validators are not your responsibility. They belong to the Polkadot ecosystem and secure all parachains as part of Polkadot’s shared security model.

This setup gives you the best of both worlds:

• You keep full control over your chain’s logic, features, and upgrades.
• You don’t have to manage a separate validator economy or build a consensus protocol from scratch.
• You get enterprise-grade security by plugging into Polkadot’s validator set.
• And you get access to XCM, letting your chain talk to other parachains, bridges, or system chains like Asset Hub.

Cumulus is what makes all of that possible. It’s the final step in taking your solo blockchain and launching it as part of something bigger.

XCM: How Blockchains Talk to Each Other

One of Polkadot’s biggest strengths is that it’s not just a single blockchain—it’s a whole network of blockchains, all connected through the relay chain.

But here’s the obvious question:

How do these chains actually talk to each other?

That’s where XCM comes in.

XCM stands for Cross-Consensus Messaging.

It’s Polkadot’s built-in way for blockchains to communicate—whether that’s parachain to parachain, parachain to relay chain, or even out to other networks through bridges.

And this is important:

XCM isn’t just for sending messages—it’s about sending actions.

It lets one chain say to another:

• “Send this token to someone on your chain.”
• “Run this instruction for me.”
• “Move this NFT over.”
• “Check this user’s balance.”

Each parachain can have its own logic and structure—that’s the whole point of Polkadot. But XCM lets them still understand each other and work together.

In most ecosystems, cross-chain messaging means building custom bridges, writing glue code, or trusting third-party relayers.

Polkadot skips all that.

Because all parachains connect to the same relay chain, and XCM is part of the Polkadot SDK, communication is built in by default. Just send a message—it’ll get routed securely through the relay chain.

You can use this to:

• Query balances on Asset Hub
• Send tokens to Moonbeam
• Trigger logic on another chain —without writing a bunch of custom infrastructure.

And since XCM is versioned and designed to work even across different consensus systems, it’s made to last.

What Concepts Only Apply to Parachains?

Right now, some of the concepts we’ve covered might feel a bit mixed together—parachain stuff blending in with solochain stuff.

So let’s take a moment to clear that up.

This section is here to show you which parts of the Polkadot SDK are only relevant when you’re building a parachain—and not something you need to worry about if you're building a solochain.

Cumulus

Cumulus exists for one reason:

To turn your Substrate-based chain into a parachain that can connect to Polkadot.

If you’re not planning to connect to the relay chain, you don’t need Cumulus.

Your solochain can run its own consensus (like Aura or BABE), and doesn’t have to sync with Polkadot’s block schedule or validators.

XCM

XCM (Cross-Consensus Messaging) is used for parachain-to-parachain communication.

It’s what lets chains inside the Polkadot ecosystem send messages, transfer assets, or trigger logic across boundaries.

If you’re building a solochain, you’re outside that network—so XCM isn’t relevant.

Quick reality check on the developer experience: it's different from Ethereum, but not necessarily harder.

Instead of Remix and Hardhat, you'll be working with Rust and Cargo. Instead of Etherscan, you'll use Polkadot.js Apps or Subscan. The testing story is solid—Substrate gives you good tools for unit testing your pallets and integration testing your runtime.

Debugging can be trickier since you're working with WASM, but the error messages are usually pretty clear. And honestly? Once you get comfortable with the Rust ecosystem, the development experience feels more structured than JavaScript-land.

The biggest adjustment? You're not just writing logic—you're thinking about the entire system. But that's also what makes it powerful.

Development Flow: Solochain vs Parachain

Here’s a high-level overview of what the development journey looks like when building with the Polkadot SDK.

Pallet Assembly

You build with pallets, assemble with FRAME, power it with Substrate, and (optionally) connect with Cumulus.

Wrapping Up

If you’re coming from Ethereum, Polkadot definitely feels like a different world at first. Instead of just writing smart contracts, you’re thinking about entire blockchains. Instead of one chain trying to do everything, you're working with a network of specialized chains, each doing its own job, yet still connected.

My advice? Start small.

Try deploying a contract on Moonbeam or Astar—something familiar to get a feel for how things work. Mess around with XCM by moving assets between parachains. You don’t have to build your own chain on day one.

But if the time comes—if you’re working on something that truly needs its own rules, its own logic, its own performance layer—that’s when the Polkadot SDK shines.

For me, learning Polkadot wasn’t just about picking up a new tool.

It made me rethink what a blockchain actually is. It forced me to look under the hood—to understand execution, consensus, storage, and architecture in a way I hadn’t before.

And if that sounds exciting to you, you're in the right place.

References

Here are some of the resources I found super helpful while trying to piece everything together:

• Polkadot SDK Official Docs
• Polkadot Wiki
• Polkadot GitHub Monorepo
• Polkadot Spammening Report (2024) – For TPS and performance insights
• Substrate Online Workshop
• Rust State Machine

My Social

• Github
• LinkedIn
• My Website
• X