Polkadot-JS: Moving Forward

Polkadot-JS: Moving Forward

Table of Contents

  1. Summary
  2. Intro About Myself
  3. Goals & Overview
  4. Priorities
  5. Conclusion
  6. Special Thanks


Over the past few years, the Polkadot ecosystem has thrived with critical support from libraries under the @polkadot namespace. Predominantly developed by a single individual, Jaco, these libraries serve as the backbone for external interactions with the Polkadot network. This blog post outlines how, with the support of my teammates on the front team (tools) and the community, I aim to take on a share of the responsibility for maintaining Polkadot-JS, increasing its bus factor and ensuring its continued stability and operation as Polkadot continues to evolve.

Intro About Myself

I am a Software Engineer at Parity with a focus on building and maintaining tools for both internal and external purposes. For over three years, I’ve contributed to projects like Substrate-api-sidecar, Asset-Transfer-Api, and Txwrapper-core, all relying on the Polkadot-JS framework. This hands-on experience has positioned me as an advanced user, allowing me to closely monitor and understand the inner workings of key Polkadot-JS repositories, such as polkadot-js/api, polkadot-js/apps, and polkadot-js/common.

Goals & Overview

Polkadot-JS plays a critical role in the ecosystem. Despite the promising Polkadot-API development, maintaining and developing Polkadot-JS remains essential for the ecosystem’s overall health.

In summary, my contributions to this project aims to achieve the following goals:

  • Increase outside contributions.
  • Restart regular maintenance with documented processes.
  • Restart regular releases.
  • Try to ensure a short turnover with issues, bugs, and PRs.
  • Update libraries with necessary upstream changes.
  • Ensure there is no single point of failure.

Let’s take a deeper look at how I plan to do this…


  1. Releases & Documentation
  2. Issues & Bugs
  3. Features & PR’s
  4. Delegation & Organization

Releases & Documentation

The aim here is to reinstate a regular release cadence for key Polkadot-JS libraries, and document the process in order to help eliminate any single point of failure, providing detailed instructions on releasing libraries and managing the dependency tree.

Documentation and releases will be considered top priority, and will be aimed to be finished within the first month.

The release process can be summarised as:

  • Wasm and Common: Mondays when necessary
  • Api: Bi-weekly on Tuesdays
  • Phishing, UI, Extension, and Tools: Wednesdays when necessary
  • Apps: Bi-weekly on Wednesdays or Thursdays

To understand this in more detail, the following dependency tree demonstrates the inheritance of Polkadot-JS libraries that would need to be released in order, where libraries each depend on the ones above them in the list.

As a note, @polkadot/dev is a dev dependency used in all the repos and does not affect production releases, but that being said the library contains all the necessary scripts and configs that the rest of the packages rely on.

@polkadot/dev - A collection of shared CI scripts and development environment (configuration, dependencies) used by all @polkadot projects.
  @polkadot/wasm - Various WASM wrappers around Rust crates (Primarily used in @polkadot/common)
    @polkadot/common - Various useful utility functions that are used across all projects in the @polkadot namespace.
      @polkadot/api - Provides a clean wrapper around all the methods exposed by a Polkadot/Substrate network client and defines all the types exposed by a node.
        @polkadot/phishing - A curated list of potentially less-than-honest sites inclusive of a simple JS utility function to check any host against this list.
          @polkadot/ui - Basic browser and framework agnostic UI components for creating apps using the polkadot{.js} libraries
            @polkadot/tools - This is a collection of cli tools to use on Polkadot and Substrate chains.
              @polkadot/apps - A Portal into the Polkadot and Substrate networks. Provides a view and interaction layer from a browser.

Given this dependency tree, the following schedule will be similar to the releases many were used to for the Polkadot-JS libraries in the past, but instead of being weekly it will be bi-weekly with the exception of urgent patches, as well as shifted to during the week instead of the weekend. More specifically, releases will follow this schedule every 2 weeks:

  • Wasm and Common: This will generally be released on Mondays. These libraries do not change often, and so this step can often be skipped.
  • Api: The api will generally be released on Tuesdays on a bi-weekly basis. This is to ensure there is plenty of time for updates and the ability to file issues if any bugs are present. Urgent patches will be addressed on an ad-hoc basis when necessary.
  • Phishing, UI, Extension, and Tools: This will generally happen on a Wednesday when necessary. These tools don’t often have releases but when necessary will be released before the Apps repo.
  • Apps: This will generally be released on Wednesday, or Thursday depending on the above releases.

