9 Ideas for the Decentralized Future of Polkadot

The Web3 Foundation just announced their Decentralized Futures program for the Polkadot Network.

In their site, they describe 9 areas which are of key importance for these funds and for development to occur in order to support and grow the Polkadot ecosystem.

I wanted to present an idea for each area that I would love to see funded by this initiative.

Indeed, I would like to directly contribute to one or more of these ideas if I can find the right people to work along side with.

Obviously each of these ideas needs more time spent to flesh out the specifics, but hopefully these ideas are both concise enough to allow people to read them all, but detailed enough for people to understand the underlying philosophy and goal behind the project.

Finally, I apologize, but many of these ideas have been brewing for a while (as you will see below, I have linked to some previous writing when applicable), but this post was written fast and off the top of my head. Hopefully feedback can allow me to edit and refine the ideas further.

Find a chatgpt summary of this post below: 9 Ideas for the Decentralized Future of Polkadot - #2 by shawntabrizi

Table of Contents

  1. Technology

  2. Development Ecosystem

  3. Community


In the technology section, the Web3 Foundation identified the following areas: Developer Experience, Growth, and Interoperability. Here is an idea for each of these areas.

Developer Experience: An Alternative to FRAME

Substrate has always positioned itself as being flexible to the needs of the developer. From its inception, they have always described at least 3 ways to approach the SDK:

It is obvious to someone who is an expert in FRAME how flexible and modular it is, and how it really can be used to develop fully customized systems.

However, to many just entering the ecosystem, FRAME itself can be quite complex to use, and especially to use correctly and safely.

I would argue that of the 3 options presented in Substrate, nearly no one builds by modifying core, and nearly no one builds by simply configuring the genesis of the node template. Entirely everyone builds using FRAME, but then the goal of flexibility in Substrate is lost due to the fact that there is only a single product to satisfy the needs of everyone.

With this in mind, I think there should exist a product between building with the Node Template and FRAME. A framework which is more simple, stupid-easy, safe, standard, satisfying, and so-on…

Perhaps a framework like: “Here is Substrate’s Super Simple Safe … STF SDK”, aka “Hissss…” :snake: (not really important what the name is, but i have had this one in mind for a while)

The core ideas:

  • Less configurable… but works out of the box.
    • You do not get to customize every single type in your runtime… but then you also don’t need to worry about or eat the costs of having every type be generic in your runtime too.
  • Providing all the primitives you expect, exported as a single system.
    • For example not feeling that you have a System Module, Balances Module, Utility Modules, XCM Modules, Consensus Modules, etc which all need to work with what you are building. It is all packaged with standards already accepted in the wider blockchain ecosystem, and you build against that.
  • Targeted toward simplifying specific ecosystem objectives, like cross chain transfers, defi, multi-token systems, smart contracts, etc…
    • Lets build the framework not to maximize flexibility, but to be the best at the goals which the current crypto ecosystem are focused on.
  • Compatibility with the chains using FRAME.
  • Ideally, well developed user stories allowing people to transition from FRAME to Hiss and Hiss to FRAME.

In summary, FRAME was the correct decision for frameworks to provide to the Polkadot ecosystem. It is designed to be maximally flexible. But now that it exists, we should start to look at lowering the barrier of entry for developers who want a more simple product, just like what was promised with developing with just the Node Template.

I think it is time for Polkadot to start getting alternative runtime SDKs.

Growth: FRAME + ink! (The Merge)

What if you only needed to learn a single language to join any part of the Polkadot ecosystem? What if you wanted to build a smart contract, an on-demand parachain, or a dedicated parachain, that you could take the exact same codebase, and use it to launch all three when the time and conditions are right?

That is the main vision behind a merge of FRAME and ink!. My belief is that runtime development is a complete superset of smart contract development. For historical reasons, both of these frameworks were built separately, but also found their way to converge over time. The shift from FRAME v1 to FRAME v2 was actually due to ink! and how they masterfully used attribute macros to build a much better Rust eDSL. However, simple syntax (like declaring calls, storage, events, errors) which could be standardized across the two languages are not, and as such, users feel that they need to learn two languages, not one.

The steps between tinkering with Polkadot and launching a parachain is just too massive at the moment. There is really no middle ground or story for a single individual to launch something like a parachain without a large team and a lot of funds.

Instead, we can market the first step toward building a parachain is building a contract with ink! and deploying it to an existing parachain. Then, since in our world, ink! and runtime development use the same language, successful products can simply turn their contract into a more performant on-demand parachain. Finally, if their on-demand parachain is demanding so much blockspace, they can obtain a dedicated slot, potentially with all the same codebase.

Of course, if you are developing code for the runtime, you get access to more APIs and more low level access to your blockchain, but the main idea should be that through your development process in the Polkadot ecosystem, you are only writing new code, not rewriting existing code.

