Dear Community,
We want to express our gratitude to everyone who has participated in our referendum and especially to those who voted Aye in support of our proposal.
After gathering input from the community, we have decided to take a step back to revise and enhance our proposal. Based on the discussions and insights shared, we believe that presenting a more refined referendum will better align with the needs and expectations of the Polkadot community.
As a result, we are now recommending that users vote Nay on referendum 1269. This will allow us to close the current proposal and focus on bringing a revised version to the table in the near future—one that incorporates the feedback we've received.
We remain committed to transparency and collaboration, and we appreciate your continued engagement. Please stay tuned for updates on the revised referendum, and thank you once again for your support and contributions to this process.
Since the launch of this proposal, we have received substantial feedback from the community. In response, we have been actively addressing concerns, resolving bug reports, and tackling issues raised regarding the proposal:
— On 9th November, Ross presented an update to the proposal on AAG. Full Video.
— Dedicated Discord and Mail support channels for Staking Dashboard were opened.
— 15 merged Staking Dashboard PRs.
— 9 merged w3ux PRs.
— Staking Dashboard statistics since 1st November:
— 44k page visits
— 22k visitors (~1.4k daily visits on average)
— Average time on dashboard: 46 seconds.
— Polkadot API (PAPI): We have chosen to proceed with a complete integration into the Staking Dashboard, phasing out the use of the Polkadot JS API. Track PR progress here.
On 30th October, prior to opening this referendum, a self report of the previous Staking Dashboard proposal was published. Find it here on Google Docs.
We are committed to maintaining an open dialogue with the community as we continue to refine and improve this proposal. The progress made so far, including merged PRs, community engagement, and updated support channels, demonstrates our dedication to addressing feedback constructively.
We welcome continued input and look forward to collaborating closely with all stakeholders to ensure the success of this initiative.
Thank you for your continued support and engagement.
The full details of our proposal can be viewed here: Full Proposal on Google Docs.
Hello Polkadot community,
We're excited to introduce our proposal for the Polkadot Developer Console and ongoing enhancements to the existing Staking Dashboard. These tools are designed to significantly improve the developer and user experience within the Polkadot ecosystem.
Proponents: Ross Bulat & Joel Kenny
Beneficiary Address: 13MNarAqpNkginnQb6gTNq2QnieZGs2SKu8JdK9LLxo6ksEP
Requested Amount: $215,000 USDT / 52,311 DOT *
Funding Period: November 2024 — November 2025 (12 months)
Planned Referendum Start Date: 1st November 2024
The Polkadot Developer Console, our newly launched tool, was first publicly revealed on August 20th, 2024. You can view the announcement and initial community response by visiting the following X Post:
Over the past six months, we've self-funded the development of an alpha version of the Polkadot Developer Console alongside Staking Dashboard maintenance. This demonstrates our commitment to delivering value and our confidence in the project's potential.
We recently hosted a Q&A leading up to publicising this proposal to provide more insights into our project and vision. Watch the full Q&A by visiting the following X Post:
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 24, 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, and with a fresh perspective, that we feel reflects the current needs of the Polkadot ecosystem, and the role Polkadot Cloud can play.
We have held back from opening this proposal until the following items were satisfied:
Our project timeline spans from November 2024 to November 2025. While we have a structured internal timeline, we understand the need for flexibility in an evolving ecosystem. Therefore, we present our key deliverables without specific dates, allowing us to adapt to changing priorities and community needs.
We continue to maintain and enhance the Staking Dashboard. This tool has become a crucial part of the Polkadot ecosystem, providing an intuitive interface for users to interact with Polkadot's staking mechanisms. Our ongoing efforts will ensure it remains up-to-date with the latest Polkadot features and continues to meet user needs.
High-Level Staking Dashboard Objectives:
Deliverables Breakdown:
1. Support “Plaza” upgrades in relation to staking as they are deployed.
Plaza is a major refactor that brings chain logic, including staking and nomination pools, from the Relay Chain to the AssetHub system chain. Staking dashboard will, therefore, need to be updated to support this migration by supporting AssetHub as an additional chain.
2. Support nomination pool bonding migration to account locks.
The ability to bond to nomination pools without transferring funds to the pool account will shortly be rolled out on Westend, Kusama and then Polkadot. Staking Dashboard will need to support this updated logic, allowing users to migrate to the new locking mechanism, and to allow new pool members to bond directly by locking their funds.
Currently, nomination pool members (and owners) must transfer their funds to the nomination pool’s stash address in order to participate. By doing this, it is no longer possible for members to vote in OpenGov. This migration will fix this shortcoming.
3. Integrate metadata and allow staking dashboard to support any network with staking / pools pallets.
To save other chains from having to fork Staking Dashboard or create their own Staking UI, we can abstract the network layer and read metadata to determine whether any chain can connect and leverage the dashboard. Polkadot will remain the default network.
The Developer Console has already abstracted a lot of the logic required to do this, acting as a proof of concept.
4. Replace account Connect UI with new unified connect UI introduced in Developer Console.
Developer Console hosts an updated, streamlined connect interface that solves problems Staking Dashboard currently demonstrates - multiple prompt UIs, 2-step processes that can be 1-step processes and a better unification of connect options that consume less real estate.
This action item will simplify Staking Dashboard’s wallet connect flow.
4b. Introduce Wallet Connect V2 support to Dashboard.
A critical API for supporting mobile wallets. Wallet Connect support is currently in Beta in Developer Console - it can be iterated to an initial release and then applied to Staking Dashboard too.
This ties into the previous action item, whereby both Console and Dashboard can share the same code for this feature.
5. Continue PAPI (Polkadot API) Integration and draw down usage of Polkadot JS API.
Polkadot JS API is in maintenance mode and will eventually be discontinued in favor of PAPI. We, therefore, are continuing integration efforts in this proposal to draw down Polkadot JS API usage with the end goal of completely removing it as a dependency.
6. Layout plans to sunset the need for staking support on JS Apps.
Task 3, along with Developer Console task 4, satisfies the requirements of sunsetting JS Apps Staking UI completely, as Polkadot Cloud will host all the critical staking functions between the dashboard, and staking admin tools in the console.
Although we cannot force this sunsetting to occur, we can post our rationale and communicate that Dashboard & Console should supersede the JS Apps Staking UI.
7. Use Developer Console’s controller framework to modularise app logic away from React components for better syncing & optimized UX.
Refactoring logic into a Typescript MVC framework (where V is the React layer) dramatically improves code integrity, multi-chain support, and syncing flows throughout the app.
8. Continued support of general dependency updates / refactors as dependencies roll out breaking changes.
Critical to keep Staking Dashboard up to date using industry-standard dependencies as they are updated.
9. Implementation of high-impact community-requested features.
Community feedback and guidance are important, and although we may not integrate the exact requests that come through, they should be analyzed for potential impact and the best way they can be integrated into the app.
10. Continued Staking Dashboard hosting at https://staking.polkadot.cloud.
The go-to deployment to use Staking Dashboard that gets over 1k visits daily.
The Polkadot ecosystem has experienced significant growth and evolution, particularly with the advent of Polkadot 2.0. However, the primary tool for developers, Polkadot JS Apps, has not kept pace with these advancements. Recognizing this gap, our team has spent the last six months developing an alpha version of the Polkadot Developer Console, a next-generation tool designed to meet the evolving needs of Polkadot developers.
The Polkadot Developer Console represents a significant leap forward in developer tooling for the Polkadot ecosystem. While it builds upon the foundation laid by Polkadot JS Apps, it introduces several innovative features that address current limitations and anticipate future needs:
These innovations address the key pain points developers face with existing tools, positioning the Polkadot Developer Console as a go-to platform for Polkadot development as we roll out features on top of these game-changing fundamentals.
High-Level Developer Console Objectives:
Deliverables Breakdown:
1. Build out mono-repo structure to formalize console components.
Developer Console is a complex suite of tools. For the console to scale, tools and libraries must be compartmentalized. It then becomes easier to iterate certain features without impacting the larger application. Packages in a mono repo can be versioned independently to the main app, and tests can be better isolated to each package.
Developer Console was rapidly developed as a singular repository / package in its discovery phase and is now ready to be better formalized as a mono repo.
1b. Formalize tab persistence and workspace management.
Persistence APis (currently achieved through local storage) can be formalized, documented and expanded to support more Console state to speed up workflows. Expanded persistence support can then be directly applied to Workspaces.
What is also an interesting pathway is persisting workspace configs on-chain (such as on the People Chain’s identity pallet), giving users the ability to share their workspace setups in a decentralized manner.
2. Create CLI tool for scraping chain lists and forming the Console directory.
A key tool for populating / forming the Developer Console directory. Instead of creating yet another chain list, Developer Console aims to source chain data from existing lists, including SubWallet’s and Talisman’s chain lists, to form its directory data.
Where existing chain lists do not contain the required data, Developer Console will leverage w3ux or packages within its mono repo.
3. Explore a Coretime task for basic coretime management.
A critical piece of infrastructure for developers.
Unlike RegionX and Lastic, Developer Console should host a Coretime interface directed to developers and simplify the process of purchasing bulk & instantaneous coretime. We aim to implement basic coretime management functionality in this proposal to pave the way for a better Agile Coretime UX.
4. Build out Chain Explorer with more features, such as a block explorer, Runtime API support (directly from metadata), and staking admin features.
To supersede JS Apps, Console should contain the features that JS Apps offers and offer them in a more intuitive manner that is quicker and easier to use. Chain Explorer has already demonstrated some ways this can happen, but there are plenty of absent tools that need to be added to this task.
5. Continue PAPI (Polkadot API) Integration and draw down usage of Polkadot JS API.
Polkadot JS API is in maintenance mode and will eventually be discontinued in favor of PAPI. We, therefore, are continuing integration efforts in this proposal to draw down Polkadot JS API usage with the end goal of completely removing it as a dependency.
6. Improve accounts interface with better transfer UI and support more account-related features, such as account locks, bringing feature parity with JS Apps.
One purpose of Developer Console is to demonstrate next-generation UI and open source the code that makes it happen. Account tooling and transfer / teleport functionality is low-hanging fruit that we foresee being greatly improved over Polkadot JS Apps.
7. Continued support of general dependency updates / refactors as dependencies roll out breaking changes.
Critical to keep Developer Console up to date using industry-standard dependencies as they are updated.
8. Implementation of high-impact community requested features.
Developer Console is designed to be heavily influenced by the developer community. Unlike Staking Dashboard, community requests should be a much higher priority to make Console a more helpful tool for development teams.
9. Continued Developer Console hosting at https://console.polkadot.cloud.
The go-to deployment to use Developer Console (still in public Alpha, traffic promo not currently active).
As part of our commitment to improving the Polkadot developer ecosystem, we will expand and enhance the documentation for our w3ux library. This library is a collection of essential tools and components that significantly simplify Web3 development for Polkadot and other blockchain platforms.
Our objectives for the w3ux library include:
By enhancing the w3ux library and its documentation, we aim to provide developers with a robust toolkit that accelerates development, improves code quality, and enhances the overall user experience of Polkadot applications. This effort aligns with our broader goal of lowering the barrier to entry for Polkadot development and fostering a vibrant, productive developer community.
Deliverables Breakdown:
1. Roll out documentation portal for w3ux, with comprehensive details of installation and usage.
W3ux requires a documentation portal, not dissimilar to docs.polkadot.cloud. This has already been requested by a community member. W3ux offers general-purpose utilities for Polkadot Dapps, and documentation is a critical piece of infrastructure if the library is to be used by Dapps beyond Staking Dashboard and Developer Console.
2. Improve modularity of React Connect Kit, and provide examples for Dapps to integrate the package.
React Connect Kit offers React components that Dapps can use directly to connect to a range of web extensions and hardware wallets. It has been battle-tested on Staking Dashboard and is ready for better abstraction and usage documentation.
3. Implementation of community-requested assets.
W3ux hosts static assets (web extensions, validator assets) and as such, is very reliant on community engagement.
4. Continued support of general dependency updates / refactors as dependencies roll out breaking changes.
Critical to keep w3ux up to date using industry-standard dependencies as they are updated.
The Staking Dashboard and Polkadot Developer Console are poised to significantly impact the Polkadot ecosystem by:
By investing in these tools, we aim to accelerate the growth and adoption of Polkadot, solidifying its position as a leading blockchain platform for developers and users alike.
The applications and tooling we develop will always be open source, available for other teams to leverage or reference for their own projects.
This list of deliverables provides a framework for our development efforts while allowing flexibility to adapt to the evolving needs of the Polkadot ecosystem and our community. We are committed to transparent communication throughout the process and will provide regular updates on our progress towards these goals.
Our approach ensures that we can prioritize and deliver features based on their impact and the current needs of the ecosystem rather than being constrained by predetermined deadlines. This flexibility allows us to remain responsive to community feedback and emerging opportunities within the Polkadot landscape.
For detailed team information, visit the Full Proposal: Team section.
For detailed plans on community engagement and contributions, visit the Full Proposal: Community section.
For detailed budgetting, visit the Full Proposal: Budget section.
This proposal represents a significant opportunity to elevate the developer and user experience within the Polkadot ecosystem. By building on the successful Staking Dashboard and Developer Console alpha release, and incorporating community feedback, we are poised to deliver tools that will:
Our team brings a wealth of experience in blockchain development, project management, and community engagement. We are committed to transparency, regular communication, and continuous improvement based on user feedback.
The requested funding of 52,311 DOT will enable us to dedicate the necessary resources to this project over the next 12 months, delivering substantial value to the Polkadot community. We believe that this investment will yield significant returns in terms of ecosystem growth, developer productivity, and overall user satisfaction.
We invite the Polkadot community to support this proposal and join us in shaping the future of Polkadot development tools. Together, we can create a more accessible, efficient, and powerful environment for building on Polkadot.
Thank you for your consideration. We look forward to the opportunity to contribute to the continued success and growth of the Polkadot ecosystem.
We welcome your thoughts, questions, and suggestions. Your input is crucial in refining these tools to best serve the Polkadot community.
We encourage you to review the full proposal and share your feedback. Your insights will help us ensure that the Staking Dashboard and Developer Console meet the needs of developers and users across the ecosystem.
Thank you for your time and consideration. We're excited about the impact of these tools on the Polkadot ecosystem and look forward to your engagement and support!
Kind Regards,
Ross Bulat & Joel Kenny
Polkadot Cloud Team
Threshold
If this ref fails, please resubmit a new ref for ~$215,000 USDT which the treasury has lots of, rather than $DOT which has a volatile price.
Hey,
Thank you for the proposal! First thing I would propose is that you split up the proposal. Staking dashboard and the developer console are two different products. I assume that the staking dashboard is more likely to get funded, given the importance for the ecosystem. Around the developer console there are already multiple different implementations coming up and it is still too early to bet on one. Things like this comparison table that is taking features that you have implemented for your dashboard and doesn't exist in the other ones is a little bit unfair. For me this is not really trying to be a comparison on neutral aspects.
Back to the staking dashboard, I would propose that you come up with more improvements. Basically you are just saying that you do maintenance plus whatever the community wants. Could be narrowed to a little bit more. IMO it would be really nice if the staking dashboard would be changed to show by default an "easy mode". Currently you are seeing tons of metrics, which for most people is not that relevant. People should open the page and be able to nominate someone in 3 clicks, similar to what Nova for example is offering. Or validators could send like "nominate me" links that will then be handled by the staking dashboard etc. Just some ideas by me.
Dear @Ross and Joel | Polkadot Cloud,
Thank you for your proposal. Our vote on this proposal is NAY. Below is a summary of our members' comments:
This proposal raised concerns among voters regarding the funding request in DOT rather than stable coins, unresolved OG tracker reports, and the high rates relative to the perceived benefits. While the staking dashboard was recognized as valuable and widely used across Polkadot, some questioned the immediate need for the continued work on the developer console. Overall, the proposal was not approved in its current form.
The full discussion can be found in our internal voting.
Kind regards,
Permanence DAO
Let's remind everyone about the discussion that happened on the polkadot forum where Ross pretends to do a "self-report", actually not addressing the questions. Here's some context, facts, with proof: