Polkadot Deployment Portal: Why should projects choose to deploy on Polkadot instead of becoming an L2?

In the past, deploying a Rollup on Polkadot was never an easy task. The more flexible a system is, the more complex the deployment process tends to be: from SDK updates, to slot auctions, to governance and runtime upgrades, every step could become a challenge for teams.

To change this situation, Parity launched the Polkadot Deployment Portal (PDP) this year—a "one-stop entry" from building, deploying, to onboarding. Its goal is clear: lower the barrier, simplify the process, and enable any team to quickly and reliably launch and run their own Rollup on Polkadot.

In this article, Parity's Head of Product Development, Santi Balaguer, will take us through the evolution of the Polkadot deployment experience over the past few years, analyze the design philosophy behind PDP, and share how this tool is gradually changing the way Rollups are launched.

The Deployment Experience on Polkadot: The More Flexible the System, the More Complex It Gets

Jay: Welcome to Space Monkeys. Today we have Santi Balaguer, Head of Product Development at Parity. We're here to talk about PDP. What does PDP stand for?

Santi: It's the Polkadot Deployment Portal.

Jay: Before you started working on PDP, what were your main responsibilities at Parity over the past four or five years?

Santi: I've always been closely connected with the developer community, mainly helping them launch parachains and Rollups on Polkadot. Like you said, I was at Parity even before parachains went live.

Jay: Among the projects you often interact with, which ones are we more familiar with?

Santi: I was previously in charge of the Substrate Builders program, which included many well-known projects. The one that impressed me most was the Hydration team. I still remember Jakub's presentation, where he introduced their Omnipool concept and the problems Hydration aimed to solve. He used the classic "money printer goes brrrr" meme to explain why they needed a new solution. I still joke about that with Jakub to this day.

Jay: Haha, that's great. You must have seen many projects successfully land on Polkadot, and surely heard about their pain points. Can you talk about the most headache-inducing aspects of deploying a project on Polkadot over the past few years?

Santi: Of course. Polkadot itself is a very complex system. You really have to understand it for your project to run smoothly. This complexity actually comes from its flexibility—the more flexible the system, the more complex it is.

In the early days, to run a parachain on Polkadot, you first had to deal with all kinds of "breaking updates" to the SDK. Back then, there was no Polkadot SDK, only Substrate, which was different from now. After you set up your development environment, you had to rally community support and participate in slot auctions. The auctions themselves were challenging; you needed enough people to back you, and the results weren't known until the last minute. Even if you won, you had to wait three months before your parachain could actually go live. Plus, the slot was only leased to you for two years. So at that time, you had to go all out on both technical development and community mobilization to secure a place on Polkadot.

Jay: Right. But in recent years, the experience has improved a lot. Can you talk about how that change happened?

Santi: Absolutely. I think Parity made a big effort, especially in reducing breaking updates to the Polkadot SDK.

Although there are still updates now, they're much more stable than before, and compatibility between versions is much better. Developers can now rely on the SDK version they're using with more confidence. Some parachains are still running on older Substrate versions, but they still work fine on Polkadot.

Another thing is the introduction of Coretime (though it has its own complexity), but it has indeed greatly lowered the barrier for developers. It makes it much easier for people to try things out and has significantly lowered the entry barrier to Polkadot. I think we should make the most of this.

Why Do Projects Choose to Deploy on Polkadot Instead of Building an Ethereum L2?

Jay: Even though there were many challenges back then, a lot of them have been solved now. So why do you think a project today would choose to deploy on Polkadot? Why not build an L2 on Ethereum, or just launch their own L1? What's the reason?

Santi: That's a very interesting question. First, I think as a community, we should do more communication and promotion in this area. In my personal understanding and opinion, Polkadot is currently the only blockchain designed from the ground up to natively support Rollups. It provides developers with infrastructure that you can't find elsewhere.

• For example, Polkadot provides a very large data availability layer for Rollups, whereas on Ethereum L2, you have to rely on some external systems or "blobs" to solve this.

• Another example is native message passing between parachains (cross-chain communication), which doesn't exist on other Rollups. Lacking this feature compromises system security.

• Looking at performance, Spamming has already verified that Polkadot's Rollup TPS is outstanding across the industry.

• There's also elastic scaling—Polkadot is currently the only system that can scale infrastructure up or down on demand. For example, if Mythical suddenly wants to launch a new game and expects a 10x user surge in the first week, they can support this traffic almost instantly without major changes.