In this story, users have a really comprehensive story from tinkering as an individual, to launching parachains on Polkadot, exactly the kind of growth we need in our ecosystem.

Most of the ideas around the merge I had were initially documented here: The Merge - HackMD

Perhaps the goal would not be to merge FRAME into ink!, but maybe Hiss (suggested above), could be that extension of ink! to provide this end to end story.

Interoperability: Reading State Across Parachains

Among the 9 ideas in this write up, this is the one with the least amount of concrete thought. However, the basic idea is this:

A huge downside of multi-chain interoperability is coordinating the state of chains as a part of constructing cross-chain messages. With monolithic chains like ethereum it is easy and completely synchronous to inspect the state of any contract or application in the system.

In Polkadot, XCM is already an extremely expensive protocol relative to basic runtime functions, but it almost entirely removes state reading and reporting from the protocol because it is a bad practice.

As of today, I do not believe there exists a set of tools which standardizes how two parachains who want to communicate to each other with XCM should synchronize their state and trigger their logic based on changes from the other chain.

It seems some kind of offchain worker with light client proofs could be used to solve this problem, but likely this is not a trivial tool to create, and it certainly should be one which is standardized across our ecosystem.

I think such tools are the catalyst needed for us to create oracle chains, which report up to date prices of other cryptocurrencies, which is a fundamental primitive for many defi tools. Hopefully in the future, these tools are also used to bring data from robust identity chains to the rest of our ecosystem.

As much as it is important to have protocols which allow us to describe moving an asset from one chain to another, I think for us to unlock the full potential of interoperability in Polkadot, we need to start also thinking about how we can let chains focus on generating high quality data, and making it dead simple and cheap for other chains to access that data when they need it.

Development Ecosystem

In the Development Ecosystem section, the Web3 Foundation identified the following areas: Development Services, High Value Partners, and Enterprise. Here is an idea for each of these areas.

Development Services: Interactive and Meaningful Tutorials

At the ground level, we need to continue to develop new ways to teach others to build with the Polkadot SDK, and actually have them use that information to launch meaningful products.

What do we want to see more of in our ecosystem?

  • More defi products
  • More cross chain interactions
  • NFTs
  • Games

One of the best ways to achieve this is to have tutorials which show the creation of working systems, which build these kind of products from zero to one hundred, with room to customize where needed.

The Polkadot developer community has always been good at producing high quality code, but not so good at educating others to be high quality coders. For this, we need to throw money and incentives at the problem.

  • create and maintain a number of high quality tutorials
    • these should be written by the experts, not having people who themselves are learning trying to teach others. I often think we are plauged with blind leading the blind.
    • target developers who need “a break” from coding. As a developer, I can speak to the fact that after large projects, having the ability to transition to create tutorials or other documentation is a nice escape from development.
    • treat this kind of work and maintenance as important as writing core code. That includes rewarding high quality authors and maintainers similar to core contributors
    • create frameworks and tools which make tutorial creation minimal effort for core knowledge holders
      • Use real rust projects, git, basic markdown, VS Code editor, and other familiar tools as the basis for creating and expressing tutorials.
      • On-hand writers to help shape “raw” content into expressive stories.
      • On-hand graphic/web artists to turn tutorials into something visually appealing and unique in story.
  • each tutorial should result in a product ready working products that we would like to see exist in our ecosystem
    • There is no value in a tutorial which teaches users to install the “name-pallet” into their chain. Or a tutorial which has users use unbounded vectors, inefficient storage structures, or other anti-practices. Tutorials should result in something useful and to be used.
    • A simple practice to achieve this could be to specifically write tutorials on creating the pallets found in Polkadot itself. However, this is also probably not the right formula.
  • tutorials should capture the whole scope of learning, from substrate specific rust, to pallet development, to parachain / solo-chain deployment, to upgrades, migrations, and other long term maintenance.
  • tutorials should be gamified and fun for the author. We should look to create full end to end experiences that users can pick up and put down on their free time, and on-chain rewards like NFTs when users complete some tutorial.

Some of these efforts are already in progress in different forms, but in my opinion the vision, incentives, and people working on this have never quite been the right mix for success. With the decentralized futures program and the right people, perhaps this can change.

I am working on some of this stuff already as a part of my efforts in the academy, with the web3 foundation education team, and personal education initiatives I am doing locally to my home. Hopefully we will see a revival of substrate kitties soon.

High Value Partners: Community Auditors and Audits

Audits are key to the survival and trust developed for ecosystems. However, for many development teams, audits are very expensive, and for many potential audit teams, they do not have access to the information or resources needed to be experts in our ecosystem, and actually provide proper audits.

For this, we need to combine two different initiatives into a single story:

  • An education path for successful audit teams outside of Polkadot to become expert Polkadot auditors.
  • A path toward free/subsidized audits from these teams for our ecosystem.

