Grant Application: Polkadot Interop Devnet (PIDN)

[shivaniD96]

Project Abstract

"Empowering developers to revolutionize cross-chain innovation—Polkadot-first, one-command multi-ecosystem devnets for seamless testing and prototyping."

The Polkadot Interop Devnet (PIDN) will make Polkadot the natural hub for multi-chain development. With a single command, developers will be able to spin up a local or CI-ready relay chain + parachains alongside optional Cosmos zones, Ethereum clients, Solana validators, and Bitcoin nodes, plus preconfigured bridges (e.g., Snowbridge, Axelar, Wormhole).

PIDN will provide a unified CLI and API to orchestrate networks, automate XCM/relayer flows, enable AI-assisted troubleshooting, and deliver benchmarking for finality, latency, and throughput. By collapsing setup time from weeks to minutes, it will allow developers to focus on application logic rather than infrastructure, accelerating the creation of interoperability-native applications.

PIDN is designed to make Polkadot the default starting point for cross-chain development:

• Every devnet will begin with a Polkadot relay chain and parachains at the core, with other ecosystems optionally layered on.
• XCM testing and benchmarking will be first-class features, positioning Polkadot as the control plane for interoperability.
• By providing a production-like environment where both human and AI developers can build, test, and rerun workflows, PIDN will turn Polkadot's interoperability promise into an accessible developer advantage.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[shivaniD96]

I have read and hereby sign the Contributor License Agreement.

[muddlebee]

Chopsticks by Acala already solves the core problem you are trying to tackle.

[shivaniD96]

@muddlebee
Zombienet and Chopsticks are good tools but they're pretty limited in scope.
Zombienet works well for spinning up quick Substrate testnets in CI. Chopsticks is solid for forking mainnets and debugging XCM stuff. But that's about it - they're Substrate-only.
The bigger issues:

1. Can't test across other chains (Cosmos, Ethereum, etc.)
2. Not really production-like - Chopsticks just simulates with WASM, Zombienet runs local emulations
3. Missing a lot of pieces - no bridges, no real orchestration, no proper observability or SDKs

PIDN is trying to solve a different problem. We want full multi-ecosystem testing that actually works like production:

1. Real nodes running, not simulations
2. Spin up entire cross-chain networks with one command
3. Benchmarking and monitoring built-in
4. Simple config files instead of complex setup

Basically Zombienet/Chopsticks handle Substrate testing fine. We're focused on the much harder problem of testing real interoperability between different blockchain ecosystems.

[muddlebee]

Not really production-like - Chopsticks just simulates with WASM, Zombienet runs local emulations

Chopsticks, Zombienet is already used for production regression/e2e tests, some examples here and here

Missing a lot of pieces - no bridges, no real orchestration, no proper observability or SDKs

Chopsticks is easily compatible with polkadot-api a TS based SDK to interact with substrate chains and XCM use-cases.

Personally, I’ve been using Chopsticks for both dev and production readiness - it’s very handy to emulate the latest chain state quickly.

[shivaniD96]

@muddlebee thanks for the pointers. Chopsticks/Zombienet are solid for Substrate-only e2e/regression and we’ll keep using them (with PAPI) for that surface. PIDN targets a different gap: cross-ecosystem orchestration — Polkadot at the center with ETH/Cosmos/etc nodes + bridges, full-node paths, observability, and CI recipes in one command. We’ll keep our milestones focused on that interop scope.

[PieWol]

Hey @shivaniD96 ,
can you please also tick the last mandatory box of the PR description? About the announcement guidelines. Otherwise looks good. We'll start reviewing and get back to you.

[keeganquigley]

• You emphasize "production-like" conditions. To add to what @muddlebee stated above, can you please provide specific technical details on how your relay chain and parachain nodes will differ from Zombienet's approach? In other words what makes your implementation more "production-like"?
• When it comes to preconfigured bridges like Snowbridge, Axelar, and Wormhole, how will you handle the bridge setup, particularly regarding collateral requirements, validator sets, and economic security models in a local devnet env?
• What's your strategy for managing computational resources across multiple blockchain networks? Just Kubernetes alone?
• Looking at your GitHub profiles, there's limited visible activity. Can you provide examples of relevant open-source contributions or projects that demonstrate your capability to deliver this scope of work?
• Unfortunately we can't offer upfront payments as part of the grants program, as it is entirely milestone based. Additionally, we require 50% to be paid in vested DOT. Would you consider upping the percentage to 50%?

[Noc2]

Thanks for the application. Could you also share your previous work here or link to it?

[Lederstrumpf]

Hi @shivaniD96, thanks for your application.

Strong testing frameworks for cross-chain interactions are of course valuable, yet I'm still left with mixed feelings about your application.

For substrate-chain↔substrate-chain interactions, I agree with @muddlebee that chopsticks already addresses the essence of the problem you're applying to create a new framework for, and am somewhat puzzled that chopsticks only shows up on the periphery of your architecture description.

For substrate-chain↔elsewhere-chain interactions, I reckon the priority is Ethereum bridging, so the primary (trustless) contenders are Hyperbridge and Snowbridge:

Conducted early Snowbridge experiments, confirming feasibility of DOT↔ETH test transfers in controlled environments.

Well, since you mention Snowbridge specifically: this already has an E2E testing framework (smoketest) for various scenarios. This is built on top of zombienet + geth/lodestar, so has reduced maintenance overhead, and is as close to "production" as, in my mind, regular tests ought to be.

And having worked a lot with snowbridge's smoketest harness, no (material) scenarios that a unified testing harness could address that couldn't (or can't already) be done with the existing smoketest environment come to mind. In particular, I don't see blockers for dApps reusing smoketest by deploying their applicable smart contracts on the local geth node, and/or adding existing / custom parachains on the zombienet side. And in principle, the smoketest framework can also be used with production networks.

DX Gaps: Through user interviews and ecosystem conversations, observed that current workflows require developers to become DevOps experts first, validating the need for PIDN's "minutes not weeks" promise.

Which ecosystem projects (bridges/dApps) have already expressed a need/desire for a solution like yours for Substrate? For the ones that tried using smoketest: in which scenarios did they encounter significant limitations?

[...] current workflows require developers to become DevOps experts first [...]

On a less serious note: I reckon running smoketests requires less DevOps experience than setting up a k8s cluster - even with helm ;-)

[shivaniD96]

Thanks guys for feedback. I gathered some more info and will try to answer you guys one by one. I will let other team members also chime in here for some of the details.

Starting with @keeganquigley.

1. The nodes themselves won't be different from how Zombienet spins up the binaries - in fact, Zombienet does a great job at it. Where PIDN extends beyond is booting a complete ecosystem environment that includes numerous peripheral services devs rely on in mainnet/testnet. This includes but is not limited to: faucets, explorers, chain registry, bridges and any other custom frontend required. Our goal is to provide a complete bootstrapped environment that is accessible not just to low-level Rust devs but also enables full-stack dapp developers to spin up complex network topologies from a simple config file.

2. Bridges will be the most complex part of the project, and where we will require the most ecosystem support as well. But our strategy is to emulate the actual processes that validators and node operators perform in production and make it part of glue code that would be able to set up the system. Economic security is not reproduced - it is just mocked. Instead we provide toggles to simulate faults/misbehavior so apps can test handling.

3. Yes, we mostly rely on Kubernetes resource management. Similar to how starship handles resources by simplifying it for users. What we will provide are smart defaults that we will test over local docker-desktop environment, GitHub Actions CI/CD pipelines and for larger k8s clusters. In our experience, these smart defaults handle 90% of use cases, and devs barely need to change them. For the remaining 10%, we will make it configurable and well documented.

4. I appreciate your concern for team capabilities - we have also reached out to the foundation and @PieWol about this as well. I am handling docs, product reviews, stakeholder management, user interviews etc., basically everything not having to deal with the implementation, while the engineering tasks will be led by @puneet2019 - you can find his opensource contributions here. He has led significant web3 projects in the Cosmos ecosystem like: persistenceCore and pstake-native. He has also contributed to the wider cosmos ecosystem including Cosmos-SDK, Osmosis and many other Cosmos L1 chains. Since PIDN is going to be a plugin for Starship, we also have @Anmol1696 helping us out, who created Starship and has a lot of experience with dev tooling. I will let them also chime in on some of the technical details in the thread. Our team is new to the Polkadot ecosystem, but not new to web3 or large opensource projects.

5. For the payment structure, we will definitely change that up and make it more milestone-based.

[shivaniD96]

@Noc2 I believe point 4. from comment will cover your ask.

[shivaniD96]

@Lederstrumpf

Strong testing frameworks for cross-chain interactions are of course valuable, yet I'm still left with mixed feelings about your application.

Sure lets change that.

1. Chopsticks: From our research, PIDN would actually be closer to Zombienet than to Chopsticks since we will be running actual binaries and nodes/operators with Docker and Kubernetes orchestration rather than with a WASM-based emulated environment.

2. Snowbridge smoketest: Thanks for pointing it out - we have been looking into it, and it seems to be an amazing project that gets the job done. Our insight so far has been that reducing integration complexity for devs and getting them started quickly has a lot of downstream benefits and overall improves developer productivity and morale as well. For individual domains, like ETH <> DOT, COSMOS <> DOT, there would be much better tooling like smoketest, ibctest etc., but overall there is no single place for an integrated dev environment. That is what we are aiming for with PIDN and Starship integration.

3. User Research: Our initial user interviews have been with individual full-stack developers and small teams exploring cross-chain development, including teams like those in the Aster ecosystem (but they already have some solution in place, looking for some neeche that is not present today). We have also seen a lot of interest from current users of Starship who want Substrate integration. We intend to conduct more user interviews and expand the usage of PIDN as we get more clarity on the grant. The consistent feedback we received was around the barrier of entry for dev environments in testing and development lifecycles. Devs know solutions exist but are often resource-constrained and face steep learning curves. Many end up skipping testing or testing directly on mainnet, which isn't ideal or safe for that matter. When we presented the concept of spinning up a complete DOT mainnet-like system alongside Cosmos and Eth environments from a simple config file, the response was very positive. The "minutes not weeks" value proposition resonated strongly with teams who want to focus on building their applications rather than becoming blockchain experts.

