Polkadot Staking Dashboard & Developer Console 2024-25 Funding Proposal Announcement

Ecosystem
, ,
1

Hello Polkadot Community!

We would like to take this opportunity to share our vision and ongoing work with the Staking Dashboard and Polkadot Developer Console prior to opening our public proposal on OpenGov for the next 12 months of funding.

The full details of our proposal can be viewed here: Full Proposal on Google Docs.

PolkAssembly discussion post: Polkadot Staking Dashboard & Developer Console 2024-25 Funding | Polkassembly

Previous Funding Period

The last funding period spanned from February - July 2024, which was dedicated to the Staking Dashboard and its surrounding tooling. Since then, we have launched an early version of the Polkadot Developer Console, with the goal of leapfrogging Polkadot JS Apps UX and eventually becoming a stable and superior alternative platform.

Developer Console has allowed us to iterate and generalize a large amount of logic that was taken from the Staking Dashboard, and this has resulted in a more robust codebase, as well as major UI iterations such as Console’s unified account connect module.

Since July 2024, we have been maintaining and implementing action items from feedback received from the community, unpaid, in preparation for our new proposal. We’ve designed this proposal from the ground up and with a fresh perspective that reflects the current needs of the Polkadot ecosystem and the role Polkadot Cloud can play.

Major Applications

Polkadot Staking Dashboard: A fully-featured Dapp for interacting with staking and nomination pools on Polkadot.

1600Ă—973 185 KB

Polkadot Developer Console: A next-generation Polkadot developer console that aims to leapfrog current console UX.

1600Ă—973 126 KB

These efforts, alongside the Polkadot Cloud landing page and documentation portal, are hosted on GitHub in the Polkadot Cloud organization.

About the Developer Console

Watch our Developer Console announcement and features overview:

As many of you know, we recently revealed the Developer Console’s alpha release. We’d like to address our development strategy: Our alpha release intentionally focuses on innovative features rather than replicating existing functionality. You might notice the absence of specific tools (like a block explorer) - this is by design.

To provide more insight into our vision and approach, we’ve prepared a detailed Q&A:

Our goal isn’t to duplicate what’s already working well in the ecosystem but rather to create new approaches to developer tooling that address current pain points and prepare for future needs. Already-working features will roll out in time but must be treated as a lower priority relative to high-impact enhancements.

What we’ve built so far:

  • A multi-chain, tab-based interface allowing simultaneous connection to multiple networks.
  • An intelligent chain directory with advanced tagging for easier network discovery.
  • State-of-the-art persistence allowing developers to maintain workspace setups with import and export support.
  • A unified connect UI simplifying wallet and extension interactions.

Over the past six months, we’ve focused on development first, ensuring we had something tangible to demonstrate before seeking wider community support.

During the period post-announcement to the public proposal, we have listened to community feedback and have implemented a number of fixes and updates. Notably, Wallet Connect V2 support has rolled out in the Console, and we are currently working on integrating PAPI’s lower-level APIs as we draw down support for Polkadot JS API and bolster open-source PAPI integration code and documentation around it. Staking dashboard bug fixes are also being merged as they are discovered, and general dependency updates are being deployed.

Here’s a comparison of key features across existing platforms to help illustrate how the Developer Console advances the Polkadot developer experience. While tools like Polkadot JS Apps have served the ecosystem well, we believe there’s room for innovation in several crucial areas:

ComparisonTable
ComparisonTable1418Ă—1838 239 KB

Importantly, this feature set represents just the beginning. Our upcoming proposal will outline plans to enhance these capabilities further.

Proposal Prerequisites

We have held back from opening this proposal until the following items were satisfied:

  1. The Plaza roadmap was finalized and publicly announced, as it has significant impacts for the Staking Dashboard.
  2. Polkadot API launched their 1.0 version for stable APIs (this happened on August 16th 2024).
  3. Developer Console was publicly announced, and the codebase open sourced.
  4. Sufficient feedback from the community was received following the Developer Console’s public alpha announcement.