This starts with funding and education. We need to draw in audit teams by paying them to complete an audit in our ecosystem, but targeted also as a learning experience for them. Perhaps in this situation, they will act always as a secondary audit for a primary auditor. These audit teams would be guaranteed some funding for their time (paid for by treasury / decentralization funding), and they would see a large queue of teams who are looking for audits for their work, meaning much more work in the future.

There should be a process for teams to submit a request for audit, and some community / technical feedback allowing prioritization and subsidization of those requests. Also some tracking to see how much support teams have received in total, and the history and knowledge of the audit teams.

In many ways, this reminds me of existing systems in our world like court assigned lawyers for defendants that cannot afford legal representation, or government contract requests which are placed in public, and allowing different parties to bid on fulfilling those requests.

In the end, any level of respectable auditing will have long term impact in our ecosystem. We can draw in and even create more high valued partners by ensuring our products are not as likely to be attacked or have erroneous bugs.

Enterprise: Competitive Research

In the spirit of attracting existing successful Web2 companies into the Polkadot ecosystem, we need to make it obvious to them that Polkadot is the correct choice among competitors and peers.

The truth is that many of the most successful blockchain ecosystems got that way off of narrative manipulation and marketing, and not actually working or philisophically aligned technology.

Beyond that, other teams have found a product market fit which seems to still elude the Polkadot ecosystem. Such problems are cyclic. Without users you don’t draw in new products. Without new products, you don’t draw in users.

Of course improving our own product is absolutely the best first step to remedy this problem, and plenty of that is already happening in Polkadot. But what I suggest here is different in that we should also be more on the offensive and call out fact from fiction.

A lot of this proposal has already been written down here: Polkadot Competitive Research Proposal - HackMD

I think there are two key outcomes which come from competitive research:

  • calling out narratives and stories which are false in other ecosystems, many of which were pioneered by Polkadot
    • Does a chain claim to achieve 1 Million TPS? What does that even mean? How would this actually compare to other protocols, and not some hand crafted benchmark.
    • “Instant finality” sounds cool, but is it really?
    • Other chains claim to have “forkless upgrades” or “shared security”, is that actually true?
    • Modular blockchains are the future, but where in the stack is modularity a benefit, and where is it actually a poor design decision?
  • learning from our competitors to better shape our product
    • Polkadot as a culture seems very deep into our own research and ideas. Many of the most successful teams have used ideas and standards from other protocols to accelerate the development of their products.
    • What products can we create which directly compete with what enterprises and users find exciting in other ecosystems.
    • how can we create more directly comparible products, and prove that our technology stack is actually better. For example, growing Polkadot SDK into a platform for developing the best L2s, in competition with arbitrum and optimism, as well as parachains.

Unfortunately, existing parties have not seemed as interested in directly funding this work, however the decentralized futures program may be the way to get such an effort going.


In the Community section, the Web3 Foundation identified the following areas: On-Chain Governance, Decentralized Marketing, Events. Here is an idea for each of these areas.

On-Chain Governance: Treasury Proposal Templates

Open gov has been an interesting experiment so far. From my observations, the blockchain level APIs and mechanisms which exist are pretty good, but the community is WRONG in trying to interface directly with it.

Even the existing UIs today like Polkassembly and Subsquare seem to be just wrappers on top of low level blockchain APIs, and not themselves an app which is expected to be used first and foremost by casual builders and new faces in our ecosystem.

A lot of this idea is already written down in this thread: A Better Treasury System

But at a high level, I imagine that we use our social standards to push forward behaviors beyond the rules of the blockchain.

As an initial MVP, I would expect that we try to standardize the following:

  • An online form that users can fill out easily to describe the funding they want. Not a word doc to fill out, but actual web based UX, that can modify itself and help users through the process.
    • These could even be different depending on the track.
  • Publishing to the public FIRST, before posting anything on chain. The discussion of proposals should happen far before anything shows up on chain. Is it possible to design systems where the outcome of proposals are known before they are posted on chain? Or as close to this as possible.
  • Gamification of treasury spending. No one wants grifters or others to take advantage of the treasury funds. No one goes to an investor and asks for millions of dollars without any evidence of previous work done successfully. We should guide people through a tier system, where their first proposal is small in scope, and small in cost. Perhaps even just paying users to make a more formal roadmap for large ideas. Then, as users successfully complete proposals, their ability to ask for more increases, up to the point where they are getting large funds and large projects that we expect to support well established teams.
  • From gamification, we will also be able to establish off-chain reputation sysytems. We should have a hub which is centered around individual contributors and teams. When someone asks for funds, it should be easy to see what things they have delivered in the past, and how well those products have been received by the ecosystem. You would never buy a product online from a seller with no reputation. Why would you give a stranger money to build something with no background information?
  • The proposal process does not end when the vote passes. There should be entire hubs and discussion areas for each proposal. Imagine forums where users can query the builders on progress, provide feedback, and even hold builders accountable for the funds they received. This is all in the hopes of finding teams which don’t just market and sell their idea well, but also execute well and show effort to be integrated in our community.

