In short: Easybuild is a chain-bounty program designed to attract and integrate new builder teams into the Polkadot ecosystem. Through a three-tiered retroactive reward system, it incentivizes the development of DOT-focused products, providing clear milestones, integrated support and mentorship, and funding to streamline the innovation process and foster user-centric solutions.
GOAL: Influx new builders and new teams into the Polkadot ecosystem and boost the development of user-centric apps, dApps, and innovative toolings.
PROBLEM: The Polkadot ecosystem is currently lacking teams that focus on creating user-centered solutions that utilize the system's full potential. More details can be found in the section "The current state of the flow of new teams and their products.
Relevance: This is particularly important now as Polkadot introduces innovative solutions (such as Asset Hub DEX, OpenGov, Agile, pallets-nfts, upcoming innovative EVM solutions, XCM, and many more), and changes in system approach to the ecosystem (Coreplay/Corejam), which provide potential new use cases within the Dot token. While current teams focus on utilizing existing concepts, and many seek product-market fit outside the ecosystem (with already existing concepts). Whereas the system needs new innovative builders prepared to test and employ new concepts.
SOLUTION: "Easybuild Bounty," a streamlined, swift, retroactive bounty-based track designed to attract and integrate new builder teams into the Polkadot ecosystem.
Concept overview: "Easybuild Bounty" is a three-tier cascade of straightforward retroactive bounties, aimed at teams that create DOT-focused products.
Graph_1: Retroactive bounty-based track explanation.
Each stage demands a new level of product development and introduces a unique mode of support and collaboration within the ecosystem. This combination of a cascading structure and short-term milestones helps veil the retroactive nature of the bounty. The blend of checklist and mentorship solutions helps counteract community conservatism and expedite the completion of milestones. Each stage checks the DOT-focus of the project, ensuring funds aren't misallocated to external ecosystems.
Easybuild Detailed: A significant portion of new teams time/org.tasks is directed towards the bounty side, with the aim of relieving new developers from tasks not directly related to their main responsibilities. Sample: Stage1 -> Stage2 detailed transaction flow. Bounty Flow Detailed can be found in the full proposal.
Graph_2: Transaction flow sample.
Important: All checks (both by the operator and the community) are reduced to checklists. This helps reduce subjectivity and relieve developers of non-core workloads. Rules do not change for existing cohorts, only with a lag AFTER a cohort (so as not to unsettle those in the funnel).
Devx prioritization: The whole track's idea aims to provide a secure developer space with all factors enabling teams to work in an environment that excludes the stress of the unknown outcome, focusing on development and gradually integrating into the ecosystem.
Meanwhile, development direction, track navigation, and funds allocation are managed by tech-savvy experts. In addition, the community can safely support promising teams with minimal risks of overfunding, attracting milkers and scammers, and not behaving aggressively toward new builders and teams.
Targeted Outcomes for the EasyBuild Bounty: The program is cohort-based and consists of six-month modules that have a “building lag”.
Graph_3: Cohort overview
On average, a successful team will take about six months to go through (~3m building, ~3m custdev+org).
Graph_4: Team full funnel
Stage 1: Attract 10-15 teams every month for 6 months to present their MVPs and initiate prototype development.
Stage 2: Propel 20 teams total from prototype creation to public beta testing. (50%* conversion from Stage 1).
Stage 3: Onboard at least 6 teams in total, moving from beta testing to ecosystem integration. (50%* conversion from Stage 2).
*Conversion rates are the subject to/during change after tests.
The full cohort size (with current conversion rates) starts from ~53 teams at stage1 (from 300+ builder teams at stage 0). Every one of these 53 teams will bring some unique MVP. Link to preliminary calculations.
Scheme of the test cohort: In our opinion, it's best to conduct a test of this concept by initiating a 3-month intake. This is the minimum intake required to obtain a successful output funnel. After this, we can fully deploy the program.
Graph_5: Test cohort overview
We'll discuss the results before the completion of the full funnel (because 9 months is too long for effective iterations). If the community approves, we'll propose to make it a full-scale initiative. Calculations.
FAQ
Thank you for your time! We will be happy to have your feedback. It can be done here, or in the document, or through Matrix: @motifnetwork:matrix.org
Threshold