Our High-Level Goals for the Next Proposal

We’re preparing a comprehensive treasury proposal that will outline our plans for the following:

  • Abstraction of the Staking Dashboard to make it a general tool for any chain built with the Polkadot SDK.
  • Continued feature support for Staking Dashboard and listening to community demands (these are outlined in more detail in our proposal).
  • Enhanced support for Polkadot 2.0 features like Agile Coretime in Developer Console.
  • Completing the Polkadot API (PAPI) integration across the platform.
  • Introducing staking features platform-wide to supersede JS Apps Staking.
  • Expansion of the w3ux library and documentation.
  • Implementation of a community contribution program.

You can explore our current progress at:

We’ll be submitting our treasury proposal soon, but we want to ensure we pick up on any final feedback or commentary. Your input now will help shape our final proposal and the future direction of these tools.

Best regards,
Ross & Joel
Polkadot Cloud Team

4 Likes
2

(I have not verified the accuracy of this report, just sharing to add to the discussion)

https://app.ogtracker.io/mediumSpender/355?tab=progress

2 Likes
3

I have not touched this tool - this report was not added by me or anyone familiar with our roadmap. We do not use this tool and so the report will be very inaccurate in reflecting the status of the previous dashboard proposal. Instead, we have provided updates and insights via our X outreach.

It would be useful to have an opt-out feature on OG Tracker for projects that do not wish to use it. In some instances the tool is flawed, e.g. requesting confidential information regarding mentorship and the status of the contractors we’ve worked with.

Update: I have followed up that post on X:

1 Like
4

Hi Ross,

In your proposal you indicate the following Personnel Costs:

costs
costs1070Ă—706 34.8 KB

Can you explain a bit about how you arrive at 4 days per week for both yourself and Joel?

Back of the napkin maths puts the commitment at around 16 hours per week.

If it’s 16 hours per week spread across 4 days, it might be better to just say that to avoid any misinterpretations.

2 Likes
5

Hey Ross, just jumping in to explain a little bit about OG Tracker. I am not a part of the project but we (as OpenGov.Watch) are working with OG Tracker closely as they are also an auditing project.

I would say only way to “opt-out” from OG Tracker is not requesting funding from the treasury, because they are independently auditing the deliverables of treasury funded projects. I mean this is the reason that they got funding for. Their entire purpose and existince is because of this. What you can, tho, opt-in and self report your deliverables if they are not properly track your deliverables.

4 Likes
6

Hello @theteriyakidon, thanks for the suggestion, I agree the 16 hour week figure is easier to understand.

We feel generally that this ~16 hour week is a a good work balance for this project for both the software engineer role and project management role, but for different reasons. I’ll try not to answer in too much detail, but in my experience of being a senior software engineer, and as a mentor, expecting 9 - 5 full day working hours is not too optimal due to a number of factors - both for productivity and mental wellbeing.

These factors range from the ergonomics of sitting at a laptop for long periods, getting “burnout” or mental fatigue from multi-hour sessions, and the asynchronous nature of solving software problems, whereby I may need a break from coding a solution to reflect and think about it for longer. Oftentimes we require collaboration from external teams that are on different timezones and schedules to yourself, that can eat in to, say, 8 hour work days.

From a personal standpoint, I feel comfortable with this 16 hour weekly figure - it is manageable, not too overwhelming, and gives me the opportunity to also prioritise mental and physical wellness. I think this is lost a lot in our line of work. From a value standpoint, I also feel it is a good balance, relative to say, 8 hour days, where perhaps the treasury wouldn’t be getting so much value for money given the fatigue and work patterns of the software engineer.

In the previous dashboard proposal I laid out longer work hours - I didn’t have Joel’s large involvement at this point and so I perceived a much larger workload! This did indeed burn me out, and caused an illness I was battling through from around April - August that I haven’t publicly talked about. But needless to say, burnout, chronic stress and anxiety are real problems in our space and we need to be mindful of them when committing to these efforts, regardless of our passion or motivation to get things done.