I think in our past discussions about "parachains and Rollups," we didn't make Polkadot the main focus, and missed an opportunity. But it's not too late; we still have a chance to put it back at center stage.

Jay: Yeah, you also told me before that Polkadot was designed from the ground up for Rollups. We just didn't call them Rollups at first.

Santi: That's right. There's another thing we often overlook: shared security. Looking back at the history of blockchain: first there was bitcoin, then Ethereum. Later, people started launching all kinds of new "Ethereums," claiming "my chain is better because it has features A, B, and C." But the problem is, ensuring the security of a new chain is very difficult. You need a large and strong validator set, which is not easy to achieve.

At that time, Gavin thought: why not provide security as a service, built into the base layer? That's what makes Polkadot unique. It not only provides shared security, but also enables efficient communication between these Rollups, which is something Polkadot excels at.

How Did the Idea for PDP Come About?

Jay: Awesome. If a Rollup wants built-in data availability (and at large scale), instead of patching together other projects, and also wants strong TPS and throughput, plus seamless communication with other Rollups, then Polkadot is indeed very attractive. But before PDP, deploying a parachain was still complex and time-consuming. So what was the original idea behind creating the PDP tool?

Santi: Actually, this idea had been brewing for a while, although we only really started working on it last November.

Our team started working full-time on this project around March or April this year, and now the team is moving fast, turning the idea into reality step by step. This has been in the works for a long time, and there are already some similar solutions in the industry. For example, in the Ethereum ecosystem, there's Conduit and Gelato; on the Polkadot side, there was Tanssi, but they later shifted mainly to Ethereum, with a similar approach.

We saw that nothing was landing on the Polkadot side, so we decided to do it ourselves to make sure it would happen. After all, we understand Polkadot more deeply and know better how to make it easier for developers to deploy projects. That's the goal PDP aims to solve.

We Don't Make Decisions for Developers—We Provide Guidance and Choices

Jay: So who is PDP actually for? I remember in the early days of Polkadot, there was a problem where some projects started out building Rollups, but actually a smart contract would have been enough. What kind of project do you think really needs its own Rollup?

Santi: That's a good question, but I don't think there's a fixed answer. Even now, we still see some projects where a contract might make sense. But sometimes the project team wants independence—they don't want to rely on another chain's infrastructure; sometimes they expect very high future throughput, so they'd rather start with a Rollup. Reasons like these make them want their own chain or more independence at the infrastructure level.

Take Hydration's Omnipool, for example. We could argue whether it could just be a contract, but I think it's reasonable for it to be a chain. On the other hand, look at Uniswap on Ethereum—it started as a contract, then later built its own chain. Do they really need a chain now? Maybe not, but they have their own business considerations.

So there's no absolute answer—it's more a result of both technical and business drivers. For me, the most important thing is: we shouldn't make decisions for developers. What we should do is provide guidance and let them choose for themselves. Whether they want to build a Rollup or a contract, they should be able to try and experiment easily.

Inside the PDP Full Process Experience: From Build, Deploy to Access, Launching a Rollup Is This Simple

Jay: Okay, so let's say a team has made the decision—whether on their own or guided by Magenta Labs or the BD team. They've decided to deploy a Rollup on Polkadot. What will their experience be like when they enter PDP? What does the deployment process look like now?

Santi: In PDP's design, we've divided the process into three main stages: Build—Deploy—Access. These three parts are interconnected.

In the "Build" stage, the core question is "How do I get started?" Our idea is: the best way is through runtime templates. Currently, OpenZeppelin is developing related templates, and the Pop CLI and ROG teams are also working on this. Pop CLI is essentially a tool you can use on your own computer to write Rollups. We're working with them to connect it with the other two stages of PDP (deploy and access).

For example, after you build a Rollup on Pop CLI, you can connect it directly to PDP and deploy the Rollup. That's how we've designed and implemented it. This way, developers can complete the entire process via CLI, just like Heroku or Vercel in Web2, both of which have their own CLI. If you're used to this, you can use the CLI directly; of course, you can also go fully graphical. Both ways work.

Jay: So besides building with templates, you can also use Pop CLI to build and then deploy. Does PDP itself help developers make choices? Or is it just a tool, and the team has to do most of the work?

Santi: Both. We hope PDP can be a self-service tool for developers to use on their own. But if they run into key issues, we'll be there to support them and make sure they get the help they need. Of course, if someone just wants to try it out themselves, that's totally fine too, haha.