Of course all of these things are not rules established on chain. Anyone could make a proposal directly on chain asking for any amount of funds. But we as a community can direct users to our socially accepted process, and encourage users to show their good intentions by having them grow in our community, not just ask for millions of dollars from out of nowhere.

In this context, I think there is nothing wrong with having more “centralized” thinking and processes around the treasury, knowing that this often provides more efficient processes to finding high quality teams and output. Most importantly, it does not compromise the decentralized nature of the underlying protocol.

Decentralized Marketing: Modular Marketing Materials

People who are reading this post are probably in the top 1% of the top 1% of people following the Polkadot ecosystem. So let me ask you:

If you had to make a presentation to describe and sell Polkadot to the world, how would you get started? What resources would you use?

As someone who has given countless presentations, I feel that no such resources exist, and in fact I am making most of my content from scratch. From the presentations I create, I see many people in the ecosystem asking for links to the presentation, and I have seen my images, words, and even ideas show up in twitter threads, blog posts, other presentations, and more.

When thinking about decentralized marketing, this is the kind of things we need. Not create bigger megaphones to blast out our ideas, but create reusable scripts that can be spread by smaller voices, and customized to the needs of the communities being reached out to.

With this in mind, I envision a marketing oriented resource website, providing content in multiple forms about many different key topics in our space.

For example, imagine that each topic had the following formats available:

  • One sentence summary.
  • One paragraph summary.
  • One essay summary.
  • One (or more) image(s).
  • One powerpoint slide.
  • One Twitter post.
  • One Twitter thread.
  • One (or more) competitive comparisons.
  • etc…

Then imagine we had this for all the key topics and differentiators in the Polkadot ecosystem, now and in the future:

  • Open Gov
  • Data Availability
  • Execution Sharding
  • Treasury
  • XCM
  • Polkadot SDK
  • Forkless Upgrades
  • etc…

These words could be copied, could be mutated, or could just be read by others. But the resources themselves are high quality and coming from and reviewed by the experts in the field. Providing ammunition to everyone who has access to the internet and a belief in what we are building.

Beyond that, I imagine that we provide many additional resources to make content development in Polkadot easier.

  • Access to graphics and themes which can be used throughout the ecosystem:
    • multiple visuals of the DOT token
    • multiple versions of the polkadot logo
    • multiple themes (for example, most recently the spacemen theme)
    • generators for custom parachain / xcm visuals
    • the best image representations of slogans and philosphies of Polkadot
  • More competitive research, and specific talking points to counter false narratives.
  • Reusable, short video clips with subtitles from various presentations, meetups, interviews.
  • Photos of our vibrant ecosystem, people, companies, meetings, development, workshops, etc…
  • And so much more.

All content would be completely open source, zero copyright, and free for the public to use as they see fit.

I think we if had to be critical of marketing efforts in the space, it was that we had people who did not have the right ammunition to effectively spread the winning messages in this space. If we want to truly adopt decentralized marketing, we need to give everyone a powerful voice with easy access to persuasive data and messaging.

Events: Familiar Faces Fund

When I think about the future of decentralized events in Polkadot, I worry that we won’t properly curate the voices which are used to represent our mission and direction. It seems that large events like Web3 Summit, Polkadot Decoded, and Sub0 are some of the only places where our public gets an insight into what we are building and where we are going.

As Polkadot becomes more decentralized, it will not be as easy for individual catalysts and leaders to be able to travel and represent their work. Having the right people at our events and shaping the narrative around Polkadot is just as important as having the right developers architecting our codebase.

Having seen how these kinds of large events are prepared behind the scenes, I know that we make the agenda based on those who request to present, not by actually reaching out and curating a story that we want to tell. I don’t think this is the right way to get the best representation for Polkadot.

We have to remember many of our best speakers and representatives are already over their head in work. Without such a support program, these speakers would need to coordinate and pay for all this travel at their own cost. This usually only makes financial sense for leaders who want to shill their product, and this does not lead to the kind of content that is best for the whole ecosystem. For those looking to the treasury to support this, the overhead is currently massive, and the politics at the time are a large deterrent to open that can of worms.

We can achieve the desired outcome using a team and set of funds support key speakers. We need to figure out with them how we can make these events more accessible to them, and the best use of their time.

Simple things like managing hotel reservations, flight tickets, and other basic administration, to more complex things like shaping a narrative of what we want the public to see and hear from Polkadot, and finding the right people to present those parts of the story.

And we should think even beyond just the Polkadot ecosystem, ensuring that we have proper representation at large multi-ecosystem events like EthCC, EthDenver, Devcon, Devconnect, etc…