I’ll let Joel follow up on his own reasoning, but we generally feel this is a fair amount based on the deliverables we’ve laid out - we believe we can deliver what we’ve laid out in these work hours, and also feel these hours are good value for the treasury.

I also feel the rates are very reasonable, especially given our track record and skillsets. We have seen some engineers requesting $200, $300 or more for their hourly rate. This is of course up to the engineer, and I’m sure there are reasons they feel these figures are justified, but relatively speaking, we feel these rates are very fair, and at the same time we are also happy with them.

7

Thank you - this is indeed a discussion to be had, and I do feel such tools can be useful. But I also feel there are drawbacks and flaws that unfortunately the previous dashboard proposal has fallen victim to.

Nevertheless, I feel this would be a good topic for another discussion. I would just like to stress here that OG Tracker specifically definitely does not reflect the status of the previous proposal, it was a very fruitful period, but a very turbulent one too, that I am sure many Polkadot devs can attest to.

But overall I am very proud of what that proposal achieved amid all the re-organisation that happened in this time, and that ultimately resulted in the migration from polkadot.network to polkadot.cloud. These factors and more will unfortunately not be reflected in tools like OG Tracker - even if I take a lot of time out of my schedule to update it, I am not able to discuss happenings and decisions that were made by other entities, such as Parity, that affected the proposal and its deliverables - both from a legal standpoint and just out of respect to the decision makers - we should stay collaborative and supportive of any decision that is made for the betterment of the ecosystem.

Ultimately, we need to be mindful over how much influence these tools have, and understand they cannot expose the full picture of a proposal’s story.

8

Are you serious?

The PolkadotCloud “Developer Console” is critically lacking essential tools and features for effective on-chain development, such as:

  • Routing: The ability to create and share links for specific views is fundamental for collaboration and issue tracking.
  • Block Explorer: A core component for on-chain development, enabling detailed block analysis and understanding of network activity.
  • Block Header Information: Vital data that provides context about each block, including its hash, parent, etc.
  • Block Transactions: Access to transaction data within blocks is essential for developers to monitor and verify on-chain actions.
  • Block Events: Events tied to transactions offer insights into state changes, an indispensable part of understanding on-chain logic.
  • Block Weight: Information on block weight helps developers gauge network load.
  • Fork Detection: Identifying forks is fairly important.
  • Runtime Calls: Insight into runtime calls is necessary to analyze custom logic execution on-chain.
  • Partial Storage Queries: This is a must have.
  • A Robust SCALE Viewer: Properly decoding SCALE data is vita.
  • A Functional SCALE Editor: The current extrinsics editor is inoperable, making it challenging to create and test transactions.
  • Light Client Support: It’s truly sad that it can’t be used in a trustless manner.

Adding tabs before implementing these foundational tools seems like a case of “bike-shedding” — focusing on minor features over core functionality. The current approach appears to lack an understanding of essential developer needs, resulting in a console that doesn’t provide a solid foundation for effective development work.

3 Likes
9

Hi Josep. Yes, we have explicitly outlined that features that have already been developed and are working on other platforms are not the priority initially.

The fundamentals of the console - the features that speed up workflows and improve UX that have never been done before - need to be solid before your quoted features are added on top of it. This is a common strategy among startup literature whereby you need your USPs realised early, otherwise you will just offer the same as everyone else without differentiation.

We also have a use-case by use-case rollout plan, whereby we will focus on a feature set for one particular use case like Staking, before moving onto others. With a feature set as large as JS Apps, it is not realistic to throw in a number of features with no coherency. We will target one use case at a time.

It is important to stress that the list of things you mention already exist and are working today elsewhere. They will come in time in the Console as use cases are realised. And this will need to be a funded effort - the bootstrapping we’ve done recently has been an unpaid effort.

We discussed our vision and strategy more in the proposal documents and touch on it in the announcement video - definitely check those out for more detail on strategy.