I’ll be working to document the release process for each library, ensuring a smooth and consistent schedule.

Issues & Bugs

Addressing outstanding issues and bugs is a priority. The focus will be on repositories such as @polkadot/api, @polkadot/apps, @polkadot/common, and @polkadot/extension. Prioritisation will be based on issue completeness and the presence of a reproducible example, as well as the overall urgency of the issue.

This doesn’t mean the other repositories won’t gain attention, but just that the above will be priority (unless there are needs for an urgent patch).

Currently there is a backlog of issues that need to be addressed. This can be specifically seen in @polkadot/apps, and @polkadot/api. Issues will be prioritised by the following:

  • Does the issue answer all template prompts?
  • Is there a reproducible example for faster resolution?

Setting a high bar for issue quality will hopefully ensure that issues and bugs can be resolved in a timely manner, and will also help to lower the barrier for entry for contributors. This will require a bit more organisation. Previously the maintainer of Polkadot-JS did an amazing job with response time to issues and dealing with bugs and upstream changes. I would like to restore that habit.

For issues that contain feature requests, the Features & PR’s section below will cover that.

Features & PR’s

Prioritising features will follow an upstream and contributor basis. Initially, the emphasis is on maintaining releases, documentation, and resolving issues and bugs. Large PR’s introducing features will need to be discussed with maintainers or the community to ensure viability and agreement. This is important to help prioritise PRs which have a good ratio of maintenance cost to overall value.

It is important that we do not introduce any breaking changes to the api and or any dependencies upstream. I would consider a large portion of the architecture to be in a stable condition with plenty of legacy commits to use as reference for any ongoing future work. Therefore a majority of the PR’s and ongoing work will be around maintenance and ensuring stability. I would expect any big PR’s that include features from outside contributors to be discussed in issues first with maintainers or the community to see if there is viability and merit. This will ensure that no time is wasted, and everyone can agree on an optimal solution.

To summarise:

  • The emphasis is on maintenance and stability.
  • We will expect discussion of significant PR’s in issues before implementation.

Given the limited bandwidth during the early stages, it is crucial to prioritise filing quality issues for features to encourage active community engagement.

Delegation & Organization

Avoiding a single point of failure is crucial. Delegating tasks to team members and other community contributors will happen when expertise is needed, bandwidth requires allocation elsewhere, or when I’m unavailable. Tasks and progress will be transparently managed on a public project board.

The public project board will be maintained and kept up to date with:

  • Todo Tasks
  • In Progress Tasks
  • In Review Tasks
  • Completed Tasks

This should also allow outside contributors to see available work that can have immediate impact and is waiting to be assigned.


In conclusion, the commitment to the continued development and fortification of Polkadot-JS is a shared endeavour that involves not only the dedication of an individual but also the collaborative efforts of the community. As we move forward, the outlined goals and priorities underscore a strategic approach to ensuring the health and adaptability of this critical component within the Polkadot ecosystem.

Special Thanks

A special acknowledgment is due to Jaco, the lead maintainer, and creator of Polkadot-JS. His invaluable contributions have not only facilitated seamless interaction with the Polkadot network but have also resulted in the development of an extensive toolkit that simplifies some of the most challenging aspects of Substrate. We express our sincere gratitude to Jaco for making participation in this ecosystem an enjoyable and enriching experience.

I extend special appreciation to Iker, my manager, and James for their assistance in reviewing and assembling this post.


Great. I support whatever that needs to be done to have this merged: Integrate chopsticks by qiweiii · Pull Request #9965 · polkadot-js/apps · GitHub


Thank you for your commitment to this @Tarik, looking forward to seeing some fresh momentum to the @polkadot suite.


This is great great news, thank you so much for this. I know it’s not the biggest endeavor, but you can count on me to help on the extension front, be it for PR, review or issue triage. First step here would be to release, and gather feedback/react accordingly to any bug, since the last release from master was years ago.


This is amazing news, I am glad to hear it. I want to point out a number of issues here that are in my opinion extremely low-hanging fruit, but will go a long way:

  • Suggest stakers to use nomination pools · Issue #7902 · polkadot-js/apps · GitHub and in general encourage all stakers to NOT use /apps/staking unless if they are power users. Instead, ask them to use nomination pools, preferably through other platforms.
  • rename and rebrand the App to Console, and, similarly, express very clearly that this is not the wallet/app that is meant for new joiners to the ecosystem. See Consider re-branding the `Apps` to `Console` · Issue #8971 · polkadot-js/apps · GitHub
  • Provide one new package that is meant to make the process of building multichain scenarios easier, such as @polkadot/multichain or similar.
    • List of all parachains, their RPC, their token symbol, decimals, etc
    • List of all open channels
    • Preludes for sending common cross chain XCMs.
    • At the moment as far as I know this either non-existent, or buried in the depth of @apps/config package, which is hard to pull.