If we do our job well in this context, we can create famous and recognizable faces outside of just Parity and the original Polkadot Founders who represent our mission and contributions to this ecosystem, and whom other look to for direction and inspiration.

So really, I would like to see:

  • changing the direction from selecting representation from among those who ask to present, to reaching out to key presenters and asking them to present at key events
    • ultimately making things more proactive from the events side, and pushing work onto event coordinators and off of the presenters where possible
  • supporting those presenters to be at those events: funds and basic administrative help for their travel
  • collaborative narration: taking advantage of these key speakers, and forming ahead of time a set of presentations which capture the key takeaways we want the audience to know about Polkadot.
    • We should never have two presenters talk about the same topic.
    • We should never have two presenters contradict the messaging between their talks.

For something like this to exist, we need funding and a small group of individuals who can help shape this and make it happen.


I asked chatgpt to summarize my post into one or two sentences.

9 Ideas for the Decentralized Future of Polkadot

The Web3 Foundation introduced the Decentralized Futures program for the Polkadot Network, here are my ideas for each of the 9 areas suggested by the program.

Technology Section:

1. Developer Experience: An Alternative to FRAME

Proposal for a new runtime development language to simplify development, offering a more user-friendly and standardized experience compared to FRAME.

2. Growth: FRAME + ink! (The Merge)

Suggests merging FRAME and ink! to enable using a single language for smart contracts, on-demand parachains, and dedicated parachains, streamlining the development process.

3. Interoperability: Reading State Across Parachains

Addresses challenges in multi-chain interoperability, proposing standardized tools for state synchronization and data sharing between parachains.

Development Ecosystem Section:

4. Development Services: Interactive and Meaningful Tutorials

Proposes creating and maintaining high-quality tutorials to improve developer education, emphasizing working systems and incentivizing experienced contributors.

5. High Value Partners: Community Auditors and Audits

Suggests a pathway for external audit teams to become Polkadot experts, offering free/subsidized audits to enhance trust and security in the ecosystem.

6. Enterprise: Competitive Research

Advocates for competitive research to attract Web2 companies, fact-checking narratives in other ecosystems, and learning from competitors to improve Polkadot’s product market fit.

Community Section:

7. On-Chain Governance: Treasury Proposal Templates

Proposes standardized online forms for funding proposals, emphasizing community discussion, gamification, and reputation systems to enhance proposal quality.

8. Decentralized Marketing: Modular Marketing Materials

Envisions a decentralized marketing resource website with reusable content formats, empowering community members to effectively communicate and promote Polkadot.

9. Events: Familiar Faces Fund

Suggests the Familiar Faces Fund to support key speakers at events, providing administrative assistance, funding, and collaborative narration for consistent representation.

Note: The summaries are concise; refer to the original post for detailed information.

For feedback, I would like to capture which if any of these ideas resonate most with readers.

I think the Web3 Foundation’s Decentralized Futures Program should support:

  • Developer Experience: An Alternative to FRAME
  • Growth: FRAME + ink! (The Merge)
  • Interoperability: Reading State Across Parachains
  • Development Services: Interactive and Meaningful Tutorials
  • High Value Partners: Community Auditors and Audits
  • Enterprise: Competitive Research
  • On-Chain Governance: Treasury Proposal Templates
  • Decentralized Marketing: Modular Marketing Materials
  • Events: Familiar Faces Fund
  • I do not think any of these ideas should be funded.
0 voters

Thanks for sharing this Shawn, your ideas here really resonate with me.

Being an inexperienced dev, I’ve personally faced most of the problems you mentioned under 1, 2, 4 and 7.

As of now, I lack the competence to contribute to 1 or 2, but I would be keen to contribute to an end-to-end onboarding system for indie hackers.

I have some details about the same documented here: catalyst crew Proposal - Polkadot Treasury - Google Docs

I would love to hear your feedback on this – regarding whether or not you think it’s a good starting point to solve 4 and 7 and if you’d recommend any improvements/changes.

I think guidance from a Substrate + FRAME expert like yourself, together with the questions I have as an inexperienced developer and my experience as a UX designer, could help shape the coding school for the developer onboarding system.

Lmk what you think.


Thanks for your comments @batman

My first thoughts is that for onboarding developers into our ecosystem and teaching how to do development on Polkadot, there really is nothing that compares to what the Polkadot Blockchain Academy offers at the moment.

Your proposal seems to talk about two extremes of the builder spectrum:

  • onboarding and helping those who are just getting in and wanting to write fast fun code
  • turning them into people who want to build web3 businesses

My perspective is that these people are often not the same, and transitioning someone from just getting started to build to having them build web3 business is a multi-year process with probably less than .01% of people making it to the end.

