4 |
5 | **Once the grants committee accepted a project's first milestone**, we want to help them acknowledge their grants publicly while observing the foundation’s guidelines.
6 |
7 | To that end, we’ve created a badge for grant-winning teams. The badge in four formats will be available for download as a “.zip” file from [web3.foundation/grants/badge](https://web3.foundation/grants/badge). Think of it like a medal or trophy.
8 |
9 | *Before you begin using the badge, please note the following points:*
10 |
11 | - Grants are awarded **for specific projects**, not to teams in general as a blanket endorsement.
12 | - Web3 Foundation and its grants program **don’t broker partnerships or joint ventures**; or cosign wholesale any external team’s work. Bearing that in mind, **the badge should only be displayed in project-specific contexts.**
13 | - Please **do**: display the badge
14 | - in a GitHub repository that contains code connected with the grant-winning project;
15 | - on any project-specific webpages; and,
16 | - when appropriate, in a tweet or blog post announcing your grant in a project-specific context.
17 | - Please **don’t**:
18 | - display the badge on your team’s landing page;
19 | - add it to any social media profiles; or
20 | - use it in any contexts that could misrepresent your relationship with the Web3 Foundation.
21 |
22 | Also, please don't use the **name or logo of the Web3 Foundation** in any contexts that could misrepresent your relationship with Web3 Foundation. Infringement of these guidelines can result in an immediate annulment of the grant.
23 |
24 | In case of any questions, please don’t hesitate to reach out to us at grants@web3.foundation.
25 |
--------------------------------------------------------------------------------
/grants/grants.md:
--------------------------------------------------------------------------------
1 | # General Grants Program
2 |
3 | This repository has been deprecated in favour of the [Grants Program repository](https://github.com/w3f/Grants-Program/).
4 |
--------------------------------------------------------------------------------
/grants/milestone-deliverables-guidelines.md:
--------------------------------------------------------------------------------
1 | # Milestone Deliverables Guidelines
2 |
3 | These are the guidelines to be followed for milestones submitted for evaluation.
4 |
5 | ## Submission
6 |
7 | For the **General Grants** program, please submit your milestones by email to grants@web3.foundation. For the **Open Grants** program, please submit your milestones via PR to the [Grant Milestone Delivery repository](https://github.com/w3f/Grant-Milestone-Delivery).
8 |
9 | ## Invoice
10 |
11 | Although a milestone needs to be reviewed and accepted, you can already submit your invoice through [this form](https://docs.google.com/forms/d/e/1FAIpQLSfmNYaoCgrxyhzgoKQ0ynQvnNRoTmgApz9NrMp-hd8mhIiO0A/viewform).
12 |
13 | ## Content
14 |
15 | The submission should contain the following information:
16 |
17 | * **Name of the grant project**
18 | * **Link to the open-source code/delivery**
19 | * **[License](#license)**
20 | * **[Documentation](#documentation)**
21 | * **[Formatted code](#formatted-code), according to a set of guidelines**
22 | * **[Testing Guide](#testing-guide)**
23 | * **A list of the [milestone deliverables](#milestone-deliverables)**
24 | * **Any [additional information](#additional-information)**
25 |
26 | ## License
27 |
28 | In order to successfully receive grant funding for your application it is necessary for the project to have open source code.
29 | We prefer Apache 2.0, but MIT or Unlicense are also acceptable. If your delivery comprises multiple repositories, make sure to include the license for each of them.
30 |
31 | ## Documentation
32 |
33 | We value high-quality open source code, but even the most performant code is of little use if it lacks proper documentation.
34 |
35 | We require that you document (where applicable):
36 | - API calls
37 | - Architecture overview and individual component details
38 | - Algorithms and protocols that are core to your project
39 | - Any other fundamental building blocks to your technology
40 |
41 | Unless absolutely necessary, make the documentation public as well, ideally as part of the appropriate code repository. This will make it easier for the community to use or adapt your project.
42 |
43 | **Note**: Only focus on your **own** contributions. Do not write detailed explanations of already existing components, e.g. IPFS.
44 |
45 | ## Formatted code
46 |
47 | A codebase that is easy to read is also easy to use. We suggest adopting one style from Day 1 and adhering to it across the entire team.
48 | This helps to keep the commit history clean and facilitates any reviews of the introduced changes.
49 |
50 | For **Substrate**, we strongly recommend formatting your code according to the [official guidelines](https://github.com/paritytech/substrate/blob/master/docs/STYLE_GUIDE.md).
51 |
52 | For **Rust**, we encourage formatting any additional support libraries or helpers by following the [Style Guidelines](https://doc.rust-lang.org/1.0.0/style/README.html).
53 |
54 | For **any other** deliveries, please commit to a particular style & let us know which official guidelines you adopt.
55 |
56 | ## Testing Guide
57 |
58 | We require that each milestone delivery includes a comprehensive test suite, consisting of:
59 |
60 | ### A step-by-step guide demonstrating how your code achieves the milestones.
61 | Please provide documentation on how to install, compile, run and test the deliverable(s). Make sure to include all necessary prerequisites. Common issues while replicating test results involve, among others, undocumented dependencies, version numbers, local database setups, breaking changes in the main branch since delivery, OS- and browser-specific incompatibilities.
62 |
63 | Depending on the deliverable, this could include (but is not limited to)
64 | - how to embed your library in another application,
65 | - how to make example API calls to your service,
66 | - running your web app,and
67 | - steps to complete some desired action in your mobile app.
68 |
69 | ### Unit tests
70 | As with any quality software project, each logical code component should be testable.
71 |
72 | ### Integration tests
73 | We prefer dockerfiles to avoid problems with versions and dependencies.
74 |
75 |
76 | **Note**: If you are not delivering code as part of your project, such a test suite is not applicable. This mainly applies to projects centering on design, research or hardware. If that is the case, please provide detailed instructions on how else we can test/run/replicate your deliverable.
77 |
78 | ## Milestone Deliverables
79 |
80 | Please provide a list of milestone deliverables. This list should closely reflect the list of deliverables agreed on in the Pull Request for the **Open Grants** program or in Annex 1 of the grant contract for the **General Grants** program.
81 |
82 | Each item in the list should include a link to the deliverable itself, e.g.:
83 | - Google Doc link - make sure anyone with the link has View access
84 | - GitHub repository - include the appropriate file/folder in the link
85 |
86 | **Please highlight anything that deviates from the contract** and include further information that you think is relevant to the deliverable, either alongside the appropriate deliverable or under [Additional Information](#additional-information).
87 |
88 | Please ensure the repo has the correct open-source license.
89 |
90 | | Number | Deliverable | Link | Notes |
91 | | ------------- | ------------- | ------------- | ------------- |
92 | | 0a. | License | https://github.com/.../LICENSE | ... |
93 | | 0b. | Documentation | ... | ... |
94 | | 0c. | Testing Guide | ... | ... |
95 | | 1. | ... | ... | ... |
96 | | 2. | ... | ... | ... |
97 |
98 | ## Additional Information
99 |
100 | Please add any additional comments that you consider relevant for the evaluation.
101 |
--------------------------------------------------------------------------------
/grants/polkadot_stack.md:
--------------------------------------------------------------------------------
1 | This document has been deprecated in favour of the **[Open Source Polkadot Stack](https://github.com/w3f/Grants-Program/blob/master/docs/polkadot_stack.md)** in the new repo.
2 |
--------------------------------------------------------------------------------
/grants/rfp-responses/targeted.md:
--------------------------------------------------------------------------------
1 | # Targeted Programme Grant Applications
2 |
3 | Please make a pull request to this folder when making an application for [grants](https://github.com/w3f/Web3-collaboration/blob/master/grants/grants.md) that are part of a defined programme (e.g. the alternative implementation of the Polkadot Runtime Enivronment).
4 |
5 | Please be sure to include all the necessary details in your application document and please check that you have correctly completed the [pull request template](https://github.com/w3f/Web3-collaboration/blob/master/.github/PULL_REQUEST_TEMPLATE/grant_application.md).
6 |
--------------------------------------------------------------------------------
/grants/speculative/Enzyme.md:
--------------------------------------------------------------------------------
1 |
2 | # BlockX Labs
3 |
4 | ## Project Description
5 | **Substrate Chrome Extensions DApp Wallet**
6 |
7 | We intend to create a Chrome Extension DApp Wallet. Similar to Metamask, this wallet will be compatible with substrate core and configurable to the modules used by any standard parachain. When a user creates a parachain, they will very quickly have a professionally made, well-tested Chrome Extension DApp Wallet. This can also interoperate between all substrate chains.
8 |
9 |
10 | ## Team members
11 | Chinmay Patel - CEO & Co-Founder
12 |
13 | Kush Patel - Solutions Architect & Co-Founder
14 |
15 | Ezadkiel “Zad” Marbella - Senior Architect & Co-Founder
16 |
17 | Jon Purdy - Project Manager
18 |
19 | Jesse Abramowitz - Blockchain Developer.
20 |
21 | We are currently a team of 10+ blockchain developers based in Toronto, Canada.
22 |
23 | ## Team Website
24 | [https://www.blockxlabs.com/](https://www.blockxlabs.com/)
25 |
26 | ## Legal Structure
27 | Corporation based in Ontario, Canada
28 |
29 | ## Team's experience
30 |
31 | ### Individual Experience
32 | Chinmay Patel is a tech leader, public speaker, and a serial entrepreneur with over a decade of team building and product development experience under his belt. He is currently the founder and CEO of BlockX Labs and works with his clients to help them build developer tools and explore the full potential of blockchain technologies. Chinmay’s aim is to bring mature software development and sound product design strategies to the world of blockchain software development.
33 |
34 | Kush is a Co-Founder and Blockchain Solutions Architect at BlockX Labs. He has been a consultant for some of Canada’s top banks. Kush’s experience spans from developing financial products to scaling complex technical architectures. He has also built and maintained Exchanges which transferred approximately $1bn worth of assets on a daily basis. Nowadays, Kush is focused on working with clients to build decentralized exchanges.
35 |
36 | Ezadkiel “Zad” Marbella is the co-founder and Senior Architect at BlockX Labs. Zad has a decade of experience as a full-stack automation test developer for Blackberry, Mozilla, and TeamBuy. He was also the Senior Architect and developer for Butter, an RBC Ventures project that has currently launched and has amassed over 20,000 users.
37 |
38 | Jon Purdy is the resident Project Manager at BlockX Labs. He has been in the cryptocurrency space for years (with building a mining rig in 2014, investing in ICOs in 2017, and automated Korean price arbitrage just a few months ago). He’s also had experience building out redundant infrastructure projects in his past role, as well as implementing Agile methodologies (Kanban and modified Scrum).
39 |
40 | Jesse Abramowitz is a Blockchain Developer at BlockX Labs. After falling in love with Ethereum, he quickly saw the value of blockchain and made a career change.. He has worked on multiple DApps, projects, and Blockchain Networks. Currently, he is also a lab assistant at a local college and is always looking to help, teach and build on the blockchain.
41 |
42 |
43 |
44 | ### Team Experience
45 |
46 | Below is the list of some of the projects we have built together in the last 12 months:
47 |
48 | [AIWA](https://getaiwa.com) - Chrome extension wallet (similar to what we are proposing)
49 |
50 | [Butter](https://www.justbutterit.ca) - Subscription Hub by RBC (One of the biggest bank in the world)
51 |
52 | [Wellspent](https://wellspent.co) - Reflect on your spending, and make better choices (again for RBC)
53 |
54 | [Universal Faucet](https://faucets.blockxlabs.com) - Test tokens for developers on various blockchains
55 |
56 | ## Team Code Repos
57 | https://github.com/blockxlabs
58 |
59 | *Note: AIWA will be released on github in about a month. Other projects are intended to be built as private repositories.*
60 |
61 | ## Team LinkedIn Profiles
62 | https://www.linkedin.com/in/patelchinmay/
63 |
64 | https://www.linkedin.com/in/kushptl/
65 |
66 | https://www.linkedin.com/in/ezadkielmarbella/
67 |
68 | https://www.linkedin.com/in/jon-purdy-6a0aa7115/
69 |
70 | https://www.linkedin.com/in/jesse-abramowitz-04b546144/
71 |
72 | https://www.linkedin.com/company/blockx-labs/
73 |
74 | ## Intended language of development
75 | - Javascript
76 | - React with Redux
77 |
78 | *Note: All Chrome extensions are built on javascript.*
79 |
80 |
81 | ## Additional Information
82 | All other details will be shared via google forum.
83 |
84 |
85 | ## Checklist- [x] The grants document has been read and understood.
86 |
87 | - [x] The Google Form will be completed accurately. Note that the Google Form requires the pull request URL.
88 |
89 | - [x] Abstract (above) is succinct and complete.
90 |
91 | - [x] The application is being included into the correct directory: either 'targeted' or 'speculative'.
92 |
93 | - [x] The application includes a project description.
94 |
95 | - [x] The application includes all names of team members.
96 |
97 | - [x] The application includes a description of the team's experience.
98 |
99 | - [x] The application includes all necessary GitHub and LinkedIn links.
100 |
101 | - [x] The application specifies the development language and the reason for choosing it.
102 |
103 | - [x] The "Development Roadmap" section in the application has a timeline of development.
104 |
105 | - [x] The "Development Roadmap" section in the application has an estimate of funds required.
106 |
107 | - [x] The "Development Roadmap" section gives an indication of the team's long term plans.
108 |
109 |
110 |
111 |
--------------------------------------------------------------------------------
/grants/speculative/GunClear.md:
--------------------------------------------------------------------------------
1 | # Project name
2 | GunClear
3 |
4 | ## Project Description
5 | * Our mission is to provide the firearm industry with a private and secure data storage solution for firearm ownership history and transactions.
6 | * GunClear is a valuable project that solves a real problem which can't be solved without the use of this technology. If successful, we will engender adoption by a community completely outside the Web3 ecosystem.
7 | * Our plan is to develop our production network leveraging Substrate as it's base. It will integrate various technologies including a Plasma bridge to Ethereum and zk-SNARKs proof generation and verification allowing private transfers on the child chain.
8 | * Substrate helps us solve a problem being giving us a secure base to build our network on. It also integrates libp2p, which we will be working to incorporate better privacy-centric p2p networking technology inside of to support our use case.
9 |
10 | ## Team members
11 | * Bryant Eisenbach (protocol architect and lead smart contract engineer)
12 | * Sean Coughlin (lead zk-SNARKs researcher)
13 | * Mat Fox (product lead)
14 |
15 | ## Team Website
16 | * gunclear.io
17 |
18 | ## Legal Structure
19 | Integritas Solutions Corp LLC (Nevada) is the entity
20 |
21 | ## Team's experience
22 | Team lead has extensive experience building mission-critical, high reliability software for Aerospace, and has been working as an Ethereum smart contract developer for 1.5 years. Lead SNARKs researcher is currently pursuing a PhD in Applied Mathematics, has extensive experience developing enterprise-grade software, and experience with p2p networking technology. Team also has experience with mobile application design and user experience development.
23 |
24 |
25 | ## Team Code Repos
26 | * https://github.com/GunClear
27 | * https://github.com/zatoichi-labs
28 |
29 | ## Team LinkedIn Profiles
30 | * https://www.linkedin.com/in/bryant-eisenbach
31 | * https://www.linkedin.com/in/sean-coughlin-b251831
32 |
33 | ## Development Roadmap
34 | * 6 month timeline is to develop a draft Plasma contract and client in Substrate, demonstrate it working.
35 | * This timeline includes many other tasks, including the incorporation of zk-SNARKs tech.
36 | * We are currently in a capital raise to collect enough money to build out the MVP and go to market.
37 | * A $30k+ grant would help us get our engineering team started on this path sooner than later.
38 | * When the product MVP is built, we intend on going to market with the product in partnership with a range of industry players and building our community.
39 |
40 | ## Licensing
41 | All GunClear backend code will be open sourced under the MIT software license.
42 |
43 | ## Additional Information
44 | * We have a proof of concept already built ([video](https://www.youtube.com/watch?v=LSJsILw4BJs))
45 | * We have accepted angel financing to build the PoC
46 |
--------------------------------------------------------------------------------
/grants/speculative/Listen.md:
--------------------------------------------------------------------------------
1 | # General Grant Proposal
2 |
3 | * **Project:** Listen
4 |
5 | ## Project Overview :page_facing_up:
6 |
7 | Listen is a voice social software based on data decentralized storage technology and blockchain technology.
8 |
9 | ### Overview
10 |
11 | - Listen is based on decentralized data storage technology and Polkadot of the underlying Substrate block chain framework to build the voice of social software, Listen tokens LT let each user can have part of the social network, at the same time will no longer be centralised collect user privacy data, using the federated learning training model of AI, the trusted computing privacy benefits for the user. Listen will launch its own main chain after the Polkadot's parachain has started.
12 |
13 | - Listen group DAO module and how to manage the relationship of members in the group.
14 |
15 | - We want the voice social will run in the Apple Watch and Airpods. We want the voice social network will share by all users.
16 |
17 | ### Project Details
18 |
19 | Listen as a voice of social software, it is different with other communication tools, and podcasting software is also different, social support acquaintances, including voice, images, text and video, such as social practices, and social group in a stranger, using a similar round table in the form of BBS, group manager invited several guests, they have speaking right, and join hands to Listen and speak to the rest of the room, at the same time also can use the LT token to buy the speaking time, all purchases will accumulate in the room below. Listen creates a unique experience that is different from a Feed stream. In a community of strangers, celebrities engage in voice discussions and audience interactions around topics.
20 |
21 | If the discussion in the room starts to decline and more and more LT COINS are accumulated, anyone can initiate a proposal to dissolve the room, and everyone in the room can vote on it. Once passed, the room can be dissolved, and the accumulated LT COINS will be divided equally among all the people in the room
22 | after deducting platform fees.
23 |
24 | The rules for dissolution are also very simple. Dissolve the room in one of the following two cases:
25 |
26 | - half of the dissolution vote.
27 | - (to vote disband - to vote against disband) over 20%.
28 |
29 | When creating a room, group manager can set free access or paid access. In the case of paid access, 10% of the user's payment belongs to group manager (5% goes directly to group manager, the remaining 5% to group manager after the group is dissolved), 50% stays in the room, and 40% goes to the Treasury.Creating a group costs LT, depending on the size of the group, and the price can be governed through the council chain.
30 |
31 | ### Ecosystem Fit
32 |
33 | No
34 |
35 | ## Team :busts_in_silhouette:
36 |
37 | ### Team members
38 | * Daniel Xie
39 | * 15
40 |
41 | ### Team Website
42 | * https://listen.io
43 |
44 | ### Legal Structure
45 |
46 | shared privately via the Google Form used for your application.
47 |
48 | ### Team's experience
49 |
50 | shared privately via the Google Form used for your application.
51 |
52 | ### Team Code Repos
53 | * https://github.com/ListenTeam
54 | * https://github.com/ListenTeam/listen
55 |
56 | ### Team LinkedIn Profiles
57 |
58 | private
59 |
60 | ## Development Roadmap :nut_and_bolt:
61 |
62 |
63 | ### Milestone 1 Example — Implement Substrate Modules
64 | * **Estimated Duration:** 6 month
65 | * **FTE:** 5-8
66 | * **Costs:** $1000
67 |
68 | | Number | Deliverable | Specification |
69 | | ------------- | ------------- | ------------- |
70 | | 0a. | License | Apache 2.0 / MIT / Unlicense |
71 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. |
72 | | 0c. | Testing Guide | The code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests |
73 | | 1. | Substrate main Chain | We use Substrate to build the economic model of Listen, and how to play group DAO. |
74 | | 2. | Listen APP | We will concentrate a lot of energy on the development of IOS-level experience APP, as a cool voice social software, will bring different from the current mainstream social software.|
75 | | 3. | Listen Apple Watch APP | Listen introduces voice social networking to smaller devices, Apple Watch and Airpods. Listen positioning will be the best social software on Apple Watch. |
76 | | 4. | Introduce the first batch of internal beta users | Test in existing communities. |
77 | | 5. | Open Beta | Public testing after launching the mainnet |
78 |
79 | ### Milestone 2 Example — Additional features
80 |
81 |
82 | ### Community engagement
83 |
84 | https://listen.io/static/listen-white-paper-1.0-en.pdf
85 |
86 | ## Future Plans
87 | Please include the team's long-term plans and intentions.
88 |
89 | ## Additional Information :heavy_plus_sign:
90 | Any additional information that you think is relevant to this application that hasn't already been included.
91 |
92 | Possible additional information to include:
93 | * What work has been done so far?
94 | * Are there are any teams who have already contributed (financially) to the project?
95 | * Have you applied for other grants so far?
96 |
--------------------------------------------------------------------------------
/grants/speculative/PolkaWorld second grant application.md:
--------------------------------------------------------------------------------
1 | **Project description**
2 |
3 |
4 |
5 | PolkaWorld is the first Chinese Community of Polkadot. We are skilled in content operations and community operations. We are a team of 3 girls（ 2 full time, a designer for part time）we both love Polkadot and CARE a lot about every user / fans in the community.
6 |
7 |
8 |
9 | The first phase of PolkaWorld has been operation for 4 months, the community is mainly focus on the education of what Polkadot / Substrate is and how it works through the articles, AMA, workshop, meetup and hosted a hackathon competition in Hangzhou with 20 development teams participated. So far, PolkaWorld has more than 10,000 fans in the community and 200 developers who has already use / learn the Substrate.
10 |
11 |
12 |
13 | The next step, PolkaWorld enters the second phase and want to apply for a second round of grant funding by Web 3 Foundation.
14 |
15 |
16 |
17 | More info about PolkaWorld, you can also check our first application of community grant.
18 |
19 | https://github.com/w3f/Web3-collaboration/pull/142/commits/1fdea9eb081de1fcc8d1569b897943a974b94599
20 |
21 | **Overview of objectives:**
22 |
23 |
24 |
25 | 1. Take Kusama and Polkadot’s launch as the main operate event.
26 |
27 | 2. On the technical perspective, we mainly to build the Substrate developer community in the second phase.
28 |
29 | 3. The content perspective is mainly around the Parachain, Parathread, and Governance section.
30 |
31 | 4. On the composition of community user, we mainly focuses on the user quality in this phase, we hope the community have more high quality fans and developers.
32 |
33 |
34 |
35 | **Objectives operation strategy**
36 |
37 |
38 |
39 | 1. Take Kusama and Polkadot’s launch as the main operate event
40 |
41 | Strategy: We will split to operate the content, community activities, meetup and the media.
42 |
43 | 2. On the technical perspective, we mainly to bulid the Substrate developer community in the second phase
44 |
45 | Strategy: Making a developer incentive plan, hold Substrate workshop every two weeks, and finally host a Substrate / Polkadot hackathon.
46 |
47 | 3. The content perspective is mainly around the Parachain, Parathread, Governance section
48 |
49 | Strategy: We will create an incentive plan to recruit excellent translators for translation, and publish 6 articles per week（a weekly report + 5 articles relate to parachain, parathread, governance）and AMA or interview with Parity / Web 3 colleagues to help Chinese community to know well about Web 3 and Polkadot in different aspects through high-quality content.
50 |
51 | 4. On the composition of community user, we mainly focuses on the user quality, we hope the community have more high quality fans and developers
52 |
53 | Strategy: Guide users to pay more attention to the in-depth discussion of technology and the design of Polkadot, not only to discuss the token price things. Organize a online topic discussion every week and summarize the results of the discussion to published on the media.
54 |
55 |
56 |
57 | **Milestones**
58 |
59 |
60 |
61 | **Milestone 1** ：**From November to Decembe**
62 |
63 | 1. Translate all content of the Polkadot wiki.
64 | 2. Produce 48 articles related to Parachain, Parathread, governance and weekly report
65 | 3. Hold an offline meetup of kusama network (meetup scale: 100 people)
66 | 4. Organize 4 workshops around the ink smart contract in 4 different cities （Beijing, Shanghai,Hangzhou, Chengdu, Xian, Qingdao, Shenzhen）The workshop scale is 20 new developers.
67 | 5. Guided by Web 3 Foundation needs, publish an online Substrate development task and recruit 20 developers to participate.
68 | 6. Interview / AMA with 8 Parity / Web 3 Foundation colleagues, and spread the interviews in China community and at least 5 top blockchain media.
69 | 7. Discuss 8 topics online with Web 3 Foundation demand as the guide, and summarize 8 articles to publish on at least 5 top blockchain media.
70 |
71 |
72 |
73 | **Milestone 2** ：**From January to February** （**Remarks: Some of the work items will be reduced during the Chinese New Year week which is from** **January 25th to January 31st**）
74 |
75 | 1. Produce 42 articles related to Parachain, Parathread, governance, and weekly report.
76 | 2. Organize 3 workshops around the ink smart contract / parachain/parathread in 3 different cities（Beijing, Shanghai,Hangzhou, Chengdu, Xian, Qingdao, Shenzhen) the workshop scale is 20 new developers (The topic also can based on the needs of Web 3 Foundation / Parity )
77 | 3. Guided by web3 needs, publish an online Substrate development task and recruit 20 developers to participate.
78 | 4. Interview / AMA with 6 Parity / Web 3 Foundation colleagues, and and spread the interviews in China community and at least 5 top blockchain media.
79 | 5. Discuss 6 topics online with Web 3 Foundation demand as the guide, and summarize 6 articles to publish on at least 5 top blockchain media.
80 |
81 |
82 |
83 | **Milestone 3** ：**From March to April**
84 |
85 | 1. Produce 48 articles related to Parachain, Parathread, governance and weekly report.
86 | 2. Hold an offline meetup of Polkadot network (meetup scale: 100 people
87 | 3. Organize 4 workshops around the ink smart contract / parachain/parathread in 4 different cities（Beijing, Shanghai,Hangzhou, Chengdu, Xian, Qingdao, Shenzhen) the workshop scale is 20 new developers (The topic also can based on the needs of Web 3 Foundation / Parity )
88 | 4. Guided by web3 needs, publish an online Substrate development task and recruit 20 developers to participate
89 | 5. Interview / AMA with 8 Parity / Web 3 Foundation colleagues, and and spread the interviews in China community and at least 5 top blockchain media.
90 | 6. Discuss 8 topics online with Web 3 Foundation demand as the guide, and summarize 8 articles to publish on at least 5 top blockchain media.
91 | 7. Guided by web3 needs, hold an offline Polkadot hackathon
92 |
--------------------------------------------------------------------------------
/grants/speculative/Rabin_DKG_Library.md:
--------------------------------------------------------------------------------
1 | # Project Name
2 | Polkadot DKG multisig Wallet part 2
3 |
4 | ## Project Description
5 | This is an application for development of a DKG multisig wallet. This project has been discussed with multiple members of the Web3 team, we have also recently finished a PSP regarding this project https://github.com/everstake/PSPs/tree/psp-dkg-multisig-wallet
6 |
7 | DKG multisig wallet will allow users to manage their funds collectively with high security level via the application with the good UX.
8 |
9 | Distributed Key Generation (DKG) is a way for a group of nodes to collectively agree on a public/private key pair without any single party knowing the private key. Everyone just knows the public key.
10 |
11 | This is actually very hard to achieve but it relies on the fact that lagrange interpolated shares are homomorphic (in that operations can be performed on shares even without knowing the full value). For example, you can add A{share1}+B{share1} to get C{share1} that you can add to someone else’s C{share2} to get the full value of C (assuming A and B were split into 2 shares each).
12 |
13 | In general, a multisig wallet which we want to develop can be divided into 3 parts: wallet APP(browser extension, desktop app, etc.), web server and DKG library in Rust.
14 |
15 | To conclude about the architecture of the wallet, we will combine different approaches and allow users to use a browser extension only or combine it with a mobile app where the phone serves as a hardware wallet only for signing transaction. Unlike other wallets in the Polkadot ecosystem we have made an accent on multisignature and DKG functionality and with our wallet the Polkadot ecosystem becomes fully equipped with all possible ways of holding tokens, sending them and generating keys. As a result it will be a multisig wallet with a very high level of security as it is fully built on the cryptography protocols.
16 |
17 | The project will be done under guidance and supervision of Jeff Brudges From Web3.
18 |
19 | ## Team members
20 | * Aleksei Korobeinikov – developer
21 | * Vadym Grozinok – developer
22 |
23 | ## Team Website
24 | * https://everstake.one & https://atticlab.net
25 |
26 | ## Legal Structure
27 | ATTIC LAB, Limited Liability Company. 89, Kazimir Malevich str., Kyiv, 03150, Ukraine
28 |
29 | ## Team's experience
30 | Everstake is an affiliate company of Attic Lab, so members from both teams are going to participate in the project. We have developed VSCode and Atom plugins for Substrate. We have also created a PSP for this project.
31 |
32 | Our prior projects and experience include: Crypto exchange Codex. Cassandra history plugin, Munin plugins, OpenBankIT open-source banking software, EOS History API running on Elasticsearch cluster, My EOS Wallet. (web and mobile), NEO IDE, Teztracker (Tezos blockchain explorer).
33 |
34 | ## Team Code Repos
35 | * https://github.com/everstake
36 | * https://github.com/atticlab
37 |
38 | ## Team LinkedIn Profiles
39 | * https://www.linkedin.com/in/vitalii-parkhomenko-493561187/
40 | * https://www.linkedin.com/in/aleksei-korobeinikov/
41 | * https://www.linkedin.com/in/pavelmidvel/
42 | * https://www.linkedin.com/in/stanislav-c-362685195/
43 | ## Development Roadmap
44 | 1. DKG library
45 | * VSS (240h)
46 | * Implement polynomial commitments with Lagrange interpolation - 72h
47 | * NewPrivPoly
48 | * RecoverSecret
49 | * NewPubPoly
50 | * Implement Dealer functionality (struct which will create shares and deals(set of data such polynomials, sessionID, threshold)) - 56h
51 | * NewDealer
52 | * EncryptDeal
53 | * SecretCommit
54 | * Implement Verifier functionality (struct which will receive deals from all the participants and verify it) - 96h
55 | * NewVerifier
56 | * ProcessEncryptedDeal
57 | * Write unit tests - 16h
58 | * DKG(320h)
59 | * Integrate with VSS functionality - 16h
60 | * Write functionality to create and process commitments of the secret polynomials - 56h
61 | * NewDistKeyGenerator
62 | * ProcessDeals
63 | * ProcessSecretCommits
64 | * Write reconstruction key functionality - 32h
65 | * GenDistKeyShare
66 | * Write unit tests - 16h
67 |
68 | ### Development team:
69 | **2 backend developers**
70 |
71 | **1 frontend developer**
72 |
73 | **Total labor-costs: 560 man-hours**
74 |
75 | **Total project length: 2.5 months**
76 |
77 |
--------------------------------------------------------------------------------
/grants/speculative/Speckle Application.md:
--------------------------------------------------------------------------------
1 | # Speckle OS
2 |
3 | ## Project Description
4 | We are building a universal user interface for Polkadot, Substrate and Web 3. This involves three parts:
5 | 1. a browser extension wallet that handles account management and dApp interactivity across Substrate chains;
6 | 2. a back-end parachain that handles identity, account management and communication; and
7 | 3. the speckle-ui framework for substrate-based chains.
8 |
9 | We are currently focusing on the browser extension 'Speckle'. We are coming to the successful end of our first grant and have delivered beyond the scope of our application. We still require a bit more support to complete the core functionality of the product before we can seek commercialisation. One such way that we hope to commercialise Speckle is through fiat-to-crypto on-boarding via the application (e.g. purchasing DOTs, EDG etc through Speckle to interact with the various networks).
10 |
11 | ## Team members
12 | This comprises the 5 team members that have completed the first grant and will be involved in the second grant (review github commits and involvement here: https://github.com/SpeckleOS/speckle-browser-extension/graphs/contributors)
13 |
14 | Antoine Najjarin (Project Manager/Founder)
15 | Antoine is the founder and project manager of Speckle OS. He has a history in business development for other Ethereum blockchain projects and has led partnerships with the United Nations World Food Programme and China’s biggest digital retailer, JD.com. Antoine, also, does most of the design and planning work for Speckle.
16 | https://www.linkedin.com/in/antoine-najjarin-904828b5
17 |
18 | Fei Yang (Senior Software Engineer and Blockchain Engineer)
19 | Fei has over 10 years’ experience as a software engineer. He was previously employed by Bitfinex to develop their Ethfinex platform, and has worked on projects on various blockchains (including Ethereum, Tron and Corda).
20 | https://www.linkedin.com/in/fyang1024
21 | https://github.com/fyang1024
22 |
23 | Tony Tao (Senior Software Engineer)
24 | Tony has over 10 years' experience as a software engineer. He has worked for various tech startups, and has experience developing applications for the Ethereum and TRON networks.
25 | https://www.linkedin.com/in/tonytao/
26 | https://github.com/ttaoS
27 |
28 | Hyungsuk Kang (Software Engineer and Blockchain Developer)
29 | Hyungsuk (Nick) Kang is an ambassador for the Web 3 Foundation and is an experienced software engineer and blockchain developer. He worked for Decentral, an Ethereum dApp consultant, and has experience building with the Ethereum tech-stack.
30 | https://www.linkedin.com/in/nick-kang-5217a7103/
31 | https://github.com/hskang9
32 |
33 | Robin Wang (Senior Software Engineer)
34 | Robin is, also, a highly experienced software engineer with over 10 years experience. He has experience working with various blockchain networks and was a core developer in completing our first grant.
35 | https://github.com/mytechtip
36 |
37 | ## Team Website
38 | * https://www.speckleos.io/
39 |
40 | ## Legal Structure
41 | LLC incorporated in Australia
42 |
43 | ## Development Roadmap
44 | Please refer to the Google Doc supplied in the form.
45 |
--------------------------------------------------------------------------------
/grants/speculative/SubstraTEE-extension-pack1.md:
--------------------------------------------------------------------------------
1 | ## SubstraTEE extension pack 1
2 |
3 | This application is (select one):
4 | - [x] Speculative (use this by default)
5 | - [ ] an RFP response
6 |
7 |
8 | ###
9 |
10 | This application is (select one):
11 | - [ ] Public (fully)
12 | - [x] Public with private finances
13 |
14 |
15 | ### Abstract
16 |
17 | SCS has developed SubstraTEE with a grant from the web3 foundation. After fulfilling that grant with the delivery of M4, SCS continued the development on its own and has reached M5, adding a private token transfer implementation that allows to instantiate a paint-balances module within an enclave. SubstraTEE has drawn the attention of the Energy Web Foundation and other industry contacts looking for confidentiality solutions for substrate or Blockchains in general. Also, synergies with other grant teams like pLibra or Advanca have been identified.
18 |
19 | On request of Parity Technologies and W3F, SCS proposes an extension to SubstraTEE that aims at approaching a production-ready MVP solution for enterprise use cases.
20 |
21 | This extension pack will add:
22 | * accessing on-chain state within an enclave state transition function (STF)
23 | * verifying inclusion proofs for extrinsics
24 | * upstream alignment with parity substrate master (PR #3778)
25 | * security audit by external entity security hardening (including known issues)
26 | * (optional) a public testnet running a demo case
27 |
28 | ## Team members
29 |
30 | * Alain Brenzikofer: @brenzi on github, Department Head, Developer
31 | * Marcel Frei: @electronix on github, Project Manager for substraTEE, Developer
32 | * Christian Langenbacher: @clang on github, Developer
33 | * Sabine Proll: @sabinep, Developer
34 | * Juraj Skripsky: @jskripsky on github, Rust-Guru, Reviewer
35 |
36 | ## Team Website
37 |
38 | * https://www.scs.ch/en/about-scs/departments/decentralized-systems/
39 |
40 | ## Legal Structure
41 |
42 | Swiss AG
43 |
44 | ## Team's experience
45 |
46 | As an engineering services company SCS AG has more than 25 years of experience in the fields of electronics, software and system design. Profound know-how, solid methodological competence as well as efficient project management are the foundation of our success.
47 |
48 | Most programming experience in the following languages: C/C++, C#, Java, Python and VHDL.
49 |
50 | Alain Brenzikofer follows Blockchain developments since 2011. He works for SCS since 2012 where he started working on blockchain projects in 2016 and was appointed to lead a new department for "decentralized systems" in summer 2018. As a private initiative, he designed a new cryptocurrency ecosystem [encointer - An Ecological, Egalitarian and Private Cryptocurrency and Self-Sovereign Identity System](https://encointer.org) . A project he currently intends to realize based on Substrate (including this privacy extension).
51 |
52 | Our team is part of the [Quartierstrom project](https://quartier-strom.ch), implementing and currently field-testing a decentralized P2P energy market in Switzerland together with ETHZ, Bosch IoT Lab, HSLU and others.
53 | SCS is in charge of the development of a dynamic grid usage-tariff smart contract as well as privacy-by-design concepts for the decentralized energy auction, thereby investigating and evaluating Zero-Knowledge Proofs, Linkable Ring Signatures, Multi-Party Computation as well as Trusted Execution Environments.
54 |
55 | Moreover, we've developed a PoC for Electric Vehicle charging process on blockchain based on Parity Ethereum: https://youtu.be/xJUKNlV79pg
56 |
57 | For trusted sensor oracles, Alain wrote a [whitepaper on decentralized trusted timestmping](https://www.scs.ch/wp-content/uploads/2017/01/trusted-sensor-whitepaper.pdf).
58 |
59 | Alain, Marcel and Christian are the core devlopers for substraTEE.
60 |
61 | A few further blockchain projects are subject to NDAs.
62 |
63 | ## Team Code Repos
64 |
65 | * https://github.com/scs/substraTEE
66 | * https://github.com/scs
67 | * https://github.com/brenzi
68 | * https://github.com/encointer
69 |
70 | ## Team LinkedIn Profiles
71 |
72 | (Not all on LinkedIn)
73 |
74 | https://www.linkedin.com/in/alain-brenzikofer-9a4480165/
75 |
76 | https://www.linkedin.com/in/christian-langenbacher-baa629182/
77 |
78 | https://www.linkedin.com/in/juraj-skripsky-4338a217/
79 |
80 | https://www.linkedin.com/in/sabine-proll-5a7118153/
81 |
82 |
--------------------------------------------------------------------------------
/grants/speculative/aPois.md:
--------------------------------------------------------------------------------
1 | # APOIS by Swisscom Blockchain
2 |
3 | ## Project Description
4 |
5 | APOIS by Swisscom Blockchain is a set of tools with the aim to easly deploy and monitor Validators with an high availabilty.
6 | The main focus of the project is a [**Kubernetes Operator**](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). The Operator will make it easy for anyone to set up their own, sophisticated Polkadot validator including a highly secured network of sentry nodes.
7 | This will help making the network as a whole more robust and less prone to attacks on individuals, thus increasing its trustworthiness.
8 |
9 | ## Team Members:
10 |
11 | Jan Bernegger (Lead, DevOps)
12 | Alessio Onori (DevOps)
13 | Jorge Alvarado (Project Manager)
14 | Milos Costantini (Software Developer)
15 |
16 | ## Company Website
17 |
18 | - https://www.blockchain.swisscom.com/
19 |
20 | ## Linkedin Profiles:
21 |
22 | https://ch.linkedin.com/in/jan-bernegger
23 | https://www.linkedin.com/in/alessioonori/
24 | https://ch.linkedin.com/in/alvaradojl
25 | https://www.linkedin.com/in/miloscostantini/
26 |
27 | ## Legal Structure
28 |
29 | Provided in the Google Form.
30 |
31 | ## Team's experience
32 |
33 | - Swisscom Blockchain is a team of software, cryptocurrency & business experts focused on the blockchain ecosystem.
34 | - We built a python wrapper of the Rust Indy SDK.
35 | - For the NEO Fundation we built Seraph ID, a set of tools that can be used by dApps developers and users to leverage Self-Sovereign identity capabilities. It relies on the W3C standards providing DID and verifiable claims functionalities. The set of tools comprehend a C# Smart Contract an SDK and a chrome extention wallet with dapp communication.
36 | - We audited part of the Energy Web Foundation codebase (Work done together with Chainsecurity, who audited the Solidity Smart Contracts)
37 | - Strong DevOps and Node deployment experience gained building our DAPPI Product (Node Hosting and gateway)
38 | - Experience in Solidity gained building a Smart Contract Factory to easly deploy and manage open zeppelin contracts using
39 | the proxy pattern.
40 |
41 | ## Company Code Repository
42 |
43 | https://github.com/swisscom-blockchain
44 |
45 | ## Specification
46 |
47 | ### Kubernetes Operator for Validator deployment
48 |
49 | A Kubernetes Operator is a pattern that allows complex application deployments through configuration of the desired state using a Kubernetes Custom Resource Definition (CRD).
50 | The resulting Operator will be able to do the following tasks:
51 |
52 | 1. Deploy the operator with one command on a Kubernetes cluster
53 | 2. Use Custom Resource Definitions (CRD) to describe a valid validator sentry deployment on a Kubernetes cluster
54 | 3. Secure the communication between the sentry nodes themselves and the validator
55 | 4. The possibility to provision a validator node as well within Kubernetes in the deployed secure environment
56 | 5. Expose all required ports and endpoints of the nodes for cluster monitoring using Prometheus
57 | 6. Possibility to connect the node network to another one setup on a different cluster through the operator (also supporting other cloud providers)
58 |
59 | The Operator will make it easy for anyone to set up their own, sophisticated Polkadot validator including a highly secured network of sentry nodes.
60 | This will help making the network as a whole more robust and less prone to attacks on individuals, thus increasing its trustworthiness.
61 |
62 | ## Operator Development Roadmap
63 |
64 | ### Milestones
65 |
66 | * **Milestone 1 - Operator Setup**:
67 | * Create Go based operator structure
68 | * Define CRD spec for validator sentry nodes
69 | * Define CRD spec for validator node
70 | * Deployment of CRD through Kubernetes native resources
71 | * Connection between sentry nodes and validator
72 | * Basic documentation
73 |
74 | * **Milestone 2 - Operator Functions**:
75 | * Data persistence support
76 | * Node cluster scaling support
77 | * Updating of node versions
78 | * Secure communications
79 | * Documentation for the points above
80 |
81 | * **Milestone 3 - Validation and Measurement**
82 | * Testing and refactoring
83 | * Metrics support using Prometheus
84 | * Support different methods of exposing node endpoints
85 | * Interconnecting node networks
86 | * Finalize documentation
87 |
88 | ## Longer-Term
89 |
90 | We are very interested in POS blockchains and Polkadot appears as one of the more promising and interesting from a technological point of view. We are facinated by the
91 | decentralized bft/nakamoto consensus algorithms that use Proof of Stake; our long-term vision is to build a strong experience on all of these networks and integrate them in our Swisscom Blockchain DAPPI service.
92 |
93 | ## Additional Information
94 |
95 | - ## What work has been done so far?
96 | - Are there are any teams who have already contributed (financially) to the project?
97 | - No
98 | - Have you applied for other grants so far?
99 | - No
100 | - Are there any other projects similar to yours? If so, how is your project different?
101 | - No
102 |
103 |
--------------------------------------------------------------------------------
/grants/speculative/cpp_api.md:
--------------------------------------------------------------------------------
1 | # Polkadot Substrate C++ API
2 |
3 | ## Project Description
4 |
5 |
6 | ### Brief Description
7 | Polkadot integration C++ API for Substrate allows to read chain information and state, block details, as well as sign and publish transactions in C++. It also allows to subscribe to substrate node websocket endpoints and receive data updates.
8 |
9 | POC is available here: https://github.com/usetech-llc/polkadot_api_cpp
10 |
11 | ### Why C++ API is Good for the Ecosystem
12 | While high quality well documented APIs help community integrate with products in general, C++ API will be especially helpful for financial sector as well as gaming industry. Financial companies are looking more and more towards crypto markets, and gaming assets become tokenized in the form of miscellaneous types of tokens, frequently cross-chain. Because of their high performance requirements, both industries historically accumulated large code bases in C++, so this API aims to greatly facilitate adoption of Polkadot for them.
13 |
14 | ### How C++ API Integrates into Substrate
15 | Substrate provides secure WebSocket endpoints, which are used directly by C++ API.
16 |
17 | ### Why our Team is Interested
18 | We see Polkadot as a very promissing technology that will be used for a large number of use cases. It will greatly contribute to adoption of blockchain in powerful applications. It is technically one of the most ambitious blockchain projects we know of, and we would like to be part of the community that's creating it, as well as developing on it once the network goes live. This proposal is just the first step in creating what we hope will be a large Polkadot team.
19 |
20 | ## Team members
21 | * Alexander Mitrovich
22 | * Greg Zaytsev
23 |
24 | ## Team Website
25 | * http://usetech.com/blockchain.html
26 |
27 | ## Legal Structure
28 | These details will be shared privately via our Google Form.
29 |
30 | ## Team's experience
31 | Our team memebers each have more then 15 years of IT experience in managing projects and writing software for product companies and large enterprises alike. We created the Blockchain practice in 2016 and have done dozens of projects for clients accross the globe on variety of blochchains, mostly on Ethereum.
32 |
33 | ## Team Code Repos
34 | * https://github.com/gregzaitsev/platform-contracts
35 | * https://github.com/gregzaitsev/wasmcharts_page
36 | * https://github.com/gregzaitsev/platform-frontend
37 | * https://github.com/usetech-llc/unicom
38 | * https://github.com/usetech-llc/votingrelay
39 | * https://github.com/usetech-llc/forever_coin
40 | * https://github.com/usetech-llc/taklimakan-network
41 |
42 | ## Team LinkedIn Profiles
43 | * https://www.linkedin.com/in/alexandermitrovich/
44 | * https://www.linkedin.com/comm/in/gregory-zaitsev-95ba633
45 |
46 |
47 | ## Development Roadmap
48 | Project roadmap and financial plan will be shared privately via Google Form.
49 |
50 | Long term plans start with developing APIs for all mainstream languages as well as in-depth API improvement. As Polkadot community high level usecases evolve, API will adapt.
51 |
52 | Also, our team plans to implement broader spectrum of applications such as
53 | * Decentralized Non-Fungible Token Exchange
54 | * Multi-chain token issuance
55 | * Cross-chain Payment Gateways
56 | * etc.
57 |
58 | ## Additional Information
59 |
60 | ### What work has been done so far?
61 | Proof of concept C++ API has been done, which successfully establishes connection to a public substrate node and retrieves a JSON string for method chain_getRuntimeVersion. Source code and preliminary documentation is available at this public repository:
62 | https://github.com/usetech-llc/polkadot_api_cpp
63 |
64 | ### Are there any other projects similar to yours? How is our project different?
65 | So far there has only been JavaScript API project: https://polkadot.js.org/api/
66 |
67 | Other mainstream languages are not yet covered. Our plan is to start with C++ and cover all mainstream languages/stacks such as Python, C#, Java, etc. We believe that having a wide coverage will greatly improve adoption of Polkadot among the software developers.
68 |
--------------------------------------------------------------------------------
/grants/speculative/crawler.md:
--------------------------------------------------------------------------------
1 | # Polkadot Network Crawler
2 |
3 | ## Project Description
4 |
5 | Build a standalone Polkadot network crawler to scan currently available nodes and saving details in external storage for further analysis or visualization.
6 |
7 | The crawler is going to implement a subset of Polkadot p2p protocol to connect to nodes it can find and gather any additional information that can be fetched by requesting a connected node. I.e., current height, blocks, genesis, node software, IP address, and so forth. Gathered details a supposed to be stored in a database (for example, MySQL), and can be accessed by a 3rd party software for analysis.
8 |
9 | ## Team Experience
10 |
11 | Igor Artamonov, lead developer. He has a master's degree in Computer Science, is a professional software developer since 2001, has been writing code since 1995. The main focus of his work has been on scalable, decentralized, distributed, and fault-tolerant applications; on projects storing and processing big data; on user authentication and security.
12 |
13 | For the past few years, he got involved in blockchain space. From 2016 through the end of 2018, he was leading the development of Ethereum Classic blockchain. He was also working on a Block Explorer, integration libraries for Ethereum, and Emerald project. He is knowledgeable of tech aspects of blockchain implementations, APIs, and usage scenarios of blockchain.
14 |
15 | He is currently working on a decentralized infrastructure for cryptocurrency transactions, and part of this work is a node crawler for Ethereum compatible networks. Some of the data is currently published one Emerald Insights website, in relation to Ethereum Istanbul upgrade progress.
16 |
17 | Links:
18 |
19 | - https://www.linkedin.com/in/igorartamonov/
20 | - https://medium.com/splix/measuring-ethereum-nodes-530bfff08e9c
21 | - https://insights.emeraldpay.io/status/ethereum-istanbul
22 |
23 | ## Legal Structure
24 |
25 | Swiss GmbH
26 |
27 | ## Development Roadmap
28 |
29 | ### Strategy and Technology
30 |
31 | The current crawler, which is designed specifically for the Ethereum and Bitcoin networks, is a closed source. However, the current proposal offers the creation of an entirely new Open Source crawler based on the experience learned from that closed source crawler.
32 |
33 | It's going to be based on JVM and the following technologies:
34 |
35 | - Kotlin
36 | - Spring Framework
37 | - Project Reactor
38 | - Other related libraries, such as io.web3j:libp2p
39 |
40 | The strategy is to create a daemon that implements a subset of the P2P protocol to discover and connect to each node one by one to learn their details.
41 |
42 | In general, there're two major components:
43 |
44 | - Nodes discovery - passive and active discovery of the network participants, by registering on a rendezvous point and query for other peers
45 | - Connect to a node and execute series commands to learn details about the node. The commands are specifically requesting info about the software, current status, genesis, etc.
46 |
47 | The result of such processing streamed to a log file in a JSON format and/or to a SQL database for further processing by an external application.
48 |
49 | ### Crawler Daemon MVP - 4 weeks
50 |
51 | Implement a basic crawler and p2p protocol. The crawler should be launchable from a command line and/or as a Docker image. As a result of the work, it is going to produce a log of found nodes to stdout.
52 |
53 | ### Gather nodes details - 4 weeks
54 |
55 | The main goal of this phase would be the stabilization of the architecture and the process of discovery and nodes processing.
56 |
57 | As a result, the crawler will be able to execute additional commands, such as block details, to gather additional information about the current state of the blockchain on a remote node. Results are going to be streamed to a file in JSON format.
58 |
59 | ### Storage - 4 weeks
60 |
61 | The crawler can store found nodes into:
62 |
63 | - MySQL database
64 | - AWS S3 Storage
65 | - GCP Storage
66 |
--------------------------------------------------------------------------------
/grants/speculative/dotnet_api.md:
--------------------------------------------------------------------------------
1 | # Polkadot Substrate .NET API
2 |
3 | ## Project Description
4 |
5 | ### Brief Description
6 |
7 | Polkadot integration .NET API for Substrate allows to read chain information and state, block details, as well as sign and publish transactions in C# or other .NET languages. It also allows to subscribe to substrate node websocket endpoints and receive data updates.
8 |
9 | Prior API implementation is done in C++ by our team and it is available here: https://github.com/usetech-llc/polkadot_api_cpp
10 |
11 | ### Why .NET API is Good for the Ecosystem
12 |
13 | Well documented and maturely designed .NET API will attract great number of Microsoft developers from all over the world to Polkadot Blockchain. .NET Core, which is also included in the development plan, is the borderline between open source community and enterprise applications. Applications created with .NET Core API will be easily portable to larger enterprise solutions.
14 |
15 | ### How .NET API Integrates into Substrate
16 |
17 | Substrate provides secure WebSocket endpoints, which are used directly by .NET API.
18 |
19 | ### Why our Team is Interested
20 |
21 | We see Polkadot as a very promissing technology that will be used for a large number of use cases. It will greatly contribute to adoption of blockchain in powerful applications. It is technically one of the most ambitious blockchain projects we know of, and we would like to be part of the community that's creating it, as well as developing on it once the network goes live. This proposal is the second step after creating C++ API in creating what we hope will be a large Polkadot team. We also have a great team experience in Microsoft technologies.
22 |
23 | ## Team members
24 | * Alexander Mitrovich
25 | * Greg Zaytsev
26 | * Maksim Styrgin
27 |
28 | ## Team Website
29 | * http://usetech.com/blockchain.html
30 |
31 | ## Legal Structure
32 | These details will be shared privately via our Google Form.
33 |
34 | ## Team's experience
35 | Our team members each have more then 15 years of IT experience in managing projects and writing software for product companies and large enterprises alike. We created the Blockchain practice in 2016 and have done dozens of projects for clients across the globe on variety of blochchains, mostly on Ethereum.
36 |
37 | ## Team Code Repos
38 | * https://github.com/usetech-llc/polkadot_api_cpp
39 | * https://github.com/usetech-llc/multichain_airdrop
40 | * https://github.com/usetech-llc/neupool
41 | * https://github.com/gregzaitsev/platform-contracts
42 | * https://github.com/gregzaitsev/wasmcharts_page
43 | * https://github.com/gregzaitsev/platform-frontend
44 | * https://github.com/usetech-llc/unicom
45 | * https://github.com/usetech-llc/votingrelay
46 | * https://github.com/usetech-llc/forever_coin
47 | * https://github.com/usetech-llc/taklimakan-network
48 |
49 | ## Team LinkedIn Profiles
50 | * https://www.linkedin.com/in/alexandermitrovich/
51 | * https://www.linkedin.com/comm/in/gregory-zaitsev-95ba633
52 |
53 | ## Development Roadmap
54 | Project roadmap and financial plan will be shared privately via Google Form.
55 |
56 | Long term plans start with developing APIs for all mainstream languages as well as in-depth API improvement. As Polkadot community high level usecases evolve, API will adapt.
57 |
58 | Also, our team plans to implement broader spectrum of applications such as
59 |
60 | * Decentralized Non-Fungible Token Exchange
61 | * Multi-chain token issuance
62 | * Cross-chain Payment Gateways
63 | * etc.
64 |
65 | ## Additional Information
66 |
67 | ### What work has been done so far?
68 |
69 | C++ API is delivered. Source code and documentation are available at this public repository: https://github.com/usetech-llc/polkadot_api_cpp
70 |
71 | ### Are there any other projects similar to yours? How is our project different?
72 |
73 | So far there has only been JavaScript API project: https://polkadot.js.org/api/
74 |
75 | Other mainstream languages are not yet covered. After C++ API (completed), the next step is to cover C# and then other mainstream languages/stacks such as Python, Java, etc. We believe that having a wide coverage will greatly improve adoption of Polkadot among the software developers.
76 |
--------------------------------------------------------------------------------
/grants/speculative/enterprise_api.md:
--------------------------------------------------------------------------------
1 | # Enterprise Polkadot API
2 |
3 | ## Project Description
4 | We propose to add uniformity across Substrate APIs and to utilize well known interfaces called Database Abstraction Layers (DBAL or DAL).
5 |
6 | In addition, in the scope of this proposal are the robust, Enterprise-level Indexer and a Consensus Ensurer, which will greatly improve security and reliability of applications that work with Polkadot.
7 |
8 | ### Why Enterprise API is Good for the Ecosystem
9 | It will allow any Enterprise-level potential Polkadot user with widely used Frameworks such as Entity or Hibernate to set up a pilot of Polkadot in a few days, rather than weeks or months. They will be able to connect multipe applications quickly and easily. Indexer and Consensus Ensurer will add unique capabilities. Combined, these features will make Polkadot stand out in meeting the needs of Enterprise users.
10 |
11 | ### How Enterprise API Integrates into Substrate
12 | Details are provided in the linked document
13 |
14 | ### Why our Team is Interested
15 | After building C++ and C# APIs for Polkadot, we see this addition as an opportunity to provide a solution to a target market that will naturally fit into Polkadot's vision and make it uniquely strong among public blockchains. We will be looking forward to supporting this segment with Integration and other pilot projects.
16 |
17 | ## Team members
18 | * Alexander Mitrovich
19 | * Greg Zaytsev
20 | * Maxim Strygin
21 | * Valentina Predtechenskaya
22 |
23 | ## Team Website
24 | * http://usetech.com/blockchain.html
25 |
26 | ## Legal Structure
27 | These details will be shared privately via our Google Form.
28 |
29 | ## Team's experience
30 | Our team memebers each have more then 15 years of IT experience in managing projects and writing software for product companies and large enterprises alike. We created the Blockchain practice in 2016 and have done dozens of projects for clients accross the globe on variety of blochchains, including 2 projects on Polkadot.
31 |
32 | ## Team Code Repos
33 | * https://github.com/usetech-llc?tab=repositories
34 |
35 | ## Team LinkedIn Profiles
36 | * https://www.linkedin.com/in/alexandermitrovich/
37 | * https://www.linkedin.com/comm/in/gregory-zaitsev-95ba633
38 | * https://www.linkedin.com/in/валентина-предтеченская-37bb4b77/
39 |
40 | ## Development Roadmap
41 | Project roadmap and financial plan will be shared privately via Google Form.
42 |
43 | Long term plans start with developing APIs for all mainstream languages as well as in-depth API improvement. As Polkadot community high level usecases evolve, APIs will adapt.
44 |
45 |
46 | ## Additional Information
47 |
48 | ### What work has been done so far?
49 | Research, Architecture and Design are completed (see Development Roadmap). We started working on the static methods for C# and on high level API methods.
50 |
51 | ### Are there any other projects similar to yours? How is our project different?
52 | This project builds upon all API projects performed so far (JavaScript, C++, etc.) and takes them to the next level.
53 |
--------------------------------------------------------------------------------
/grants/speculative/ink-remix-plugin.md:
--------------------------------------------------------------------------------
1 | # ink! Remix Plugin
2 |
3 | ## Project Description
4 | Implementing fully-fledged IDE with React frontend inside Remix (as a remix plugin) and backend (Node.js) with websocket connection between the two.
5 |
6 | The backend will then connect to multiple instances of ink! CLI running on multiple hosts all managed by Kubernetes.
7 |
8 | The whole backend and CLI part would be built on kubernetes with autoscaling as the most performance consuming part are ink! CLI’s themselves. Both backend and ink! CLI will be dockerized.
9 |
10 | Standard REST API requests can’t be used here as timeout would often happen on long build times and that is not a feasible solution. Usage of websockets solves this problem.
11 |
12 | Further on deploy command to multiple networks would be built at the top when ink! team implements this inside CLI.
13 |
14 | ## Team members
15 | * Edi Sinovčić
16 | * Darko Mačešić
17 |
18 | ## Team Website
19 | * https://blockchain-it.hr/
20 |
21 | ## Legal Structure
22 | Company in Republic of Croatia
23 |
24 | ## Team's experience
25 | * Edi is a blockchain architect and technical writer working on multiple projects in the blockchain space with previous experience working for both RChain and Ethereum. Similar tool that he has built is https://rchain.cloud/ where he learned a lot about scalling solutions like this and UX. Also a DevOps guy that is fascinated by power of modern tools like Kubernetes. (https://github.com/edisinovcic)
26 | * Darko is a senior full-stack developer specialized in Spring, Node.js and React development with extensive knowledge of linux systems. (https://github.com/dark64)
27 |
28 | Companies Github: https://github.com/blockchain-it-hr
29 |
30 | We've also previously built ZoKrates as a Remix plugin (zkSNARKs on Ethererum) that is wasm based and it runs all inside React plugin and rchain.cloud which is a IDE built on the same principle as our proposition.
31 |
32 | ## Team Code Repos
33 | * https://github.com/blockchain-it-hr/ink-remix-plugin
34 |
35 | ## Team LinkedIn Profiles
36 | * https://www.linkedin.com/in/edi-sinovcic/
37 | * https://www.linkedin.com/in/darko-macesic/
38 |
39 | ## Development Roadmap
40 |
41 | Milestone 1: Building base Remix plugin and backend separately (4 weeks)
42 |
43 | * Building base React project as a Remix plugin
44 | * Compile button to compile code (in the future deploy button will also be added as other commands become available inside CLI)
45 | * Building Node.js backend with websockets connection to frontend
46 | * Building docker containers for frontend, backend and ink! CLI
47 | * Setting up CI using GitHub actions
48 | * Deploying on development environment on develop.ink-remix.blockchain-it.hr
49 |
50 | Milestone 2: (4 weeks)
51 |
52 | * CD part of the CI/CD pipeline with Kubernetes template for backend and CLI
53 | * Running testnet on development, staging and later production environments (testnets can be restarted periodically)
54 | * On frontend Download button for .wasm and ABI will be added
55 | * Stress testing CLI and backend on a staging server
56 | * Setting up staging environment staging.ink-remix.blockchain-it.hr
57 | * Adding tests for backend
58 | * Adding tests for frontend
59 | * Showing error output to the user on the frontend
60 |
61 | Milestone 3: (3 weeks)
62 |
63 | * Writing documentation for the frontend, backend, and kubernetes part
64 | * Creating a production environment and geo-distributing Kubernetes nodes so it’s a more resilient environment and stress testing it
65 |
66 | Future plans:
67 | In the future version control and using local compiler (that runs on host machine) will be available. Also standalone option for the plugin as fully-fledged IDE is an option.
68 |
69 | ## Additional Information.
70 |
71 | ### Are there are any teams who have already contributed (financially) to the project?
72 | Currently we are looking for other means of financing the project as well.
73 |
74 | ### Have you applied for other grants so far?
75 | No
76 |
77 | ### Are there any other projects similar to yours?
78 | Polkadot-js - https://github.com/polkadot-js/apps
79 | Remix - https://remix.ethereum.org/
80 |
81 | ## How is your project different?
82 | * We are integrating with the most used IDE in the Ethereum ecosystem and would gain a lot by using well knows ecosystem most Ethereum developers know with no need to transfer to something new and by that gain tracktion and usage of this tool by that.
83 |
--------------------------------------------------------------------------------
/grants/speculative/ink_playground.md:
--------------------------------------------------------------------------------
1 | # ink! playground
2 |
3 | ## Project Description
4 |
5 | ink! playground is the browser IDE for Substrate's smart contract(srml-contract). This will be similar to [Remix](https://github.com/ethereum/remix), the smart contract IDE of Ethereum.
6 | Currently, if developers want to run ink! smart contract, they have to install substrate and ink into local environment. But this takes many steps, and also it is not easy to run stably because of version compatibility issues or so.
7 | By using ink! playground, Substrate developers can test contracts easily just by writing main code ("lib.rs") on browser.
8 | It doesn't require installing Substrate or running Substrate node. This is very useful for Substrate smart contract developers.
9 | For the future works, ink! playground also provides high level security audits. This is for developer who wants to make high secured smart contracts like for enterprise use.
10 |
11 | Overview of the technical specification idea is as follows:
12 | * We put ink! compiler and abi generator on AWS EC2. User send ink! code to server, and then get compiled wasm code and abi.
13 | * We implement test environment for wasm(compiled from ink!) on frontend using javascript. User can test deploying and running wasm code without running substrate node. (instead of this spec, test environment might be run on server)
14 |
15 | ## Team members
16 | * Task Ohmori
17 | * Takumi Yamashita
18 | * Sota Watanabe
19 |
20 | ## Team Website
21 | * https://stake.co.jp
22 |
23 | ## Legal Structure
24 | Incorporated in Japan
25 |
26 | ## Team's experience
27 | Stake Technologies is a blockchain company which aims to build digital economy where everyone belongs.
28 |
29 | * Task is the lead engineer of the company. He was the silver medalist in International Physics Olympiad 2012|2013. He is now a researcher of acoustic engineering at the University of Tokyo.
30 |
31 | * Takumi is the CTO of the company. He was the world finalist of the ACM-ICPC International Collegiate Programming Contest 2016|2017 and he was selected one of the 21 best U25 engineers by an NPO which is supported by Japanese Government in 2018. In 2018, he has made his own blockchain platform called [Proskenion](https://proskenion.github.io/).
32 |
33 | * Sota is the CEO of the company. He also is a Polkadot ambassador in Tokyo. As an ambassador, he is hosting Polkadot and Substrate meetups at least once in a month and making Japanese document for developers. (e.g. Substrate Tutorials and [Polkadot whitepaper Japanese edition](https://github.com/stakedtechnologies/PolkadotWP)) In addition to that, he is a blockchain researcher at the University of Tokyo. He became the researcher at the age of 23, the youngest record. He used to work at Chronicled, a San Francisco based blockchain company which uses blockchain for supply chains.
34 |
35 |
36 | ## Team Code Repos
37 | * https://github.com/stakedtechnologies/ink-playground
38 |
39 | ## Team LinkedIn Profiles
40 | * https://www.linkedin.com/in/task-ohmori-604398176/
41 | * https://www.linkedin.com/in/sota-watanabe-b962b3110/
42 | ## Development Roadmap
43 |
44 | Each milestones represent the feature goals of ink! playground. These also includes UI goals.
45 |
46 | - M1: Compike ink! into wasm on AWS stably (3 weeks).
47 | - M2: Run wasm on test environment (3 weeks).
48 | - M3: Choose version of ink! compiler (1 weeks).
49 | - M4: Enable to deploy to the Testnet of Substrate (2 weeks).
50 |
51 | ## Additional Information.
52 |
53 | ### Are there are any teams who have already contributed (financially) to the project?
54 | We have accepted seed financing from a Japanese VC.
55 |
56 | ### Have you applied for other grants so far?
57 | Yes:
58 | * [Plasm](https://github.com/stakedtechnologies/Plasm)
59 |
60 | ### Are there any other projects similar to yours?
61 | [Remix](https://github.com/ethereum/remix)
62 | [Polkadot-js](https://github.com/polkadot-js/apps)
63 |
64 | ## How is your project different?
65 | * Remix is a browser IDE for Solidity, the smart contract of Ethereum. This is very useful for solidity developers who want to test contract easily. But, there is still no such useful browser IDE for Substrate contract, so we are making ink! playground which is useful for substrate developers who want to test ink! contracts.
66 | As a technical talk, remix compile solidity using javascript. But ink! playground compike ink! into wasm using original ink projects (https://github.com/paritytech/ink).
67 |
68 | * Polkadot-js is a UI for operating substrate node or contract.
69 | Polkadot-js itself doesn't compile the ink! code into wasm, but just uses already compiled wasm code and run that code on substrate node.
70 | On the other hand, ink! playground is going to compile ink! into wasm (on AWS server). Also, we implement test environment for running wasm (without running Substrate node).
71 |
--------------------------------------------------------------------------------
/grants/speculative/litentry.md:
--------------------------------------------------------------------------------
1 | # Litentry
2 |
3 | ## Project Description
4 | Polkadot Runtime Modules and corresponding UIs: Identity
5 |
6 | Litentry is a second layer protocol and infrastructure based on Substrate. It focuses on Identity of person and IoT devices, and the authorization and permissions granted by the Person or IoT devices.
7 | Details please see [our blog](https://www.litentry.com/post/litentry-introduction) and [the pitch presentation](https://drive.google.com/file/d/1-mesEZV5eoRW_dP3MZwbZPUaqNPtMoxd/view?usp=sharing)
8 |
9 | It mainly includes three parts:
10 |
11 | 1. Identity runtime module
12 |
13 | 2. API server
14 |
15 | 3. Identity management application
16 |
17 | We are interested into the project since we find the crosschain function provided by Substrate is extremly powerful, thus we do not need to create a centralized server to relay the informations to different application-specific blockchain.
18 |
19 | ## Team members
20 | Currently one full-time developer works on that.
21 |
22 | * Hanwen Cheng
23 |
24 | We have a few developer, I could offer their information in private.
25 |
26 | After we have grant, we will transfer one more part-time developer into full-time.
27 |
28 | ## Team Website
29 | * https://www.litentry.com/
30 |
31 | ## Legal Structure
32 | Blockweise Ltd.
33 |
34 | ## Team's experience
35 | 1. [Jingtum Blockchain](https://github.com/jingtum) consensus layer, REST API, Javascript SDK.
36 | 2. [Genesis Space](https://github.com/hanwencheng/GenesisMobile) - Ethereum based self-regulated mobile application.
37 | 3. Longhash Berlin Hackathon 2018 Everitoken challenge winner.
38 | 4. Longhash Berlin Hackathon 2019 MXC challenge winner.
39 |
40 | ## Team Code Repos
41 | * https://github.com/litentry/lintentry-runtime
42 | * https://github.com/litentry/litentry-mobile-app
43 | * https://github.com/litentry/litentry-api
44 | * https://github.com/litentry/litentry-web-app
45 |
46 | ## Team LinkedIn Profiles
47 | * https://www.linkedin.com/in/hanwen-cheng-3bb928a7/
48 | * https://www.linkedin.com/in/risheng-xu-7bb39339/
49 |
50 | ## Development Roadmap
51 |
52 | Financial information is sent by the Google form.
53 |
54 | RoadMap could also be seen [here](https://www.litentry.com/post/litentry-roadmap-july-september-2019)
55 |
56 |
57 | ## Additional Information
58 |
59 | * What work has been done so far?
60 | In our github repository, we have implemented:
61 | 1. The protocol of the Substrate Runtime Module.
62 | 2. The graphQL server bootstrap.
63 | 3. Mobile application bootstrap with cold wallet already integrated.
64 |
65 | * Are there are any teams who have already contributed (financially) to the project?
66 | No.
67 |
68 | * Have you applied for other grants so far?
69 | No.
70 |
71 | * Are there any other projects similar to yours?
72 | Not familiar.
73 |
74 | As Jingtum's European project director last year I was in Europe to promote the blockchain solution on access control, that's also why we came up with this idea, check our [previous work](https://www.litentry.com/post/oss-meeting)
75 | An access control parachain example could be find [here](https://video.wixstatic.com/video/760d3a_fd3919e6e8944f5d8684b7224f84675b/1080p/mp4/file.mp4)
76 |
--------------------------------------------------------------------------------
/grants/speculative/lunie.md:
--------------------------------------------------------------------------------
1 | # Lunie + Kusama + Polkadot = 😍
2 |
3 | ## A brief description of the project.
4 | Lunie is one of the top staking and governance platforms for proof of stake blockchains. We'd like to add support for Kusama and Polkadot to our iOS, Android, and web applications. Support would include integration with the [Ledger Nano app](https://github.com/ZondaX/ledger-polkadot) and our [Lunie browser extension](https://chrome.google.com/webstore/detail/lunie-browser-extension/hbaijkfbhhdhhjdfbpdafkjimohblhgf) — as well as support for key management, portfolio management, and staking. We'd also like to include guides for how these things work inside the Lunie apps.
5 |
6 | From the "Areas of Interest" list:
7 | - ✅ Wallets (including Metamask-like wallets)
8 | - ✅ Mobile integration
9 | - ✅ Hardware wallet integration
10 | - ✅ Guides
11 |
12 | ## An indication of why this project is good for the ecosystem.
13 |
14 | Participating in the staking economy can be complex and overwhelming. Lunie can help by providing a modern user experience and easy-to-use products that Kusama / Polkadot users will love. Our mobile apps, web wallet, and browser extension make it extremely simple to send and receive tokens, build a staking portfolio, interact with the network, and monitor performance over time.
15 |
16 | Having support for Kusama and Polkadot in Lunie will make them more accessible, understandable, and more delightful to engage with. Cosmos token holders and validators love Lunie — and we think Polka-folks will too. 😇
17 |
18 | ## An indication of how you will integrate this project into Substrate / Polkadot.
19 |
20 | Lunie is an extensible staking platform. The integration will involve setting up the node infrastructure, writing API mappers for the Lunie API, integrating Polkadot in our test suites, and building UI for key management, and staking into mobile, the Lunie browser extension, and Lunie.io.
21 |
22 | - 💻 Adding extension support to the Lunie browser extension
23 | - 👋 Browser extension support for existing extensions
24 | - 🔑 Kusama / Polkadot key management and staking on iOS and Android
25 | - 📱 Ledger Nano support for web and mobile (Nano X)
26 | - 📚 Integrated Guides for key management and staking
27 |
28 | ## An indication of why your team is interested in creating this project.
29 |
30 | Polkadot is one of the most promising new blockchain platforms. We are passionate about providing world class experiences for staking communities around the world and are confident that a Lunie x Polkadot integation would be extremely well-received and impactful. We're excited to dive deep into Polka-land and help in any way we can.
31 |
32 | ## Team members
33 | * Jordan Bibla
34 | * Fabian Weber
35 |
36 | ## Team Website
37 | * https://lunie.io
38 |
39 | ## Legal Structure
40 | * Lunie International Software Systems Inc.
41 |
42 | ## Team's experience
43 | Jordan and Fabian helped launch the Cosmos Network as employees of Tendermint Inc. They have spent the last two years building, researching, and designing proof of stake experiences together.
44 |
45 | Jordan has been working on production software systems for the last six years in a number of product and leadership roles. He is an experienced product manager, product designer, and front end developer.
46 |
47 | Fabian has been building production software systems for the last seven years in a number of engineering and leadership roles. He is an experienced software engineer, team lead, and engineering manager. Fabian was instrumental in battle testing the Cosmos SDK and the core Cosmos APIs before mainnet launch.
48 |
49 | ## Team Code Repos
50 | * https://github.com/luniehq
51 | * https://github.com/luniehq/lunie
52 |
53 | ## Team LinkedIn Profiles
54 | * https://www.linkedin.com/in/jbibla
55 | * https://www.linkedin.com/in/fabian-weber-04100a37
56 |
57 | ## Development Roadmap
58 | **Milestone 1 - Staking - 1 Month**
59 |
60 | * View validator list in Lunie web, iOS, and Android
61 | * View nominator list in Lunie web, iOS, and Android
62 | * View staking rewards in Lunie web, iOS, and Android
63 | * View staking portfolio based on Polkadot address
64 | * Learn about NPoS with guide in Lunie web, iOS, and Android
65 |
66 | **Milestone 2 - Mobile Accounts and Staking - 1 month**
67 |
68 | * Create an address in Lunie iOS and Android
69 | * Recover an address in Lunie iOS and Android
70 | * Stake tokens in Lunie iOS and Android
71 | * Send tokens in Lunie iOS and Android
72 | * Learn about key management with guide in Lunie iOS and Android
73 |
74 | **Milestone 3 - Ledger Nano and Extensions - 1 month**
75 |
76 | * Sign transactions with Ledger Nano S/X on Lunie web
77 | * Sign transactions with Ledger Nano X with Lunie iOS and Android
78 | * Sign transactions with browser extension on Lunie web
79 | * Learn about key management with guide in Lunie web
80 |
81 | _Apache 2.0 is our preferred license._
82 |
83 | ## The team's long-term plans and intentions
84 | Long term, we will continue to support other staking and decentralized communities. After these three milestones we would love to add support for governance, push notifications, accounting tools, and many other key features that will benefit the Polkadot community.
85 |
--------------------------------------------------------------------------------
/grants/speculative/messaging.md:
--------------------------------------------------------------------------------
1 | # HOPR
2 |
3 | ## Project Description
4 | This grant application supports the development of a decentralized and privacy-preserving messaging protocol called HOPR. Within the framework of this grant application we will provide an implementation of the payment layer of HOPR in Substrate. Validity Labs recently started developing HOPR as a privacy-preserving and incentivized messaging protocol which provides:
5 | * metadata-privacy (and not just end-to-end encryption) via Chaumian onion encryption
6 | * incentives for relayers that get paid by the sender of a message or third parties (similar to meta-transactions currently discussed for other blockchains) instead of just relying on services by altruistic parties (e.g. as required for TOR)
7 | * efficient implementations without proof-of-work or SNARKs that would hinder adoption on embedded or mobile devices
8 | * a scalable network architecture (in contrast to snowball-messaging, e.g. Whisper)
9 | * a payment layer that is currently being implemented for Ethereum. Here we aim to provice a more efficient implementation of the payment layer with Substrate / Polkadot
10 | * a messaging layer that is building upon the SPHINX message format
11 |
12 | While we have seen some prior work in the ecosystem towards privacy-preserving messaging protocols (e.g. Whisper, Orchid, Matrix), we are still missing a go-to protocol that is scalable, provides metadata anonymity and incentivizes node operators.
13 |
14 | ## Team members
15 | * team lead: Dr. Sebastian Bürgel
16 | * developer: Robert Kiel
17 | * developer: Matt Swezey
18 |
19 | ## Team Website
20 | * https://validitylabs.org
21 |
22 | ## Legal Structure
23 | Validity Labs AG, registered in Zug, Switzerland.
24 |
25 | ## Team's experience
26 | Sebastian is co-founder and CTO of Validity Labs and leads a mostly technical team of 17. Before co-founding Validity Labs he worked as a Postdoctoral researcher at ETH Zurich in the domain of microtechnology for biomedical applications. Prior to Validity Labs, he co-founded SONECT, a Swiss fintech startup backed by PostFinance and other major financial infrastructure providers. Sebastian has been developing in the Ethereum ecosystem since 2015, the first public example was a decentralized lab book developed during the hack.ether.camp hackathon in 2015 (https://github.com/dlabbook https://youtu.be/GXSTKjS7UZE).
27 |
28 | Robert holds an MSc degree in Computer Science from TU Darmstadt with a specialization in IT security. He is full time with Validity Labs since beginning of August 2018 to work on the architecture and implementation of a privacy-preserving messaging protocol.
29 |
30 | Matt joined Validity Labs in November 2017 as a decentralized application developer and has worked across the full dApp stack from smart contracts to web technologies. He is also CEO of Pactum IO, LLC, providing graphical user interfaces for creating configurable smart contracts. Matt holds a degree in Computer Science from Midwestern State University Texas.
31 |
32 | ## Team Code Repos
33 | * https://github.com/validitylabs
34 | * https://github.com/validitylabs/messagingProtocol
35 |
36 | ## Team LinkedIn Profiles
37 | * https://www.linkedin.com/in/scbuergel/
38 | * https://www.linkedin.com/in/robert-kiel-176878161/
39 | * https://www.linkedin.com/in/matt-swezey-46691755/
40 |
41 | ## Intended language of development
42 | * JavaScript
43 | The first implementation of the HOPR protocol will be in JavaScript in order to cater to both backend services running as a NodeJS CLI application as well as browser-based dapps. We deem this crucial for fast adoption of early showcases that give us a feeling for the viability of the approach.
44 |
45 | * Rust
46 | Within the framework of this grant application, we will decouple the payment layer from the message layer and provide a Substrate implementation of the payment layer in Rust. The existing and more complex message layer thus does not have to be entirely re-written in Rust in order to complete the grant within the anticipated timeline and budget. Integration via APIs in both directions is however in scope of this grant and needs to be implemented.
47 |
48 | ## Development Roadmap
49 | This grant application is targeting a 4 months implementation and assessment timeline during which we aim to reach the following milestones:
50 | * Milestone 1:
51 | * decouple existing message and payment layer
52 | * detailed documentation of payment layer
53 | * Deliverables: architecture, implementation and documentation detailed publicly on GitHub
54 | * Duration: 1 month
55 | * Funding: CHF 25'000
56 | * Milestone 2: Substrate implementation
57 | * Rust implementation of existing HOPR smart contract logic that has initially been built on Ethereum
58 | * Deliverables: Working code available publicly on GitHub
59 | * Duration: 2 months
60 | * Funding: CHF 40'000
61 | * Milestone 3: Integration, testing & reporting
62 | * integrate the new Substrate implementation with message layer
63 | * testing and documentation
64 | * tutorial article and video that details how to setup a HOPR node and participate in the network
65 | * report outcomes and detail future work
66 | * Deliverables: Report summarizing the work available as blog post and demonstrate in at least on public event
67 | * Duration: 1 month
68 | * Funding: CHF 25'000
69 |
70 | The total funding is CHF 90'000. Validity Labs plans to spin out the protocol in a separate legal entity that generates revenue by taking a cut of relayer fees (this initial business model is under discussion and might be subject to change) in order to sustainably finance protocol development.
71 |
72 | ## Additional Information
73 | Validity Labs started some initial research and development on this project which is publicly available under https://github.com/validitylabs/hopr (GPL3 license). The initial research and development is so far exclusively financed by Validity Labs, no further grant applications are pending at this time.
74 |
--------------------------------------------------------------------------------
/grants/speculative/metamask-plugin-polkadot.md:
--------------------------------------------------------------------------------
1 | # Metamask plugin for Polkadot
2 |
3 | ## Project Description
4 | This project includes the development of Polkadot wallet for simple interaction with Polkadot dapps. Considering the whole ecosystem, we propose implementing wallet as a MetaMask plugin (in future references “snap”) to enable all MetaMask users interaction with Polkadot dapps. This will enable simple and easy onboarding of existing Ethereum users into Polkadot.
5 |
6 | Snap would be able to generate Polkadot account keys from dapp’s unique MetaMask key and enable those keys to receive/send units (assets), sign messages and interact with dapps. This means that users will automatically get Polkadot wallet generated.
7 |
8 | Please note, we won’t be able to change Metamask UI but instead dapps should use injected API to display relevant information and trigger transactions (some will require MetaMask prompts). This is a new feature in MetaMask and will require extra research and following up with the development updates to continuously make UX better.
9 |
10 | ## Team members
11 | * [Marin Petrunić](https://github.com/mpetrunic)
12 | * [Belma Gutlić](https://github.com/morrigan)
13 | * [Mak Muftić](https://github.com/MakMuftic)
14 | * [Ivan Rubido](https://github.com/irubido)
15 | * [Nikola Mlinarić](https://github.com/nmlinaric)
16 |
17 |
18 | ## Team Website
19 | * https://www.nodefactory.io/
20 |
21 | ## Legal Structure
22 | Company in the Republic of Croatia
23 |
24 | ## Team's experience
25 | We are a blockchain research and development company but also a group of friends and developers working from an office in Zagreb. Being mostly fullstack developers and blockchain developers for the last 3 years, we are successfully providing services such as dapp development, infrastructure and tooling.
26 |
27 | We are already working on some grant sponsored projects like:
28 | * **ChainGuardian** - Eth2 validator desktop application
29 | * **js-libp2p-noise** - libp2p stream security transport to be used in eth2 mainnet
30 | * **Hactar** - a Filecoin miner analyzer
31 | * https://github.com/NodeFactoryIo/hactar-daemon
32 | * https://github.com/NodeFactoryIo/hactar-frontend
33 | * https://github.com/NodeFactoryIo/hactar-backend
34 |
35 | Some of the other projects that we have been working on can be found on our [website portfolio](https://www.nodefactory.io/portfolio/).
36 |
37 | ## Team Code Repos
38 | * https://github.com/NodeFactoryIo
39 |
40 | ## Team LinkedIn Profiles
41 | * https://www.linkedin.com/in/belmagutlic/
42 | * https://www.linkedin.com/in/mpetrunic/
43 | * https://www.linkedin.com/in/mak-muftic/
44 | * https://www.linkedin.com/in/nikola-mlinari%C4%87-6159b1168/
45 | * https://www.linkedin.com/in/ivan-rubido-917169151/
46 |
47 |
48 | ## Development Roadmap
49 |
50 | #### Milestone 1: Generating Polkadot compatible keys and read-only actions (3 weeks - 2 persons full time):
51 | * Prepare Metamask snap package and installation
52 | * Generate `ed25519` keys using `@polkadot/keyring` and Metamask App Key as seed
53 | * List DOT token asset
54 | * Provide following read-only actions:
55 | * get public key `ed25519`
56 | * get balance
57 | * get blocks by hash/number
58 | * get transactions
59 | * export private key
60 | * Simple web dapp demonstrating snap functionality
61 |
62 | #### Milestone 2: Enable sending transactions and signing messages (2 weeks - 2 persons full time):
63 | * Send units to other account
64 | * Notification of successful or failed transaction
65 | * Notification of incoming transactions
66 | * Signing custom messages
67 | * Making snap compatible with [Polkadot extension api](https://github.com/polkadot-js/extension#api-interface)
68 | * Demonstrating functionality on simple web dapp
69 |
70 |
71 | #### Milestone 3: Integrate and documentation (2 weeks - 1 person full time):
72 | * Create documentation on how to integrate snap into your dapp
73 | * Create PR integrating snap into https://github.com/polkadot-js/apps/tree/master/packages/app-accounts dapp
74 |
75 | We'll keep this plugin updated in case of Metamask API breaking changes. We hope Metamask will expose API to allow UI modification
76 | in which case we plan to apply for additional grants to enhance Metamask experience in Polkadot space.
77 |
78 | ## Additional Information
79 | * **What work has been done so far?**
80 |
81 | Mostly just researching API, snap documentation and similar projects.
82 |
83 | * **Are there are any teams who have already contributed (financially) to the project?**
84 |
85 | No.
86 |
87 | * **Have you applied for other grants so far?**
88 |
89 | No.
90 |
91 | * **Are there any other projects similar to yours? If so, how is your project different?**
92 |
93 | [MetaMask Agoric Plugin](https://github.com/danfinlay/metamask-agoric-plugin) - Metamask snap for non-Ethereum blockchain.
94 |
95 | [Polkadot{.js} extension](https://github.com/polkadot-js/extension#api-interface) - Browser extension for interacting with Polkadot dapps
96 |
97 | This project aims to combine those two previously mentioned projects to enable hassle-free onboarding of Ethereum users to Polkadot Dapps by providing the same API as Polkadot browser extension.
--------------------------------------------------------------------------------
/grants/speculative/multisignature_implementation.md:
--------------------------------------------------------------------------------
1 | # Project Name
2 |
3 | Multisignature Implementation
4 |
5 | ## Project Description
6 |
7 | This is an application for development of multisignature implementation for Polkadot. Multisignature (multisig) refers to requiring more than one key to authorize a transaction.
8 | It is generally used to divide up responsibility for possession of assets. By using a multisig wallet, users are able to prevent the problems caused by the loss or theft of a private key.
9 | So even if one of the keys are compromised, the funds are still safe.There are couple of methods to implement Multisignature: Shamir's Secret Sharing Scheme, m of n signature and n of n signature.
10 |
11 | We investigated all these approaches, noted their advantages and disadvantages and stand on the next ways to implement multi signature for Polkadot:
12 | - using multisignature runtime module
13 | - using threshold Schnorr signature for ed25519
14 | - using Schnorr multi signature n of n sr25519
15 | We are providing for your consideration the roadmap for all 3 approaches.
16 | ## Team members
17 | - Vitalii Parkhomenko – team leader/researcher/tech writer
18 | - Aleksei Korobeinikov – developer
19 | ## Team Website
20 | - https://everstake.one & https://atticlab.net
21 | ## Legal Structure
22 | ATTIC LAB, Limited Liability Company. 89, Kazimir Malevich str., Kyiv, 03150, Ukraine
23 | ## Team's experience
24 | Everstake is an affiliate company of Attic Lab, so members from both teams are going to participate in the project. Everstake has developed an online IDE for the IOST blockchain. Attic Lab’s development experience includes the following projects: Crypto exchange Codex. View Here Cassandra history plugin. View Here Munin plugins. View Here OpenBankIT. Open-source banking software. View Here EOS History API running on Elasticsearch cluster. View Here My EOS Wallet. View Here My EOS Wallet mobile version. View Here1. View Here2. EOS Book. View Here My Telos Wallet. View Here My BOS Wallet. View Here
25 | Besides, we have successfully developed VSCode & Atom plugins for Web3Foundation previously
26 | ## Team Code Repos
27 | - https://github.com/everstake
28 | - https://github.com/atticlab
29 | ## Team LinkedIn Profiles
30 | - https://www.linkedin.com/in/vitalii-parkhomenko-493561187/
31 | - https://www.linkedin.com/in/aleksei-korobeinikov/
32 | ## Development Roadmap
33 | ### Onchain implementation:
34 | 1. Library for multisig (wrapper to polkadot-js) 30h
35 | 1. Blockchain(Runtime Module) 60h
36 | 1. Wallet setup
37 | 1. Multisignature wallet logic
38 | 1. Daily limit management
39 | 1. Signers managements
40 | 1. Unit-tests
41 | 1. Integration testing 16h
42 | 1. Documentation, tutorials 10h
43 |
44 | Total for Onchain implementation: 126 hours
45 | Budget: 8,000 USD
46 |
47 | ### Onchain implementation (reusing F3Joule):
48 | 1. Library for multisig (wrapper to polkadot-js) 30h
49 | 1. Blockchain(Runtime Module) 24h
50 | 1. Refactoring
51 | 1. Daily limit management
52 | 1. Unit-tests
53 | 1. Integration testing 16h
54 | 1. Documentation, tutorials 10h
55 |
56 | Total for Onchain (reusing F3Joule) implementation: 80 hours
57 | Budget: 5,200 USD
58 |
59 | ### Worker implementation (using Schnorr signatures)
60 | 1. Library(wrapper to polkadot-js) 70h
61 | 1. Client(ui) 48h
62 | 1. Blockchain(Runtime Module) 104h
63 | 1. Multisignature transaction logic
64 | 1. Submit transaction logic
65 | 1. Events
66 | 1. Unit-tests
67 | 1. Worker 140h
68 | 1. Multisignature transaction logic
69 | 1. Verification and collecting all signatures logic
70 | 1. Signature aggregation logic
71 | 1. Send extrinsic to Module logic
72 | 1. Integration testing 24h
73 |
74 | Total for worker implementation: 386 hours
75 | Budget: 25,000 USD
76 | ## Long-term plans
77 | We would like to continue developing tools and products for Polkadot, and not only in the area of editors and IDE’s.
78 | ## Additional Information
79 | What work has been done so far? Getting familiar with the Substrate codebase and researching possible ways to do it.
80 | Have you applied for other grants so far? We have finished one project with Web3 so far.
81 | Are there any other projects similar to yours? Not to our knowledge.
82 |
83 |
--------------------------------------------------------------------------------
/grants/speculative/nft_tracker.md:
--------------------------------------------------------------------------------
1 | # NFT Tracking Module
2 |
3 | ## Project Description
4 |
5 | ### Brief Description
6 |
7 | The Tracking Module is the core of NFT functionality. Like ERC-721 standard in Ethereum ecosystem, this module provides the basement for creating collections of unique non-divisible things, also called Non Fungible Tokens (NFTs), minting NFT of a given Collection, and managing their ownership.
8 |
9 | ### Why NFT Tracking Module is Good for the Ecosystem
10 |
11 | The NFT Tracking Module is the first step in building NFT Parachain and NFT bigger pucture inside the Polkadot ecosystem. NFT standard ERC-721 is widely used in Ethereum ecosystem for tracking miscellaneous real-world and gaming assets. Having an analogue will speed up transformation of Ethereum based NFT applications towards Polkadot, so it will enable development of new applications.
12 |
13 | ### How NFT Tracking Module Integrates into Substrate
14 |
15 | NFT Tracking Module is the Substrate Runtime module built with substrate-up or similar scripts.
16 |
17 | ### Why our Team is Interested
18 |
19 | We see Polkadot as a very promissing technology that will be used for a large number of use cases. It will greatly contribute to adoption of blockchain in powerful applications. It is technically one of the most ambitious blockchain projects we know of, and we would like to be part of the community that's creating it, as well as developing on it once the network goes live.
20 |
21 | In particular, NFT technology are a great part of our roadmap, which includes integration with Gaming frameworks, building gaming APIs, wallets, etc. NFT Tracking Module will enable next steps in this roadmap.
22 |
23 |
24 | ## Team members
25 | * Alexander Mitrovich
26 | * Greg Zaytsev
27 | * Maksim Styrgin
28 |
29 | ## Team Website
30 | * http://usetech.com/blockchain.html
31 |
32 | ## Legal Structure
33 | These details will be shared privately via our Google Form.
34 |
35 | ## Team's experience
36 | Our team members each have more then 15 years of IT experience in managing projects and writing software for product companies and large enterprises alike. We created the Blockchain practice in 2016 and have done dozens of projects for clients across the globe on variety of blochchains, mostly on Ethereum.
37 |
38 | ## Team Code Repos
39 | * https://github.com/usetech-llc/polkadot_psql_indexer
40 | * https://github.com/usetech-llc/sr25519_dotnet
41 | * https://github.com/usetech-llc/sr25519
42 | * https://github.com/usetech-llc/polkadot_api_dotnet
43 | * https://github.com/usetech-llc/polkadot_api_cpp
44 | * https://github.com/usetech-llc/multichain_airdrop
45 | * https://github.com/usetech-llc/neupool
46 | * https://github.com/gregzaitsev/platform-contracts
47 | * https://github.com/gregzaitsev/wasmcharts_page
48 | * https://github.com/gregzaitsev/platform-frontend
49 | * https://github.com/usetech-llc/unicom
50 | * https://github.com/usetech-llc/votingrelay
51 | * https://github.com/usetech-llc/forever_coin
52 | * https://github.com/usetech-llc/taklimakan-network
53 |
54 | ## Team LinkedIn Profiles
55 | * https://www.linkedin.com/in/alexandermitrovich/
56 | * https://www.linkedin.com/comm/in/gregory-zaitsev-95ba633
57 |
58 | ## Development Roadmap
59 | Project roadmap and financial plan will be shared privately via Google Form.
60 |
61 | Our team plans to implement broader spectrum of applications such as
62 |
63 | * Decentralized Non-Fungible Token Exchange
64 | * Multi-chain token issuance
65 | * Cross-chain Payment Gateways
66 | * etc.
67 |
68 | ## Additional Information
69 |
70 | ### What work has been done so far?
71 |
72 | C++ and C# APIs are delivered. Also, ports of SR25519 to C and C# are done.
73 |
74 | ### Are there any other projects similar to yours? How is our project different?
75 |
76 | So far there have been no projects that tie together Polkadot ecosystem and NFT.
--------------------------------------------------------------------------------
/grants/speculative/ngrave_substrate_1.md:
--------------------------------------------------------------------------------
1 | # NGRAVE Wallet Substrate Integration
2 |
3 | ## Project Description
4 | The goal of NGRAVE is to create a fully integrated, end-to-end security solution for all aspects relating to security on the blockchain. From wallet generation, to wallet management, and secure key storage to posthumous recovery and more, NGRAVE's goal is to offer the highest level of security.
5 |
6 | Central to this endeavour is our flagship product, the NGRAVE ZERO. It is a versatile hardware wallet with a novel key creation procedure, fingerprint authentication, and touchscreen display. It has been given incubator support and is being built by belgium's own IMEC.
7 |
8 | Impeccable security is a requirement. The Polkadot ecosystem needs a wallet management solution that can compete with the best industry standards currently available for other blockchains, and we want to build it. Without good security there are hard limitations on adoption, especially in order to get institutional support.
9 |
10 | **Our interest is twofold:**
11 | 1. It is exciting to help pioneer solutions while the technology is still new and thus creates a more meaningful impact.
12 | 2. A single substrate integration will allow us to offer support for any substrate derived chain.
13 |
14 | As it stands, besides the Parity Signer we have no knowledge of other hardware wallets that already have or are planning on adding substrate support. We would like to remedy that.
15 |
16 | All code we would develop for this project would be open source and reusable for other projects, as our main goal is to increase adoption signing by QR code.
17 |
18 |
19 | ### Team members
20 | - Xavier Hendrickx (Lead)
21 | - Edouard Vanham
22 | - Ruben Merre
23 |
24 | ### Team Website
25 | https://www.ngrave.io
26 |
27 | ### Legal Structure
28 |
29 | - Incorporated in Belgium as NGRAVE.IO NV
30 |
31 | ### Team’s experience
32 | The team is highly complementary, jointly having a worldwide network in crypto, and over 20,000 hours of project management experience in launching new tech projects from ideation to post go-live.
33 |
34 | Our CEO Ruben Merre has a comprehensice background in strategy, management, and innovation consulting. Prior to NGRAVE he lead a multi-million-dollar program to build a new group-wide automated investment business unit for the top financial institution KBC, consisting of 20 subprojects including all business and ICT tracks. He is well-versed in growth strategies, go to market, marketing & sales, and business development.
35 |
36 | Our COO Edouard Vanham bridges the technical and business aspects, leveraging his expertise as a former IT and Management consultant, where he led several digitization projects in the banking and insurance industry.
37 |
38 | Our CTO Xavier Hendrickx has been in the crypto space for a long time and was CTO of the Belgo-American top blockchain project SwarmCity, which he ultimately left for a full-time position at NGRAVE.
39 |
40 | NGRAVE has many experienced advisors including business veterans, sales & general managers, sales leaders, serial entrepreneurs, company founders, and financial leaders.
41 |
42 | Our manufacturing partner in both hardware and firmware is IMEC: the world leader in R&D for nanotechnology and digital technologies (such as battery-, sensor, IoT-technology) and a leading micro/nano chip manufacturer.
43 |
44 | ### Team LinkedIn Profiles
45 | * https://www.linkedin.com/in/xavierhendrickx/
46 | * https://www.linkedin.com/in/edouardvanham/
47 | * https://www.linkedin.com/in/ruben-merre/
48 |
49 | ## Intended language of development
50 | * C++
51 |
52 | ## Development Roadmap
53 | #### Milestones:
54 |
55 | We will require 4-6 months to complete the proposed milestones.
56 |
57 | 1. Milestone 1 (4-6 weeks): R & D, identifying libraries, defining exact seed derivation scheme, integration of libraries into firmware for Ristretto compressed Ed25519, with WIP documentation as it pertains to NGRAVE.
58 |
59 | 2. Milestone 2 (4-6 weeks): Implement C++ code into NGRAVE Zero using information gained from R & D milestone above.
60 |
61 | 3. Milestone 3 (2-4 week): Finalize the documentation of NGRAVE’s integration and publish under MIT license, showcasing the first hardware solution with a seed derivation scheme for a wallet.
62 |
63 | Once the milestones have been delivered, it is our intention to address the next steps towards creating a fully functional integration. This includes things like account creation, account management, transaction signing, message signing, contract calls, and various other functions as needed.
64 |
65 | ## Additional Information
66 |
67 | ##### NGRAVE's achievements so far:
68 | * Enrolled in IMEC iStart the #1 university-linked tech accelerator in Europe (ranked #4 in the world), one of the best global product development and industrialisation partners (while preserving the IP as fully ours).
69 | * Obtained trust and funding of a financial institution **,Belfius Bank**, our federal government (subsidy), the European Commission (H2020 project), a big technology corporate (IMEC), and business angels.
70 | * Advised by COSIC, one of the best cryptography and hardware security teams in the world, known for inventing AES (the most advanced encryption protocols used by the NSA and the US government), as well as for hacking Tesla cars.
71 | * Selected to showcase as one of the top projects at IMEC's annual Future Summit, on the 14th and 15th of May, 2019.
72 | * Selected by top platform Neufund to do an STO/ETO in Q4 2019 / Q1 2020.
73 | * Selected by the Belgian Chamber of Commerce to participate in their exclusive Silicon Valley program over the summer of 2019, to fully streamline our operations in the US.
74 |
--------------------------------------------------------------------------------
/grants/speculative/open_square_network.md:
--------------------------------------------------------------------------------
1 | # Project name
2 | Open Square Network
3 |
4 | ## Project Description
5 | Open Square Network is a blockchain based crowdsourcing and reputation platform. It will be implemented as a para-chain
6 | of Polkadot. We aim to attract thousands of middle and small sized enterprises and millions of developers in China for the first phase.
7 | This platform is a trial to evolve the human resource market. First phase features include:
8 | - Bounty funders can fund a bounty, while hunters can apply it.
9 | - Funders can get mining powers by successful collaboration with hunters.
10 | - Reputation of both funders and hunters will be calculated based on the finished bounty and remarks.
11 | - Aim to maintain relatively long collaboration between bounty funders and hunters.
12 |
13 | ## Team members
14 |
15 | * Yongfeng Li(@wliyongfeng), Full stack developer
16 | * Chaojun Huang(@hyifeng), Full stack developer
17 | * Wentao Chen(@qiyisi), Full stack developer
18 | * Alcazar, Designer
19 | * Yan Xu, Community operation intern
20 |
21 | ## Team Website
22 | https://www.opensquare.network
23 |
24 | ## Legal Structure
25 | Hangzhou Lianzheng Technology Co., Ltd
26 |
27 | ## Team's experience
28 |
29 | - Yongfeng Li has 10+ years software development experience, while focusing on block chain development for recent 4 years.
30 | - Chaojun Huang is a developer with 10+ years experience on developing complex backend service and rich frontend application. Has rich experience on both enterprise application and internet application.
31 | - Wentao Chen has about 6 years of full stack development experience, mainly in charge of front development in OpenSquare.
32 | - Alcazar served several blockchain companies in China with his disign skills for about 4 years.
33 | - Yan Xu is an undergraduate, now serve OpenSquare as community operation intern.
34 |
35 | ## Team Code Repos
36 | We will contribute our code to [opensquare-network](https://github.com/opensquare-network).
37 |
38 | ## Team LinkedIn Profiles
39 | Sorry but we don't use linkedin heavily in China.
40 |
41 | - [Yongfeng LI's LinkedIn Profile](https://www.linkedin.com/in/yongfeng-li-80950017/)
42 |
43 | ## Development Roadmap
44 | `The Open Square Network MVP` will be a 3-month project, aiming to deliver a testnet based on Substrate which support basic business for bounty founders and hunters.
45 |
46 | * **M1: Economic/reputation model, technical design (2 weeks)**
47 | - We will create and publish relevant documents and whitepapers.
48 | - Design the native currency distribution model for the chain participators(validators, bounty funders and hunters).
49 | - Validators' reward model will be relatively stable.
50 | - Several candidate reward models will be apply to keep funders and hunters from cheating to get higher reputation.
51 | - Technical specifications and modules design.
52 | - DApp UX design.
53 |
54 | * **M2: Implementation of the runtime modules (1 month)**
55 | - Native asset module, which will support transfer, staking, while chain dividends amount will be decided by native asset holdings.
56 | - Bounty management module. A basic user story will be:
57 | 1. Funders create bounty.
58 | 2. Chain council(Fixed members for the MVP version) may give some feedback and do some management for the bounty.
59 | 3. Hunters apply and resolve it.
60 | 4. Hunters get funding and the council get some management fee.
61 | 5. Successive mining powers will be assigned to funders and hunters.
62 | - Reputation module mainly manage funders and hunters' reputation based on the collaboration remarks.
63 |
64 | * **M3: Implementation of the DAPPs, explorer and user manual (6 weeks)**
65 | - A DAPP will be delivered to facilitate bounty funders and hunters to finish the basic business.
66 | - The chain explorer will be provided for blocks/extrinsic explorer.
67 | - The testnet will be launched with the DAPPs and explorer.
68 | - User manuals will be provided.
69 |
70 |
71 | ## Future Plans
72 | * Build the identity system for users.
73 | * Polkadot para-chain assets will be introduced as bounty currency.
74 | * More PR work will be done to attract bounty founders and hunters.
75 | * Our vision is to build a new block chain human resource platform involve crowdsourcing, reputation building, recruitment.
76 |
77 | ## Additional Information
78 | Any additional information that you think is relevant to this application that hasn't already been included.
79 |
80 | Several google docs below will be helpful for you to understand our ideas.
81 | 1. [[OSN] Why](https://docs.google.com/document/d/1ozwyhQ7g0UabVny5g-uF5z9TC8hya5yhVDz-SVreDek/edit?usp=sharing) shows why we have the idea to build Open Square Network.
82 | 2. [[OSN] How](https://docs.google.com/document/d/1hhAyEixHa-qfMiv-6mf2Fk5EVPSTns9Ehv-EZ3_Dj3g/edit?usp=sharing) shows some details about the reputation score calculation.
83 |
84 | Possible additional information to include:
85 | * What work has been done so far?
86 | 1. We have drafted the basic economic model. More details about the model and technical specifications will be done in future work.
87 | 2. Yongfeng has rich experience about substrate related developing, for the contribution to [ChainX](https://github.com/chainx-org).
88 | * Are there any teams who have already contributed (financially) to the project?
89 | ChainX help OpenSquare a lot. We have some community contributors, and please check [here](https://www.opensquare.network/team/) for more details.
90 | * Have you applied for other grants so far?
91 | No
92 | * Are there any other projects similar to yours? If so, how is your project different?
93 | Some of our ideas are inspired by [Gitcoin Bouties](https://gitcoin.co/bounties/funder). Main differences are:
94 | - Open Square Network will support relatively long time collaboration between bounty funders and hunters.
95 | - A separate Polkadot para chain will be developed to support the business and reduce the friction for users.
96 | - Bounty funders and hunters can get financial reward by mining.
97 | - Both the reputation of funders and hunters will be built.
98 | - On-chain governance will be built to provide more fairness and transparency.
99 |
--------------------------------------------------------------------------------
/grants/speculative/plasm.md:
--------------------------------------------------------------------------------
1 | # Plasm
2 |
3 | ## Project Description
4 | Plasm is a Substrate Runtime Module Library which allows developers to add Plasma functions to their Substrate chain. Since we are making SRML, we can also make both plasma parent chains and plasma child chains with Substrate. [We have made some Plasma chains by using Plasm](https://www.youtube.com/watch?v=T70iEgyuXbw&feature=youtu.be). We aim to be a Plasma parachain once Polkadot is ready. You can see our slide deck from [here](https://docs.google.com/presentation/d/1c-O0Ch-m2vX4bo4KMO5KxrDQlyDqn3Kl36gjo--5A5k/edit#slide=id.p).
5 |
6 | Today, there are many problems in this space like the scalability of a public blockchain, security of L2 and so on. Plasma is one of the ideal solutions for these problems public blockchain is facing. However, there are many derivative "Plasmas" and this makes developers difficult to understand how Plasma works. Plasm is a simple but versatile SRML and makes it easier for developers to make Plasma chain with Substrate. You can choose one of the plasma solutions from Plasm and apply it to your use case. This means Plasm allows you to use Plasma freely and easily. In the future, we would like to make a GUI developer tool to use Plasm. Our goal is to bring infinite scalability into the Polkadot ecosystem.
7 |
8 | * Plasm has some features.
9 | * It deals with many types of "Plasmas". (Both UTXO based model and account-based model.)
10 | * We have already had some rust implementations. Check out our GitHub.
11 | * Developers can define original transaction logics by themselves.
12 | * Substrate chain can be both a parent chain and a child chain.
13 | * Scalability is needed in the Polkadot ecosystem. Since Plasm is SRML with high versatility and expansibility, we are also making a Plasma paracahin. In addition, Plasm makes it easier even for other developers to make a Plasma chain.
14 | * We believe that blockchain is the social infrastructure. As an operating system for the next generation, we think Plasma like hierarchical/layered specification which brings high social scalability is needed.
15 |
16 | ## Team members
17 | * Sota Watanabe (CEO)
18 | * Takumi Yamashita (CTO)
19 |
20 | ## Team Website
21 | * https://staked.co.jp/ （New web page is coming soon）
22 |
23 | ## Legal Structure
24 | Incorporated in Japan
25 |
26 | ## Team's experience
27 | Staked Technologies is a blockchain company which aims to build digital economy where everyone belongs.
28 |
29 | * Sota is the CEO of the company. He also is a Polkadot ambassador in Tokyo. As an ambassador, he is hosting Polkadot and Substrate meetups at least once in a month and making Japanese document for developers. (e.g. Substrate Tutorials and [Polkadot whitepaper Japanese edition](https://github.com/stakedtechnologies/PolkadotWP)) In addition to that, he is a blockchain researcher at the University of Tokyo. He became the researcher at the age of 23, the youngest record. He used to work at Chronicled, a San Francisco based blockchain company which uses blockchain for supply chains.
30 |
31 | * Takumi is the CTO of the company. He was the world finalist of the ACM-ICPC International Collegiate Programming Contest 2016|2017 and he was selected one of the 21 best U25 engineers by an NPO which is supported by Japanese Government in 2018. In 2018, he has made his own blockchain platform called [Proskenion](https://proskenion.github.io/).
32 |
33 |
34 | ## Team Code Repos
35 | * https://github.com/stakedtechnologies/Plasm
36 |
37 | ## Team LinkedIn Profiles
38 | * https://www.linkedin.com/in/sota-watanabe-b962b3110/
39 |
40 | ## Development Roadmap
41 | Listed some of our milestones below. In parallel with making our product, we will make the Japanese community as well.
42 |
43 | - M1: Build the prototype modules including (5 weeks)
44 | - Plasm-Core
45 | - UTXO
46 | - Parent
47 | - Child
48 | - Plasm-Client
49 | - Operator
50 | - Wallet
51 | - M2: Implement a plasma chain with Plasm and connect it to the Polkadot Testnet (1 week)
52 | - M3: Support Plasma Cash (2 weeks)
53 | - M4: Support [Plasm Chamber](https://github.com/cryptoeconomicslab/plasma-chamber) (1 week)
54 | - M5: Build a GUI developer tool (2 weeks)
55 | - M6: Documentation
56 |
57 | After successful implementation, we will research and implement ZK-SNARKs and 99% fault tolerant consensus algorithm on our plasma chain in parallel with making real use cases.
58 |
59 | ## Additional Information
60 | * [Our demo video in English](https://www.youtube.com/watch?v=T70iEgyuXbw&feature=youtu.be)
61 | * [Plasm without technical explanations](https://docs.google.com/presentation/d/1er_QAOuRk4h97FCq8Sjp5h4YNQSOsRbO4mtiuCgInhY/edit?usp=sharing)
62 |
63 | ### What work has been done so far?
64 | * Plasm Rust implementations.
65 | * UTXO Rust implementations.
66 | * Plasm Demo.
67 | * Presented Plasm at Sub0.
68 |
69 | ### Are there are any teams who have already contributed (financially) to the project?
70 | We have accepted seed financing from a Japanese VC.
71 |
72 | ### Have you applied for other grants so far?
73 | No
74 |
75 | ### Are there any other projects similar to yours?
76 | [GunClear](https://github.com/w3f/Web3-collaboration/pull/83/files)
77 |
78 | ## How is your project different?
79 | From our understanding, they are making Plasma bridge to Ethereum. We are making SRML(s) and try to make it easier for developers to use Plasma. We are similar in that we are both using Plasma, but the approach is completely different.
--------------------------------------------------------------------------------
/grants/speculative/polkadot_Substrate_Java_API.md:
--------------------------------------------------------------------------------
1 | # Polkadot/Substrate Java API
2 |
3 | ## Project Description
4 |
5 | - Our team will develop the Polkadot/Substrate Java API.Java APIs around Polkadot and any Substrate-based chain RPC calls. It is dynamically generated based on what the Substrate runtime provides in terms of metadata.
6 | - Java has the largest number of programmers in the world, with a wide range of applications. Most companies use Java as the front-end back-end programming language. The biggest advantage of Java is its large and complete ecosystem.
7 | - Our team is optimistic about the future ecology of Polkadot/Substrate, and Polkadot/Substrate brings new technologies and new opportunities for the blockchain 3.0 era, paving the way for us to develop an application-level ecosystem in the future.
8 |
9 | ## Team members
10 |
11 | - gemZhang
12 | zycFran,acmen
13 |
14 | # Team Website
15 |
16 | - Domain name is being filed
17 |
18 | ## Legal Structure
19 |
20 | No
21 |
22 | ## Team's experience
23 |
24 | gemZhang:
25 |
26 | China Ocean University, computer major, mobile development for 3 years, blockchain development for 3 years, project development experience, rich management experience, familiar with Polkadot/Substrate architecture, can be responsible for project management, code review.
27 |
28 | zycFran:
29 |
30 | Zhejiang University, computer major, front-end development for 5 years, rich project experience, clean and concise code, deep understanding of js design pattern, independent development of module components, strong sense of responsibility, serious responsibility, and acmen pair programming, can be responsible for Polkadot/Substrate Javascript API translation, Gitbook presentation of the Polkadot/Substrate Java API.
31 |
32 | wqking:
33 |
34 | 20 years C++ experience. Experienced in C++/Python/Java/PHP/JavaScript/C#/Perl, blockchain, desktop software, web development, mobile game,Responsible for Polkadot/Substrate Java API programming.
35 |
36 | https://github.com/wqking
37 |
38 | https://github.com/zycFran/
39 |
40 | https://github.com/gemZhang
41 |
42 | ## Team Code Repos
43 |
44 | - https://github.com/polkadot-java/api
45 |
46 | ## Team LinkedIn Profiles
47 |
48 | - https://www.linkedin.com/in/%E7%8E%89-%E5%BC%A0-575831143/
49 | - https://www.kbasm.com/
50 |
51 | ## Development Roadmap
52 |
53 | - 2019.03.10-2014.04.011
54 |
55 | Our team analyzes Polkadot/Substrate and combines the JavaScript API to design the best way to implement in the Java programming language. During this time, part of the Java code, a runable Jar package, and the basic Polkadot/Substra Java API functionality will be implemented on GitHub.
56 | The specific functions of the API are as follows:
57 | A.JSON-RPC, specifically includingAuthoring of network items,Retrieval of chain data,Query of state,Methods to retrieve system info.
58 | B.balances, session, demoracacy, staking, consensus and other functions corresponding to Storage, Extrinsics, Events.
59 | C.timestamp function corresponding to Storage, Extrinsics.
60 | D.type, including Primitive types, Substrate types, Codec types, RPC types, Derived types.
61 |
62 | - 2019.04.12-2019.05.11
63 |
64 | Implement the existing Polkadot/Substra API in the Java programming language. During the period, submit Java code on GitHub, and a runable Jar package. Implement some API documentation with Gitbook.
65 | The specific functions of the API are as follows:
66 | A.council, councilMotions, councilVoting, grandpa, sudo, treasury and other functions corresponding to Storage, Extrinsics, Events.
67 | B.some API examples, including Simple Connect, Listen to new blocks, Listen to balance changes, Unsubscribe from listening to updates, Read storage, Make a simple transfer, Traverse events.
68 |
69 | - 2019.05.12-2019.06.11
70 |
71 | Submit all Java code on GitHub, a runable Jar package, implement all API documentation with Gitbook, build a Polkadot/Substra Java API official website, open Twitter, and set up a technical exchange group to promote the Polkadot/Substra Java API. If it goes well and has plenty of time, with a deep understanding of Polkadot/Substrate, we will expand the team to develop the Java client for Polkadot/substrate.
72 |
73 | ## Licensing
74 |
75 | GNU GPL v3 license.
76 |
77 | ## Additional Information
78 |
79 | - Has set up a team, rented office space, and set up office supplies.
80 | - The team has started research Polkadot/Substrate and Polkadot Javascript API.
81 |
--------------------------------------------------------------------------------
/grants/speculative/polkadot_overview.md:
--------------------------------------------------------------------------------
1 | # Polkadot Overview
2 |
3 | ## Project Description
4 | We intend to create a validators explorer for Polkadot Network. The main features list:
5 |
6 | 1. Ability to see the list of active validators, their info (description, website, twitter, commission, etc.) and their statistic (status, uptime, stability info, etc.)
7 | 2. Nominators will be able to see their stake distribution across the validators
8 | 3. General network information (number of validators, number of validator candidates, era, latest block, etc.)
9 |
10 | We are interested to build a project like this because we are currently running the validation nodes in Tendermint based networks (Cosmos, IRIS, Terra, and Minter) and see the needs from delegators to have the summarized data about validators in one place.
11 |
12 | Our main goal is to make the Polkadot Overview app and also to run our validation node in Polkadot.
13 |
14 | ## Team members
15 | * Tim Kabanov
16 | * Ilya Stepanov
17 | * Dmitriy Petrov
18 |
19 | ## Team Website
20 | [https://genesislab.net](https://genesislab.net)
21 |
22 | [https://twitter.com/GenesisLab_net](https://twitter.com/GenesisLab_net)
23 |
24 | ## Team's experience
25 | We are a team of 3 developers focused on blockchain related web services development. We are also running validation nodes in Proof of Stake networks like Cosmos, IRIS, Terra, Minter, and Polkadot (PoC-4 testnet).
26 |
27 | For our web applications we are using Laravel (PHP) + VueJS. For our cross-platform desktop applications we are using Electron.
28 |
29 | So far we have running validator explorers for Cosmos ([Cosmos Overview](https://cosmos-overview.genesislab.net/)), Minter ([Minter Overview](https://overview.minter.store/)) and other Tendermint based networks. Also, we have the open source [Autodelegation tool](https://github.com/genesis-lab-team/minter-autodelegator) for Minter to give the ability for users to automatically re-delegate their rewards.
30 |
31 | ## Team Code Repos
32 | * https://github.com/genesis-lab-team
33 | * https://github.com/i7495
34 | * https://github.com/tim-kabanov
35 | * https://github.com/PetrovDw
36 |
37 | ## Team LinkedIn Profiles
38 | * https://www.linkedin.com/in/tim-kabanov
39 | * https://www.linkedin.com/in/ilya-stepanov-79058038/
40 | * https://www.linkedin.com/in/dmitriy-petrov-b79671187
41 |
42 | ## Development Roadmap
43 | #### Milestone 1 - Research and backend development - 1 month - 1/3 of DOTs requested
44 | * Setup the Polkadot full node
45 | * Development of the blockchain parsing system to collect all the required information for the application and setup of the database (Mongo DB) to store the blockchain data in it
46 | * Analyze and prepare the data that will be used in frontend of the Polkadot Overview application
47 | * Backend code development to retrieve the data from DB using the Laravel framework
48 |
49 | *Milestone 1 result will be delivered as a docker container with MongoDB and backend code in it. You will be able to connect to the MongoDB and check that application collect the data from the blockchain.*
50 |
51 | #### Milestone 2 - Frontend development - 1 month - 1/3 of DOTs requested
52 | * Frontend development with the UI to show the collected data to the end users with VueJS
53 |
54 | *Milestone 2 result will be delivered as a docker container that will provide the full functional application with the backend and frontend. You will be able to see the running application on your local machine.*
55 |
56 | #### Milestone 3 - Feedback collection, application testing and documentation - 1/3 of DOTs requested
57 | * Preparation of the setup instructions and documentation / tutorials that describes application features
58 | * Release Polkadot Overview on [https://polkadot-overview.genesislab.net](https://polkadot-overview.genesislab.net)
59 | * Collect users feedback and feature requests
60 | * Code refactoring, new features implementation based on users feedback, bug fixing
61 | * Upload the application's code to [our GitHub](https://github.com/genesis-lab-team)
62 |
63 | *Milestone 3 result will be the publicly available application on [https://polkadot-overview.genesislab.net](https://polkadot-overview.genesislab.net) with the open source code and documentation available for everyone.*
64 |
65 | Our long-term plans and intentions after the grant has been awarded is to run the validation node in Polkadot main net and to continue the Polkadot Overview application development based on the features requests.
66 |
67 | ## Additional Information
68 |
69 | **What work has been done so far**
70 |
71 | Setup the Polkadot full node. Research for the possible ways to collect the blockchain data.
72 |
73 | **Have you applied for other grants so far?**
74 |
75 | No
76 |
--------------------------------------------------------------------------------
/grants/speculative/polkadot_sofia.md:
--------------------------------------------------------------------------------
1 | # Polkadot Sofia Meetup
2 |
3 | ## Project Description
4 | We the organizers of Blockchain Developers Meetup in Sofia,Bulgaria. And we also want to organize a dedicated Polkadot Sofia Meetup
5 |
6 | >The plan is to organize a Polkadot meetup in Sofia, Bulgaria. The initial meetup is planned for the end of November, where we will introduce Polkadot to our community, and talk about the basics. Furthermore we are planning to explore deeply Polkadot and continue making other meetups/events about more sophisticated use cases of Polkadot. We would greatly appreciate if some from Polkadot can join some of our events, give a talk/presentation and meet our community.
7 | Our meetup group is already consisted of 100+ blockchain developers interested and attending at our events. We are doing all the marketing and organization, as well as providing all the necessary details to our community.
8 |
9 | ## Team members
10 | * Milen Radkov
11 | * Hristo Georgiev
12 | * Elena Gugleva
13 |
14 | ## Team Website
15 | * https://hack.bg
16 | * https://meetup.com/blockchain-developers-meetup-bulgaria
17 | * https://meetup.com/sofia-polkadot
18 |
19 | ## Legal Structure
20 | Ltd.
21 |
22 | ## Team's experience
23 | We are blockchain developers with background in web and software development.
24 |
25 |
26 | ## Team Code Repos
27 | * https://github.com/mradkov
28 | * https://github.com/hackbg
29 |
30 | ## Team LinkedIn Profiles
31 | * https://www.linkedin.com/in/milenradkov
32 | * https://www.linkedin.com/in/hristo-georgiev-b23a9a129/
33 |
34 | ## Intended language of development
35 | * Not related.
36 |
37 | ## Development Roadmap
38 | The events are being organized and held once a month.
39 |
40 | The requested grants will be used for:
41 | * Covering our venues expenses.
42 | * Covering some of the guest speakers' expenses.
43 | * Creating educational materials - workshops, tutorials.
44 | * Creating content /blogposts, media coverage, etc./
45 | * Expenses for video recording and editting.
46 | * Snacks and drinks for the community.
47 |
48 | ## Additional Information
49 | * [Blockchain Developers Meetup 05 - Introduction to Polkadot](https://medium.com/hackbg/blockchain-developers-meetup-05-introduction-to-polkadot-3b4789fa4e1f)
50 | * [/r/dot/ Blockchain Developers Meetup (Sofia, Bulgaria) — Introduction to Polkadot](https://www.reddit.com/r/dot/comments/a1tsmp/blockchain_developers_meetup_sofia_bulgaria/)
51 | * Please see: [w3f/Web3-collaborations/issues/47](https://github.com/w3f/Web3-collaboration/issues/47)
52 |
53 |
--------------------------------------------------------------------------------
/grants/speculative/postgre_indexer_consensus_ensurer.md:
--------------------------------------------------------------------------------
1 | # PostgreSQL Indexer and Consensus Ensurer
2 |
3 | ## Project Description
4 |
5 | ### A brief description of the project.
6 |
7 | Indexer analyses metadata and produces database schema from it, then it scans blocks, extracts data from transactions and saves it to database tables.
8 |
9 | CE ensures that the node a dApp communicates to entered consensus with the rest of the network.
10 |
11 | ### An indication of why this project is good for the ecosystem.
12 |
13 | Indexer will enable creating applications with high performance requirements.
14 |
15 | CE will add missing layer of security that is assumed to be present in any blockchain network.
16 |
17 | ### An indication of how you will integrate this project into Substrate / Polkadot.
18 |
19 | Indexer interacts with Substrate/Polkadot via RPC interface, and CE acts as a transparent layer for a client API (so that dApps will not need to change), but the set of nodes to interact with will be managed by CE instead of application maintainers.
20 |
21 | ### An indication of why your team is interested in creating this project.
22 |
23 | Currently available solution from Polkascan serves its needs well. We would like to expand capabilities of indexers and create a flexible indexer that is less dependent on concrete runtime configuration and opens capabilities to many high performance dApps including ones that require their own runtime modules and new transaction types.
24 |
25 | CE is a very needed (and missing) part for any blockchain. Operating with preset hardcoded node is an obvious vulnerability for a dApp because this single node may be attacked. We are interested in improving network security so, this problem is of our interest as well.
26 |
27 | ## Team members
28 | * Alexander Mitrovich
29 | * Greg Zaytsev
30 | * Maksim Styrgin
31 |
32 | ## Team Website
33 | * http://usetech.com/blockchain.html
34 |
35 | ## Legal Structure
36 | These details will be shared privately via our Google Form.
37 |
38 | ## Team's experience
39 | Our team members each have more then 15 years of IT experience in managing projects and writing software for product companies and large enterprises alike. We created the Blockchain practice in 2016 and have done dozens of projects for clients across the globe on variety of blochchains, mostly on Ethereum.
40 |
41 | ## Team Code Repos
42 | * https://github.com/usetech-llc/
43 |
44 | ## Team LinkedIn Profiles
45 | * https://www.linkedin.com/in/alexandermitrovich/
46 | * https://www.linkedin.com/comm/in/gregory-zaitsev-95ba633
47 |
48 | ## Development Roadmap
49 | Project roadmap and financial plan will be shared privately via Google Form.
50 | Our areas of interest in Polkadot and Substrate are around:
51 |
52 | * Decentralized Non-Fungible Token Exchange
53 | * Enterprise applications
54 | * Bridges
55 |
56 | ## Additional Information
57 | C++ and C# APIs are delivered. Source code and documentation are available at these public repositories:
58 | * https://github.com/usetech-llc/polkadot_api_cpp
59 | * https://github.com/usetech-llc/polkadot_api_dotnet
60 | * sr25519 porting to C is implemented, available here:
61 | * https://github.com/usetech-llc/sr25519
62 | * We have already completed most of the development for the Indexer, to insure we undestand the limits of the possible implementation
63 |
--------------------------------------------------------------------------------
/grants/speculative/robotics_in_polkadot.md:
--------------------------------------------------------------------------------
1 | Robotics integration in Polkadot
2 | ================================
3 |
4 | Objective: to improve the integration of robotics with parachains of the Polkadot network.
5 |
6 | Project Description
7 | -------------------
8 |
9 | The Polkadot network is useful for robotics developers. Installing the network client will help engineers to engage capabilities of decentralized technologies in a robotic system. For example, to control an autonomous robot through a decentralized application.
10 | The best way for that is creating a bridge between the Polkadot client and the ROS framework. ROS ([Robot Operating System](http://ros.org)) is the most popular open source framework for robotics development. Stats of ROS usage: http://download.ros.org/downloads/metrics/metrics-report-2018-07.pdf. Now ROS supports more than 100 different models of existing robots.
11 |
12 | I am one of the core developers of the Robonomics project ([robonomics.network](https://robonomics.network)). Since 2015, we have been experimenting with the use of decentralized technologies, in particular we use the Ethereum platform for managing cyber-physical systems (CPSs). A CPS performs its work providing a service to the end user on signal that contains both financial and technical information. Such an approach seems to be useful in the concepts of Smart cities and Industry 4.0. In these concepts, Cyber-physical systems are often presented as autonomous services that provide services directly to the user: drone delivery, a 3D-printer in a subway station, a smart factory, an autonomous sensor network and inter-machine services.
13 |
14 | Today we are expanding support for Robonomics towards the Polkadot network, so that the robotics community will have an opportunity to use not only Ethereum, but also the closest alternatives. You can see the current results in the [repository on GitHub](https://github.com/airalab/substrate-node-robonomics).
15 |
16 | In this application, I propose to add two features, which will be useful for the Polkadot ecosystem, to the existing development:
17 |
18 | 1. to use a token from any parachain in the signal to launch the robot;
19 | 2. to use meta-information about the task performed by the robot in other parachains.
20 |
21 | Today Robonomics on Substrate allows you to run a ROS-compatible robot using a signal in the [Robonomics substrate-chain](https://telemetry.polkadot.io/#/Robonomics). Also, according to the result of task execution, the robot publishes a log of operations in IPFS and settles the hash of the saved log in the Robonomics substrate-chain as a result of the program execution. As part of the grant, I will extend the runtime module of the robot launch in order to implement the paragraphs (1) and (2).
22 |
23 | Team members
24 | ------------
25 |
26 | * Alexander Krupenkin
27 |
28 | Team Website
29 | ------------
30 |
31 | * https://aira.life
32 | * https://robonomics.network
33 |
34 | Legal Structure
35 | ---------------
36 |
37 | Individual
38 |
39 | Team's experience
40 | -----------------
41 |
42 | * ITMO MSc, Mechatronics and Robotics (Saint-Petersburg, Russia)
43 | * Open-source contributions: ros_comm, roshask, haxr, hs-web3
44 | * Since 2015 - Ethereum application developer
45 |
46 | Team Code Repos
47 | ---------------
48 |
49 | * https://github.com/airalab/substrate-node-robonomics
50 | * https://github.com/airalab/substrate-node-robonomics/tree/parachain
51 |
52 | Team LinkedIn Profiles
53 | ----------------------
54 |
55 | * https://www.linkedin.com/in/krupenkin/
56 |
57 | Development Roadmap
58 | -------------------
59 |
60 | * Inter-chain communication:
61 | - using asset transfer proof from another parachain (weeks 0-4);
62 | - transfer proof adoption for robot liability execution process (weeks 4-6);
63 | - share liability metadata with another parachains (weeks 6-9).
64 | * Add `ros-integration` feature to polkadot node (weeks 9-12).
65 | * Integrate all parts together and works as intended (weeks 12 - 14).
66 |
67 | Ideally, we can receive part payment at the end of each milestone: $2400.
68 | Total cost: $12000
69 |
70 | We would be willing to consider part payment in DOTs, up to 100%.
71 |
72 | Additional Information
73 | ----------------------
74 |
75 | * Robonomics Whitepaper: https://robonomics.network/robonomics_white_paper_en.pdf
76 | * Robonomics on Substrate demo: https://github.com/airalab/substrate-node-robonomics/tree/master/examples/turtlesim_liability
77 |
--------------------------------------------------------------------------------
/grants/speculative/ruby_substrate_api.md:
--------------------------------------------------------------------------------
1 | # Polkadot Substrate RUBY API
2 |
3 | ## Project Description
4 |
5 | This is an substrate json-rpc api client and libraries implemented in ruby language for general use. It contains the implementation of low-level data formats, various substrate types and metadata support.
6 |
7 | This work is the prerequisite of our subsequent series of projects. We hope to familiarize and quickly access Polkadot and Substrate through ruby, and use our existing ruby experience to quickly develop applications based on Polkadot / Substrate. We plan to develop some substrate-based web games. The back end of these applications is prepared to be developed in ruby language, and then interact with nodes or synchronize data through rpc.
8 |
9 | ### Why Ruby Substrate API is Good for the Ecosystem
10 |
11 | Ruby is a very elegant language and is very popular among developers. Ruby's development efficiency is very high, so it is widely used in startups and small businesses. Ruby has a very high-quality community, and the Ruby ecosystem is also very mature. If there is a Ruby-based scale codec and API implementation, it will attract many Ruby developers and startups.
12 |
13 | ### Why our Team is Interested
14 |
15 | We have accumulated a lot of experience with Polkadot and Substrate, and think that Substrate is the most valuable blockchain framework. We hope to make more attempts on this framework. And many of our colleagues have ruby development experience. In addition, we believe we can complete this project in a timely and efficient manner with the highest quality standards.
16 |
17 | ## Team members
18 | * Aki Wu
19 | * Alex Chien
20 | * Denny Wang
21 | * Bruce Sun
22 |
23 | ## Team Website
24 | https://www.itering.com
25 |
26 | https://darwinia.network/
27 |
28 | ## Team's experience
29 |
30 | - Aki Wu
31 |
32 | Technical expert in blockchain and web development, has been using ruby development since 2011, and have been involved in blockchain development since 2017, and has used ruby to develop tools that connect to blockchain nodes such as Ethereum and Bitcoin.
33 |
34 | - Alex Chien
35 |
36 | Excellent technical expert in blockchain, full stack ruby engineer, has been involved in the technical work of bitcoin and blockchain since 2011, and has participated in the technology development of several open source projects, especially in graphene technology and EVM smart contract technology. Very rich development experience.
37 |
38 | - Denny Wang
39 |
40 | Excellent technical expert in blockchain, core developer of BitShares 1.0, intelligent contract security expert. Now he is mainly engaged in Ethereum's Layer2 network and Polkadot cross-chain related research. He has served as technical leader in several blockchain technology companies.
41 |
42 | - Bruce Sun
43 |
44 | Full-stack developer graduated from NUIST, and has more than 5 years experiences of web development. He worked as a back-end development project for companies such as momo company, ATA, etc. Now he is doing development of blockchain browser and smart contracts.
45 |
46 | Core team is from Itering Tech Co., Ltd.
47 |
48 | Itering has a complete and professional team from technology to operation. The technical department has many senior experts engaged in the development and technical research of blockchain field, and has rich experience in consulting and development on blockchain technology such as public chain technology, Ethereum and smart contract.
49 |
50 | ## Team Code Repos
51 | * https://github.com/itering
52 | * https://github.com/wuminzhe
53 | * https://github.com/darwinia-network
54 | * https://github.com/evolutionlandorg
55 |
56 | ## Team LinkedIn Profiles
57 | * https://www.linkedin.com/in/alex-chien-46448216/
58 | * https://www.linkedin.com/in/denny-wang/
59 | * https://www.linkedin.com/in/sunbobin/
60 |
61 | ## Development Roadmap
62 | ### Milestones
63 |
64 | * M1 (2 weeks): Implement scale codec low level data format
65 |
66 | * M2 (2 weeks): Implement types of substrate, support dynamic type generation from json
67 |
68 | * M3 (2 weeks): Metadata(versioned) support
69 |
70 | * M4 (2 weeks): Full compatibility with native Substrate API
71 |
72 | All milestones will include documents for explaining how to use the features.
73 |
74 | After these are completed, this project will be used in subsequent projects and adjusted according to actual usage, which may include: better exception handling, and add support for other substrate-based chains.
75 |
76 | ## Additional Information
77 |
78 | ### What work has been done so far?
79 |
80 | Substrate encodes data in the "Simple Concatenated Aggregate Little-Endian" (SCALE) data format, as implemented by:
81 | * [parity-scale-codec](https://github.com/paritytech/parity-scale-codec) in Rust
82 | * [@polkadot/types](https://github.com/polkadot-js/api/tree/master/packages/types) in Javascript
83 | * [ChainSafe/gossamer](https://github.com/ChainSafe/gossamer/tree/development/codec) in Go
84 | * [opennetsys/golkadot](https://github.com/opennetsys/golkadot/tree/develop/common/codec) in Go
85 | * [soramitsu/kagome](https://github.com/soramitsu/kagome/tree/master/core/scale) in C++
86 | * [polkascan/py-scale-codec](https://github.com/polkascan/py-scale-codec) in Python
87 |
--------------------------------------------------------------------------------
/grants/speculative/speckleos.md:
--------------------------------------------------------------------------------
1 | # Speckle OS
2 |
3 | ## Project Description
4 |
5 | We are building a universal user interface for Polkadot, Substrate and Web 3. This involves three parts:
6 | 1. Speckle Browser: a front-end browser specialized for a web of connected chains;
7 | 2. Speckle Parachain: a back-end parachain that handles identity, account management and communication; and
8 | 3. Speckle Box: the speckle-ui framework for substrate-based chains.
9 | The front-end that acts as a universal user interface for Polkadot and its parachains. This closest similarity would be Metamask and Status; however, a user interface for a connected web of chains requires significant innovation to the user experience as opposed to an interface for a single chain. As part of this innovation, we will be deploying a parachain back-end to handle account management, identity and communication across the Polkadot Network. Further, this will be repurposed into a general UI framework for substrate-based chains. This will allow substrate chains to quickly deploy their own UI and modify its feature-set to suit their consensus and governance modules.
10 |
11 | ## Team members
12 | 1. Antoine Najjarin (Project Manager/Founder)
13 |
14 | Antoine is the founder and project manager of Speckle OS. He has a history in business development for other Ethereum blockchain projects and has led partnerships with the United Nations World Food Programme and China’s biggest digital retailer, JD.com.
15 | * https://www.linkedin.com/in/antoine-najjarin-904828b5
16 |
17 | 2. Fei Yang (Senior Full-Stack Developer and Blockchain Engineer)
18 | Fei has over 10 years’ experience as a programmer and software engineer. He was previously employed by Bitfinex to develop their Ethfinex platform, and has worked on projects on various blockchains (including Ethereum, Tron and Corda).
19 | * https://www.linkedin.com/in/fyang1024
20 | * https://github.com/fyang1024
21 |
22 | + 1 (Full-time) Senior Full-Stack Developer
23 | + 1 (Part-time) UX/UI Designer
24 |
25 |
26 | ## Team Website
27 | * https://www.speckleos.io/
28 |
29 | ## Legal Structure
30 | * LLC incorporated in Australia
31 |
32 | ## Intended Language of Development
33 | * Javascript (React)
34 |
35 | ## Development Roadmap
36 | * MVP Desktop Application/Browser Extension (3 months of work)
37 |
38 | 1. R&D and Planning for POC 3.0, UI Design and Project Setup (2 weeks)
39 |
40 | Research and planning for the upcoming POC-3 to determine additional features required and amendments to our workflow. In parallel, we will design the user interface and workflow outlines for the feature-sets that connect to the test-net.
41 |
42 | 2. Account Management (2 weeks)
43 | Setup account creation, compatibility with Parity Signer, account management, key generation, local browser storage and key encryption
44 |
45 | 3. Asset Dashboard (1 week)
46 | Setup real-time viewing of assets (requires connection to testnet). Initially, this will be DOTs for the MVP – later scale to native assets on parachains closer to Polkadot’s release.
47 |
48 | 4. Transaction Management (2 weeks)
49 | Facilitate send/receive functions, as well as a viewing of transaction history.
50 |
51 | 5. Governance Participation (3 weeks)
52 | Allow users to view, vote and stake for validators, as well as on-chain governance upgrades.
53 |
54 | 6. Message Signing (1 week)
55 | Allow users to sign messages to interact with dApps on the Polkadot Network.
56 |
57 | 7. Chain switching and curation framework (1 week)
58 | A simple framework for parachain switching and curation, which will be as functional as the POC permits. It will be iteratively upgraded in lock-step with POC releases in Milestone 3.
59 |
60 | ##Future Plans
61 | The Speckle Browser is the first component of the Speckle Universal Interface, and serves as the MVP for connecting to the Polkadot Network. Extended features for the next step of development will include fully-functional parachain switching, universal account management via the Speckle Parachain, full mobile integration, and self-contained light-clients within the Speckle Browser.
62 |
--------------------------------------------------------------------------------
/grants/speculative/speculative.md:
--------------------------------------------------------------------------------
1 | # Speculative Grant Applications
2 |
3 | Please make a pull request to this folder when making an application for speculative [grants](https://github.com/w3f/Web3-collaboration/blob/master/grants/grants.md). Any application that falls into this category is one that we aren't specifically requesting, but you think may be of interest to us.
4 |
5 | Please be sure to include all the necessary details in your application document and please check that you have correctly completed the [pull request template](https://github.com/w3f/Web3-collaboration/blob/master/.github/PULL_REQUEST_TEMPLATE/grant_application.md).
6 |
--------------------------------------------------------------------------------
/grants/speculative/sr25519_port.md:
--------------------------------------------------------------------------------
1 | # SR25519 Ports to C and C#
2 |
3 | ## Project Description
4 |
5 | ### Brief Description
6 |
7 | Currently only one implementation of Sr25519 signing algorithm (a.k.a. Ritstretto255, a.k.a. Schnorrkel-Ristretto) is known and finished: Curve255-dalek in Rust. Also, a C implementation (curve255-donna) was stopped half done in April this year. Also, a Go implementation is mentioned in Ristretto website, but the last commit was done in May this year, and it looks less finished that C implementation.
8 |
9 | We have researched portability of SR25519 into other mainstream languages such as C and C# and conclude that this is possible to do.
10 |
11 | We will deliver SR25519 library implemented in pure C as well as C# that is capable of producing a valid signature and validating a signature. The validity of signature can be verified with an existing Rust library. Also, the libraries should be capable to verify signatures produced by an existing Rust library.
12 |
13 | ### Why SR25519 Ports is Good for the Ecosystem
14 |
15 | Having only one single Rust implementation presents two major portability problems:
16 |
17 | * If Rust cross-compiler is not available (like for many embedded CPUs), linking or pinvoking of Rust library becomes impossible
18 | * When Rust compiler or cross-compiler is available, pinvoking of Rust library is platform dependent and in many cases (e.g. with .NET) is not solved by finding an appropriate compiler: Some additional code tweaks are needed
19 |
20 | Having multiple implementations of SR25519 will allow developers in multiple langauges to integrate with Substrate natively without Rust dependency.
21 |
22 | ### How SR25519 Ports Integrates into Substrate
23 |
24 | SR25519 is one of the signing algorithms Substrate uses. Alexander testnet version uses SR25519 based on Schnorrkel 0.1.1 and Kusama and futher versions of network use SR25519 based on Schnorrkel v.0.8.5, both of which will be implemented within this grant application.
25 |
26 | ### Why our Team is Interested
27 |
28 | We've been working on several Client APIs for Substrate, noticed this portability problem and got interested. This is an exciting problem to solve, and we believe it will make jobs of many Substrate developers easier.
29 |
30 | ## Team members
31 | * Alexander Mitrovich
32 | * Greg Zaytsev
33 | * Maksim Styrgin
34 | * Mikhail Zaicev (professor of Higher Algebra, Moscow State University)
35 |
36 | ## Team Website
37 | * http://usetech.com/blockchain.html
38 |
39 | ## Legal Structure
40 | These details will be shared privately via our Google Form.
41 |
42 | ## Team's experience
43 | Our team members each have more then 15 years of IT experience in managing projects and writing software for product companies and large enterprises alike. We created the Blockchain practice in 2016 and have done dozens of projects for clients across the globe on variety of blochchains, mostly on Ethereum.
44 |
45 | ## Team Code Repos
46 | * https://github.com/usetech-llc/polkadot_api_dotnet
47 | * https://github.com/usetech-llc/polkadot_api_cpp
48 | * https://github.com/usetech-llc/multichain_airdrop
49 | * https://github.com/usetech-llc/neupool
50 | * https://github.com/gregzaitsev/platform-contracts
51 | * https://github.com/gregzaitsev/wasmcharts_page
52 | * https://github.com/gregzaitsev/platform-frontend
53 | * https://github.com/usetech-llc/unicom
54 | * https://github.com/usetech-llc/votingrelay
55 | * https://github.com/usetech-llc/forever_coin
56 | * https://github.com/usetech-llc/taklimakan-network
57 |
58 | ## Team LinkedIn Profiles
59 | * https://www.linkedin.com/in/alexandermitrovich/
60 | * https://www.linkedin.com/comm/in/gregory-zaitsev-95ba633
61 |
62 | ## Development Roadmap
63 | Project roadmap and financial plan will be shared privately via Google Form.
64 |
65 | Long term plans start with developing APIs for all mainstream languages as well as in-depth API improvement. As Polkadot community high level usecases evolve, API will adapt.
66 |
67 | Also, our team plans to implement broader spectrum of applications such as
68 |
69 | * Decentralized Non-Fungible Token Exchange
70 | * Multi-chain token issuance
71 | * Cross-chain Payment Gateways
72 | * etc.
73 |
74 | ## Additional Information
75 |
76 | ### What work has been done so far?
77 |
78 | C++ and C# APIs are delivered. Source code and documentation are available at these public repositories:
79 | * https://github.com/usetech-llc/polkadot_api_cpp
80 | * https://github.com/usetech-llc/polkadot_api_dotnet
81 |
82 | ### Are there any other projects similar to yours? How is our project different?
83 |
84 | 1. Ristretto255 C Implementation by Frank Denis - does not cover SR25519
85 | https://download.libsodium.org/doc/advanced/point-arithmetic/ristretto
86 |
87 | 2. C implementation by Isis Agora, unfinished and stopped (Isis kindly confirmed she does not have an intention to finish it):
88 | https://github.com/isislovecruft/ristretto-donna
89 |
90 | C# implementation is not covered by anyone yet.
91 |
--------------------------------------------------------------------------------
/grants/speculative/subscan_grant_application.md:
--------------------------------------------------------------------------------
1 | # Subscan Essential
2 |
3 | ## Project Description
4 | Subscan(https://www.subscan.io/) is a popular blockchain explorer for Substrate based blockchains, it supports various projects including Polkadot CC1, Kusama, Darwinia Crab, Edgeware, Plasm, Acala Mandala etc. We are planning to provide a cloud hosting explorers for Substrate developers to easily deploy explorers for their blockchain, and can flexiblity config and display their domain-specific SRML using Subscan explorer plugin frameworks besides standard runtime modules.
5 |
6 | By integrating numerous components into Subscan, we believe Subscan can help developers improve their efficiency substantially by eliminating the need to develop and host explorers.
7 |
8 | Scope of this grant will include some essentials components used by Subscan:
9 |
10 | * Explorer's common shared indexing and querying service for generalized Substrate types(e.g. Block, Extrinsic, Event, Log, Storage), support any blockchain which is Substrate based.
11 | * Subscan explorer plugin framework and an explorer plugin template.
12 |
13 | This project is to build the Substrate explorer infrastructure and reduces the development cost for Substrate developers. It is consistent with the Substrate framework and standards. Blockchain developers can better focus on application layer development, and at the same time, Subscan explorer's fast and agile support can meet the flexible requirement of the development stage and promotion stage.
14 |
15 | ## Team members
16 | * Yakio Liu, product manager
17 | * Carl Hong, full-stack developer, project outreach
18 | * Bruce Sun, experienced devops and backend developer
19 | * Bei Wan, experienced front-end developer
20 | * Dre, graphic/UX designer
21 | * Denny, architecture consultant
22 |
23 | ## Team Website
24 | * Explorer: https://www.subscan.io
25 | * Medium: https://medium.com/@subscan_io
26 | * Twitter: https://twitter.com/subscan_io
27 |
28 | ## Legal Structure
29 | Shanghai Yitaiyuan Co. LTD
30 |
31 | ## Team's experience
32 | Our team has many years of blockchain development experience. We are familiar with the Substrate framework and polkadot ecology, and have been actively participating in ecological development. Currently, it is focused on the research and development of explorer.
33 |
34 | ## Team Code Repos
35 | https://github.com/itering/subscan-essentials
36 |
37 | ## Team LinkedIn Profiles
38 | * Bruce Sun: https://www.linkedin.com/in/sunbobin/
39 | * Denny: https://www.linkedin.com/in/denny-wang/
40 |
41 | ## Development Roadmap
42 |
43 | ### Milestone 1 — Subscan explorer's common components — 1 month — $15,000
44 | * Subcan explorer's common components supporting Substrate general types and datas, can be used by any Substrate based blockchain.
45 | * A basic indexing and querying framework implemented in Golang
46 | * Querying service including Block, Extrinsic, Event, Log, Runtime Metadata, indexing the data from Substrate node to relational database (e.g. postgresql)
47 | * Basic web user interface to query the indexed datas.
48 | * Docker image to setup basic explorer service.
49 | * Documentations for developers to get started and configration.
50 |
51 | ### Milestone 2 — SRML explorer plugin framework — 1 month — $15,000
52 | * An explorer plugin framework paring with Substrate to provide the flexibility of providing customized explorer plugin for various SRML.
53 | * Framework Specification
54 | * Runtime module metadata and types preprocessing and schema auto generating specification
55 | * Extrinsic dispatch call parsing and indexing solution, using signed extension metadata definition
56 | * Example of using customize module rpc call to providing data for module explorer plugin
57 | * Basic Implementation of the framework
58 | * Indexing and parsing *Extrinsic* calls according to dispatch call definition from decl_module! macro.
59 | * Indexing and parsing Events, Errors, Logs according decl_event!, decl_error!, Block Digest definition
60 | * Basic View Control Support: Table Control
61 | * Custom Data/Storage Parsing API and Data Processing API Specification
62 | * Module plugin template (Balance)
63 | * Follow the framework specification and implementing a sample plugin which can work with it. (A plugin for Substrate balance module)
64 | * Deployer can select the plugin through web interface
65 | * Docker image demonstrating its functionality.
66 | * Documentations for deployers.
67 |
68 | 30,000 USD in total, we are willing to accept up to 50% of payment in vested DOTs.
69 |
70 | ### Open-source license
71 | Each component in this grant scope will be open sourced, all required code to leverage the components in this grant scope will be open sourced as well. We plan to open source more components of Subscan Essential in the future. The license is GNU GPL v3.
72 |
73 | ## Future Plans
74 | Subscan is a complex product, we've been building it for 10 months and we can only cover core features during the 3-month period. We would like to combine the components into upcoming Subscan cloud services, and will continue working on Subscan explorer in the future to make it more complete and mature.
75 |
76 | We are optimistic about the prospects of Substrate and will maintain good communication with the Substrate community and developers. We are striving to provide high-quality Explorer Instance cloud services for chains based on Substrate. At the same time, developers can earn income by developing an explorer extension for SRML module via our explorer platform, which may become a new business model in the future. Subscan will always support the update of Substrate and grow together.
77 |
78 | We hope this project will benefit Substrate ecological developers.
79 |
80 |
--------------------------------------------------------------------------------
/grants/speculative/substrate x (prometheus + grafana) by B-Harvest.md:
--------------------------------------------------------------------------------
1 | # substrate x (prometheus + grafana) by B-Harvest
2 |
3 | ## Project Description
4 |
5 | - general initiative
6 | - substrate should provide more general information exporter inside the module so that users can expand their monitoring tool in various ways.
7 | - telemetry has already customized feature and it is difficult to expand such potential use-cases using existing tools.
8 |
9 | - substrate module expansion(prometheus exporter built in substrate)
10 | - objective : we hack substrate so that it can stream node/blockchain information by prometheus as a default feature of substrate.
11 | - why : telemetry does not provide user customization for monitoring and alarming. therefore we want to provide any node operator of substrate base blockchain one of the most general and customizable node monitoring/alarming platform, prometheus.
12 |
13 | - prometheus-grafana easy default implementation for nodes monitoring center
14 | - objective : we provide validator/collator community basic prometheus-grafana implementation with various parameters and easy installation.
15 | - why : we want to provide high standard of node monitoring and alarming capability to substrate base blockchain node operators by easy implementation of prometheus-grafana.
16 |
17 | - potential expansion of the project
18 | - support monitoring and alarming of various economic activities on the relay chain and parachains, including transaction and state change monitoring.
19 | - connecting prometheus to Grafana for better visualization and query functionality, which will significantly upgrade node operator's post-event analytic abilities on stability of node operation.
20 | - expansion of this project will greatly benefit blockchain statistics explorer on substrate base blockchains.
21 |
22 | ## Team members
23 |
24 | - Hyungyeon Lee: B-Harvest Team CEO, spec design
25 | - Jeseon Lee: B-Harvest Team Engineer, major development
26 | - Dongsam Byun: B-Harvest Team Engineer, development support
27 | - Hyungsuk Kang: Korean Polkadot Ambassador, technical/relationship advisor
28 |
29 |
30 | ## Team Website
31 |
32 | -
17 | 
18 |
19 |
20 | You can find more details here:
21 | https://medium.com/layerx/announcing-zerochain-5b08e158355d
22 |
23 | ## Team Members
24 | * Osuke Sudo - Lead
25 | * Ozaki Yoichi
26 |
27 | ## Team Website
28 | https://layerx.co.jp/
29 |
30 | ## Legal Structure
31 | incorporated in Japan
32 |
33 | ## Team's experience
34 | LayerX is a blockchain company which has some separeted teams and projects. Zerochain is one of the focusing R&D project. The lead enginner Osuke has been working as an Ethereum smart contract developer and zero-knowledege proofs developer total for 2 years.
35 |
36 | Osuke’s works on blockchain space are following.
37 | * The first implementation of Plasma in Vyper
38 | * https://github.com/LayerXcom/plasma-mvp-vyper
39 |
40 | * A 64bit-TinyRAM simulator in Go lang (The TinyRAM architecture is a random-access machine designed to be a convenient tool for expressing the correctness of nondeterministic computations like zk-SNARKs.)
41 | * https://github.com/LayerXcom/gram
42 |
43 | * A Solidity implementation of the zk-STARKs verifier for a MiMC calculation (incomplete)
44 | * https://github.com/LayerXcom/stark-sol
45 |
46 | * A zk-STARK implementation for fibonacci sequence in C++ and executing in Rust (using libstark)
47 | * C++: https://github.com/LayerXcom/libSTARK/tree/macOS/fibonacchiseq
48 | * Rust: https://github.com/osuketh/stark-rust
49 |
50 | ## Team Code Repos
51 | * Zerochain: https://github.com/LayerXcom/zero-chain
52 | * A UI for Zerochain: https://github.com/LayerXcom/zero-chain-ui
53 |
54 | ## Team LinkedIn Profiles
55 | We are not on LinkedIn.
56 |
57 | ## Development Roadmap
58 | The milestones are spread out over a total of 3 months as following:
59 | * M1: Generating transaction on a browser as a (kind of) wasm wallet (2 weeks)
60 | * M2: Implementation of a runtime module for confidential transfer fees (2 weeks)
61 | * M3: Protecting from front running attacks (2 weeks)
62 | * M4: Implementation of a runtime module for confidential fungible assets (2 weeks)
63 | * M5: Implementation of anonymous transactions (4 weeks)
64 |
65 | In addition, we will research and implement the small PoC for the new zero-knowledge proofs like SONICs, zkSTARKs and Bulletproof for eliminating the trusted setup problem of the current zk-SNARKs.
66 | We don’t include, however, these into the above milestones because it would take more time and not fix the specification yet.
67 |
68 | ## Additional Information
69 | ### What work has been done so far?
70 | Implementing the MVP for confidential payment on Substrate.
71 |
72 | ### Have you applied for other grants so far?
73 | No.
74 |
75 | ### Are there any other projects similar to yours?
76 | * In terms of zero-knowlege proofs: Zcash, Monero, Grin
77 |
78 | * In terms of privacy for substrate: [Substrate sgx proposal](https://github.com/w3f/Web3-collaboration/blob/master/grants/speculative/substrate_sgx_proposal.md)
79 |
--------------------------------------------------------------------------------
/rfps/candle-auction.md:
--------------------------------------------------------------------------------
1 | # Candle auction smart contract
2 |
3 | * **Status:** Open
4 | * **Proposer:** [mmagician](https://github.com/mmagician)
5 |
6 |
7 | ## Project Description :page_facing_up:
8 |
9 | Auctions will come in handy for various types of applications, but especially for NFTs.
10 |
11 | The idea behind this proposal is to create an `ink!` smart contract that is able to run a candle auction mechanism. This will be known to Polkadot followers from the [parachain auction mechanism](https://wiki.polkadot.network/docs/en/learn-auction). One of the advantages of the candle mechanism is that it incentivises bidders to submit their true bids early, thus leading to more optimal market.
12 |
13 | Rather than restricting the use of candle auctions to parachain slot allocation only, users should be able to utilise it for other needs, e.g. auctioning off their NFTs.
14 |
15 | Such a smart contract could have specific call logic embedded and give the winner the right to execute that logic (with supplied parameters). For example, the smart contract could own an asset, and such call logic could transfer such asset to whichever account the winners supplies.
16 |
17 | ## Deliverables :nut_and_bolt:
18 |
19 | * **Total Estimated Duration:** 1 month
20 | * **Full-time equivalent (FTE):** 1
21 |
22 | ### Milestone 1 - Basic auction
23 |
24 | * **Estimated Duration:** 3 weeks
25 | * **Costs:** 7500 DAI
26 |
27 |
28 | | Number | Deliverable | Specification |
29 | | ------------- | ------------- | ------------- |
30 | | 1. | Start & close period | Create an auction mechanism that has a fixed start and end period |
31 | | 2. | Accept bids | Any user can call the contract with a bid that is higher than the last highest bid |
32 | | 3. | Find winner | Determine a winner at the close period |
33 | | 4. | Embed reward logic | The contract creator should set logic that will be executable by the winner. Such call logic should accept optional parameters. This logic should be set at the start and be immutable henceforth |
34 | | 5. | Payout | A winner should be able to make a call, with an arbitrary number of parameters, to the reward/payout method. The contract would then pass the arguments to whichever logic is encoded as the reward (and e.g. send tokens) |
35 |
36 | ### Milestone 2 - Random close
37 |
38 | * **Estimated Duration:** 1 weeks
39 | * **Costs:** 2500 DAI
40 |
41 |
42 | | Number | Deliverable | Specification |
43 | | ------------- | ------------- | ------------- |
44 | | 1. | Retroactive close | At the close block, rather than announcing the highest bidder at that point, the contract should randomly determine a block in the past (between start & end blocks) and calculate the highest bidder at that block to be the winner |
45 | | 2. | Randomness source (optional) | Randomness source should be configurable (e.g. from hash of the block in the relay chain, from a randomness beacon parachain etc.)
46 |
47 |
--------------------------------------------------------------------------------
/rfps/implementation-benchmarking.md:
--------------------------------------------------------------------------------
1 | # ink!/pallet/solidity performance benchmarking
2 |
3 | * **Status:** Open
4 | * **Proposer:** [mmagician](https://github.com/mmagician)
5 |
6 |
7 | ## Project Description :page_facing_up:
8 |
9 | When a new team comes to the ecosystem, they are faced with a decision on how to best implement the logic that they need.
10 | Traditionally in substrate, this has been a choice between a smart contract vs. runtime module (a.k.a. pallet) and elaborated on [in this StackOverflow question](https://stackoverflow.com/questions/56040779/when-should-i-build-a-substrate-runtime-module-versus-a-substrate-smart-contract) or [this entry in Substrate Developer Hub](https://substrate.dev/docs/en/knowledgebase/smart-contracts/#smart-contracts-vs-runtime-development). The choice has since been augmented by the possibility to deploy solidity contracts to an EVM-compatible chain, or even writing solidity code and compiling it to WASM with the help of a [solang](https://solang.readthedocs.io/en/latest) compiler.
11 |
12 | As substrate is gaining traction, more and more tools will enable developers to write their logic in their language of choice and deploy on-chain, such as:
13 | - Move: [diem on polkadot](https://docs.pontem.network), PoC finished
14 | - Yatima: [pure functional language for web3](https://github.com/w3f/Open-Grants-Program/pull/463), application in progress
15 |
16 | This RFP calls for a benchmarking effort to help inform newcomers about the choice of the best tool for writing application logic.
17 | Apart from quantifiable metrics, we would like the outcome of this work to be a guide for developers, perhaps expanding on the aforementioned StackOverflow post. Depending on the outcome, the work might get integrated into our READMEs/wikis.
18 |
19 | Before starting this effort, it might make sense to take a look at the official [runtime benchmarking docs](https://substrate.dev/docs/en/knowledgebase/runtime/benchmarking) to assess whether it can be leveraged in some way.
20 |
21 | ## Deliverables :nut_and_bolt:
22 |
23 | * **Total Estimated Duration:** 4 weeks
24 | * **Full-time equivalent (FTE):** 1
25 | * **Total Costs:** 10,000 DAI
26 |
27 | ### Milestone 1 - Basic benchmarking
28 |
29 | * **Estimated Duration:** 2 weeks
30 | * **Costs:** 5000 DAI
31 |
32 |
33 | | Number | Deliverable | Specification |
34 | |--------|----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
35 | | 1. | Devise performance metrics | List the quantifiable metrics that can be compared across different implementations, such as storage footprint and execution speed. |
36 | | 2. | Pallets: basic read & write | Create a pallet which exposes simple methods for writing to storage and reading from on-chain storage. Should be implemented for basic types. |
37 | | 3. | `ink!`: basic read & write | As above, but for smart contracts |
38 | | 4. | Benchmarking framework | Create a set of tools that allows calling both the pallet's extrinsics and contract's public methods multiple times, measuring the execution time, impact on on-chain storage etc., to enable extraction of statistically meaningful data for performance comparison |
39 |
40 | ### Milestone 2 - Integrate native solidity & `solang`-compiled solidity
41 |
42 | * **Estimated Duration:** 2 weeks
43 | * **Costs:** 5000 DAI
44 |
45 | | Number | Deliverable | Specification | |
46 | |--------|---------------------------------------|--------------------------------------------------|---|
47 | | 1. | "native" solidity: basic read & write | As per previous milestone | |
48 | | 2. | WASM-compiled solidity | As per previous milestone | |
49 | | 3. | Adapt the benchmarking framework | Include both flavours of solidity into the tools | |
50 | | | | | |
51 | | | | | |
52 |
53 | ### Milestone 3 - More complex application logic
54 |
55 | Apart from just reading & writing basic types, all the above implementations should be extended to include more complex logic. The scope is up to the implementers, but here are some ideas:
56 | - cross-contract calls
57 | - emitting events
58 | - storage-agnostic logic (self-contained methods performing e.g. some heavy computation)
59 |
60 | The cost is scope dependent.
61 |
--------------------------------------------------------------------------------
/rfps/implemented/ksm-tipping-button.md:
--------------------------------------------------------------------------------
1 | # Tip or Donate KSM Embeddable Button
2 |
3 | * **Status:** [Implemented](https://github.com/Shard-Labs/kusama-tips-widget)
4 | * **Proposer:** swader
5 |
6 | ## Project Description :page_facing_up:
7 |
8 | This is a request for proposals to build an embeddable self-contained "Propose tip or Donate KSM" button for websites.
9 |
10 | The applying team is more than welcome to apply through [open grants](https://github.com/w3f/Open-Grants-Program), or [the Kusama Treasury itself](https://wiki.polkadot.network/docs/en/learn-treasury#creating-a-treasury-proposal).
11 |
12 | ## The Tipping System
13 |
14 | Most Substrate-based chains like Polkadot and Kusama have an on-chain treasury. This treasury is filled from transaction fees, slashes, inflation, and donations. The treasury supports three different disbursement mechanisms: proposals, bounties, and tips. This RFP deals with Tips.
15 |
16 | Anyone can propose a tip. The proposer becomes the finder, and receives a small fee if the tip is accepted. The Council votes on the tip by members seconding it with an arbitrary amount. The final amount to pay out is the median of all the amounts given by all Council members.
17 |
18 | The tip begins its closing process (a countdown) when more than a half of councilors have seconded a tip. During this countdown, the remaining members can still submit their tips, but don't have to. After the countdown has elapsed, the `close_tip` extrinsic has to be called (by anyone) to perform the actual payout.
19 |
20 | ## Proposal
21 |
22 | The Kusama Tip Button sould be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
23 |
24 | Before the user interacts with the button, the button's embedded code should:
25 |
26 | 1. Sanitize the current URL (remove UTM, hashes, alphabetically order query params, etc.)
27 | 2. Convert this URL to bytes
28 | 3. Check if a tip for the same URL already exists and IS ACTIVE (past tips for the same URL are OK)
29 | - if yes, grey out button and make it unavailable with the text "Tip already pending - click to see", linking to http://kusama.dotapps.io/#/treasury/tips (text customizable by website owner)
30 | - if no, button is available.
31 |
32 | Once clicked, the button should:
33 |
34 | - ask for permission to connect to PolkadotJS extension
35 | - if none is present, offer to install it (take user to Github page)
36 | - if allowed, a popup appears asking to "select an account"
37 | - if denied, cancel all
38 | - offer two options: Propose Tip and Donate Directly (text customizable by website owner)
39 | - Propose Tip
40 | - clearly inform visitor that they need to have enough funds for both a fee AND a deposit, and that they will only get the deposit back after the tip has been paid out, which doesn't have to ever happen.
41 | - if current user is a Council member, ask for amount and then create a new Tip entry with treasury.tip_new
42 | - if current user is not in Council, create a new Tip entry with treasury.report_awesome.
43 | - Optionally allow visitor to attach a message. If provided, use utility.batch to batch the tip creation with system.remark. Final system remark is: "Tip for URL: MESSAGE FROM TIPPER".
44 | - re-execute "tip exists" check to disable button and link to Tips page in treasury
45 | - Donate
46 | - ask visitor for amount
47 | - wrap Transfer in utility.batch function along with a system.remark. (not optional, always wrap)
48 | - allow visitor to enter a custom note
49 | - final system remark is "Donation for URL: MESSAGE FROM TIPPER".
50 |
51 | ## Challenges
52 |
53 | ### Performance
54 |
55 | Websites must not be notably slowed down by this implementation. This is especially challenging because the button's code needs to do some checking well before a visitor interacts with it. Gating the approach more (i.e. behind an additional "Tipping" button) would degrade UX, especially if the click requires a long load and check time before even allowing progress into the Tip or Donate area.
56 |
57 | Ideally, the code would be a minimal extraction of PolkadotJS API, or even slimmer standalone version, which could do the check painlessly. The tipping code itself can then be bigger and be async loaded only once a visitor interacts with the button. We assume the vast majority of users never will, so this is an acceptable tradeoff, but we welcome creative solutions to this problem.
58 |
59 | ### Tip Spam
60 |
61 | It is reasonable to assume that highly popular websites will, in time, have many users wanting to create tips for them. The tip-existence check helps with that, but it does not help with minor URL modifications (i.e. no-effect query params) or tipping every page on a website.
62 |
63 | The fee and deposit to create a Tip should take care of this problem.
64 |
--------------------------------------------------------------------------------
/rfps/implemented/staking-rewards-collector-front-end.md:
--------------------------------------------------------------------------------
1 | # Front-End for Staking Rewards Collector
2 |
3 | * **Status:** Implemented: [Repo 1, finished](https://github.com/w3f/Open-Grants-Program/blob/master/applications/cryptolab-staking-reward-collector-front-end.md), [Repo 2, in progress](https://github.com/w3f/Open-Grants-Program/blob/master/applications/staking-rewards-collector-front-end.md)
4 | * **Proposer:** JonasW3F
5 | * **Your Project(s):** -
6 | * **Projects you think this work could be useful for** Staking operations of all nominators and validators.
7 | * **Teams/People that could deliver the RFP** -
8 |
9 | ## Project Description :page_facing_up:
10 |
11 | The [staking-rewards-collector](https://github.com/w3f/staking-rewards-collector) is a tool to gather staking rewards for given addresses and cross-reference those with daily price data. This is a very useful tool for every validator and nominator in the ecosystem. However, since it has currently a CLI and requires some technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users getting access to this tool and enjoy the benefits.
12 |
13 | The backend is already written in javascript, this should make it quite easy to host as a website and develope a front-end.
14 |
15 | ## Deliverables :nut_and_bolt:
16 |
17 | In order to apply for the project, we will require you to propose the design in the form of mock-ups.
18 |
19 | - **Implementation of a user interface**:
20 | - **Query input parameters (from the users)**:
21 | - Addresses (multiple ones are supported by the code).
22 | - Start and end date
23 | - Does the user want price data linked to staking rewards?
24 | - What are the startBalances of each address?
25 |
26 | - **Data output viewer**:
27 | - The code produces a .csv and .json file which should be displayed in the browser.
28 | - Visualization for the varying number of input addresses.
29 | - Some sorting based on network / amount.
30 | - Search for specific entries like dates.
31 | - Option to download to local storage.
32 | - **Help page / buttons:**
33 | - Both the input query and output viewer should have several help buttons to give explanations for all users.
34 |
35 | - **Compatibility**:
36 | - It should be easy to extend the underlying script and the UI should be flexible enough to incorporate that (e.g., adding another column in the data output).
37 | - **Hosting**
38 | - Centralized and preferably decentralized (IPFS).
39 | - **Testing**
40 | - Test if the code behaves as expected.
41 |
42 | * **Total Estimated Duration:** 3 Weeks
43 | * **Full-time equivalent (FTE):** 15 days
44 | * **Total Costs:** 4000 USD (provisional)
45 |
46 | ### Milestone 1 (Implementation)
47 |
48 | * **Estimated Duration:** 9 days
49 | * **FTE:** 9
50 | * **Costs:** 3500 USD
51 |
52 |
53 | | Number | Deliverable | Specification |
54 | | ------------- | ------------- | ------------- |
55 | | 1. | UI for user input | Develop an UI to request necessary data from the users. |
56 | | 2. | UI for data visualizer | Develop an environment to display the output (.csv and .json) for the end user in a pleasurable way. |
57 | | 3. | Help pages / comments | Implement help texts and descriptions for users. |
58 | | 4. | Internal testing | Unit tests covering the functionality and logic |
59 |
60 |
61 | ### Milestone 2 (Testing)
62 |
63 | * **Estimated Duration:** 3 days
64 | * **FTE:** 3 days
65 | * **Costs:** 500 USD
66 |
67 |
68 | | Number | Deliverable | Specification |
69 | | ------------- | ------------- | ------------- |
70 | | 1. | Deployment | Deploy the code on a centralized server and IPFS. |
71 | | 2. | Test live environment | Test the homepage with various different OS and browsers and provide a report |
72 | | 3. | Polishing | Reach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like font size, colors, typos etc. |
73 |
74 |
75 |
--------------------------------------------------------------------------------
/rfps/on-chain-quadratic-funding.md:
--------------------------------------------------------------------------------
1 | # On-chain Quadratic Funding
2 |
3 | * **Status:** Open
4 | * **Proposer:** [Noc2](https://github.com/Noc2)
5 |
6 | ## Project Description :page_facing_up:
7 |
8 | CLR, short for [Constrained Liberal Radicalism algorithm](https://blogchains.org/wp-content/uploads/sites/4/2019/04/SSRN-id3243656.pdf), commonly called quadratic funding (QF), is a way to efficiently fund projects in the Web3 ecosystem. The way it works is that users contribute directly to projects which they value and in doing so, help the projects earn a share of a matching pool of funds. The *number* and amount of each contribution influences the total amount allocated to a project. This means even a small contribution is valuable and can result in a high matched amount.
9 |
10 | [Gitcoin](https://gitcoin.co/) is currently using this mechanism to successfully fund and support public goods. However, Gitcoin is centralized. The goal of this RFP is to develop a decentralized solution on top of [Substrate](https://github.com/paritytech/substrate), which can potentially be integrated into Kusama, Polkadot or any other Substrate-based chain as a pallet. The on-chain treasury could potentially sustainably fund the matching pool in the long-run. However, the Web3 Foundation would also be committed to fund a matching pool of the solution for initial test rounds.
11 |
12 | Key-problems to solve as part of the grant:
13 | 1. **Anti-collusion**
14 | 2. **Sybil resistance**
15 | 3. **User-friendly UI**
16 |
17 |
18 | ## Deliverables :nut_and_bolt:
19 |
20 | The milestones below are just an initial draft. The milestones can be structured completely differently and the implementation can also leverage other tools and infrastructure as long as the overall goal of the RFP is met. Specifically it might make sense to initially start with milestone 3 and leverage centralized solutions for milestone 1 and 2 at the beginning of the project in order to start testing the implementation early.
21 |
22 | ### Milestone 1 - Anti-collusion
23 |
24 | | Number | Deliverable | Specification |
25 | | ------------- | ------------- | ------------- |
26 | | 0a. | License | Apache 2.0 / MIT / Unlicense |
27 | | 0b. | Documentation | Inline documentation of the code and a basic tutorial that explains how a developer can use the project |
28 | | 0c. | Testing Guide | The code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests |
29 | | 0d. | Article/Tutorial | Article or tutorial that explains the work done as part of the grant.
30 | | 1. | Anti-collusion | Implement a mechanism to prevent bribery and collusion, leveraging encrypting votes (ZKPs) potentially via [Minimum Anti-Collusion Infrastructure (MACI)](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) |
31 | | 2. | Voting Example | Integrate a basic voting example that lets you test the mechanism |
32 |
33 |
34 | ### Milestone 2 - Sybil resistance
35 |
36 | | Number | Deliverable | Specification |
37 | | ------------- | ------------- | ------------- |
38 | | 0a. | License | Apache 2.0 / MIT / Unlicense |
39 | | 0b. | Documentation | Inline documentation of the code and a basic tutorial that explains how a developer can use the project|
40 | | 0c. | Testing Guide | The code will have unit-test coverage (min. 70%) to ensure functionality and robustness. In the guide we will describe how to run these tests |
41 | | 0d. | Article/Tutorial | Article or tutorial that explains the work done as part of the grant.
42 | | 1. | Sybil resistance | Mechanism to prevent Sybil attacks, either implemented as its own Substrate pallet or possible integration of the existing on-chain identity on Kusama/Polkadot provided by specified registrar |
43 | | 2. | UI | UI for verification of identities, including a polkadot.js extension support |
44 |
45 | ### Milestone 3 - CLR
46 |
47 | | Number | Deliverable | Specification |
48 | | ------------- | ------------- | ------------- |
49 | | 0a. | License | Apache 2.0 / MIT / Unlicense |
50 | | 0b. | Documentation | Inline documentation of the code and a basic tutorial that explains how a developer can use the project |
51 | | 0c. | Testing Guide | The code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests |
52 | | 0d. | Article/Tutorial | Article or tutorial that explains the work done as part of the grant.
53 | | 1. | CLR pallet(s) | Implement the necessary substrate pallets, potentially containing a Token Curated Registry (TCR) to allow anyone to permissionlessly register eligible recipients each round and DAO to govern the protocol. |
54 | | 2. | Off-chain Storage | Integrate an off-chain storage solution, for example IPFS for storing the applications and information about the grants |
55 | | 2. | Test 1 | Set up a test network and leverage the extrinsics tabs of polkdaot.js to test the implementation and improve it. The Web3 Foundation provides a small matching pool as a incentive. |
56 |
57 | ### Milestone 4 - UI
58 |
59 | | Number | Deliverable | Specification |
60 | | ------------- | ------------- | ------------- |
61 | | 0a. | License | Apache 2.0 / MIT / Unlicense |
62 | | 0b. | Documentation | Inline documentation of the code and a basic tutorial that explains how a developer can use the project |
63 | | 0c. | Testing Guide | The code will have unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests |
64 | | 0d. | Article/Tutorial | Article or tutorial that explains the work done as part of the grant.
65 | | 1. | CLR UI | UI for the whole process (creation and funding of grants), including polkadot.js extension support. |
66 | | 2. | Test 2 | Test the newly created UI. The Web3 Foundation provides another small matching pool as a incentive. |
67 |
68 |
69 |
--------------------------------------------------------------------------------
/rfps/php-api.md:
--------------------------------------------------------------------------------
1 | # PHP Substrate API
2 |
3 | * **Proposer:** [swader](https://github.com/api)
4 | * **Status:** Open
5 |
6 | ## Project Description :page_facing_up:
7 |
8 | The Substrate API is currently most developed in TypeScript and Rust. This RFP is looking for teams willing to implement a PHP version, perhaps in tandem with the PHP SCALE Coded (see relevant RFP).
9 |
10 | The PHP API should:
11 |
12 | - be able to hook into a running Substrate node via WS or HTTP
13 | - read and write to RPC endpoints (will need SCALE codec - see relevant related RFP)
14 |
15 | Optionally, the API should support types as exposed by the API. Supporting types is a long term project as those evolve constantly and differ from chain to chain, so if this road is taken by the applying team, it should be stated in a separate milestone and well defined in added maintenance time and cost (i.e. this is not something that can be delivered once - it would require a long term commitment).
16 |
17 | ## Deliverables :nut_and_bolt:
18 |
19 | The basic deliverable of this project is an API package hosted on Packagist which can instantiate a connection to a Substrate node and talk to constants, chain storage, and RPC endpoints. For inspiration, see the JS version: https://polkadot.js.org/docs
20 |
21 | Example use:
22 |
23 | - reading from RPC
24 |
25 | ```php
26 | $api = new SubstrateApi\Api("websocket_or_http_url");
27 | echo $api->rpc->system->chain(); // Kusama
28 | ```
29 |
30 | - writing a tx:
31 |
32 | ```php
33 | $api = new SubstrateApi\Api("websocket_or_http_url");
34 | $signer = new SubstrateApi\Keyring\Signer("privatekey");
35 | $api->setSigner($signer);
36 | $tx = $api->tx->balances->transfer("recipient_address", 10000);
37 | $tx->signAndSend();
38 | ```
39 |
40 | ## Notes
41 |
42 | - look into https://github.com/paritytech/scale-info
43 |
--------------------------------------------------------------------------------
/rfps/php-scale.md:
--------------------------------------------------------------------------------
1 | # PHP Version of SCALE Codec
2 |
3 | * **Proposer:** [swader](https://github.com/swader)
4 | * **Status:** [In progress](https://github.com/w3f/Open-Grants-Program/blob/master/applications/php-scale-lib.md)
5 |
6 | ## Project Description :page_facing_up:
7 |
8 | The SCALE codec is the de-factor encoding method in Substrate-based chains. It is necessary for APIs to be able to communicate with a running node. There are several implementations already available in the wild, all listed [here](https://substrate.dev/docs/en/knowledgebase/advanced/codec). This proposal is for a team to build a PHP version.
9 |
10 | ## Deliverables :nut_and_bolt:
11 |
12 | The deliverable should be a standalone SCALE codec package, hosted on Packagist. It can (but does not have to) depend on existing Base58 packages already present on Packagist.org.
13 |
14 | The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusivley a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone.
15 |
--------------------------------------------------------------------------------
/rfps/scale-codec-comparator.md:
--------------------------------------------------------------------------------
1 | # SCALE Codec Comparator
2 |
3 | * **Status:** [In progress](https://github.com/arijitAD/dotscale) for Golang, submissions for other languages welcome
4 | * **Proposer:** [Marcin Górny](https://github.com/mmagician/)
5 |
6 | ## Project Description :page_facing_up:
7 |
8 | To date, there are [9 published](https://substrate.dev/docs/en/knowledgebase/advanced/codec#implementations) implementations of the SCALE Codec. Since each is implemented by a different team & [the reference implementation](https://github.com/paritytech/parity-scale-codec) still introduces small fixes, it would be beneficial to compile a table of feature-completeness.
9 | This would provide (some) assurance that the implementation in a given language is safe & sound to use.
10 |
11 | One approach would be to provide wrappers to the Rust reference implementation, like in [scale.rb](https://github.com/itering/scale.rb/blob/develop/src/lib.rs) and using the Foreign Function Interface (e.g. [here](https://github.com/itering/scale.rb/blob/develop/spec/ffi_helper.rb)) to call these directly from within the library.
12 |
13 | Stage 2: To take this a step further, a GitHub action could be integrated to run all native unit tests also against the Rust lib. For repos which provide feature completeness & pass all relevant tests, a SCALE specific badge could be awarded.
14 |
15 | ## Deliverables :nut_and_bolt:
16 |
17 | * **Total Estimated Duration:** 2+ months
18 | * **Full-time equivalent (FTE):** 1
19 | * **Total Costs:** ~ 12,000 DAI
20 |
21 | ### Milestone 1: Feature-completeness & FFI to Rust
22 |
23 | * **Estimated Duration:** 2 months
24 | * **FTE:** 1
25 | * **Costs:** ~ 10,000 DAI
26 |
27 | For each library listed on [substrate.dev](https://substrate.dev/docs/en/knowledgebase/advanced/codec#implementations):
28 | * Create a PR, providing a FFI to Rust's reference implementation.
29 | * Ensure feature completeness, by ensuring there are comprehensive unit tests for each data type.
30 |
31 | ### Milestone 2: Badge integration
32 |
33 | * **Estimated Duration:** 1 week
34 | * **FTE:** 1
35 | * **Costs:** ~ 2000 DAI
36 |
37 | * Create a GitHub badge for SCALE feature complete libs
38 | * Ensure that each lib listed above has the process of publishing the badge integrated into the CI workflow (e.g. GitHub action to run tests & award badge on successful run)
39 |
40 | Note: The goal is to have your changes merged upstream. While the final decision is taken by the repo owners, you should make sure that your PRs pass all checks specific to each lib, conforms to their contributing guidelines etc.
41 |
--------------------------------------------------------------------------------
/rfps/suggestion-template.md:
--------------------------------------------------------------------------------
1 | # Title of the RFP Proposal
2 |
3 | * **Status:** Open (anyone is allowed to apply) / Closed (invited respondents only) / Implemented (finished)
4 | * **Proposer:** GitHub username
5 | * **Your Project(s):** [optional]: Link(s)
6 | * **Projects you think this work could be useful for** [optional]: Link(s)
7 | * **Teams/People that could deliver the RFP** [optional]: Link(s)
8 |
9 | ## Project Description :page_facing_up:
10 |
11 | Please describe exactly why you are proposing this RFP. Make sure to point out why it’s potentially useful for your project or other projects in the ecosystem.
12 |
13 | ## Deliverables :nut_and_bolt:
14 |
15 | Please list the deliverables of the project in as much detail as possible. Please also estimate the amount of work required and try to divide the project into meaningful milestones.
16 |
17 | * **Total Estimated Duration:** Duration of the whole project
18 | * **Full-time equivalent (FTE):** Amount of time (in days) required for a single person to complete this project ([see](https://en.wikipedia.org/wiki/Full-time_equivalent))
19 | * **Total Costs:** Amount of Payment in USD for the whole project.
20 | ### Milestone 1
21 |
22 | Please add additional milestones in the same way:
23 | * **Estimated Duration:** Duration of milestone 1
24 | * **FTE:** Amount of time (in days) required for a single person to complete this milestone
25 | * **Costs:** Amount of Payment in USD for milestone 1
26 |
27 |
28 | | Number | Deliverable | Specification |
29 | | ------------- | ------------- | ------------- |
30 | | 1. | Title of the deliverable | Please describe the deliverable here as detailed as possible |
31 | | 2. | ... |...|
32 |
--------------------------------------------------------------------------------
/rfps/xcm-tool.md:
--------------------------------------------------------------------------------
1 | # XCM library & tools
2 |
3 | * **Status:** Open
4 | * **Proposer:** [Bryan Chen](https://github.com/xlc)
5 | * **Projects you think this work could be useful for** : Every parachain.
6 |
7 | ## Project Description :page_facing_up:
8 |
9 | XCM is the crosschain communication standard that will be used by all the parachains. Currently XCM is still in early stage but is already support some main usecases such as crosschain transfer of fungible tokens.
10 |
11 | There are currently two major areas of XCM that still awaiting to be improves:
12 |
13 | - Extend & improve [xcm-format](https://github.com/paritytech/xcm-format) to support more use cases
14 | - We have few issues & PRs so we are on track on getting this done but of couse more helps as always welcome
15 | - Implement library & tools to ease the development of XCM related code
16 | - [xtokens](https://github.com/w3f/Open-Grants-Program/blob/master/applications/xtokens.md) handles the fungible asset implement, and we also need simialr one for NFT
17 | - We need some tool to allow developer to test XCM related code: https://github.com/paritytech/polkadot/issues/2544
18 | - To implement more complicated XCM scenarios, we need some tools to help with async programming
19 |
20 | The scope of the new project count be one of:
21 |
22 | - Develop tools to help developer to test XCM related code
23 | - Develop pallets or utility libraies to better handle the async nature of XCM communication
24 | - Develop pallet to handle crosschain transfer of NFT
25 |
26 |
--------------------------------------------------------------------------------
/src/General_Grants_Program.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/General_Grants_Program.png
--------------------------------------------------------------------------------
/src/like.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/like.png
--------------------------------------------------------------------------------
/src/map.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/map.png
--------------------------------------------------------------------------------
/src/medium.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/medium.png
--------------------------------------------------------------------------------
/src/reddit.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/reddit.png
--------------------------------------------------------------------------------
/src/twitter.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/twitter.png
--------------------------------------------------------------------------------
/src/web.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/web.png
--------------------------------------------------------------------------------
/src/youtube-play.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3f/General-Grants-Program/88792d64e87e44c1977ef0135217489f30d3d0a3/src/youtube-play.png
--------------------------------------------------------------------------------
18 |