Strongly disagree, and respectfully, shows a lack of understanding on your part. The reason no other console has implemented generic multi-chain support like a tab interface is that it is extremely complex, and it is not trivial to just code on top of an existing product. Tabs, directory & tags, persistance and workflows, are just some of the groundwork that developers require for a modern developer experience.

2 Likes
10

I disagree with your assessment. Implementing generic multi-chain support with a tab interface is not that complex, with a properly architected SPA is actually very straightforward. In our experience developing a developer console in our spare time, we’ve found that features like a block explorer, an intuitive UI for SCALE encoding, and effective routing are much more complex and important features.

It’s worth considering that the reason many consoles haven’t implemented tab interfaces is that web browsers already offer tab functionality, so it really is unclear whether it adds that much value. In fact, implementing robust routing can be more challenging than adding multi-tab support, yet it provides substantial benefits like shareable links and improved navigation. Plus, considering all the other core features I’ve already pointed out—wouldn’t you agree that those seem even more challenging to implement? I get that implementing tabs might be a complex task on your end. For me, though, this raises some questions about whether the hourly rate is fully justified.

Focusing on foundational features such as a block explorer, block header information, and functional SCALE editors can provide immediate value to developers. These elements are crucial for effective on-chain development and can lay a solid groundwork for additional features like multi-chain tab support in the future.

1 Like
11

Thanks @theteriyakidon and I echo Ross’s points.

From my experience working in the space, I’ve found that shorter, more focused work periods consistently produce better outcomes. It allows for deeper strategic thinking, better documentation quality, and more effective coordination.

The structure also aligns well with the project’s needs and deliverables. Ross and I have worked together long enough to know what schedule works best for producing high-quality results while maintaining sustainable output.

1 Like
13

Relevant to future discussion:

14

I’m a dev and I find this console very effective :slight_smile:
IMO Polkadot Developer Console is by far the best we have right now with very good UX.

4 Likes
15

Seriously? which concrete “developer” features are the ones that you find to have a better UX? Is it the extrinsic creator that doesn’t work? Is it perhaps the extremely deficient storage queries? how do you find the block explorer and the block analyzer in comparison with the other consoles? Please elaborate. I’m very eager to understand what is it exactly what you find so amazing that it can make up for all these essential missing features :pray:

1 Like
16

I’d like to explain why I believe it’s crucial for Ross to pause any new proposals until he addresses his previous commitments and clarifies some key concerns for the DOT token holders.

The Previous Proposal

There are several concerns about Ross’s previous proposal that I’d like to address individually.

When Did the Transfer of Ownership Occur?

On December 2nd, 2023, Ross submitted an OpenGov proposal titled “Polkadot Staking Dashboard: Maintenance and Growth of Polkadot UX proposal,” naming himself as the beneficiary. I was among those who enthusiastically supported this proposal.

At the time, it seemed reasonable to believe that Ross had reached an agreement with Parity Technologies to transfer ownership of the Staking Dashboard. It’s important to remember that the Staking Dashboard was under Parity’s ownership, and Parity is funded directly by the Web3 Foundation. Therefore, requesting OpenGov funds for a project still owned and maintained by Parity wouldn’t make sense unless there was an agreement to transfer ownership by February 1st, 2024.

I believe we deserve a clear explanation from both Parity and Ross regarding the actual date of the ownership transfer.

If the transfer occurred after February 1st, 2024, it suggests there may have been “an oversight”. In that case, I think it would be appropriate for Ross to:

  1. Publicly acknowledge and address the situation.
  2. Consider returning to the treasury the proportional amount corresponding to the period the project remained under Parity’s ownership. Alternatively, he could adjust this amount in his next proposal, which ideally should come after fulfilling his commitments from the first proposal.

It’s worth noting that other projects transitioning from Parity have been legally required to publicly announce the transfer of ownership, as seen in example 1 and example 2. To my knowledge, the Staking Dashboard hasn’t made such an announcement, leaving the official transfer date unclear.