That is great to hear @Tarik ! I am super supportive on this and will try to refresh my PRs that are stale, and contribute even more. You have my sword - in case needed.


Another lowish-hanging, but very important fruit is to upgrade the parachains tab to come up to date with coretime.

The keyword parathread is used often in the relay chain parachains tab, and looking at the wss://westend-coretime-rpc.polkadot.io as an example, I don’t see a custom page dedicated to all the coretime related pallets, such as the broker.


Great to hear @Tarik, all the best with it!

Further to Kian’s comment, I’ve just made an issue to get the ball rolling on the discussion about adding coretime views here

1 Like

The current mode should be mainly on maintenance and easy fixes. Something like this should not be done anymore on polkadot-js. Shiny new stuff should be build on top of polkadot-api from @josep and co.

I also think that there should be some new developer console that directly builds on top of polkadot-api as well. Branded as developer console from the beginning. When we have this, polkadot js can finally go to its well deserved retirement. We should try to keep polkadot-js alive as long as we need it, but not any longer.


This is a key requirement, without a complex app like a developer console using the API is very difficult to adapt for real use cases (toy examples help but could lead to the wrong direction in design). So, the branding concerns are secondary, you need a demanding app to adapt for real scenarios, and IMO both should be done at the same time, since the app drives the problem space and the API co-evolves the solution space.

Another relevant consideration is the ease of migration, would be nice if the external boundaries does not change so much and the use is easy to port (maybe including even the existing documentation).

1 Like

Thanks for taking the lead and great post @Tarik, I’m glad you’ll still welcome external contributors.

I’m familiar with these codebases and I have availability these days to contribute to their open-source maintenance.

I agree that it’s very important for the issues to be well defined to help inboard external contributors like graduates of the Polkadot Blockchain Academy or the Polkadot Developer Heroes Program so they’re able to champion parts of it.

It may also be helpful to have brief community calls or in-person side-event gatherings at ecosystems events such as the sub0 Asia next month. I’ll be there.


Hey @kianenigma, as for making interaction with XCM easier, consider to check out our XCM tool set. There are tools such as XCM SDK, XCM API and even XCM Router. We have playground for the tools deployed live so each tool can be tested easily. Feel free to explore more here:

We are open to any new ideas that can ease usage of XCM.

Thank you for your time.

With kind regards,
Team ParaSpell


Thank you all for the support! It means a lot. I am sure we will need all the help we can get as the wheels start turning. I had a few necessary days off to recalibrate, and reset in the mountains and now I am ready to get the engine fully running for this endeavor.

Things I have on the immediate list:

  • Get a project board with initial PR’s and Issues up by Monday. It will be available for anyone to look at and grab issues, but also see what is on the agenda.

  • Additionally I plan on a release for polkadot/api on Tuesday followed by a release for polkadot/apps.

  • Help the InkV5 PR move forward: feat: ink! v5 by peetzweg · Pull Request #5791 · polkadot-js/api · GitHub

  • Review any outstanding PR’s that seem to hold merit before release day.

  • See if there are any immediate issues with pressing bugs that also need patching.


I generally agree, but correcting things that are obviously a mistake (eg. remove the keyword parathread) is IMO part of “maintenance” and should happen.

But a brand new dashboard for coretime eg. as requested in Update polkadot.js UI for coretime · Issue #10285 · polkadot-js/apps · GitHub, yeah maybe that is out of scope and should happen in external apps.

Good to hear @Tarik. I would love to contribute to the tooling side :smiley:
also if you could add good first issue label to the repos mentioned above, that will be great :rocket:


It would be amazing if you could please look into this :pray:

I could provide a lot more context than what’s in the issue :slightly_smiling_face:

Responded :slight_smile:

Likewise :wink:

I’m happy to see this issue on the board – would save us a lot of headache if this finally got solved :pray:

@rflechtner I added that issue to the project board yesterday which can be seen here. I too would like to get that solved. I am not completely sure as to the timeline yet but it’s definitely going to be sorted out in the near horizon.