Summary
Polkadot is on the verge of a major transformation with the introduction of JAM. As we actively develop both JAM and Polkadot 2.0 implementations in Go, this post aims to highlight the evolving role of the Gossamer team at ChainSafe within the ecosystem. We invite you to share your thoughts and feedback to help shape the next chapter of Polkadot’s journey — your input is invaluable to us.
About Us
Gossamer is a dedicated Go implementation of the Polkadot Validator node, developed to enhance client diversity within the Polkadot ecosystem. As an alternative client implementation, it contributes to the decentralization and robustness of the network by serving as a validator node.
The Gossamer team, initially seeded by Web3 Foundation, became a community-funded initiative within the Polkadot ecosystem when OpenGov was introduced — initially through the 2022 treasury proposal, and more recently via the 2024 referenda. We’ve operated with no profit motive, and are driven by a commitment to the growth and resilience of the Polkadot network.
The Vision
The heart of Gossamer is its team — and this is not just a group of developers writing lines of code. It’s a dedicated team of Polkadot protocol engineers who have spent years building toward a shared vision: the importance of client diversity and true community decentralization.
We believe the Polkadot protocol is among the most sophisticated and well-thought-out technologies in the Web3 space. However, we also believe that real decentralization doesn’t stop at the protocol layer — it must extend to how that protocol is built and maintained.
That’s why we deeply support the Polkadot Technical Fellowship (in fact, at least four of our engineers are active members) and OpenGov (we are active participants in Governance and recently formed a core of JAM DAO that received a delegation from the Decentralized Voices program). At the same time, we can’t ignore that much of the protocol’s development today is concentrated on a single entity. We see this as a risk. A scenario similar to the Parallel Finance exploit could, in the worst case, repeat itself on a broader scale if Parity were ever halted — legally or maliciously.
This is precisely why we are committed to building an independent client, developed outside that single entity. It’s also why we are strong proponents of JAM and its spec-first, multi-team clean room approach. We believe in JAM — and we believe in a truly decentralized Polkadot.
Present and Future of Polkadot
The following chart contains Gossamer’s past and future roadmap:
Our yearly report for OpenGov:
https://polkadot.polkassembly.io/referenda/709?tab=evaluation
Achieving validating node capability by the end of Q2 2025 is a significant step forward for the project. This demonstrates that the core technical challenges of implementing a Polkadot validator in Go are being addressed.
While our time was mostly spent catching up to the Parity roadmap during 2023, in 2024 and 2025, the Gossamer team had an opportunity to develop all the necessary components for Polkadot 2.0 — including the ELVES protocol updates coming in 2025 such as Elastic Scaling and Async Backing (e.g., Prospective Parachain, Provisioner, RFC-103, etc.).
This was possible because those components were already specified by the Web3 Foundation and implemented by Parity. Now, we are on a good track to finish the Polkadot 2025 Roadmap in time.
Given the rarity of Disputes on Paseo, the Gossamer team adjusted the Dispute subsystem to expedite real-world validator testing. This was done acknowledging potential risks, with the commitment for further iteration and a full Disputes implementation.
Even with the upcoming transition to JAM, the work done on Gossamer for Polkadot 1.0 and 2.0 initiatives provides valuable experience and a foundation of knowledge about Polkadot architecture. Modules built for Polkadot will be reused in the JAM node, so it is not throwaway work. More importantly, the garnered expertise will be leveraged in the development of a Go-based implementation for JAM.
JAM
While Polkadot 2.0 lays a solid foundation, it also sets the stage for JAM, the next evolution of the network. This shift doesn’t signal Gossamer’s departure from Polkadot, but rather strengthens its commitment to the ecosystem through client diversity and ongoing contribution to security and resilience.
Since JAM’s announcement in Q1 2024, part of the Gossamer team has been involved in its development. Their efforts include:
- JAM Specification Analysis and Development: Studying the Gray Paper and related materials to build Gossamer as a JAM network client.
- PVM Research & Implementation: Developing a Go-based Polkadot Virtual Machine (PVM) to test features for both Polkadot 2.0 and JAM. Additionally, we are experimenting with compiling Go to PVM to build a Go JAM Service SDK.
- Community Engagement: Actively participating in JAM calls, the JAM Implementers DAO, and running an external contributor program to onboard developers from other ecosystems.
Rather than reacting passively, the Gossamer team is proactively building for JAM, awaiting the opening of Milestone 1 submissions to contribute with their implementation.
Work on Polkadot 1.0 and 2.0 continues to be valuable — modules that implement ELVES, GRANDPA, and Safrole will be reused in JAM. Most importantly, the expertise gained is directly feeding into the development of a Go-based JAM client.
What’s Next?
Currently, we have three part-time engineers contributing to the JAM initiative. These engineers are also partially focused on Polkadot 2.0. However, under the current JAM Prize guidelines, future funding for this work remains uncertain. According to Gav’s Unofficial JAM Prize Notes, clarity on funding is unlikely before the release of the Grey Paper v1.0, which depends on a complete audit of both the paper and the implementations. Realistically, this may not occur until sometime in 2026.
However, with all the excitement that Polkadot’s future holds, it is important to focus not only on what role Gossamer takes in this future, but also on what the general vision and strategy for client diversification should look like.
Given this situation, we intend to return to the Polkadot Treasury with a new proposal — this time structured around smaller, quarterly milestones (3–6 months). This approach is designed to ensure the continued involvement of our current team and the preservation of existing expertise as we work toward JAM.
We now invite you — the Polkadot community — to share your thoughts and feedback. Your insights are invaluable in helping shape the next chapter of our journey.