All of the challenge of onboarding is the middle part.

  • projects/bounties which are easy enough to jump into in a few hours are usually of little value
  • projects/bounties which have high value usually are complex and have not been done yet because they are too difficult
  • the distribution of open issues and tasks do not line up with users. For example, you can imagine issues are much like a bell curve, where most issues require intermediate core developer experiences, but majority of people looking for issues want to tackle “good first issues” or “easy tasks”

Ultimately, I think I find it hard to realistically deliver the outcomes you hope for with the proposal you have written, and because of that, I am not super bullish on this specific idea.

That being said, I think we agree about some kind of heavily opinionated UX which overlays the current treasury process, which can apply to indie hackers aswell. For me, the goal is not promising some outcome of proposals, applications built, or users onboarded, but having a goal of making information which helps decision making easier to access for token holders distributing funds.

If you are good with react, and you want to build some kind of better UX in this direction, I can def provide my thoughts on a specification and north star. Truthfully, I think a product like this would best exist as a new internal initiative at Polkassembly or Subsquare, since I would rather help improve these existing products than build new ones from scratch.

1 Like

Thinking a little more, if your goal is to create a proposal to specifically target the success of indie hackers, I think we should be focusing our efforts at making really amazing in-person hackathons at existing web3 conferences.

To be honest, I have not been super impressed with the Polkadot hackathons so far, or perhaps I do not see enough about them to be.

But I think this kind of more targeted initiative will have higher impact than some general website.

1 Like

Happy to find people sharing similar idea and giving some potential solution to the problem I raised here: Underestimated developer cost in Polkadot ecosystem

Strong personal opinion warning. To me, the enterprise things are strongly negative to Web3 native community. I’m not saying I’m against enterprise at all, but at this stage, enterprise partnership or collaboration is more or less just scams and lies used my a lot of projects to manipulate the market. How much enterprise stuffs are really taking use of the decentralized technology? So as a developer, when judging a project, the more enterprise narrative I hear, the worse impression I would have.

Thank you @shawntabrizi for putting this great analysis together. In my opinion, these sections are crucial for improving the developer experience:

  1. Developer Experience: An Alternative to FRAME.
  2. Growth: FRAME + ink! (The Merge).
  3. Development Services: Interactive and Meaningful Tutorials.

This would be a good user experience.

In regards to tutorials, I agree that they should be done by experts. Interesting point to target developers who need " a break". I believe that the tutorials should have a video component ( not just text based).

The NFT can be a badge that certifies completion of the tutorial. With enough badges, users can prove that they acquired a new skill.

The experts doing the tutorials can also learn NFT badges based on how many users complete their tutorials ( or something like that). That way we are creating a system where both the experts and learners are rewarded.

1 Like

Thanks for explaining your thought process @shawntabrizi.


  • I agree that Polkassembly/Subsquare would be better suited to build a treasury UX to ease decision making and I don’t want to build a competing product.

  • I agree that easy projects are of little value in isolation, but I believe such value compounds with volume. Specifically:

    • It contributes to increase in the frequency of transactions and makes the economy of the ecosystem more liquid.

    • Projects like these can help new devs up-skill and contribute in more meaningful ways, either through direct evolution of the same project or a completely different project.

  • I do wish to build a structured, simple and accessible onboarding system for indie devs, where I believe PBA and current resources fall short.

  • I believe hackathons are one of the key pillars needed to onboard devs, but is insufficient in isolation.

Regardless of the approach, since you mentioned "Development Services: Interactive and Meaningful Tutorials" in your original message, I assume you have a target user and a goal in mind here.

Question: Could you share the user persona you had in mind for a product like this? Specifically, what assumptions would there be regarding the end user of a tutorial like this?

Would they know need to learn rust prior to this? Do they need to be familiar with web3 concepts, or do we explain that? etc.

I would be keen to build this, perhaps something similar to https://cryptozombies.io/. But as you mentioned, it would require significant mind space from an expert.

Adding to the above thought:

Instead of an expert writing the tutorial, I think they should work alongside a student, because many things that might look intuitive to an expert can be baffling for a student.

Details (feel free to ignore - raw thoughts)

Replying inline:

I agree.

To clarify, do you mean there’s nothing like PBA, hence we need something to fill that gap or that PBA itself should be extended/made more accessible?

Also, I’m keen to understand - what goal according to you does the academy aim to accomplish?

Is it solely to help people already within the Polkadot community become better devs or onboarding new devs?

I ask because I don’t think it does a good job at the latter, because all of its documents have an underlying assumption that people want to contribute to not only web3 but also specifically to Polkadot.

I agree.

I wish to gain a deeper understanding of the user persona you have in your mind, specifically what would the ideal user of this developer education program look like?

True. My perspective is that little value can compound with volume.

Projects that may seem uninteresting to experienced devs and entrepreneurs, often having a thin layer of code and negligible barrier to entry are what keep the economy liquid.

An example is the degen/NFT culture on Ethereum and Solana, which arguably adds 0 “real” value, yet keeps the SOL economy stimulated enough to attract more builders and capital.