This raises some questions: Did Parity make an exception for Ross, and if so, why? Or was there an oversight in making the announcement?

What we do know is that the GitHub repository remained under Parity’s organization until at least mid-June 2024.

Did Ross Deliver?

In short, no—Ross clearly did not deliver on his commitments. Not only did he not attempt to experiment with Polkadot-API as he promised, but he also seemed to have deprioritized it entirely. I first reached out to him on April 30th, 2024, asking if he’d started on the Polkadot-API migration as promised. Two days later, he replied, “I haven’t started any API change as of yet.”

When I followed up a few weeks later, he explained he didn’t have time for that because he was “extremely tied up” preparing something unrelated for Polkadot Decoded. He even mentioned he wouldn’t be available to work on the Polkadot-API integration until well after the event. This was concerning because we wanted real-world feedback from a developer migrating a DApp from PJS to PAPI before releasing the first stable version. And we had evidence the library was on track, with developers like @Kheops successfully building complex DApps like KheopSwap. But Ross replied, “Staking dashboard needs stability and reliability right now. Its purpose is not to be a testing ground for new APIs.”

This response was baffling. Here was Ross not only disregarding an important item of the work he’d committed to but also prioritizing unrelated projects, while the Staking Dashboard itself was still under Parity’s ownership. Before making these concerns public, I reached out to his direct report at Parity, explaining this situation, which had become increasingly troubling. His report responded promptly, agreeing that if Ross had committed to this work, he should follow through. So, he assured me that he was going to talk with him.

I naively believed Ross would finally start on this item. However, two weeks later, he contacted me, explaining that his situation with Parity was about to change, and due to personal circumstances, he’d had limited bandwidth. He assured me he would get to the work eventually. Despite the delay, I chose to believe him.

Months later, Ross revealed the project that had consumed his time: the “PolkadotCloud Developer Console.” !:person_facepalming:

Perhaps Ross delivered in other areas. In this one, I’m fairly confident that he didn’t even try to. I think that if he wants to make another proposal he should have a very good justification for all the items where he didn’t even attempt to deliver.

The PolkadotCloud Developer Console

It’s clear that Ross didn’t deliver on his initial proposal because he chose to focus on something else: the PolkadotCloud Developer Console, which is now central to his new proposal.

If you haven’t tried it, this console is, quite frankly, unusable—not due to personal opinion, but because it lacks essential tools. It’s missing a block explorer, a block analyzer, runtime calls, partial storage queries, a reliable SCALE encoder, and a reliable SCALE decoder, to name a few. At first glance, it might look appealing, but in practice, it’s so severely limited that it becomes useless. Please, try it yourself—you’ll see what I mean. Beyond these functional gaps, Ross chose to build it on the legacy JSON-RPC API, against direct advice to avoid this path. But, as usual, he did as he pleased.

Despite these glaring issues, Ross seems to believe that multitabs and state persistence are somehow indicators of a “solid foundation.” But how are multitabs and persistent state useful when we still need to turn to the PJS console for any substantial work? It’s absurd.

Now he expects my team to provide personalized assistance on using PAPI’s lower-level libraries to build a functional developer console. To clarify, we’re always glad to help DApp teams utilize PAPI, and many teams can confirm this. Our relationship with these teams is symbiotic: we help them use PAPI effectively, they provide feedback on pain points and issues, and we leverage that feedback to improve PAPI for everyone.

Instead, we have someone expecting us to hand-hold him through every step via private chats. This takes time and resources from our team and adds no value back to PAPI. Essentially, he’s expecting free consulting from us while claiming that this somehow equates to exploring the viability of using PAPI on the Staking Dashboard. It’s worth noting that other teams, such as @sodazone, have successfully utilized our lower-level libraries without any special guidance from us.

The Real Problem

It’s difficult to understand how someone could be so disconnected from reality that they don’t recognize the gravity of their actions.