4. DevOps complexity: 100% agreed - running smoketest or ibctests requires less DevOps than dealing with k8s clusters. But this is exactly where we see our value proposition. We are essentially wrapping the k8s complexity and providing it with DevX as simple as running docker-desktop. This is also a tested strategy that Starship pioneered. Everything that the dev would need, we want to provide as handy libraries and packages, GitHub Actions, Docker images etc., all packaged up into a simple 'pidn' binary and a simple config file that defines the topology you need. Whether you are running it locally with docker-desktop, in GitHub Actions CI/CD pipeline, or on a large k8s cluster, we aim to make it super simple and reduce operational overhead. If we don't do that, we fail.

[Anmol1696]

@keeganquigley

how will you handle the bridge setup, particularly regarding collateral requirements, validator sets, and economic security models in a local devnet env?

I think ICS support as well as neutron-query-relayer is the best parallel of handling custom bridges and protocols with Starship, where for ICS integration there are multiple moving parts, gov proposals having to be passed, and spinning up consumer chains accordingly, we follow the steps required for setup and run as if it would be in production, with some internal tools like the exposer, init-containers and internal glue code. From a user perspective, it will remain a simple config file toggle.

I think PIDN here can follow the same approach for integration of these protocols. Exact details would become clear with a couple of spikes and getting this integrated.

[diogo-w3f]

@shivaniD96 please note that the grants guidelines have recently changed
. It would be helpful if you could provide information showing how your project fits what we’re looking for, and how it avoids the categories listed under What Doesn’t Fit Our Program.

[shivaniD96]

@diogo-w3f thanks for the heads-up on the updated guidelines. Below is how PIDN fits “What We’re Looking For” and how it avoids “What Doesn’t Fit.”
How PIDN fits the program

1. User-Centric Innovation
       •    Primary users are cross-chain application developers who want a single, unified environment to spin up a Polkadot relay + parachains and run end-to-end tests quickly.
       •    Helps product teams build and QA internally without juggling brittle public testnets or defaulting to mainnet testing.
2. Dogfooding & Practical Value
       •    PIDN runs locally and in CI. Each milestone includes runnable examples with verifiable artifacts (pass/fail reports, logs, dashboards) so anyone can validate outcomes.
       •    Low-friction developer tooling so newcomers can prototype on Polkadot with minimal setup.
3. Sustainable Business Model
       •    Open-source tooling delivered milestone-only (≥50% vested DOT), built by a small, experienced team with a track record in multi-chain dev tooling.
       •    Post-grant sustainability via support, training, and sponsorships—no token, no SaaS lock-in. Resource presets keep infra costs predictable.
4. Regulatory Awareness
       •    No custody, no token, no production bridge operations. Test-only profiles with clear disclaimers; per-run keys/secrets; documented limits (e.g., economic security is not reproduced).

How PIDN avoids “What Doesn’t Fit”

1. Generic Approaches
       •    Polkadot-specific by design: relay + parachains, HRMP/XCM, Asset Hub-oriented examples. The goal is to make Polkadot the default place to prototype cross-chain apps.
2. Token-Only Focus
       •    Not token-focused. PIDN is developer infrastructure aimed at improving build velocity, reliability, and testing depth.
3. Marketing Without Substance
       •    Engineering-first deliverables each milestone: charts/dashboards, CLI/SDK, XCM runners, CI templates, and acceptance tests. Outreach is targeted solely to recruit builders for feedback.
4. Financial Sustainability Concerns
       •    Tight, experienced pod with shipped infrastructure in web3; milestone-gated scope; transparent cost controls via presets.
5. Limited Usability
       •    The opposite: anyone can run it with one command locally or in CI. Clear docs, examples, and artifacts make it easy for W3F/Parity and ecosystem teams to dogfood immediately. We also aim for a low-code feel to speed iteration and shorten feedback loops.
6. Misaligned Objectives
       •    Mission is to bring more builders to Polkadot and make cross-chain workflows easier to develop and test on Polkadot-first infrastructure.
7. Regulatory Blindness
       •    Open-source license and test-only environments with explicit compliance caveats so teams can build safely on top.

[PieWol]

Hey @shivaniD96 ,
Thanks again for the effort you put into the application as well as the discussion that followed.
After extensive and careful consideration of your application by the team, we have decided to not go ahead with it. This is mostly due to the fact that we were made aware of the cross ecosystem testing capabilities that Snowbridge already offers. With the launch of the EVM compatible Polkadot AssetHub this was the most relevant feature of your project.

Of course cross chain testing capabilities are also of interest, but we would rather re-visit this idea in case Polkadot AssetHub actually creates the need for it. So please don't consider our rejection a sign of insufficient quality of the application or your existing product. Instead it's a combination of AssetHub launch timing, existing testing capabilities through Snowbridge and the currently missing need for a testing framework that goes beyond Ethereum.

Please let me know if you have any questions. We are happy to continue the conversation in the future.

Best,
Piet