I believe small tools and projects with relatively little value, can:

  1. contribute to initial momentum and create a positive growth spiral for the ecosystem

  2. gradually turn into more valuable projects over time as the developer gains more experience and skill by building the project

At the end of the day, I see it as a bet on the ability of humans to learn, adapt and improve over time.

If given the right support and direction from the start, project builders develop an almost tribal affinity towards web3 ecosystems and continue to build in the ecosystem where they initially got started.

Yes. I don’t think an education program can directly contribute to this.

Problems like these require primary focus of experienced devs.

Yes. This adds to my point above - i.e. creating a path for inexperienced devs to learn and up-skill by building small projects initially and transitioning into the intermediate role over time.

I understand. As documented above, my perspective on this is a little different.

I do believe an effort like this is worth trying in conjunction with PBA and hackathons. Perhaps collaborating with each other to create a cohesive onboarding solution to direct candidates appropriately, depending on where they are in their web3 journey.

Yes. I do believe there’s a need for a UX layer that makes decision making simpler for voters and am familiar with react.

But as you mentioned, something like this is better served by Polkassembly/Subsquare.

It would only make sense to make a new platform if the target audience is applicants, not current OpenGov voters.


  1. What about the current hackathons is unappealing/insufficient to you?
  2. What would an ideal hackathon look like according you?

Completely with you.

I think the document I shared fails to communicate what I was aiming for, but the goal isn’t to build a website aggregating a few resources.

It’s to create an initiative similar to SuperteamDAO.

I believe the collaterals documented in the proposal are important to have in place to improve the conversion rates - i.e. something that gives devs:

  1. a structured pathway to learn how to build on Polkadot (web3 coding school and project ideas)

  2. incentive to learn about building on Polkadot (grants, bounties and jobs)

As I write this, I realize that the proposal may be too broad right now, and creating an interactive coding school like the one you described under “4. Development Services: Interactive and Meaningful Tutorials” could be the first step.

Something similar to this perhaps:

1 Like

@batman I will spend time to respond to your other questions and feedback soon, but addressing the TLDR, if you are interested to contribute to making something similar to cryptozombies, I am also working on this right now for a “pre-substrate” rust course:

I will myself be working on writing some code to turn this repo into a generated interactive tutorial, but my time is better spent writing more raw content, and leaving the UX to those who are professional.

This tutorial captures someone who has been introduced to Rust, but is still learning and looking to start writing pallets with FRAME.

The tutorial that will immediately follow this tutorial is a remake (in the same format as the state machine tutorial) of: https://docs.substrate.io/tutorials/build-application-logic/use-macros-in-a-custom-pallet/

Which I think is a solid spot to do comparisons between the raw rust users did in the first tutorial and jumping into FRAME.

Finally, what I will work on is probably the creation of tutorials like this for: Fungible Tokens, Non-Fugngible Tokens (substrate kitties), and a DEX (probably uniswap v1).

The hope would be that we could keep extending the various tutorials, but ultimately once it is shown this format of tutorial (and framework to make it interactive) works well.

I am leading a workshop in Puerto Rico the beginning of December, and hoping to have this material done by then.


This is perfect!

I’m not sure if I can build something in time for your workshop, but I’ll keep you posted regarding progress on this and might bug you for feedback.