Jay: Sounds fun. Can you give some specific template examples? Which ones do you like?

Santi: For example, the ROG team has a ready-made Pilot Revive template you can use to launch right away. OpenZeppelin has the Frontier template—if you want to run a chain with EVM functionality, you can use that directly.

Jay: That's cool—so it's like several smart contract-related options.

Santi: Exactly. There are also templates without smart contracts. For example, if someone just wants to build a chain for asset custody, especially for real-world asset (RWA) projects, there's a template for that too. In short, there will be plenty of options at the start, and you can expand from there.

Jay: Can you add new Pallets to the template as needed?

Santi: Not at first. The idea is you start from a template, and then we'll guide you step by step to do runtime upgrades. We hope this approach helps teams gradually find product-market fit. This design is quite interesting and is one of our current key features. We're now using a very interesting tool built by the Puppet team, which compares the runtime you're about to upgrade with the currently deployed runtime, generates a report, and tells you what has changed, what might affect developers, and what to watch out for.

Jay: Yeah, I saw you just integrated that—awesome.

Santi: Yes, we just finished it this week. This way, you'll get a runtime upgrade report to make sure what you're pushing matches your expectations. Next, we want to add a feature to simulate a few blocks in the background to test the new runtime. If everything works, we'll tell you "ready to go live"; if not, we'll tell you "our tests failed, you should check again." This helps teams avoid mistakes during upgrades. We believe one of Polkadot's advantages is supporting flexible runtime upgrades, and teams can use this to iterate quickly and find product-market fit.

Jay: Wait, so is this part of the "deploy" stage? Is what we just discussed—from building to runtime—considered deployment?

Santi: Yes, there's some overlap here. You can think of building as starting from a template; deployment involves the underlying infrastructure. Previously, you needed your own DevOps team to set up collator nodes and handle operations, but now you don't need to worry about that at the beginning. If your project grows and you have the funds and resources, you can build your own ops team later, and we can help you migrate. But at the start, we'll handle these things for you.

Jay: So who's doing this now?

Santi: Currently, Parity is providing it. But in the future, we'll let developers freely choose which cloud platform to deploy on, or even IBP (infrastructure providers). Abstracting this layer takes some time, so for now, to ensure the experience, we're using Parity's own infrastructure, but eventually, there will be more options.

We've also introduced a concept called BDU (Basic Deployment Unit). As long as you want to deploy a Rollup on the production network, we'll deploy a standardized set of infrastructure for you, including three collator nodes (one of which can serve as an RPC endpoint), and we'll also provide you with an indexer.

We're now working with Subscan, which has an open-source solution we plan to integrate into PDP. This way, you'll not only have an indexer, but also a block explorer. In the past, teams had to spend a long time setting these up, but now we provide it all in one place—it's a great design.

Jay: Wow, sounds great. Is this part of building?

Santi: This is deployment.

Jay: Got it. So at this point, the Rollup is running? It's producing blocks? The team can also do runtime upgrades to keep iterating and find product-market fit? So the next step is the final one—"Access," right? What is that?

Santi: Yes! Access is Polkadot's highlight. I think this is where Polkadot brings unique value to Rollup teams. Building and deploying involve runtime and infrastructure, which most people can figure out quickly, but truly leveraging Polkadot's features is where the difference shows. For example, Coretime is part of Access. PDP will pre-purchase Coretime, so as soon as developers want to deploy a Rollup, they can use it immediately, instead of waiting 28 days to start producing blocks. This is a huge improvement in user experience.

Jay: If I want to deploy, do I have to buy Coretime myself on PDP?

Santi: We'll buy it for you, then charge you for it. In fact, we offer different options for Coretime. For example, if you want to go all out from the start, you can use a full core. But we also offer "sliced cores," which are portions of a core. If you just want to test the waters and don't want to spend too much, you can use a small part of a core.

Jay: Is this feature already available?

Santi: It's already available on PDP. It's running on the Westend and Paseo networks. Paseo just launched sliced cores, and on Westend, you can directly trade for a portion of a core. The downside is your block time will be longer, but the benefit is a much lower barrier to entry—you can test at very low cost. If it works well, you can upgrade to a full core and enjoy six-second block times, all on PDP. However, the onboarding mechanism still needs to solve how to effectively leverage Polkadot. Currently, Polkadot Hub is about to launch as a key functional module, and we're very excited about it.