I fear the underlying issue might be systemic. Ross could be a byproduct of an environment where favoritism and preferential treatment have overshadowed accountability. After he delivered a decent DApp a couple of years ago—when the bar was perhaps lower—he gained significant recognition within Parity. This elevated status earned him strong connections, and since then, it seems he believes he can proceed without fulfilling his commitments because he has the unwavering support of influential individuals who can push his proposals through, even when previous obligations remain unmet.

It’s disheartening to consider, but perhaps this explains why he feels he can get away with acting the way he is acting. This situation underscores the importance of transparency and equal accountability for everyone in our community. We all benefit when proposals are thoroughly reviewed, and when trust is built on consistent actions rather than connections.

A Way Forward

Our community cannot afford to be this uncoordinated, nor can we afford to lose talented developers. At the same time, we have to put a stop to unaccountable practices. If we don’t, we risk seeing more projects emerge that lack true market fit or user demand, funded simply because of someone’s connections. To prevent this, I’d like to propose a path forward:

  1. Deliver on All Previous Commitments: Ross should complete every outstanding item from his previous proposal before any new ones are considered. Either that, or have a very convincing justification for not completing it.

  2. Transparency on Ownership Transfer: DOT holders deserve clarity on when the Staking Dashboard officially changed ownership. If this transfer occurred after February 1st, 2024, then we should calculate what portion of the OpenGov funds Ross is genuinely entitled to.

  3. Repayment or Adjustment of Funds: Once we have a clear figure, Ross should decide whether to return the funds owed to the treasury (in stables, reflecting the rate at which he initially converted) or to subtract this amount from any future OpenGov proposal.

These steps aren’t just about ensuring accountability—they’re about setting a standard that will ultimately strengthen our ecosystem and preserve its integrity.

3 Likes
18

I’m genuinely trying to propose a constructive way forward.

Could you please clarify the following points?

  • When did the transfer of ownership of the Staking Dashboard officially take place?
  • When was the last month you were compensated by Parity while the Staking Dashboard was still under their management?
  • Could you explain why you haven’t fulfilled the obligations from your previous proposal?
  • When did you sell the DOT tokens that OpenGov entrusted to you? Were you still billing Parity for the maintenance of the Staking Dashboard at that time?
  • Wouldn’t you agree that it’s alarming to see that while you were not working on what you said that you were going to be working, you were instead working on something completely unrelated?

I’m not intending to threaten or accuse you unfairly. My goal is to seek transparency and understanding so that we can address these concerns collaboratively. I hope we can work together to find a solution.

Additionally, I’m having difficulty understanding what specifically you find “illegal” about my comments. Could you point out the exact part that you believe is unlawful? I’d appreciate any clarification so I can better understand your perspective.

5 Likes
19

Thank you for the encouraging words @muddlebee, I hope the public alpha does communicate the potential for the console and wider idea of Polkadot Cloud.

Where some projects merely present mockup illustrations for their concept - some of which are good but do not demonstrate knowledge of an implementation pathway - we made a huge effort to create a working prototype, solving some of the initial problems that allow the UX progression we’re aiming for.

This unfortunately comes at the expense of exposure to commentators criticising an unfinished product - and I definitely would not want other teams to be put off by this. Any sort of demo or tangible concept that illustrates your idea should be positively received. Proposals with clear action items and milestones should overcome such criticisms. And after all, the whole purpose of funding is to allow your team to complete your product inline with ecosystem needs- not to reveal a completed product and then request funding for it.

As for the other speculation regarding the previous dashboard maintenance and growth proposal, updates and a self report will be published in due course.

2 Likes
20

Following up on the discussion regarding referendum #355, we’ve prepared a comprehensive self-report covering the Staking Dashboard funding period (February - July 2024). While the self-report functionality isn’t currently available in OG tracker, we’ve submitted this report directly to the OG tracker team and wanted to ensure this information is also accessible to the wider community.

You can view the complete self-report Here (Google Docs).

3 Likes