thanks for this inspiring post @shawntabrizi. below are some of the ways i’d like contribute to the Decentralized Futures Program based on some quick brainstorming by myself this morning, but i’d need feedback and help to determine which to prioritise, if any. i’ve been studying all year and recently finished the EPF. i’m still doing ZK and IPFS courses until the end of the year, and my plan in the new year is to focus on core development (long-term ambition to become a Polkadot Fellow rank 1 and to build other important infrastructure.

  1. Development Services: Interactive and Meaningful Tutorials
  • build a framework and tool for creation of gamified and useful tutorials by core knowledge holders that use cross-chain interactions and use ZK
    • build a specific expertise assessment tool to determine whether someone is ready to use the tool to teach others, to avoid “blind leading the blind”
  1. High Value Partners: Community Auditors and Audits
  • build an audit marketplace dapp for matching submitted requests for audit with offers from auditors
  1. On-Chain Governance: Treasury Proposal Templates
  • build a treasury marketplace dapp to guide users in submitting treasury proposals using bid management best practice
    • build a dynamic online form (i’ve built many of these before) that integrates with their on-chain identity and reputation
    • automatically determines level of authorisation scrutiny required to expedite the process based on data from reputation systems
      • note: i have prior consulting experience in program, bid, and procurement management that could be useful
  1. Decentralized Marketing: Modular Marketing Materials
  • build a marketing marketplace dapp to guide users in decentralised marketing best practice tailored to the Polkadot ecosystem
    • integrate with decentralized storage
  • generate data structures for use with decentralized marketing in the Polkadot ecosystem
  1. Events: Familiar Faces Fund
  • build an event marketplace dapp to help presenters shape their narrative that aligns with the Polkadot ecosystem whilst also matching them with tailored support personnel (collaborative narration), travel administration to match them with suitable hosts, and event coordinators who may be given permission to manage their desired event logistics and gain a reputation for doing it
  • build a host marketplace dapp to match presenters (and their families if necessary) with suitable homestays and experiences that align with the Polkadot ecosystem
1 Like

@hangyin: Strong personal opinion warning. To me, the enterprise things are strongly negative to Web3 native community. I’m not saying I’m against enterprise at all, but at this stage, enterprise partnership or collaboration is more or less just scams and lies used my a lot of projects to manipulate the market. How much enterprise stuffs are really taking use of the decentralized technology? So as a developer, when judging a project, the more enterprise narrative I hear, the worse impression I would have.

I’ve been a consultant for web2 for a few years and if I had to choose, I think it would be more beneficial for Polkadot if businesses would adopt it, rather to see the Solana NFT-hype on it.

Of course, it would be great to make it without them, but I always try to overcome by tribalism mindset in that regard and would like to extend my hand and invite them.
But I have noticed, that only the very committed managers are able to get to the level where they’re able to understand Polkadot. I’m therefore in favor of the “Enterprise: Competitive Research” suggestion.
It would be great to publish a study (they share very well) with lots of graphs and maps (they share even better), which consultants can copy-paste on their presentations :slight_smile:

Are there any working groups active?

1 Like

A lot of interesting ideas to ponder, thank you for sharing ser!

Would like to highlight 4;7;8 - all could be great resources that various ecosystem participants would undoubtedly lean on.

4 - Interactive and Meaningful Tutorials - As many high quality resources as possible! This could fit neatly under the PBA umbrella as a part of Online Academy experience. Having been involved with the PBA team quiet extensively, I am absolutely positive that building an incentivised and gamified online experience is the next step in the evolution.

7 - UX, Gamification and reputation systems - All essential for future success and I would include both on/off chain reputation. Gamification is rapidly establishing itself as one of the key tools to promote user activity and adoption in Web3. POAPs and NFTs in general are misunderstood and underutilised as a component for next gen CRM and Social Profiles. Honestly, I truly believe that this section is could be vast in scope and act as a crucial pillar to building successful future.

8 - Modular Marketing Materials - This is both a no brainer and a must have. Enabling others and promoting coherent brand experience at the same time. There some reliance on the Polkadot brand and its future… Generally speaking something that could be kickstarted as a part of a brand book, subsequently hosted online and handed over to community for updates and upkeep. Moreover, there are examples to learn from.

We at R0GUE see much alignment between some of @shawntabrizi’s ideas and an idea that we posted on the forum: Pop Network! We would really like to hear your thoughts to find out whether this could help solve some of these painpoints :muscle: :heart:

Also feel free to contact us: gor0gue:matrix.org

1 Like

Lots of great ideas here Shawn, with regards to the below I’m going to try address this with a video clips repos which I generate from spin-off material for a new series of Behind the Code. If the proposal goes ahead I’ll definitely be reaching out to see what’s going to be of most use to teams across the ecosystem

1 Like

Thank you for sharing your thoughts @shawntabrizi. I’ve just stumbled upon your post, and I’m excited to see that some of your ideas, especially 1. Developer Experience: An Alternative to FRAME really resonate with us. This Growth: FRAME + ink! (The Merge) also sounds very interesting.

Actually, I am part of a team that is working on an alternative to FRAME, Gosemble. It aims to provide the core characteristics of what you outlined, plus more:

  • Easy to understand and use
  • Streamlined building without unnecessary complexity
  • Less configurable, containing only the most necessary options
  • Provides all the core primitives
  • Compatible with Polkadot-sdk/FRAME

We have been thinking of providing something like presets, based on the Gosemble, but configured in a way that is more suitable for specific use cases, which seems similar to what you suggested (targeted toward simplifying specific ecosystem objectives (cross chain transfers, defi, multi-token systems, smart contracts, etc…))

Some other goals we are trying to achieve include:

  • Making the ecosystem more accessible to other languages / technologies / developers, since we see Polkadot as more abstract and not bound to any specific technology
  • Helping formalize the specification, which currently is strongly influenced by Polkadot-sdk/Rust and is missing a lot of details regarding the runtime
  • Protocol improvement/development is mainly focused around Polkadot-sdk/Rust, but perhaps we can use Gosemble as a tool to quickly prototype and test out new ideas, including our own or those from the RFCs

I hope we can collaborate on this to identify what is worth implementing, so it is most beneficial for the ecosystem. There is a separate thread on the forum where we could discuss it and potential features that could be implemented in Gosemble. I am interested to see what you think about this.