├── static ├── .nojekyll └── img │ ├── rfp-header.png │ ├── Grants_Program.png │ ├── Web3Foundation.png │ ├── web3 foundation grants_black.jpg │ ├── Learn.svg │ ├── Youtube.svg │ ├── Twitter.svg │ ├── Wiki.svg │ ├── Web.svg │ ├── Reddit.svg │ └── Polkadot_Logo_Horizontal_BlackOnWhite.svg ├── docs ├── index.md ├── RFPs │ ├── Open │ │ ├── img │ │ │ ├── grants_page.png │ │ │ └── grants_details.png │ │ ├── move_smart_contract_pallet.md │ │ ├── validator-setup-maintenance.md │ │ ├── xcm-tool.md │ │ ├── IDE_for_ink_Smart_Contracts.md │ │ ├── ISO_20022.md │ │ ├── ISO_8583.md │ │ ├── anti-collusion_infrastructure.md │ │ ├── alternative-polkadot-js-api-console.md │ │ ├── analysis-website-and-data-platform.md │ │ ├── parachain_validation_conformance_testing.md │ │ ├── sub-consensus.md │ │ ├── Static-Analysis-for-Runtime-Pallets.md │ │ ├── decentralized-security-marketplace.md │ │ ├── data_analysis_tools.md │ │ ├── formal_guarantees_for_grandpa.md │ │ ├── bpf-contracts.md │ │ └── user-account-access-analysis.md │ ├── Under Development │ │ ├── ink_smart_contract_block_explorer.md │ │ ├── multi-chain-block-explorer.md │ │ ├── alternative_polkadot_host_implementations.md │ │ ├── scale-codec-comparator.md │ │ ├── social-recovery-wallet.md │ │ ├── privacy-enhancement-polkadot-extension.md │ │ ├── validator-selection-algorithm.md │ │ └── crowdloan_front_end_template.md │ ├── Closed │ │ ├── php-scale.md │ │ ├── php-api.md │ │ ├── wallet-aggregator-library.md │ │ ├── polkadot-collator-setup.md │ │ ├── candle-auction.md │ │ ├── epassport-zk-validation.md │ │ ├── uncollateralized-stablecoin-research.md │ │ └── staking-rewards-collector-front-end.md │ └── suggestion-template.md ├── Support Docs │ ├── polkadot_stack.md │ ├── grant-badge-guidelines.md │ └── grant_guidelines_per_category.md ├── Process │ ├── milestone_delivery.md │ ├── changes.md │ ├── review.md │ └── how-to-apply.md ├── introduction.md ├── referral-program.md ├── Introduction │ ├── support.md │ ├── levels.md │ ├── ideas.md │ ├── team.md │ └── intro.md ├── process.md ├── contribute.md ├── help.md ├── suggesting.md ├── maintenance.md └── funding.md ├── applications ├── _category_.yml ├── workflow_testing.md ├── halva_bootstrapping.md ├── example-project.md ├── php-scale-lib.md ├── subwallet.md ├── halva_framework.md ├── PolkaKey.md ├── polkadotjs-hardware.md ├── sup.md ├── polkadotjs-ecdsa.md ├── dart-scale-codec.md ├── multisignature_management_tool.md ├── php-rpc-lib.md ├── ink-boxes.md └── java-client.md ├── babel.config.js ├── src ├── components │ ├── HomepageFeatures.module.css │ └── HomepageFeatures.js ├── pages │ ├── index.module.css │ └── index.js └── css │ └── custom.css ├── .github ├── workflows │ ├── ready_for_review.yml │ ├── stale_checker.yml │ ├── publish.yml │ ├── application_approved.yml │ ├── check_application_document.yml │ ├── label_comment.yml │ ├── codeql.yml │ └── README.md ├── PULL_REQUEST_TEMPLATE │ └── rfp_pr_template.md └── pull_request_template.md ├── .gitignore ├── package.json └── sidebars.js /static/.nojekyll: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | draft: true 3 | --- 4 | 5 | -------------------------------------------------------------------------------- /applications/_category_.yml: -------------------------------------------------------------------------------- 1 | position: 12 2 | label: 'List of Grants' -------------------------------------------------------------------------------- /static/img/rfp-header.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CoR/Grants-Program/master/static/img/rfp-header.png -------------------------------------------------------------------------------- /babel.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | presets: [require.resolve('@docusaurus/core/lib/babel/preset')], 3 | }; 4 | -------------------------------------------------------------------------------- /static/img/Grants_Program.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CoR/Grants-Program/master/static/img/Grants_Program.png -------------------------------------------------------------------------------- /static/img/Web3Foundation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CoR/Grants-Program/master/static/img/Web3Foundation.png -------------------------------------------------------------------------------- /docs/RFPs/Open/img/grants_page.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CoR/Grants-Program/master/docs/RFPs/Open/img/grants_page.png -------------------------------------------------------------------------------- /docs/RFPs/Open/img/grants_details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CoR/Grants-Program/master/docs/RFPs/Open/img/grants_details.png -------------------------------------------------------------------------------- /static/img/web3 foundation grants_black.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CoR/Grants-Program/master/static/img/web3 foundation grants_black.jpg -------------------------------------------------------------------------------- /docs/Support Docs/polkadot_stack.md: -------------------------------------------------------------------------------- 1 | # Open Source Polkadot Stack 2 | 3 | This document has been deprecated in favour of the [Open Source Polkadot Stack as part of the Polkadot Wiki](https://wiki.polkadot.network/docs/build-open-source). 4 | -------------------------------------------------------------------------------- /src/components/HomepageFeatures.module.css: -------------------------------------------------------------------------------- 1 | /* stylelint-disable docusaurus/copyright-header */ 2 | 3 | .features { 4 | display: flex; 5 | align-items: center; 6 | padding: 2rem 0; 7 | width: 100%; 8 | } 9 | 10 | .featureSvg { 11 | background-color: white; 12 | height: 200px; 13 | width: 200px; 14 | } 15 | -------------------------------------------------------------------------------- /docs/Process/milestone_delivery.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 3 3 | title: 3. Delivery and Payment 4 | --- 5 | 6 | 7 | 8 | Milestones are to be delivered via the [Grant Milestone Delivery](https://github.com/w3f/Grant-Milestone-Delivery/) repository following the [process](https://github.com/w3f/Grant-Milestone-Delivery#mailbox-milestone-delivery-process) described therein. 9 | -------------------------------------------------------------------------------- /applications/workflow_testing.md: -------------------------------------------------------------------------------- 1 | # DuoSwap Module 2 | 3 | * **Team Name:** Duo 4 | * **Payment Address:** 123mp123 5 | 6 | ### Contact 7 | * **Contact Name:** John Brown 8 | * **Contact Email:** john@duo.com 9 | 10 | ### Legal Structure 11 | * **Registered Address:** High Street 1, London LK1 234, UK 12 | * **Registered Legal Entity:** Duo Ltd. 13 | 14 | ### Overview 15 | * **Total Estimated Duration:** 2 months 16 | * **Total Costs:** 0.80 btc 17 | 18 | -------------------------------------------------------------------------------- /src/pages/index.module.css: -------------------------------------------------------------------------------- 1 | /* stylelint-disable docusaurus/copyright-header */ 2 | 3 | /** 4 | * CSS files with the .module.css suffix will be treated as CSS modules 5 | * and scoped locally. 6 | */ 7 | 8 | .heroBanner { 9 | padding: 20vh 0; 10 | text-align: center; 11 | position: relative; 12 | overflow: hidden; 13 | } 14 | 15 | @media screen and (max-width: 966px) { 16 | .heroBanner { 17 | padding: 2rem; 18 | } 19 | } 20 | 21 | .buttons { 22 | display: flex; 23 | align-items: center; 24 | justify-content: center; 25 | } 26 | -------------------------------------------------------------------------------- /docs/introduction.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Introduction 3 | --- 4 | 5 | # 👋 Introduction 6 | 7 | As part of our commitment to promoting the Web3 ecosystem, we offer a comprehensive grants program focused on funding software development and research efforts related to **Polkadot and Kusama**. For more information about the Web3 Foundation, please visit the [About page](https://web3.foundation/about/) on our website. 8 | 9 | The following pages describe the scope, intentions and processes behind the W3F grants program. Please familiarize yourself and, if you have a project you would like to present, [apply!](process.md) 10 | -------------------------------------------------------------------------------- /static/img/Learn.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.github/workflows/ready_for_review.yml: -------------------------------------------------------------------------------- 1 | name: Ready for Review notification 2 | 3 | on: 4 | pull_request_target: 5 | types: [ready_for_review] 6 | 7 | jobs: 8 | send_matrix_review_msg: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: fadenb/matrix-chat-message@v0.0.6 12 | with: 13 | homeserver: 'matrix.web3.foundation' 14 | token: ${{ secrets.MATRIX_TOKEN }} 15 | channel: ${{ secrets.MATRIX_CHANNEL_ID }} 16 | message: | 17 | PR READY FOR REVIEW: [${{ github.event.pull_request.title }}](https://github.com/w3f/Grants-Program/pull/${{ github.event.pull_request.number }}) is ready for review. Labeled by ${{ github.event.sender.login }}; -------------------------------------------------------------------------------- /docs/RFPs/Under Development/ink_smart_contract_block_explorer.md: -------------------------------------------------------------------------------- 1 | # RFP: ink! block explorer 2 | 3 | * **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_explorer.md) 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | We are looking for a team or multiple teams to implement [ink! smart contract](https://paritytech.github.io/ink/) block explorer. Ink! is a domain specific language for writing smart contracts in Rust and compiles to Wasm code. 9 | 10 | ## Deliverables 11 | 12 | The structure of the grant and the milestones depends highly on the supported features of the block explorer. 13 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md: -------------------------------------------------------------------------------- 1 | # Request for Proposals 2 | 3 | ## Abstract 4 | 5 | > Provide a brief description of your idea here (1-2 paragraphs). 6 | > 7 | > The details should be in the RFP document that is being added to the repository via this pull request. 8 | 9 | 10 | ## Background 11 | 12 | > Feel free to provide further information that you find relevant and didn't fit into the RFP template here. 13 | 14 | 15 | ## Checklist 16 | 17 | - [ ] I have checked the [RFPs](https://github.com/w3f/Grants-Program/tree/master/docs/rfps) to make sure this is not a duplicate. 18 | - [ ] I have read and followed the [RFP Suggestion instructions](https://github.com/w3f/Grants-Program#mailbox_with_mail-suggest-a-project). 19 | -------------------------------------------------------------------------------- /.github/workflows/stale_checker.yml: -------------------------------------------------------------------------------- 1 | name: Stale checker 2 | 3 | on: 4 | schedule: 5 | - cron: '0 7 * * *' # run at 7:00 UTC every day 6 | workflow_dispatch: 7 | 8 | jobs: 9 | mark_as_stale: 10 | if: github.repository_owner == 'w3f' 11 | runs-on: ubuntu-latest 12 | steps: 13 | - id: stale 14 | uses: w3f/label-stale-pull-requests@main 15 | with: 16 | context: ${{ toJSON(github) }} 17 | token: ${{ secrets.GITHUB_TOKEN }} 18 | - if: steps.stale.outputs.message != '' 19 | uses: fadenb/matrix-chat-message@v0.0.6 20 | with: 21 | homeserver: 'matrix.web3.foundation' 22 | token: ${{ secrets.MATRIX_TOKEN }} 23 | channel: ${{ secrets.MATRIX_CHANNEL_ID }} 24 | message: | 25 | ${{ steps.stale.outputs.message }} 26 | -------------------------------------------------------------------------------- /static/img/Youtube.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/multi-chain-block-explorer.md: -------------------------------------------------------------------------------- 1 | # Multi-chain Block Explorer 2 | 3 | * **Status:** Open 4 | * **Teams/People that could deliver the RFP:** @clearloop, @carlhong 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | As parachains become an integral part of the Polkadot and Kusama ecosystems, a cross-chain block & accounts explorer becomes all the more useful. 9 | 10 | Some of the functionality that should be covered as part of the development: 11 | - select which chains to view (e.g. default when selecting Kusama is Kusama relay + all its parachains). Should be feasible to select alternative mainnets too. 12 | - input an address and see Tx's on all the selected mainnets, including teleports/XCMs between various parachains 13 | - when a Tx includes a XCM, it should be easy and intuitive to open the relevant block from the other chain(s). 14 | -------------------------------------------------------------------------------- /docs/referral-program.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 7 3 | title: 💰 Referral Program 4 | --- 5 | 6 | We give away 500 USD to each referral of a successful grant application by _anyone having previously worked on a Web3 Foundation grant_ or _a [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors)_. Web3 Foundation and Parity employees do not qualify for the program, even if they previously worked on a grant. 7 | 8 | In order to be eligible for the referral bonus, the application itself must contain the name of the [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors) or the GitHub account of the grantee as well as the payment address for the referral bonus (see the [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md)). Payment is made in Bitcoin, USDT (on Kusama or Polkadot) or USDC/DAI (Ethereum). 9 | -------------------------------------------------------------------------------- /static/img/Twitter.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/Process/changes.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 4 3 | title: 4. Changes to a Grant 4 | --- 5 | 6 | 7 | 8 | - Accepted grant applications can be amended at any time. However, this _necessitates a reevaluation by the committee_ and the same number of approvals as an application (according to the [levels](../Introduction/levels.md)). If your application has been accepted and, during development, you find that your project significantly deviates from the original specification, please open a new pull request that modifies the existing application. This also applies in case of significant delays. 9 | - If your _delivery schedule_ significantly changes, please also open a pull request with an updated timeline. 10 | - If your deliveries are significantly delayed and we cannot get a hold of you, we will terminate the grant (3 approvals required, regardless of level. If a member of the committee creates the termination PR, only 2 more approvals are required). 11 | -------------------------------------------------------------------------------- /docs/Introduction/support.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 4 3 | --- 4 | 5 | # Support 6 | 7 | The scope of our Grants Programs consists of funding and feedback on delivered milestones. This means that we do not provide hands-on support as part of a grant, but if you face specific issues during development, we will do our best and try to direct you to the correct resources. If this sounds like something you would like however, you may also want to apply to Parity's [Substrate Builders Program](https://www.substrate.io/builders-program/), which provides hands-on technical, ecosystem and strategical long-term support and access to extensive resources. You can find general documentation and more information on Substrate on the [Substrate Developer Hub](https://substrate.dev/), and we encourage you to join the [community](https://substrate.dev/en/community) in order to get help with specific issues or to stay up to date with the most recent developments. 8 | 9 | For questions about the grants program itself, see our [FAQ](docs/faq.md#frequently-asked-questions). 10 | -------------------------------------------------------------------------------- /static/img/Wiki.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/Process/review.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 2 3 | title: 2. Review 4 | --- 5 | 6 | 7 | 8 | 1. The [committee](../Introduction/team.md#w3f-grants-committee) can (and usually does) issue comments and request changes on the pull request. 9 | 2. Clarifications and amendments made in the comments _need to be included in the application_. You may address feedback by directly modifying your application and leaving a comment once you're done. Generally, if you don't reply within 2 weeks, the application will be closed due to inactivity, but you're always free to reopen it as long as it hasn't been rejected. 10 | 3. When all requested changes are addressed and the terms and conditions have been signed, someone will mark your application as `ready for review` and share it internally with the rest of the committee. 11 | 4. The application will be accepted and merged as soon as it receives the required number of approvals (see [levels](../Introduction/levels.md)), or closed after two weeks of inactivity. Unless specified otherwise, the day on which it is accepted will be considered the starting date of the project, and will be used to estimate delivery dates. 12 | -------------------------------------------------------------------------------- /docs/Introduction/levels.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 2 3 | title: Grant Levels 4 | --- 5 | 6 | 7 | 8 | The W3F Grants Program offers different grant levels to help you best depending on your current stage. 9 | 10 | ## :hatching_chick: Level 1 (= InstaGrants) 11 | 12 | - **Target:** Individuals & small teams 13 | - **Amount:** Up to $10,000 14 | - **Requirements:** 2 approvals 15 | - **Benefits:** Feedback during application process and evaluation, introduction to related teams/projects 16 | 17 | ## :baby_chick: Level 2 18 | 19 | - **Target:** Small teams/start-ups 20 | - **Amount:** Up to $30,000 21 | - **Requirements:** 3 approvals 22 | - **Benefits:** All of the above + [co-promotion](../Support%20Docs/announcement-guidelines.md), [Grants Program badge](../Support%20Docs/grant-badge-guidelines.md) and fast track to [Substrate Builders Program](https://www.substrate.io/builders-program/) 23 | 24 | ## :rooster: Level 3 25 | 26 | - **Target:** Companies/foundations with a proven track record 27 | - **Amount:** Unlimited 28 | - **Requirements:** 5 approvals (for >$100k: Web3 Foundation Council approval + Pitch call) 29 | - **Benefits:** All of the above + VC introductions 30 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/php-scale.md: -------------------------------------------------------------------------------- 1 | # PHP Version of SCALE Codec 2 | 3 | * **Proposer:** [swader](https://github.com/swader) 4 | * **Status:** [Done](https://github.com/w3f/Grants-Program/pull/235) 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 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: Publish website 2 | 3 | on: 4 | push: 5 | branches: 6 | - master 7 | 8 | jobs: 9 | build: 10 | if: github.repository_owner == 'w3f' 11 | name: build and deploy 12 | runs-on: ubuntu-latest 13 | steps: 14 | - uses: actions/checkout@master 15 | - uses: actions/setup-node@v2 16 | with: 17 | node-version: "16.16.0" 18 | - uses: actions/checkout@v2 19 | with: 20 | fetch-depth: 0 21 | - name: Publish 22 | run: | 23 | git config --global user.email "grants-deployer@users.noreply.github.com" 24 | git config --global user.name "grants-deployer" 25 | echo "machine github.com login grants-deployer password ${{ secrets.ACCESS_KEY }}" > ~/.netrc 26 | yarn && yarn build && GIT_USER=grants-deployer PUBLISHING=true yarn deploy 27 | - if: ${{ failure() }} 28 | uses: fadenb/matrix-chat-message@v0.0.6 29 | with: 30 | homeserver: 'matrix.web3.foundation' 31 | token: ${{ secrets.MATRIX_TOKEN }} 32 | channel: ${{ secrets.MATRIX_CHANNEL_ID }} 33 | message: | 34 | WEBSITE BUILD FAILED: [This](https://github.com/w3f/Grants-Program/commit/${{ github.sha }}) is the last push commit. 35 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | # Created by https://www.toptal.com/developers/gitignore/api/macos,windows 3 | # Edit at https://www.toptal.com/developers/gitignore?templates=macos,windows 4 | 5 | ### macOS ### 6 | # General 7 | .DS_Store 8 | .AppleDouble 9 | .LSOverride 10 | 11 | # Icon must end with two \r 12 | Icon 13 | 14 | 15 | # Thumbnails 16 | ._* 17 | 18 | # Files that might appear in the root of a volume 19 | .DocumentRevisions-V100 20 | .fseventsd 21 | .Spotlight-V100 22 | .TemporaryItems 23 | .Trashes 24 | .VolumeIcon.icns 25 | .com.apple.timemachine.donotpresent 26 | 27 | # Directories potentially created on remote AFP share 28 | .AppleDB 29 | .AppleDesktop 30 | Network Trash Folder 31 | Temporary Items 32 | .apdisk 33 | 34 | ### Windows ### 35 | # Windows thumbnail cache files 36 | Thumbs.db 37 | Thumbs.db:encryptable 38 | ehthumbs.db 39 | ehthumbs_vista.db 40 | 41 | # Dump file 42 | *.stackdump 43 | 44 | # Folder config file 45 | [Dd]esktop.ini 46 | 47 | # Recycle Bin used on file shares 48 | $RECYCLE.BIN/ 49 | 50 | # Windows Installer files 51 | *.cab 52 | *.msi 53 | *.msix 54 | *.msm 55 | *.msp 56 | 57 | # Windows shortcuts 58 | *.lnk 59 | 60 | # End of https://www.toptal.com/developers/gitignore/api/macos,windows 61 | 62 | # IDE settings 63 | .vscode 64 | node_modules 65 | 66 | # docusaurus 67 | build/ 68 | .docusaurus/ -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "grants", 3 | "version": "0.0.0", 4 | "private": true, 5 | "scripts": { 6 | "docusaurus": "docusaurus", 7 | "start": "docusaurus start", 8 | "build": "docusaurus build", 9 | "swizzle": "docusaurus swizzle", 10 | "deploy": "docusaurus deploy", 11 | "clear": "docusaurus clear", 12 | "serve": "docusaurus serve", 13 | "write-translations": "docusaurus write-translations", 14 | "write-heading-ids": "docusaurus write-heading-ids" 15 | }, 16 | "dependencies": { 17 | "@docusaurus/core": "^2.2.0", 18 | "@docusaurus/preset-classic": "^2.2.0", 19 | "@mdx-js/react": "^1.6.22", 20 | "@svgr/webpack": "^7.0.0", 21 | "clsx": "^1.1.1", 22 | "file-loader": "^6.2.0", 23 | "mdx-mermaid": "^1.2.3", 24 | "mermaid": "^10.1.0", 25 | "prettier": "^2.6.2", 26 | "pretty-quick": "^3.1.3", 27 | "prism-react-renderer": "^1.2.1", 28 | "react": "^18.2.0", 29 | "react-countup": "^6.4.0", 30 | "react-dom": "^18.2.0", 31 | "url-loader": "^4.1.1" 32 | }, 33 | "browserslist": { 34 | "production": [ 35 | ">0.5%", 36 | "not dead", 37 | "not op_mini all" 38 | ], 39 | "development": [ 40 | "last 1 chrome version", 41 | "last 1 firefox version", 42 | "last 1 safari version" 43 | ] 44 | } 45 | } 46 | -------------------------------------------------------------------------------- /src/components/HomepageFeatures.js: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import clsx from 'clsx'; 3 | import styles from './HomepageFeatures.module.css'; 4 | import CountUp from 'react-countup'; 5 | 6 | 7 | const FeatureList = [ 8 | { 9 | title: 1300, 10 | description: ( 11 | <>applications 12 | 13 | ), 14 | }, 15 | { 16 | title: 500, 17 | description: ( 18 | <>projects funded 19 | 20 | ), 21 | }, 22 | { 23 | title: 50, 24 | description: ( 25 | <>countries 26 | 27 | ), 28 | }, 29 | ]; 30 | 31 | function Feature({Svg, title, description}) { 32 | return ( 33 |
34 |
35 |
36 |
37 |

+

38 |

{description}

39 |
40 |
41 | ); 42 | } 43 | 44 | export default function HomepageFeatures() { 45 | return ( 46 |
47 |
48 |
49 | {FeatureList.map((props, idx) => ( 50 | 51 | ))} 52 |
53 |
54 |
55 | ); 56 | } 57 | -------------------------------------------------------------------------------- /docs/Introduction/ideas.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 3 3 | --- 4 | 5 | # Project Ideas 6 | 7 | An overview of existing projects in the Web 3.0 Technology Stack along with broad project ideas we would potentially be interested in funding can be found [here](https://wiki.polkadot.network/docs/build-open-source), as well as a list of previously accepted applications [here](../../applications/index.md). 8 | 9 | [Requests For Proposals](../rfps.md) (RFPs) represent concrete ideas for projects that we would like to see implemented. Several teams may apply for the same RFP, so even if another team has already applied to implement a certain RFP, we invite you to do the same if you're interested. 10 | 11 | Finally, you don't need to start your own project in order to be eligible for a grant. Instead, some teams choose to port existing work to Substrate, where the pertinent licenses allow, or even to contribute to an existing open-source project. In the latter case, you should check in advance that the maintainers of the project are interested in your contribution, and the acceptance of the milestones will generally be tied to the inclusion of your work in said project. See the [Maintenance Grants section](../maintenance.md) for more info. 12 | 13 | If you have a **good concept of the technical challenges** that your idea entails and would like feedback/input before submitting it, you can send us an [email](mailto:grants@web3.foundation) and tell us about it. 14 | -------------------------------------------------------------------------------- /.github/workflows/application_approved.yml: -------------------------------------------------------------------------------- 1 | name: Approvals notification 2 | 3 | on: 4 | pull_request_review: 5 | types: [submitted] 6 | 7 | jobs: 8 | send_matrix_approved_msg: 9 | if: github.event.review.state == 'approved' && contains(github.event.pull_request.body, 'Project Abstract') 10 | runs-on: ubuntu-latest 11 | steps: 12 | - run: echo 'APPROVALS=?' >> $GITHUB_ENV 13 | - if: contains(github.event.pull_request.body, '[x] **Level 1**') 14 | run: echo 'APPROVALS=2' >> $GITHUB_ENV 15 | - if: contains(github.event.pull_request.body, '[x] **Level 2**') 16 | run: echo 'APPROVALS=3' >> $GITHUB_ENV 17 | - if: contains(github.event.pull_request.body, '[x] **Level 3**') 18 | run: echo 'APPROVALS=5' >> $GITHUB_ENV 19 | - id: 'reviews' 20 | uses: 'jrylan/github-action-reviews-counter@main' 21 | with: 22 | repo-token: '${{ secrets.GITHUB_TOKEN }}' 23 | - uses: fadenb/matrix-chat-message@v0.0.6 24 | with: 25 | homeserver: 'matrix.web3.foundation' 26 | token: ${{ secrets.MATRIX_TOKEN }} 27 | channel: ${{ secrets.MATRIX_CHANNEL_ID }} 28 | message: | 29 | PR APPROVED: [${{ github.event.pull_request.title }}](https://github.com/w3f/Grants-Program/pull/${{ github.event.pull_request.number }}) has been approved by ${{ github.event.review.user.login }}. 30 | Approvals: ${{ steps.reviews.outputs.approved }}/${{ env.APPROVALS }} -------------------------------------------------------------------------------- /docs/RFPs/Open/move_smart_contract_pallet.md: -------------------------------------------------------------------------------- 1 | # Move Smart Contract Pallet 2 | * **Status:** Open 3 | * **Proposer:** [David Hawig](https://github.com/Noc2) 4 | 5 | ## Project Description :page_facing_up: 6 | 7 | The Move Virtual Machine (MoveVM) was initially developed by Facebook and is now maintained by the Aptos Foundation. Move is a smart contract programming language that emphasises access control and scarcity. 8 | 9 | [Pontem Network](https://pontem.network/) initially developed the [Move virtual machine pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm) to execute Move smart-contracts on Substrate-based chains. However, they stopped working on this pallet to focus on other initiatives. 10 | 11 | The purpose of this RFP is to find other teams that are willing to pick up this initial work and continue with it or work on their own implementation of the Move virtual machine in Substrate. 12 | 13 | **Useful resources:** 14 | - [Move: A Language With Programmable Resources](https://developers.diem.com/papers/diem-move-a-language-with-programmable-resources/2020-05-26.pdf) 15 | - [Move virtual machine pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm) 16 | - [Move on Aptos](https://aptos.dev/guides/move-guides/move-on-aptos) 17 | 18 | ## Deliverables 19 | 20 | The structure of the grant and the milestones depends highly on the project itself. It’s therefore up to the applying team to come up with a milestone and delivery structure. 21 | 22 | 23 | -------------------------------------------------------------------------------- /docs/RFPs/Open/validator-setup-maintenance.md: -------------------------------------------------------------------------------- 1 | # polkadot-validator-setup maintenance 2 | 3 | * **Status:** Open 4 | * **Teams/People that could deliver the RFP:** @melozo, @pmensik, @tylerztl, @bLd75 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | One of the more accessible ways of spinning up validator nodes is by using the [`polkadot-validator-setup`](https://github.com/w3f/polkadot-validator-setup) repository, which uses a mix of terraform and ansible tools to create a server, adjust its configuration and install the necessary packages needed for running a substrate node. 9 | 10 | This RFP aims at providing maintenance to that repository and add some small features. 11 | 12 | ## Deliverables :nut_and_bolt: 13 | 14 | A list of possible tasks to work on: 15 | - fixing issues and improving documentation 16 | - updating any libraries/deps needed 17 | - support additional terraform backends to store the terraform state (currently only `gcp`, could add `s3`: see [this issue](https://github.com/w3f/polkadot-validator-setup/issues/108) and local storage or even git - it should be discouraged in prod but very useful for testing). See also [this issue](https://github.com/w3f/polkadot-validator-setup/issues/7) 18 | - investigate pass-phrased ssh key deployment: [issue 109](https://github.com/w3f/polkadot-validator-setup/issues/109) 19 | - add additional cloud providers to terraform: [alicloud](https://github.com/w3f/polkadot-validator-setup/issues/111), [OVS](https://github.com/w3f/polkadot-validator-setup/issues/116) 20 | -------------------------------------------------------------------------------- /docs/RFPs/Open/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 are still awaiting to be improved: 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 implementations, and we also need a similar one for NFTs 17 | - We need some tool to allow developers 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 libraries to better handle the async nature of XCM communication 24 | - Develop a pallet to handle crosschain transfers of NFTs 25 | -------------------------------------------------------------------------------- /src/pages/index.js: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import clsx from 'clsx'; 3 | import Layout from '@theme/Layout'; 4 | import Link from '@docusaurus/Link'; 5 | import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; 6 | import styles from './index.module.css'; 7 | import HomepageFeatures from '../components/HomepageFeatures'; 8 | 9 | 10 | 11 | function HomepageHeader() { 12 | const {siteConfig} = useDocusaurusContext(); 13 | return ( 14 |
15 |
16 |

{siteConfig.title}

17 |

{siteConfig.tagline}

18 |
19 | 22 | Apply 23 | 24 | 30 | Browse RFPs 31 | 32 |
33 |
34 |
35 | ); 36 | } 37 | 38 | export default function Home() { 39 | const {siteConfig} = useDocusaurusContext(); 40 | return ( 41 | 44 | 45 |
46 | 47 |
48 | 49 | ); 50 | } 51 | -------------------------------------------------------------------------------- /docs/process.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Apply 3 | --- 4 | 5 | If you are certain you want to apply for a W3F grant, head straight to our [application process documentation](Process/how-to-apply.md). Otherwise, check out the flowchart below for a broad overview of which funding source your application might fit best. 6 | 7 | 8 | ## Funding Opportunities Overview 9 | 10 | For a longer list and a description of the programs listed below, check out [our page on alternative funding opportunities](funding.md). 11 | 12 | ```mermaid 13 | flowchart LR 14 | A(Project Focus) 15 | A -->|Development| B[Stage of Development] 16 | A -->|Research| C[Grants Program] 17 | A -->|Other| D[Treasury] 18 | B -->|Existing POC| E[Goal of the Application] 19 | B -->|No POC| F[Grants Program] 20 | E -->|Funding| G[Treasury or Grants Program] 21 | E -->|Support| H[Substrate Builders Program] 22 | style C stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 23 | style D stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 24 | style F stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 25 | style G stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 26 | style H stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 27 | 28 | click C "Process/how-to-apply" "Apply now" 29 | click F "Process/how-to-apply" "Apply now" 30 | click D "https://wiki.polkadot.network/docs/en/learn-treasury" "https://wiki.polkadot.network/docs/en/learn-treasury" _blank 31 | click H "https://www.substrate.io/builders-program/" "https://www.substrate.io/builders-program" _blank 32 | ``` 33 | -------------------------------------------------------------------------------- /docs/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 | -------------------------------------------------------------------------------- /docs/RFPs/Open/IDE_for_ink_Smart_Contracts.md: -------------------------------------------------------------------------------- 1 | # Browser based IDE for ink! Smart Contracts 2 | 3 | * **Status:** Open 4 | * **Proposer:** [David Hawig](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | [ink!](https://github.com/paritytech/ink) is a domain-specific language for writing smart contracts in Rust and compiles to Wasm code. You can deploy ink! contracts on parachains that support the contracts pallet, as well as on stand-alone blockchains built with Substrate. 9 | 10 | The goal of this RFP is to find teams that would like to develop or maintain a browser-based playground for editing, compiling & sharing ink! smart contracts. The [ink! Playground](https://ink-playground.substrate.io/), previously maintained by Parity, utilizes Typescript, React, Docker, and [Monaco Editor](https://microsoft.github.io/monaco-editor/). Teams could continue to work on the [ink! Playground](https://github.com/paritytech/ink-playground), or choose to build something new if desired. For example, it might be possible to leverage GitHub Codespaces in combination with GitHub Actions or the previously developed [ink! Remix plugin](https://github.com/blockchain-it-hr/ink-remix-plugin). 11 | 12 | **Useful resources:** 13 | - [ink!](https://use.ink/) 14 | - [ink-playground](https://ink-playground.substrate.io) 15 | - [GitHub ink-playground](https://github.com/paritytech/ink-playground) 16 | - [GitHub: ink! Remix plugin](https://github.com/blockchain-it-hr/ink-remix-plugin) 17 | 18 | ## Deliverables 19 | 20 | The structure of the grant and the milestones depends highly on the project itself. It’s therefore up to the applying team to come up with a milestone and delivery structure. 21 | 22 | 23 | -------------------------------------------------------------------------------- /docs/RFPs/Open/ISO_20022.md: -------------------------------------------------------------------------------- 1 | # RFP: ISO 20022 2 | 3 | * **Status:** Open 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | ISO (International Organization for Standardization) 20022 is becoming the de facto global data standard for payments and electronic data interchange between financial institutions. It’s a global message standard that is already adopted by a lot of countries and is independent of the network layer. Compared to older standards, like for example ISO 8583, ISO 20022, covers all transactions, whereas ISO 8583 covers only card transactions. 9 | 10 | The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage substrate and ink! smart contracts to interact with ISO 20022 in various ways (e.g. cross border payments, card payments, etc.). These tools could be, but are not limited to: 11 | 12 | - (Java) APIs or packages that make it possible for the traditional finance industry to integrate a substrate-based ISO 20022 solution into their existing tech stack. 13 | - Proof of concepts, potentially leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/v3/concepts/off-chain-features/) that show the advantages of using ISO 20022 together with Substrate. 14 | - Efficient on-chain representation of the ISO 20022 XML or ASN.1-based syntax 15 | 16 | **Useful resources:** 17 | - https://www.iso20022.org/ 18 | - https://www.swift.com/standards/iso-20022/iso-20022-programme 19 | - https://github.com/element36-io/ocw-ebics 20 | 21 | ## Deliverables 22 | 23 | The structure of the grant and the milestones depends highly on the project itself. It’s therefore up to the applying team to come up with a milestone and delivery structure. 24 | -------------------------------------------------------------------------------- /docs/contribute.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 9 3 | title: 🫶 Contribute 4 | --- 5 | 6 | The W3F Grants Program aims to be as open and accessible as possible. If you are interested in contributing or getting involved, there are several ways you can do that: 7 | 8 | 📋 We are open to milestone evaluations from third parties. If you are particularly interested in a certain project, or particularly knowledgeable on a relevant subject, feel free to comment on any [open grant applications](https://github.com/w3f/Grants-Program/issues?q=is%3Aopen+label%3A%22ready+for+review%22+sort%3Aupdated-desc), or have a look at the [open pull requests on our milestone delivery repository](https://github.com/w3f/Grant-Milestone-Delivery/pulls) and [submit your own evaluation](https://github.com/w3f/Grant-Milestone-Delivery#ballot_box_with_check-external-evaluations). 9 | 10 | 🔍 If you find that there is something missing in our ecosystem (a tool, a project, infrastructure, etc.) that we could help fund, please [submit a Request For Proposals (RFP)](https://github.com/w3f/Grants-Program/blob/master/README.md#mailbox_with_mail-suggest-a-project). If writing an RFP seems too daunting a task, feel free to [submit it as an issue on our Github repository](https://github.com/w3f/Grants-Program/issues) so anyone can contribute. 11 | 12 | 🤝 Join us! We are looking for a Technical Grants Evaluator (among other things) to join us full time. Check out [our current job openings](https://web3.bamboohr.com/jobs/) and apply! 13 | 14 | We strive to continue improving our grants program and are always open to feedback. If you would like to share any suggestions or criticism, please reach out to us on [Github](https://github.com/w3f/Grants-Program) or [Matrix](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org)! 15 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | #### Project Abstract 2 | 3 | > Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs). 4 | > 5 | > If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable. 6 | 7 | #### Grant [level](https://github.com/w3f/Grants-Program#level_slider-levels) 8 | 9 | - [ ] **Level 1**: Up to $10,000, 2 approvals 10 | - [ ] **Level 2**: Up to $30,000, 3 approvals 11 | - [ ] **Level 3**: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval) 12 | 13 | #### Application Checklist 14 | 15 | - [x] The [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md) has been copied and aptly renamed (`project_name.md`). 16 | - [ ] I have read the [application guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/grant_guidelines_per_category.md). 17 | - [ ] Payment details have been provided (bank details via email _or_ BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application). 18 | - [ ] The software delivered for this grant will be released under an open-source license specified in the application. 19 | - [ ] The initial PR contains only one commit (squash and force-push if needed). 20 | - [ ] The grant will only be announced once the first milestone [has been accepted](https://github.com/w3f/Grant-Milestone-Delivery#process) (see the [announcement guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/announcement-guidelines.md)). 21 | - [ ] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: `@_______:matrix.org` (change the homeserver if you use a different one) 22 | -------------------------------------------------------------------------------- /docs/RFPs/Open/ISO_8583.md: -------------------------------------------------------------------------------- 1 | # RFP: ISO 8583 2 | 3 | * **Status:** Open 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | ISO 8583 is an international standard for systems that exchange electronic transactions initiated by cardholders using payment cards. It defines a message format and a communication flow, but offers also custom fields and custom usages. Most transactions that involve ATMs are based on this standard and Mastercard, Visa and Verve networks base their authorization communications on the ISO 8583 standard. 9 | 10 | Even though ISO 8583 is going to be replaced by [ISO 20022](https://github.com/w3f/Grants-Program/blob/master/rfps/open/ISO_20022.md), it might take some time before it’s actually fully replaced. 11 | 12 | The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage substrate and ink! smart contracts to interact with ISO 8583 in various ways. These tools could be, but are not limited to: 13 | 14 | - (Java) APIs or packages that make it possible for the traditional finance industry to integrate a substrate-based ISO 8583 solution into their existing tech stack. 15 | - Proof of concepts, potentially leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/v3/concepts/off-chain-features/) that show the advantages of using ISO 8583 together with Substrate. 16 | - Efficient on-chain representation of the ISO 8583 syntax 17 | 18 | **Useful resources:** 19 | - https://www.iso.org/standard/31628.html 20 | - https://github.com/element36-io/ocw-ebics 21 | 22 | ## Deliverables 23 | 24 | The structure of the grant and the milestones depends highly on the project itself. It’s therefore up to the applying team to come up with a milestone and delivery structure. 25 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/php-api.md: -------------------------------------------------------------------------------- 1 | # PHP Substrate API 2 | 3 | * **Proposer:** [swader](https://github.com/api) 4 | * **Status:** [Implemented](https://github.com/gmajor-encrypt/php-substrate-api) 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 | -------------------------------------------------------------------------------- /static/img/Web.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/Introduction/team.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 5 3 | --- 4 | 5 | # Team 6 | 7 | ## W3F Grants Committee 8 | 9 | The committee consists of individuals who know the funding priorities of the Polkadot ecosystem, and is responsible for evaluating grant applications and providing feedback on these. 10 | 11 | In cases where a niche expert opinion is desirable, one of the committee members may request such a review. 12 | 13 | - [Nabil Abdellaoui](https://github.com/randombishop) 14 | - [Santiago Balaguer](https://github.com/SBalaguer) 15 | - [Aeron Buchanan](https://github.com/aeronbuchanan) 16 | - [Gautam Dhameja](https://github.com/gautamdhameja) 17 | - [David Hawig](https://github.com/Noc2) 18 | - [Diogo Mendonça](https://github.com/dsm-w3f) 19 | - [Sebastian Müller](https://github.com/semuelle) 20 | - [Bill Laboon](https://github.com/laboon) 21 | - [Keegan Quigley](https://github.com/keeganquigley) 22 | - [Raul Romanutti](https://github.com/rrtti) 23 | - [Seraya Takahashi](https://github.com/takahser) 24 | - [Benjamin Weiß](https://github.com/BenWhiteJam) 25 | - [Gavin Wood](https://github.com/gavofyork) 26 | 27 | ## W3F Grants Evaluators 28 | 29 | Evaluators are individuals able to evaluate the technology delivered as a result of the Grants Program. The committee has the right to add or remove evaluators on the basis of supermajority. 30 | 31 | - [Nabil Abdellaoui](https://github.com/randombishop) 32 | - [Matteo Casonato](https://github.com/0xCaso) 33 | - [David Hawig](https://github.com/Noc2) 34 | - [Diogo Mendonça](https://github.com/dsm-w3f) 35 | - [Sebastian Müller](https://github.com/semuelle) 36 | - [Keegan Quigley](https://github.com/keeganquigley) 37 | - [Seraya Takahashi](https://github.com/takahser) 38 | 39 | ## W3F Operations Team 40 | 41 | The Operations Team takes care of legal documents, invoicing and remittances. 42 | 43 | - [Melanie Diener](https://github.com/meldien) 44 | - [Federica Dubbini](https://github.com/fededubbi) 45 | - [Rouven Pérez](https://github.com/RouvenP) 46 | -------------------------------------------------------------------------------- /.github/workflows/check_application_document.yml: -------------------------------------------------------------------------------- 1 | name: Check application document 2 | 3 | on: 4 | workflow_dispatch: 5 | pull_request: 6 | types: [opened, synchronize] 7 | 8 | jobs: 9 | discussion_private: 10 | if: | 11 | github.event.action == 'opened' && 12 | github.event.pull_request.body && ( 13 | contains(github.event.pull_request.body, '- [x] I prefer the discussion') || 14 | ( 15 | contains(github.event.pull_request.body, '- [ ] I prefer the discussion') && 16 | !contains(github.event.pull_request.body, '@_______:matrix.org') 17 | ) 18 | ) 19 | runs-on: ubuntu-latest 20 | steps: 21 | - name: Add 'discussion private' label if the application is private 22 | uses: actions/github-script@v6 23 | with: 24 | script: | 25 | github.rest.issues.addLabels({ 26 | issue_number: context.issue.number, 27 | owner: context.repo.owner, 28 | repo: context.repo.repo, 29 | labels: ["discussion private"] 30 | }) 31 | 32 | get_filename: 33 | if: contains(github.event.pull_request.body, 'Project Abstract') 34 | runs-on: ubuntu-latest 35 | outputs: 36 | filename: ${{ steps.files.outputs.added }} 37 | steps: 38 | 39 | - name: Get application filename # We assume there's only one 40 | id: 'files' 41 | uses: Ana06/get-changed-files@v2.0.0 42 | with: 43 | filter: 'applications/*.md' 44 | format: 'csv' 45 | 46 | parse_document: 47 | needs: get_filename 48 | if: needs.get_filename.outputs.filename 49 | runs-on: ubuntu-latest 50 | steps: 51 | 52 | - name: Checkout 53 | uses: actions/checkout@v2 54 | 55 | - name: Parse application file 56 | id: grant_parser 57 | uses: w3f/parse-grant-application-action@master 58 | with: 59 | path: "${{ github.workspace }}/${{ needs.get_filename.outputs.filename }}" 60 | -------------------------------------------------------------------------------- /docs/RFPs/Open/anti-collusion_infrastructure.md: -------------------------------------------------------------------------------- 1 | # Anti-Collusion Infrastructure 2 | 3 | * **Status:** Open 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | A lot of blockchain applications that involve some kind of voting, like on-chain quadratic funding, can potentially be exploited via collusion and bribery (see [Vitalik’s post about collusion](https://vitalik.ca/general/2019/04/03/collusion.html)). Therefore, it’s important to design mechanisms that effectively prevent any kind of on-chain collusion or at least make it more difficult. The goal of this RFP is to encourage people to try to research and come up with their own solutions or to implement existing solutions, like [Minimal anti-collusion infrastructure](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) as a substrate pallet or ink! smart contract. 9 | 10 | ## Deliverables :nut_and_bolt: 11 | 12 | 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. 13 | 14 | ### Milestone 1 - Anti-collusion 15 | 16 | | Number | Deliverable | Specification | 17 | | ------------- | ------------- | ------------- | 18 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 19 | | 0b. | Documentation | Inline documentation of the code and a basic tutorial that explains how a developer can use the project | 20 | | 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 | 21 | | 0d. | Article/Tutorial | Article or tutorial that explains the work done as part of the grant. 22 | | 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) | 23 | | 2. | Voting Example | Integrate a basic voting example that lets you test the mechanism | 24 | 25 | 26 | 27 | -------------------------------------------------------------------------------- /docs/Support Docs/grant-badge-guidelines.md: -------------------------------------------------------------------------------- 1 | # Usage guidelines for the W3F Grants Program badge 2 | 3 | 4 | 5 | **Once a project's first milestone has been accepted**, we intend to help teams acknowledge their grant publicly while observing the foundation’s guidelines. 6 | 7 | To that end, we’ve created a badge for grant recipients. This is available for download in four formats under [web3.foundation/grants/badge](https://web3.foundation/grants/badge). 8 | 9 | *Before you begin using the badge, please note the following points:* 10 | 11 | - Use of the Grants Program badge is reserved for [Level 2 and 3 grants](https://github.com/w3f/Grants-Program/blob/master/README.md#level_slider-levels). 12 | - Grants are awarded **for specific projects**, not to teams in general as a blanket endorsement. 13 | - 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.** 14 | - Please **do**: display the badge 15 | - in a GitHub repository that contains code connected with the grant project, 16 | - on any project-specific webpage **that specifically concerns the deliverables completed as part of the grant**, or 17 | - when appropriate, in a tweet or blog post announcing your grant in a project-specific context. 18 | - Please **don’t**: 19 | - display the badge on your team or project's landing page, 20 | - use the badge before your first milestone has been accepted, 21 | - add it to any social media profiles, or 22 | - use it in any other context that could misrepresent your relationship with the Web3 Foundation. 23 | 24 | 25 | Also, please don't use the **name or logo of the Web3 Foundation** in any context that could misrepresent your relationship with Web3 Foundation. Infringement of these guidelines can result in an immediate annulment of the grant. 26 | 27 | In case of any questions, please don’t hesitate to reach out to us at grantsPR@web3.foundation. 28 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/wallet-aggregator-library.md: -------------------------------------------------------------------------------- 1 | # Wallet Aggregator Library 2 | 3 | * **Status:** [Implemented: SubConnect](https://github.com/Koniverse/SubConnect), [Implemented: talisman-connect](https://github.com/TalismanSociety/talisman-connect) 4 | * **Proposer:** [Matteo Casonato](https://github.com/0xCaso) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Users of Polkadot and Substrate-based projects need to connect their wallet to a front-end when using a dApp. At the moment, there are [several wallets and browser extensions](https://wiki.polkadot.network/docs/build-wallets) that can be used (Polkadot-JS, Talisman, Fearless, just to name a few). However, it's common that the frontends don't support all of them, and the users need to install a new wallet or browser extension to connect to the frontend. 9 | 10 | This project aims to create a **React library** that allows users to connect with any wallet or browser extension to the frontends that adopts it. This way, the users can use the wallet they prefer, and the frontends can support all of them without the need to implement the connection logic for each wallet, just integrating one library (making life easier for developers). Though we would prefer a React library, we would also consider implementations for other libraries as well. 11 | 12 | ## Deliverables :nut_and_bolt: 13 | 14 | The following items could be the initial deliverables of the project. Of course, improvements and additions are more than welcome. 15 | - Initial **research**: 16 | - study from the [RainbowKit](https://www.rainbowkit.com/docs/introduction) library (which is the same thing, already developed for EVM chains); 17 | - understand which wallets/extensions can be integrated, what is needed to connect to them, etc.; 18 | - Library **development**: 19 | - various connectors for each wallet; 20 | - UI components (connect button, account and chain selector, etc.); 21 | - UI/UX (for both users/devs) **improvement**: 22 | - addition of a tool that scaffolds a new project with the wallet connection library (firable, for example, with `npm init @user/wallet-aggregator@latest`); 23 | - selective account disclosure implementation (view [this](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/privacy-enhancement-polkadot-extension.md) RFP). 24 | -------------------------------------------------------------------------------- /src/css/custom.css: -------------------------------------------------------------------------------- 1 | /* stylelint-disable docusaurus/copyright-header */ 2 | /** 3 | * Any CSS included here will be global. The classic template 4 | * bundles Infima by default. Infima is a CSS framework designed to 5 | * work well for content-centric websites. 6 | */ 7 | 8 | /* You can override the default Infima variables here. */ 9 | :root { 10 | --ifm-color-primary: #000000; 11 | --ifm-color-primary-dark: rgb(33, 175, 144); 12 | --ifm-color-primary-darker: rgb(31, 165, 136); 13 | --ifm-color-primary-darkest: rgb(26, 136, 112); 14 | --ifm-color-primary-light: rgb(70, 203, 174); 15 | --ifm-color-primary-lighter: rgb(102, 212, 189); 16 | --ifm-color-primary-lightest: rgb(146, 224, 208); 17 | --ifm-code-font-size: 95%; 18 | font-family: SuisseIntl,sans-serif; 19 | } 20 | 21 | .hero__title { 22 | font-size: 4rem; 23 | } 24 | 25 | 26 | .footer__link-item { 27 | text-decoration: none; 28 | } 29 | 30 | .footer__link-item:hover { 31 | color: #ebedf0; 32 | } 33 | 34 | .navbar__items { 35 | font-size: 18px; 36 | } 37 | 38 | .number--count { 39 | font-size: 4rem; 40 | } 41 | 42 | .number--title { 43 | font-size: 1.5rem; 44 | } 45 | 46 | .hero--primary { 47 | --ifm-hero-background-color: #fff; 48 | --ifm-hero-text-color: #000; 49 | } 50 | 51 | .footer--dark { 52 | --ifm-footer-background-color: #000; 53 | } 54 | 55 | .docusaurus-highlight-code-line { 56 | background-color: rgba(0, 0, 0, 0.1); 57 | display: block; 58 | margin: 0 calc(-1 * var(--ifm-pre-padding)); 59 | padding: 0 var(--ifm-pre-padding); 60 | } 61 | 62 | html[data-theme='dark'] .docusaurus-highlight-code-line { 63 | background-color: rgba(0, 0, 0, 0.3); 64 | } 65 | 66 | [data-theme='dark'] { 67 | --ifm-color-primary: #ffffff; 68 | } 69 | 70 | a { 71 | text-decoration: underline; 72 | } 73 | 74 | /* All other links should not be underlined */ 75 | .button, .menu__link, .navbar__brand, .navbar__item, .pagination-nav__link, .table-of-contents__link { 76 | text-decoration: none; 77 | } 78 | 79 | /* Divider for sidebar */ 80 | .sidebar-divider { 81 | border-top: 1px solid var(--ifm-color-gray-200); 82 | display: block; 83 | margin: 0.5rem 0 0.25rem 1rem; 84 | } 85 | 86 | /* Title for sidebar */ 87 | .sidebar-title { 88 | font-size: 0.8rem; 89 | letter-spacing: 0.05rem; 90 | text-transform: uppercase; 91 | font-weight: 600; 92 | color: var(--ifm-color-gray-600); 93 | } -------------------------------------------------------------------------------- /applications/halva_bootstrapping.md: -------------------------------------------------------------------------------- 1 | # Halva [Bootstrapping and Scaffolding] 2 | 3 | > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. 4 | 5 | * **Proposer:** [Halva](https://github.com/halva-suite/halva) 6 | * **Payment Address:** 1837ca1w8WK9yfaVo5Lhgg4sENK2Tq3FgW 7 | 8 | ## Project Description :page_facing_up: 9 | 10 | We want to automate the process of bootstrapping a new project using the Halva framework. To do this, we add the cli commands `halva-cli init` and`halva-cli create`. In the basic case, `halva-cli init` adds the file `halva.js` and adds the directory with sample tests`/tests` for standard pallets to the substrate project's directory. The command `halva-cli create` deploys new code from template e.g`halva-cli create test Token` creates a new test case `/tests/Token.ts` 11 | 12 | ## Team :busts_in_silhouette: 13 | 14 | * **Members:** Wintex 15 | * **LinkedIn Profiles:** - 16 | * **Code Repos:** 17 | * **Website:** 18 | * **Legal Structure:** individual 19 | * **Team's Experience:** Our team develops software about 10+ years and decentralized applications since 2017. We have a great experience with typescript, node.js, and testing frameworks. 20 | 21 | ## Development Roadmap :nut_and_bolt: 22 | 23 | * **Total Estimated Duration:** 2 weeks 24 | * **Full-time equivalent (FTE):** 1.5 25 | * **Total Costs:** 0.728 BTC 26 | 27 | ### Milestone 1 28 | 29 | * **Estimated Duration:** 2 weeks 30 | * **FTE:** 1.5 31 | * **Costs:** 0.728 BTC 32 | 33 | | Number | Deliverable | Specification | 34 | | ------------- | ------------- | ------------- | 35 | | 1. | Command `init` | Create a new Halva project within the existing substrate project directory or creating new substrate project with initialed halva within | 36 | | 2. | Command `create` | Helper to create new test-cases | 37 | | 3. | Testing | Write unit-tests for implemented functions | 38 | | 4. | Examples | Update [halva-test-example](https://github.com/halva-suite/halva-test-example) | 39 | | 5. | Tutorial | Write step by step tutorial and publish it | 40 | | 6. | Documentations | Write documentations for both commands | 41 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/alternative_polkadot_host_implementations.md: -------------------------------------------------------------------------------- 1 | # Alternative Polkadot Host Implementation 2 | 3 | * **Status:** [Under Development 1](https://github.com/LimeChain/java-host-research), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/hybrid_node_research.md) 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | The architecture of Polkadot can be divided into two different parts, the Polkadot runtime and the Polkadot host. The Polkadot runtime is the core state transition logic of the chain and can be upgraded over the course of time and without the need for a hard fork. In comparison, the Polkadot host is the environment in which the runtime executes and is expected to remain stable and mostly static over the lifetime of Polkadot. 9 | 10 | The Polkadot host interacts with the Polkadot runtime in limited, and well-specified ways. For this reason, implementation teams can build an alternative implementation of the Polkadot host while treating the Polkadot runtime as a black box. For more details of the interactions between the host and the runtime, please [see the specification](https://github.com/w3f/polkadot-spec/). 11 | 12 | **The Web3 Foundation is interested in supporting additional implementations of the Polkadot Host. If you are interested in this RFP, please reach out to spec@web3.foundation.** 13 | 14 | Currently the following implementations are under development: 15 | 16 | - [Gossamer: A Go implementation of the Polkadot Host](https://github.com/ChainSafe/gossamer) 17 | - [Kagome - C++ implementation of Polkadot Host](https://github.com/soramitsu/kagome) 18 | - [Polkadot Node Implementation in Rust](https://github.com/paritytech/polkadot) 19 | - [Smoldot - A Lightweight Substrate and Polkadot client in Rust](https://github.com/paritytech/smoldot) 20 | 21 | ## Deliverables :nut_and_bolt: 22 | 23 | For Polkadot Host Implementations, it’s probably too complex to structure the entire implementation via milestones. Components of the Polkadot host are: 24 | 25 | - Networking components such as Libp2p that facilitates network interactions. 26 | - State storage and the storage trie along with the database layer. 27 | - Consensus engine for GRANDPA and BABE. 28 | - Wasm interpreter and virtual machine. 29 | - Low level primitives for a blockchain, such as cryptographic primitives like hash functions. 30 | - Availability & Validity components to support parachains. -------------------------------------------------------------------------------- /docs/help.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 7 3 | title: 💡 Help 4 | --- 5 | 6 | 7 | ### Real-time Conversation 8 | 9 | We have a Matrix channel for grant-related questions and activities. Head over there to ask grants-related questions, share your experience with other applications and grantees, or simply hang out: 10 | 11 | - [W3F Grants Community](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org) 12 | 13 | We also have Matrix/Element channels for real-time discussions on Web3 and Polkadot. Join the conversation! 14 | 15 | - [Web3 Foundation Chat](https://matrix.to/#/#w3f:matrix.org) 16 | - [Polkadot Space](https://matrix.to/#/#polkadot:web3.foundation) 17 | - [Kusama Space](https://matrix.to/#/#kusama:web3.foundation) 18 | 19 | ### Office Hours 20 | 21 | Web3 Foundation Grants Office Hours are a chance to ask the grants team questions regarding a specific (potential) grant application. It offers 22 | 23 | - general guidance regarding the grants program, 24 | - some quick initial feedback and 25 | - help how to navigate the ecosystem. 26 | 27 | Apply for Office Hours if you 28 | 29 | - need feedback before submitting an application, 30 | - want to find out what kind of support there might be available or 31 | - need help finding the resources you need. 32 | 33 | It is **not** a chance to pitch your project, especially since only a small subset of the committee will participate in the call. To apply, please fill out the [Office Hours :alarm_clock: form](https://forms.gle/54xkiqU37WwdN9UR6). Be as specific as possible, so we can help you more quickly. We will get back to you with follow-up questions or a link for booking a timeslot. 34 | 35 | ### Additional Information 36 | 37 |
38 | 39 | | | | | | | | 40 | | :-: | :-: | :-: | :-: | :-: | :-: | 41 | | [W3F Website](https://web3.foundation) | [W3F Twitter](https://twitter.com/web3foundation) | [W3F Medium](https://medium.com/web3foundation) | [Polkadot Wiki](https://wiki.polkadot.network/en/) | [Web 3.0 Reddit](https://www.reddit.com/r/web3) | [W3F YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) | 42 | 43 |
44 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/polkadot-collator-setup.md: -------------------------------------------------------------------------------- 1 | # Polkadot Collator Setup 2 | 3 | - **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/unified_collator_node_deployment.md) 4 | - **Proposer:** mmagician 5 | - **Your Project(s):** https://mmagician.github.io/ 6 | - **Projects you think this work could be useful for** Any parachain team 7 | 8 | ## Project Description :page_facing_up: 9 | 10 | This is meant as a companion repository to [polkadot-validator-setup](https://github.com/w3f/polkadot-validator-setup), which allows anyone to launch a validator node in an automated and secure fashion. 11 | 12 | I would like to standardize (as much as possible) the process of spinning up new collator nodes for different parachains. 13 | 14 | I understand it might be tricky to bundle all the parachain launch setups into one repository, but there are some ideas of how this can be tackled: 15 | 16 | 1. Have a single collator ansible role, and each branch would correspond to a specific parachain 17 | 2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed. 18 | 19 | I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independant chains without meddling with git branching too much. 20 | 21 | ## Deliverables :nut_and_bolt: 22 | 23 | Ideally the PoC would 24 | 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. 25 | 26 | - **Total Estimated Duration:** Duration of the whole project 27 | - **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)) 28 | - **Total Costs:** Amount of Payment in USD for the whole project. 29 | 30 | ### Milestone 1 31 | 32 | Please add additional milestones in the same way: 33 | - **Estimated Duration:** Duration of milestone 1 34 | - **FTE:** Amount of time (in days) required for a single person to complete this milestone 35 | - **Costs:** Amount of Payment in USD for milestone 1 36 | 37 | 38 | | Number | Deliverable | Specification | 39 | | ------------- | ------------- | ------------- | 40 | | 1. | Title of the deliverable | Please describe the deliverable here as detailed as possible | 41 | | 2. | ... |...| 42 | -------------------------------------------------------------------------------- /sidebars.js: -------------------------------------------------------------------------------- 1 | /** 2 | * Creating a sidebar enables you to: 3 | - create an ordered group of docs 4 | - render a sidebar for each doc of that group 5 | - provide next/previous navigation 6 | 7 | The sidebars can be generated from the filesystem, or explicitly defined here. 8 | 9 | Create as many sidebars as you want. 10 | */ 11 | 12 | // @ts-check 13 | 14 | const sidebars = { 15 | docs: [ 16 | { 17 | type: 'html', 18 | className: 'sidebar-title', 19 | value: 'Basic Information', 20 | defaultStyle: true, 21 | }, 22 | { 23 | type: 'category', 24 | label: '👋 Introduction', 25 | link: {type:'doc', id:'docs/introduction'}, 26 | items: [{type: 'autogenerated', dirName: 'docs/Introduction'}] 27 | }, 28 | { 29 | type: 'category', 30 | label: '📝 Application Process', 31 | link: {type:'doc', id:'docs/process'}, 32 | items: [{type: 'autogenerated', dirName: 'docs/Process'}] 33 | }, 34 | { 35 | type: 'doc', 36 | id:'docs/maintenance' 37 | }, 38 | { 39 | type: 'html', 40 | value: '', 41 | }, 42 | { 43 | type: 'html', 44 | className: 'sidebar-title', 45 | value: 'In Depth', 46 | defaultStyle: true, 47 | }, 48 | { 49 | type: 'doc', 50 | id:'docs/help' 51 | }, 52 | { 53 | type: 'doc', 54 | id:'docs/faq' 55 | }, 56 | { 57 | type: 'doc', 58 | id:'docs/suggesting' 59 | }, 60 | { 61 | type: 'doc', 62 | id:'docs/referral-program' 63 | }, 64 | { 65 | type: 'html', 66 | value: '', 67 | }, 68 | { 69 | type: 'html', 70 | className: 'sidebar-title', 71 | value: 'Beyond', 72 | defaultStyle: true, 73 | }, 74 | { 75 | type: 'doc', 76 | id:'docs/funding' 77 | }, 78 | { 79 | type: 'doc', 80 | id:'docs/contribute' 81 | }, 82 | { 83 | type: 'doc', 84 | label: '📜 List of Grants', 85 | id:'applications/index' 86 | }, 87 | { 88 | type: 'category', 89 | label: '🪧 Requests for Proposal', 90 | link: {type:'doc', id:'docs/rfps'}, 91 | items: [{type: 'autogenerated', dirName: 'docs/RFPs'}] 92 | }, 93 | { 94 | type: 'category', 95 | label: '🦮 Supporting Documents', 96 | items: [{type: 'autogenerated', dirName: 'docs/Support Docs'}] 97 | }, 98 | ] 99 | }; 100 | 101 | module.exports = sidebars; 102 | -------------------------------------------------------------------------------- /docs/RFPs/Open/alternative-polkadot-js-api-console.md: -------------------------------------------------------------------------------- 1 | # Alternative javascript console for Polkadot JS API 2 | 3 | * **Status:** Open (anyone is allowed to apply) 4 | * **Proposer:** [muddlebee](https://github.com/muddlebee) 5 | * **Projects you think this work could be useful for** [optional]: Javascript console at https://polkadot.js.org/apps/#/js 6 | 7 | ## Project Description :page_facing_up: 8 | 9 | ### Current State 10 | We have a Javascript console on the Developer tab which is really useful for running Polkadot-JS API scripts [Polkadot-JS API docs](https://polkadot.js.org/docs/) 11 | 12 | 13 | **Link** - [https://polkadot.js.org/apps/#/js](https://polkadot.js.org/apps/#/js), UI screenshot below 14 | 15 | ![image](https://user-images.githubusercontent.com/8139783/197954316-1449075f-b8be-4a30-a759-873c15f8a14f.png) 16 | 17 | 18 | **Current limitations of the above console**: 19 | Cannot save code properly, not many keyboard shortcuts, cannot customize configurations. 20 | 21 | **Alternative polkadot js API playground** 22 | 1. [https://github.com/subdirectory/subshell](https://github.com/subdirectory/subshell) 23 | 24 | 25 | ### Proposed-RFP 26 | 27 | A new Polkadot-JS API playground with VS Code-like configurations like save the code, workspace, keyboard shortcuts, etc. 28 | [https://polkadot.js.org/apps/#/js](https://polkadot.js.org/apps/#/js) 29 | 30 | some examples -> https://playground.substrate.dev/ 31 | here we have to manually build and run our js bundles 32 | ![image](https://user-images.githubusercontent.com/8139783/198254152-abdd0f2e-62d4-4f0f-aad1-bcfdd6d48a74.png) 33 | 34 | **Why alternative javascript console for Polkadot-JS API**? 35 | 36 | Current polkadot js API console which I mentioned in beginning of this post, has some limitations, which we can overcome by creating a better version for smoother dev experience. 37 | 38 | 39 | 40 | ## Deliverables :nut_and_bolt: 41 | 42 | The following items could be the initial deliverables of the project. Of course, improvements and additions are more than welcome. 43 | 44 | - Initial research: 45 | - study how the current javascript console is developed at https://polkadot.js.org/apps/#/js 46 | - understand the libaries currently integrated from [polkadot JS API docs](https://polkadot.js.org/docs/) 47 | 48 | - Development: 49 | - design a new UI/UX with better experience than current javascript console with features like 50 | - save code preferably with secure session management 51 | - keyboard shortcuts 52 | - [example](#Proposed-RFP) 53 | 54 | Any additional features which make the Polkadot-JS experience more productive and smoother are welcome. 55 | 56 | -------------------------------------------------------------------------------- /docs/RFPs/Open/analysis-website-and-data-platform.md: -------------------------------------------------------------------------------- 1 | # Analytics Website/Data Platform 2 | 3 | * **Status:** Open 4 | * **Proposer:** [Keegan Quigley](https://github.com/keeganquigley) 5 | * **Teams/People that could deliver the RFP**: @web3go-xyz 6 | 7 | ## Project Description :page_facing_up: 8 | On-chain analysis is an important emerging field for the Polkadot & Kusama ecosystems. One can currently use GraphQL to query data via backend services such as [Subquery](https://explorer.subquery.network/) and [Subsquid](https://app.subsquid.io). However, it would be nice to have an easy-to-use front-end with sharable customized dashboards as well. The end result might look similar to [Dune Analytics](https://dune.com/browse/dashboards), a popular data sharing dashboard used in the Ethereum community. Using Dune Analytics, users can quickly create and openly share queries which can then be forked and remixed in a variety of ways by others. 9 | 10 | This RFP, based on a [forum post](https://forum.polkadot.network/t/dune-analytics-style-data-service-for-polkadot-kusama/271) by Rob Habermeier, aims to fund a dashboard designed to allow analysts and power-users to interactively query high-quality data, and subsequently create custom charts and visualizations to share metrics with others. Ideally, many projects would create custom dashboards to share data with the Polkadot & Kusama community. 11 | 12 | At the moment, building custom dashboards requires quite a bit of effort since the data needs to be fed directly from the parachain via Polkadot.js, or through a custom squid or GraphQL via Subquery. This RFP aims to ease the process of building dashboards and sharing powerful data visualizations. 13 | 14 | ## Deliverables :nut_and_bolt: 15 | The following items could be potential expected deliverables for the project. Of course, improvements and additions are more than welcome. 16 | 17 | - Define a common dataset and data model for Substrate that can be shared for interactive querying use cases such as on Dune Analytics. 18 | - Build a publicly accessible interactive query engine. The platform should allow users to aggregate raw data from relay chains and parachains into SQL databases that can be easily queried. This might include storing data on a postgreSQL database, for example. 19 | - Users should be able to perform simple SQL queries in a matter of minutes, and create visualizations and dashboards using these queries. 20 | - Provide the ability to integrate data from backend services such as Subsquid, Subquery. 21 | - Create UX/UI to make it easier for analysts and power-users to easily query human-readable data and follow key metrics. The front-end could be written in React, AngularJS, Vue, etc. 22 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/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, [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/scale-codec-comparator.md) 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 | -------------------------------------------------------------------------------- /.github/workflows/label_comment.yml: -------------------------------------------------------------------------------- 1 | name: comment_on_label 2 | 3 | on: 4 | pull_request_target: 5 | types: [labeled] 6 | 7 | jobs: 8 | request_details: 9 | if: github.event.label.name == 'details missing' 10 | runs-on: ubuntu-latest 11 | steps: 12 | - name: Comment PR 13 | uses: thollander/actions-comment-pull-request@1.0.2 14 | with: 15 | message: > 16 | Thank you for submitting a grant application.
17 | 18 | We've assessed your submission and have found that it requires a higher level 19 | of technical detail in order to be considered for review. We encourage you to 20 | expand on it by providing a more precise specification/technical details. The 21 | [section on project details](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#project-details) 22 | in the application template is a good reference as to what type of information 23 | we expect applicants to provide, and these 24 | [category-specific requirements](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/grant_guidelines_per_category.md) 25 | contain more precise guidelines depending on what type of software you're building.
26 | 27 | An area of the application that we often find to be insufficiently elaborated are the 28 | milestone deliverables. At a minimum, please indicate what languages/technologies 29 | you will be using to implement each deliverable, and provide a technical summary 30 | of its expected functionality. Note that deliverables should be tangible, reusable 31 | by other teams and in most cases not already present in the ecosystem. If they are, 32 | you will need to provide a comparison to existing implementations and explain why 33 | it makes sense to fund your approach. Also see our 34 | [FAQ](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md#-general) 35 | for a breakdown of what we fund and what we don't.
36 | 37 | Let us know as soon as you're done with your changes, and we'll give your application another look! 38 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 39 | 40 | private_conversation: 41 | if: github.event.label.name == 'discussion private' 42 | runs-on: ubuntu-latest 43 | steps: 44 | - name: Comment PR 45 | uses: thollander/actions-comment-pull-request@1.0.2 46 | with: 47 | message: > 48 | The applicant has requested the discussion of the application to happen in a private chat room. 49 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 50 | -------------------------------------------------------------------------------- /applications/example-project.md: -------------------------------------------------------------------------------- 1 | # Example Project 2 | 3 | * **Proposer:** [Grant-Tester](https://github.com/Grant-Tester) 4 | * **Payment Address:** 3Q5qD4JDJEHjVT74PLWsASxhba9xwjgX9d 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | We are building a Substrate RPC client in the programming language XYZ. The client will be modeled after polkadot-js/api. We want to lower the friction of using XYZ with Substrate and believe this will benefit the whole ecosystem. An XYZ client will help us with our own parachain project. 9 | 10 | ## Team :busts_in_silhouette: 11 | 12 | * **Members:** Jane Doe, Joe Bloggs 13 | * **LinkedIn Profiles:** https://www.linkedin.com/Jane, https://www.linkedin.com/Joe 14 | * **Code Repos:** https://github.com/_jane, https://github.com/_joe 15 | * **Website:** http://example.com/ 16 | * **Legal Structure:** Example GmbH 17 | * **Team's Experience:** 18 | 19 | The example team has 15 years of experience building applications in XYZ. We also already finished all the https://substrate.dev/ tutorials. 20 | 21 | ## Development Roadmap :nut_and_bolt: 22 | 23 | * **Total Estimated Duration:** 8 weeks 24 | * **Total Costs:** 2 BTC 25 | 26 | ### Milestone 1 27 | 28 | * **Estimated Duration:** 4 weeks 29 | * **Costs:** 1 BTC 30 | 31 | 32 | | Number | Deliverable | Specification | 33 | | ------------- | ------------- | ------------- | 34 | | 0. | Apache License 2.0 | All code will be published under Apache 2.0 | 35 | | 1. | Coded types | This deliverable includes the following types of polkadot-js/api integrated into XYZ including unit tests: AbstractArray, Base, Compact, Enum, Int, ...| 36 | | 2. | Docker | A docker container that will also run on CI to test the deliverables of the milestone | 37 | | 4. | Repository | Repository including a README that describes the milestone and explains how to run, test and contribute | 38 | 39 | ### Milestone 2 40 | 41 | * **Estimated Duration:** 4 weeks 42 | * **Costs:** 1 BTC 43 | 44 | 45 | | Number | Deliverable | Specification | 46 | | ------------- | ------------- | ------------- | 47 | | 0. | Apache License 2.0 | All code will be published under Apache 2.0 | 48 | | 1. | Primitive types| This deliverable includes the following types of polkadot-js/api integrated into XYZ including unit tests: AccountId, AccountIndex, AccountInfo, Address, Bool, Bytes, ... | 49 | | 2. | Docker | A docker container that will also run on CI to test the deliverables of the milestone| 50 | | 3. | Repository | Repository including a README that describes the milestone and explains how to run, test and contribute| 51 | 52 | 53 | ## Additional Information :heavy_plus_sign: 54 | 55 | * We're currently implementing a Substrate-based chain. 56 | * We're also receiving a grant by the European Union for another XYZ project 57 | 58 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/social-recovery-wallet.md: -------------------------------------------------------------------------------- 1 | # Social Recovery Wallet 2 | 3 | * **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/Plus-social-recovery-wallet.md), [Implemented](https://github.com/hypha-dao/hashed-wallet), [Under Development 3](https://github.com/w3f/Grants-Program/blob/master/applications/keysafe_network.md) 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Managing your own private keys is a difficult task. The average person doesn’t want to spend multiple hours to ensure the security of their keys. This leads to people having difficulties to join the blockchain space or even worse leads to the loss of funds. One solution to this problem is the implementation of a social recovery system. It allows users to recover their accounts if their key or other authentication mechanism has been lost. Therefore you usually set up at least 3 "guardians" (e.g. other devices, friends or family or institutions), of which a majority can cooperate to change the key of the account (often after some delay). Kusama has for this purpose currently the [social recovery pallet implemented](https://github.com/paritytech/substrate/blob/master/frame/recovery). 9 | 10 | The goal of this RFP is to find teams that are willing to leverage this or similar mechanism to create wallet solutions (desktop, web, mobile, extensions, etc.) which are as easy to use as possible and at the same time offer a high security for the average user. 11 | 12 | Apart from the [social recovery pallet](https://github.com/paritytech/substrate/blob/master/frame/recovery), the support of the [Proxy Module](https://github.com/paritytech/substrate/tree/master/frame/proxy) and [Multisig Module](https://github.com/paritytech/substrate/tree/master/frame/multisig) is encouraged as part of this RFP to further improve the user experience. 13 | 14 | **Existing Social Recovery Wallets on Ethereum:** 15 | - https://www.argent.xyz/ 16 | - https://loopring.io/#/ 17 | 18 | **Other interesting sources:** 19 | - https://www.parity.io/social-recovery-on-substrate/ 20 | - https://vitalik.ca/general/2021/01/11/recovery.html 21 | - https://github.com/paritytech/substrate/blob/master/frame/recovery 22 | - https://github.com/paritytech/substrate/tree/master/frame/proxy 23 | - https://github.com/paritytech/substrate/tree/master/frame/multisi 24 | 25 | ## Deliverables :nut_and_bolt: 26 | 27 | The deliverables highly depend on the exact wallet implementation and therefore aren’t further described as part of this RFP. For the grant application you should take a look at the [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#overview-1) and try to specify the deliverables as detailed as possible. 28 | -------------------------------------------------------------------------------- /docs/RFPs/Open/parachain_validation_conformance_testing.md: -------------------------------------------------------------------------------- 1 | # Parachain Validation Conformance Testing 2 | 3 | * **Status:** Open 4 | * **Proposer:** [bkchr](https://github.com/bkchr) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Each Polkadot host implementation that wants to take part in consensus needs to implement the Parachains protocol. Part of the Parachains 9 | protocol is the execution of the Parachain Validation Function (`PVF`). The `PVF` is a wasm blob that is required to provide the `validate_block` 10 | function that takes a fixed set of arguments (part is the proof of validity from a collator), validates the proof of validity and returns (on success) some 11 | information back to the Polkadot host implementation. The `PVF` is a black box for the Polkadot node and it can only use the `validate_block` to 12 | make use of it. The execution of these `PVF`s is required to stay in certain limits to reach consensus across different node implementations, 13 | node versions, different hardware configuration and OS configurations. Some of these limits are: 14 | 15 | - A deterministic maximum stack depth. All node implementations should support the same stack depth. 16 | - A deterministic maximum memory. All node implementations should support the same maximum memory usage per `PVF` execution. 17 | - A deterministic maximum execution time. All node implementations should execute a given `PVF` in the same maximum time frame. 18 | - A deterministic compilation/preparation of the `PVF`. All node implementations should compile/prepare a given `PVF` in the same maximum time frame and maximum memory budget. 19 | 20 | There are probably a lot of other limits as well. To ensure that all node implementations/versions are staying in these limits it is required 21 | to have conformance tests. These should include basic execution of valid wasm files over to complex wasm files that ensure that the compilation/preparation 22 | stays in the given limits and/or helps to define these limits properly across different implementations. 23 | 24 | **Useful resources:** 25 | - [The Polkadot Parachain Host Implementers' Guide](https://paritytech.github.io/polkadot/book/index.html) 26 | - [Pre-checking for PVF Compilation time](https://github.com/paritytech/polkadot/issues/3211) 27 | 28 | ## Deliverables :nut_and_bolt: 29 | 30 | - Basic conformance tests that are running valid wasm files 31 | - Conformance tests that are resulting in running over the limits. 32 | - Fuzzing across different implementations ensuring that all are coming to the same result 33 | 34 | This is more some never ending task trying to find issues in different implementations, getting them fixed and searching for new vulnerabilities. 35 | In the end these tests should ensure that updating wasm engines, introducing new node implementations 36 | etc can be done in a sane way without hoping for the best. 37 | -------------------------------------------------------------------------------- /docs/suggesting.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 5 3 | title: 📬 Suggesting a Project 4 | --- 5 | 6 | 7 | 8 | If you think that we should support the development of certain tools or projects that aren't in the Polkadot/Kusama [tech stack](https://wiki.polkadot.network/docs/build-open-source), feel free to submit a suggestion ("Request for Proposal") using the process described below. We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem. 9 | 10 | For a list of previous Requests for Proposal and their status, see our [separate RFP page below](./rfps.md). 11 | 12 | **Submit an idea:** 13 | 14 | If you have an idea for a project or would like to highlight an area in which you'd like to see teams build, but lack the technical background to create a detailed outline, you're welcome to open an [issue](https://github.com/w3f/Grants-Program/issues/new) or add it to the [tech stack](https://wiki.polkadot.network/docs/build-open-source) as a potentially interesting project. We will review your suggestion and, if necessary, will create an RFP based on it and reach out to teams able to build it. 15 | 16 | **Submit an RFP (Request for Proposals):** 17 | 18 | Ideas generally have better chances of being implemented if they're presented in a project outline format that can be picked up straight away by a team, so if you have a good concept of the milestones required to bring your project to life, you can follow the process below and directly submit an RFP: 19 | 20 | 1. [Fork](https://github.com/w3f/Grants-Program/fork) this repository. 21 | 2. In the newly created fork, create a copy of the suggestion template ([`rfps/suggestion-template.md`](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/suggestion-template.md)) inside the [`rfps`](https://github.com/keeganquigley/Grants-Program/tree/master/docs/RFPs) folder. Make sure you create a new file and copy the [contents](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/suggestion-template.md) of the template into the new one, and _do not modify the template file directly._ 22 | 3. Name the file after your idea: `project_name.md`. 23 | 4. Fill out the template with the project details. Please include as many details as possible. 24 | 5. Once you're done, create a pull request in **our** main [Grants-Program repository](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/README.md). The pull request should only contain _one new file_—the Markdown file you created from the template. 25 | 6. You will see the same template as for creating an application. Please replace it with [the RFP PR template](https://github.com/w3f/Grants-Program/blob/master/.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md). 26 | 7. The RFP will be accepted and merged as soon as it receives three approvals from [W3F Grants Committee](./Introduction/team.md#w3f-grants-committee) members. 27 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/candle-auction.md: -------------------------------------------------------------------------------- 1 | # Candle auction smart contract 2 | 3 | * **Status:** [Implemented](https://github.com/agryaznov/candle-auction-ink/tree/master) 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 | -------------------------------------------------------------------------------- /docs/maintenance.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 6 3 | title: 🛠️ Maintenance Grants 4 | --- 5 | 6 | 7 | 8 | Maintenance Grants are yet another idea to get involved with the Polkadot community. If you are a user of an open-source library that has gone out of date, or you simply want to work on small new features/fix bugs in these repos, we can support your contributions via a grant. We are happy to award rolling grants on a monthly basis, as long as the work done within each time period is performed to a quality standard deemed satisfactory by the grant evaluators. 9 | 10 | ## Application Process 11 | 12 | The process of applying for a Maintenance Grant is similar to what was already outlined above, but instead of defining very detailed deliverables for each milestone upfront, we will ask you to specify, where possible: 13 | 14 | - the repo(s) that need maintenance, 15 | - outline of why the specific project should continue being supported, 16 | - broad overview of the features/bugs that need development contributions, 17 | - an assurance that the current project owners are willing to review/accept your contributions (a note here: if you're fully taking over the project, it would make more sense for the current owners to transfer the repository to your organisation. If you can't get in touch with them, you may, of course, work on a fork), and 18 | - max budget per month. 19 | 20 | Then, at the end of each month, you will need to provide a comprehensive report of the work done, including the list of issues/bugs/pull requests worked on, time spent on each of these & finally the associated cost. It is quite likely that the time allocation & cost will vary from month to month, depending on the nature of the project you're contributing to. The delivery process and format should follow that of a typical [milestone delivery](https://github.com/w3f/Grant-Milestone-Delivery#mailbox-milestone-delivery-process), as will the processing of the payment. 21 | 22 | ## Notes 23 | 24 | - Maintenance grants, as the name suggests, are meant to allow teams/individuals to maintain a certain project, and not to continue its development or implement larger features. Please use the traditional application process for this purpose. 25 | - The 1-month timeframe is just a guideline. If you find it unsuitable for you or the chosen project for any reason, feel free to adjust as seen fit and point this out in your application. 26 | - Please bear in mind that the Grants Committee might be stricter in accepting maintainers when compared to typical grants, mostly selecting for applicants with proven experience in the relevant tech stacks. 27 | - Maintenance Grants are only awarded for fixed timeframes. The requested duration needs to be specified in the application. 28 | 29 | ## Help 30 | 31 | - For a list of previously accepted maintenance grants, see the `applications/maintenance` folder in our grants repository. 32 | - For a list of ways to reach us and ask questions, see our [Help page](help.md). 33 | -------------------------------------------------------------------------------- /static/img/Reddit.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /applications/php-scale-lib.md: -------------------------------------------------------------------------------- 1 | # PHP Scale Codec 2 | 3 | * **Team Name:** [gmajor](https://github.com/gmajor-encrypt) 4 | * **Payment Address:** 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F 5 | 6 | 7 | ## Project Overview :page_facing_up: 8 | Scale Codec is PHP lib for decode/encode used by substrate. 9 | 10 | 11 | ## Team :busts_in_silhouette: 12 | 13 | ### Team members 14 | * gmajor 15 | 16 | ### Contact 17 | * **Contact Name:** gmajor 18 | * **Contact Email:** gmajorencrypt@gmail.com 19 | * **Legal Structure:** individual 20 | 21 | 22 | ### Team's experience 23 | 24 | I have many years of php development experience and nearly three years of blockchain development experience, familiar with php, golang, python, js 25 | 26 | 27 | ### Team Code Repos 28 | https://github.com/gmajor-encrypt/php-scale-codec 29 | https://github.com/gmajor-encrypt/php-substrate-api 30 | 31 | 32 | ## Development Roadmap :nut_and_bolt: 33 | 34 | * **Total Estimated Duration:** 8 weeks 35 | * **Total Costs:** 12000 Dai 36 | 37 | ### Milestone 1 38 | 39 | * **Estimated Duration:** 4 weeks 40 | * **Costs:** 6000 Dai 41 | 42 | 43 | | Number | Deliverable | Specification | 44 | | ------------- | ------------- | ------------- | 45 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 46 | | 0b. | Documentation | Simple documentation on how to use this library | 47 | | 1. | Scale decode | This deliverable includes the following types of https://substrate.dev/docs/en/knowledgebase/advanced/codec : Fixed-width Integers,Compact/General Integers,Boolean,Options,Vectors,Strings,Tuples, Structures, Enum| 48 | | 2. | Scale encode | This deliverable includes the following types of https://substrate.dev/docs/en/knowledgebase/advanced/codec : Fixed-width Integers,Compact/General Integers,Boolean,Options,Vectors,Strings,Tuples, Structures, Enum | 49 | | 3. | Unit test | Including all the unit tests mentioned above | 50 | | 4. | Packagist | Submit to Packagist for composer to use | 51 | 52 | 53 | ### Milestone 2 Example — Additional features 54 | 55 | * **Estimated Duration:** 2 weeks 56 | * **Costs:** 6200 Dai 57 | 58 | 59 | | Number | Deliverable | Specification | 60 | | ------------- | ------------- | ------------- | 61 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 62 | | 0b. | Documentation | Simple documentation on how to use this library | 63 | | 1. | Metadata decode | support recent runtime metadata decode | 64 | | 2. | Results encode/decode | Results types encode/decode, https://substrate.dev/docs/en/knowledgebase/advanced/codec#results| 65 | | 3. | Event decode | storage EventRecord decode| 66 | | 4. | Extrinsic decode | Extrinsic decode | 67 | | 5. | Custom Type reg | Can register a custom type through the file | 68 | | 6. | Unit test | Including all the unit tests mentioned above | 69 | | 7. | Packagist | Submit to Packagist for composer to use | 70 | 71 | ## Future Plans 72 | 73 | 1. Long-term support, Because I found that the underlying changes of substrate are still very frequent, I expect scale lib will be a long-term job in the future 74 | 75 | 76 | -------------------------------------------------------------------------------- /docs/RFPs/Open/sub-consensus.md: -------------------------------------------------------------------------------- 1 | # Sub-consensus mechanism 2 | 3 | * **Status:** Open 4 | * **Proposer:** mmagician, laboon 5 | * **Projects you think this work could be useful for:** All parachains 6 | 7 | ## Project Description :page_facing_up: 8 | 9 | ### Summary 10 | 11 | Parachain dApps suffer from long confirmation times due to the time taken for the Relay Chain to issue an on-chain verification of the parachain blocks. This proposal aims at providing an alternative mechanism for providing parachain users with an alternative, probabilistic sub-consensus mechanism. 12 | 13 | ### Project Details 14 | 15 | Currently the time taken from collator producing a block on a parachain, to that block becoming finalised, is prohibitive to some applications deployed on the parachain. What we'd like to introduce is a mechanism for parachain collators to achieve consensus among themselves on the "best" block. This mechanism would most likely be realised as an additional runtime module in which all collators can (but don't have to) participate, thus providing a faster way for the users of parachain applications to see quasi-finalised blocks -> note that this sub-consensus on parachains will have no effect on the decision of relay chain validators' votes and can at times diverge from the outcome on the relay chain. 16 | Should this mechanism be opt-in for collators, they could be incentivised to participate honestly by bonding a small stake, that is later slashed (the stick) in case a relay-chain-finalised-block causes a reorg on the sub-consensus mechanism. Conversely, the carrot would be a small reward paid out by the parachain governance (tied to the decision by that governance to include such a module) 17 | 18 | ## Deliverables :nut_and_bolt: 19 | 20 | * **Total Estimated Duration:** 3 months 21 | * **Full-time equivalent (FTE):** 1 22 | * **Total Costs:** 40,000 DAI 23 | 24 | ### Milestone 1 - Research and technical specification 25 | 26 | * **Total Estimated Duration:** 2 months 27 | * **Full-time equivalent (FTE):** 1 28 | * **Total Costs:** 20,000 DAI 29 | 30 | While normally the Grants Program doesn't fund the research phase, in this case a comprehensive write-up should proceed the implementation and should be subject to acceptance. 31 | 32 | At the end of the milestone, a detailed document should contain, at a minimum, the following parts: 33 | - summary of the current technical implementation and its limitations 34 | - technical proposal, including full specification of any pallets needed, as well as necessary changes (if any) to upstream substrate/cumulus repositories 35 | - security analysis of the proposed solution 36 | - summary of adoption of the proposed solution by a parachain team (either case study or general guidelines) 37 | 38 | ### Milestone 2 - PoC 39 | 40 | * **Total Estimated Duration:** 2 months 41 | * **Full-time equivalent (FTE):** 1 42 | * **Total Costs:** 20,000 DAI 43 | 44 | A proof of concept implementation of the proposed solution, or a full-fledged delivery. 45 | The scope of this milestone is highly dependant on the proposal submitted in M1. 46 | -------------------------------------------------------------------------------- /applications/subwallet.md: -------------------------------------------------------------------------------- 1 | # subwallet 2 | 3 | * **Proposer:** [Faber](https://github.com/yxf) 4 | * **Payment Address:** 1BHAopuz14S7L58oea1e6eTZpXuzYt8Ap9 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | `subwallet` is a light command line interface wallet for Polkadot/Substrate. `subwallet` will be like bitcoin-cli, includes address management and extrisinc(transaction) management. It will be implemented with Rust. 9 | 10 | ## Team :busts_in_silhouette: 11 | 12 | * **Members:** Faber 13 | * **LinkedIn Profiles:** - 14 | * **Code Repos:** https://github.com/yxf/subwallet 15 | * **Website:** https://github.com/yxf/subwallet 16 | * **Legal Structure:** individual 17 | * **Team's Experience:** 18 | 19 | Faber is a backend developer with 10+ years of strong experience. Learned and researched blockchain technology about 3 years. Familiar with Rust and Substrate. 20 | 21 | 22 | 23 | 24 | ## Development Roadmap :nut_and_bolt: 25 | 26 | * **Total Estimated Duration:** 8 weeks 27 | * **Total Costs:** 0.8 BTC 28 | 29 | ### Milestone 1 30 | 31 | * **Estimated Duration:** 4 weeks 32 | * **Costs:** 0.3 BTC 33 | 34 | 35 | | Number | Deliverable | Specification | 36 | | ------------- | ------------- | ------------- | 37 | | 1. | Command help | `subwallet --help` prints help information | 38 | | 2. | Address generation | `subwallet getnewaddress [label]` will generate a random address and save to local file. | 39 | | 3. | Address list | `subwallet listaddresses` will list all generated addresses | 40 | | 4. | Backup | `subwallet backup [address_or_label]` will backup address as json that compatible with `https://polkadot.js.org/apps`| 41 | | 5. | Restore | `subwallet restore [file]` will restore address from the file that compatible with `https://polkadot.js.org/apps` | 42 | | 6. | Unit Tests | Write unit tests for commands: `getnewaddress`, `listaddresses`, `backup` and `restore`. | 43 | | 7. | Documentation | Usages and demos of every command. | 44 | 45 | ### Milestone 2 46 | 47 | * **Estimated Duration:** 4 weeks 48 | * **Costs:** 0.5 BTC 49 | 50 | 51 | | Number | Deliverable | Specification | 52 | | ------------- | ------------- | ------------- | 53 | | 1. | Set RPC url | `subwallet setrpcurl [url]` save the RPC url to local file for other commands(transfer/syncextrinsics)| 54 | | 2. | Display balances | `subwallet getbalances` will also show balances of addresses | 55 | | 3. | Balance transfer | `subwallet transfer [from] [to] [amount]` transfer `amount` balances from `from` address to `to` address | 56 | | 4. | Sync extrinsics | `subwallet syncextrinsics [address_or_label]` download and save address related extrinsics from remote node to local file through RPC. | 57 | | 5. | Extrinsic list | `subwallet listextrinsics [address_or_label]` lists all downloaded extrinsics of address | 58 | | 6. | Unit Tests | Write unit tests for every command. | 59 | | 7. | Documentation | Usages and demos of every command. | 60 | 61 | ## Additional Information :heavy_plus_sign: 62 | * This will be version 0.1. In the future, more RPC methods will be implemented and will support other Substrate-based chains. 63 | 64 | 65 | -------------------------------------------------------------------------------- /docs/RFPs/Open/Static-Analysis-for-Runtime-Pallets.md: -------------------------------------------------------------------------------- 1 | # Static Analysis of Runtime Pallets 2 | * **Status:** Open 3 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 4 | 5 | ## Project Description :page_facing_up: 6 | 7 | [Runtime Pallets](https://docs.substrate.io/fundamentals/runtime-development/) are modules for writing the business logic of blockchains in [Substrate](https://github.com/paritytech/substrate) (a Rust framework fo rbuilding blockchians). These are usually concise pieces of standalone code with relatively few dependencies and clear specifications, hence tractable targets for performing static analysis and verification. We would like to develop tools and techniques to perform static analysis with reasonable soundness guarantees. In particular, we would like to target vunerability classes that are detectable using dataflow analysis techniques like *tag analysis* and *taint analysis*. Just to give a flavor, relevant might vulnerabilities include: 8 | * [incorrect origin](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/incorrect-origin/description.md) of dispatchable functions. 9 | * [unsigned transaction](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/unsigned-transaction/description.md) validation. 10 | * tracking bad randomness: ensure bad randomness does not leak into sensitive functions. 11 | * detect panics statically to avoid potential DoS attacks: these include [unsafe arithmetic operations](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/arithmetic-overflow/description.md), access outside bounds, assertion failures, etc. 12 | * tracking unsanitised input leakage for sensitive functions. 13 | 14 | We seek applications that either extend existing static analysers for rust like [MIRAI](https://github.com/facebookexperimental/MIRAI/), [Prusti](https://www.pm.inf.ethz.ch/research/prusti.html), or build Rust front-ends to static analysis engines. Our preliminary feasibility study shows that MIRAI would be a good starting point as it includes a tag analysis framework, however, we are open to other tools and techniques. 15 | 16 | ## Deliverables 17 | 18 | The deliverables listed are an innitial draft and can be modified taking into consideration the interests of the applicant. 19 | 20 | | Number | Deliverable | Specification | 21 | | ------------- | ------------- | ------------- | 22 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 23 | | 0b. | Documentation | A document describing the design decisions for the tool and modeling of vulnerabilities. Clear usage guideline along with the trade-off of different modes if any.| 24 | | 0c. | Testing Guide | Test-suite which exercises various features. | 25 | | 0d. | Article | A brief outreach article describing the high-level technique used and outcomes of the grant, including asample of minimal examples. | 26 | | 1 | Tool | A robust static analysis tool that works on Subsstrate runtime pallets and analyses vulnerabilities classes described above. | 27 | | 2 | Engaegment | Engage with teams at Web3 Foundation and Parity to prioritise targeting vulnerability classes.| 28 | 29 | -------------------------------------------------------------------------------- /docs/funding.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 8 3 | title: 🪙 Alternative Funding 4 | --- 5 | 6 | Some funding sources might be more and some less suitable for your project throughout its various stages. We encourage you to explore alternative funding options listed below. Please note, however, that you should not seek to fund the **same scope of work** from multiple sources and that any team found doing so will have its Web3 Foundation support terminated. 7 | 8 | ### Treasury 9 | 10 | The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both [Polkadot](https://polkadot.network/) and [Kusama](https://kusama.network/) offer everyone the opportunity to apply for funding via the treasury. See: 11 | 12 | - [Treasury](https://polkadot.network/treasury/) 13 | - [Treasury Bounties](https://polkadot.subsquare.io/treasury/bounties) 14 | - [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) 15 | - [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) 16 | 17 | ### Hackathons 18 | 19 | From time to time, Web3 Foundation and/or Parity organise hackathons to promote quick prototyping of Polkadot related ideas. We highly encourage you to participate in these hackathons. Bear in mind, however, that you cannot submit the **same work** for a hackathon and the Grants Program. If you have worked or are planning to work on a project for a hackathon, your grant application should either propose a different set of features or otherwise build on top of your hackathon work. The same applies in reverse, although that will likely be less common. 20 | 21 | The best way to find out about upcoming hackathons is by following Polkadot on the various social channels, such as Element or Twitter. 22 | 23 | ### Other Grant or Bounty Programs 24 | 25 | Below is a list of other grant and bounty programs in the Polkadot/Substrate ecosystem: 26 | 27 | - [Acala Grants Program](https://acala.network/ecosystem-program) 28 | - [Astar / Shiden Network Builders Program](https://github.com/PlasmNetwork/Builders-Program) 29 | - [Crust Grants Program](https://github.com/crustio/Crust-Grants-Program) 30 | - [Darwinia Grants Program](https://github.com/darwinia-network/collaboration/blob/master/grant/README.md#grant-program) 31 | - [Edgeware Grants and Bounties](https://gov.edgewa.re/discussion/1132-edgeware-proposal-process-and-template) 32 | - [HydraDX Grants and Bounties](https://docs.hydradx.io/new_deal/) 33 | - [ink!ubator](https://use.ink/ubator/) 34 | - [Interlay Labs Grants Program](https://github.com/interlay/Grants-Program) 35 | - [Moonbeam Grants Program](https://moonbeam.foundation/grants/) 36 | - [OAK’s Developer Grants](https://oak.tech/community/grants/) 37 | - [peaq Ecosystem Grant Program](https://www.peaq.network/grant-program) 38 | - [Phala Builders Program](https://wiki.phala.network/en-us/build/general/builders-program/) 39 | - [Picasso / Composable Grants Program](https://grants.composable.finance) 40 | - [SubQuery Grants Programme](https://subquery.network/grants) 41 | -------------------------------------------------------------------------------- /applications/halva_framework.md: -------------------------------------------------------------------------------- 1 | # Halva 2 | 3 | > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. 4 | 5 | * **Proposer:** [Halva](https://github.com/orgs/halva-suite) 6 | * **Payment Address:** 1837ca1w8WK9yfaVo5Lhgg4sENK2Tq3FgW 7 | 8 | ## Project Description :page_facing_up: 9 | 10 | Halva is a toolchain for improving the experience of developing Decentralized Applications based on Substrate. It provides a high-level way to configure a development environment, interact with Substrate through external API and writing your test cases. 11 | 12 | Halva inspired by [Truffle](https://github.com/trufflesuite/truffle) but implements Substrate specific API. It targets testing extrinsics via RPC calls this allows test Substrate (or clients compatible with Substrate RPC) as a black-box. Halva uses [Polkadot.js](https://github.com/polkadot-js) to interact with RPC. 13 | 14 | Right now you must do much boilerplate code around your testing framework (mocha, chai, ava, etc) so that beginning testing your Substrate based app. Halva addressing these challenges. 15 | 16 | ## Team :busts_in_silhouette: 17 | 18 | * **Members:** Wintex 19 | * **LinkedIn Profiles:** - 20 | * **Code Repos:** 21 | * **Website:** 22 | * **Legal Structure:** individual 23 | * **Team's Experience:** 24 | 25 | Our team develops software about 10+ years and decentralized applications since 2017. We have a great experience with typescript, node.js, and testing frameworks. 26 | 27 | ## Development Roadmap :nut_and_bolt: 28 | 29 | * **Total Estimated Duration:** 5 weeks 30 | * **Full-time equivalent (FTE):** 1.5 31 | * **Total Costs:** 1.82 BTC 32 | 33 | ### Milestone 1 34 | 35 | Core functional for automated testing with Mocha and Chai. This stage involves the creation of basic functionality for running tests. It will include the TestRunner package, and assertions to simplify checking external calls. 36 | 37 | Assertions: 38 | * **.passes** Asserts that the passed async extrinsic does not fail. 39 | * **.eventEmitted** The eventEmitted assertion checks that an event has been emitted by the transaction with result 40 | * **.eventNotEmitted** The eventNotEmitted assertion checks that an event has not been emitted by the transaction with result 41 | * **.reverts** Asserts that the passed async extrinsic fails with a certain reason. 42 | 43 | * **Estimated Duration:** 5 weeks 44 | * **FTE:** 1.5 45 | * **Costs:** 1.82 BTC 46 | 47 | | Number | Deliverable | Specification | 48 | | ------------- | ------------- | ------------- | 49 | | 1. | Configuration | Network config for interacting with many public & private networks, keyring config for initializing test accounts and chain spec parser | 50 | | 2. | Core | Implement primitives, assertions, a high-order function for a test-cases | 51 | | 3. | Testing | Implement scripts for command `halva test`. It run JavaScript tests with pre-initialized accounts. | 52 | | 4. | Documentations | Write documentations | 53 | -------------------------------------------------------------------------------- /.github/workflows/codeql.yml: -------------------------------------------------------------------------------- 1 | # For most projects, this workflow file will not need changing; you simply need 2 | # to commit it to your repository. 3 | # 4 | # You may wish to alter this file to override the set of languages analyzed, 5 | # or to provide custom queries or build logic. 6 | # 7 | # ******** NOTE ******** 8 | # We have attempted to detect the languages in your repository. Please check 9 | # the `language` matrix defined below to confirm you have the correct set of 10 | # supported CodeQL languages. 11 | # 12 | name: "CodeQL" 13 | 14 | on: 15 | push: 16 | branches: [ "master" ] 17 | pull_request: 18 | # The branches below must be a subset of the branches above 19 | branches: [ "master" ] 20 | schedule: 21 | - cron: '18 7 * * 5' 22 | 23 | jobs: 24 | analyze: 25 | name: Analyze 26 | runs-on: ubuntu-latest 27 | permissions: 28 | actions: read 29 | contents: read 30 | security-events: write 31 | 32 | strategy: 33 | fail-fast: false 34 | matrix: 35 | language: [ 'javascript' ] 36 | # CodeQL supports [ 'cpp', 'csharp', 'go', 'java', 'javascript', 'python', 'ruby' ] 37 | # Use only 'java' to analyze code written in Java, Kotlin or both 38 | # Use only 'javascript' to analyze code written in JavaScript, TypeScript or both 39 | # Learn more about CodeQL language support at https://aka.ms/codeql-docs/language-support 40 | 41 | steps: 42 | - name: Checkout repository 43 | uses: actions/checkout@v3 44 | 45 | # Initializes the CodeQL tools for scanning. 46 | - name: Initialize CodeQL 47 | uses: github/codeql-action/init@v2 48 | with: 49 | languages: ${{ matrix.language }} 50 | # If you wish to specify custom queries, you can do so here or in a config file. 51 | # By default, queries listed here will override any specified in a config file. 52 | # Prefix the list here with "+" to use these queries and those in the config file. 53 | 54 | # Details on CodeQL's query packs refer to : https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs 55 | # queries: security-extended,security-and-quality 56 | 57 | 58 | # Autobuild attempts to build any compiled languages (C/C++, C#, Go, or Java). 59 | # If this step fails, then you should remove it and run the build manually (see below) 60 | - name: Autobuild 61 | uses: github/codeql-action/autobuild@v2 62 | 63 | # ℹ️ Command-line programs to run using the OS shell. 64 | # 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun 65 | 66 | # If the Autobuild fails above, remove it and uncomment the following three lines. 67 | # modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance. 68 | 69 | # - run: | 70 | # echo "Run, Build Application using script" 71 | # ./location_of_script_within_repo/buildscript.sh 72 | 73 | - name: Perform CodeQL Analysis 74 | uses: github/codeql-action/analyze@v2 75 | with: 76 | category: "/language:${{matrix.language}}" 77 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/epassport-zk-validation.md: -------------------------------------------------------------------------------- 1 | # e-Passport ZK Validation [ON HOLD PENDING REVISIONS] 2 | 3 | 4 | * **Status:** On Hold 5 | * **Proposer:** [burges](https://github.com/burges), [FlorianFranzen](https://github.com/FlorianFranzen) 6 | 7 | 8 | ## Project Description :page_facing_up: 9 | 10 | The issue of verifying identities on-chain and providing Proof-of-personhood is a challenging one. 11 | 12 | One idea to authenticate users is to ask them to submit the details from their e-passports. While it would provide authentication, it forgoes the aspect of privacy. 13 | 14 | This proposal aims to provide the verifiability of personal data coming from e-passports, while ensuring protection of personal information by using zero-knowledge proofs. 15 | 16 | ## Deliverables :nut_and_bolt: 17 | 18 | Please note that the below given details do not comprise neither detailed nor security-complete plan of development. The implementing party should perform in-depth research on each part of the protocol in order to understand its limitations and nuances. 19 | 20 | ### Milestone 1 - transparent solution PoC on substrate 21 | 22 | * **Estimated Duration:** 3 months (incl. research) 23 | * **Costs:** 60,000 kUSD 24 | 25 | As the first step, we propose the creation of a working PoC without the use of zero-knowledge proofs that can be deployed on substrate. 26 | 27 | Deliverables: 28 | - Chain can store the necessary certificates from CSCA 29 | - User can upload their DSO (Document Security Object) as well as the associated DSC (Document Signer Certificate) on chain 30 | - The chain logic verifies: 31 | - DSC is valid against CSCA 32 | - the signature contained within the DSO checks out against DSC 33 | 34 | ### Milestone 2 - adding ZK functionality 35 | 36 | * **Estimated Duration:** 5 months 37 | * **Costs:** 100,000 kUSD 38 | 39 | Rather than supplying the entire DSO, which would reveal the user's personal information, users should be able to upload a cryptographic proof that they indeed know the data contained within the DSO, without revealing it in its entirety. 40 | 41 | There should be two parts to this functionality: off-chain prover and on-chain verifier. 42 | 43 | The users would supply all their private information to the off-chain prover (which they can either run themselves or use a trusted third party) and the prover would produce a cryptographic proof. 44 | 45 | Later, the proof is uploaded on-chain, and the chain logic performs verification of the proof given the pre-agreed circuit. The circuit must be shared between prover and verifier and should include public inputs such as the latest [Master List](https://www.icao.int/Security/FAL/PKD/Pages/ICAO-Master-List.aspx) of CSCA certificates, revocations, etc., as well as use the same algorithms and parameters. 46 | 47 | ### Milestone 3 - Updateability 48 | 49 | * **Estimated Duration:** 1 month 50 | * **Costs:** 20,000 kUSD 51 | 52 | The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furhtermore, countries are expected to publish the revocations of any compromised certificates. 53 | 54 | It is important that both prover and verifier circuits are updated accordingly - else the proof won't match. 55 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/privacy-enhancement-polkadot-extension.md: -------------------------------------------------------------------------------- 1 | # Privacy Enhancement for Polkadot Extension 2 | 3 | * **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/polkadot-js-extension-per-account-auth.md) 4 | * **Proposer:** jonasW3F 5 | * **Projects you think this work could be useful for** [optional]: https://github.com/polkadot-js/extension 6 | * **Teams/People that could deliver the RFP:** @celrisen 7 | 8 | ## Project Description :page_facing_up: 9 | 10 | An increasing number of websites require access to the Polkadot extension with a growing ecosystem. By allowing access to the extension, websites (naturally) can see the addresses that are contained in the extension. This imposes a big risk to privacy, because malicious actors could create lists about which addresses belong to one entity and, in the worst case, even link it to real-world identities (if at least one address is linked to an on-chain identity). A feature to prevent this is currently the "hide" button on single addresses, which prevent websites from seeing that address. However, it is currently cumbersome to handle that feature. The idea of this RFP is to extend on that feature and include a few QOL functionalities to make it easier for users to protect their privacy. 11 | 12 | ## Deliverables :nut_and_bolt: 13 | 14 | As outlined [here](https://github.com/polkadot-js/extension/issues/893), the deliverable should include five features to the extension and a successful completion of this RFP includes a merge of a PR to the main polkadot-js/extension repo. **It is of great importance to generate clean code that follows best-practices**. 15 | 16 | * **Total Estimated Duration:** 1 month 17 | * **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)) 18 | * **Total Costs:** $10'000. 19 | 20 | ### Milestone 1 21 | 22 | * **Estimated Duration:** 1 month 23 | * **FTE:** Amount of time (in days) required for a single person to complete this milestone 24 | * **Costs:** $10'000 25 | 26 | 27 | | Number | Deliverable | Specification | 28 | | ------------- | ------------- | ------------- | 29 | | 1. | "Hide all" | A global button that hides/un-hides all addresses | 30 | | 2. | "View-Groups" | Create and name groups which a user can organize their accounts to. For example, a "polkadot-js" group could unhide all accounts, while a "Parachain X" group only unhides those accounts a user knows that they have those parachain tokens on. | 31 | | 3. | "Privacy Mode" | A setting that automatically changes the extension to a specific view group (which could be "hide all"). | 32 | | 4. | "Hide from Extension" | A feature that lets users hide addresses in the extension itself. This is useful for doing demos or presenting the screen. Those accounts are listed in a special tab and can be unhidden from there. | 33 | | 5. | "Link View-Groups to URLs" | The extension already features an access control to specific URLs. To add on that, the extension could automatically switch to a defined view-group when entering an URL. Building on that, upon *first* authorization of a website, the extension could ask which view-groups to add it to or offer to create a new one. | 34 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/validator-selection-algorithm.md: -------------------------------------------------------------------------------- 1 | # RFP: Validator Selection Algorithm 2 | 3 | * **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/validators_selection.md) 4 | * **Proposer:** [jonasW3F](https://github.com/jonasW3F) 5 | 6 | ## Project Description 7 | 8 | Together with colleagues from academia, we developed an interactive process for nominations to better find suitable validators and the study is published [here](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4253515). The process is non-opinionated, which means that we do not have any opinion on any validator ex ante. The score of a validator is purely derived by the choices of the nominators. 9 | 10 | After having validated the results in the study, I'd like to see this implemented. For that, we need to set up a proper backend that exposes an API for other services to connect to. 11 | 12 | 13 | ## Deliverables :nut_and_bolt: 14 | 15 | The aim of this project is only a backend. The final result will be a Python flask application exposing its functionality via RESTful API 16 | 17 | - **Functionality**: 18 | - **Providing a pair of validators for comparison**: 19 | - Input: 20 | - previous comparisons 21 | - Output: 22 | - next pair 23 | - current model’s quality 24 | - current model 25 | - **Providing a ranking for a given model** 26 | - Input: 27 | - model 28 | - Output: 29 | - ranking of validators 30 | - **Accepting new data** 31 | - Input: 32 | - validators.csv file that contains information of recent era data from trusted sources 33 | 34 | - **Requirements**: 35 | - Linux system with python 3 and listed packages installed 36 | - 2GB of RAM 37 | - GPU (optional) 38 | - Network configuration allowing for communication on a selected port 39 | 40 | - **Testing** 41 | - Test if the code behaves as expected. 42 | 43 | * **Total Estimated Duration:** 6 weeks 44 | * **Full-time equivalent (FTE):** 30 days 45 | * **Total Costs:** 9000 USD (provisional) 46 | 47 | ### Milestone 1 (Implementation) 48 | 49 | * **Estimated Duration:** 4 weeks 50 | * **FTE:** 20 days 51 | * **Costs:** 6000 USD 52 | 53 | 54 | | Number | Deliverable | Specification | 55 | | ------------- | ------------- | ------------- | 56 | | 1. | Next pair | Develop an algorithm for efficient calculations of the next pair to be compared to maximize the model’s information gain. | 57 | | 2. | Ranking calculation | Develop an algorithm calculating a score for each validator | 58 | | 3. | New data | Develop a function for the data preprocessing | 59 | | 4. | Internal testing | Unit tests covering the functionality and logic | 60 | 61 | 62 | ### Milestone 2 (Testing) 63 | 64 | * **Estimated Duration:** 2 weeks 65 | * **FTE:** 10 days 66 | * **Costs:** 3000 USD 67 | 68 | 69 | | Number | Deliverable | Specification | 70 | | ------------- | ------------- | ------------- | 71 | | 1. | Deployment | Deploy the code on a provided server. | 72 | | 2. | Test live environment | Test the server efficiency and provide a report | 73 | | 3. | Polishing | Reach out for feedback to the Grants Team. Integrate final feedback on functional, as well as cosmetic changes like the way data are provided, configuration, etc. | 74 | -------------------------------------------------------------------------------- /docs/Process/how-to-apply.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | title: 1. Application 4 | --- 5 | 6 | 7 | :::caution 8 | 9 | The process below is independent of the [level](../Introduction/levels.md). Payment is made in fiat, Bitcoin, USDT (on Kusama or Polkadot) or USDC/DAI (Ethereum). If you want to apply in **private**, you can apply [:arrow_right: here](https://docs.google.com/forms/d/e/1FAIpQLSfMfjiRmDQDRk-4OhNASM6BAKii7rz_B1jWtbCPkUh6N7M2ww/viewform). Note that this is generally a slower process and imposes stricter requirements on applicants. 10 | 11 | ::: 12 | 13 | 14 | ## How to apply: 15 | 16 | 1. Please read our [FAQs](../faq.md), [category guidelines](../Support%20Docs/grant_guidelines_per_category.md), [announcement guidelines](../Support%20Docs/announcement-guidelines.md) and [Terms & Conditions](../Support%20Docs/T&Cs.md) to familiarize yourself with the subtleties of grants, applications and the program as a whole. 17 | 2. [Fork](https://github.com/w3f/Grants-Program/fork) our grants program repository. 18 | 3. In the newly created fork, create a copy of the [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md). If you're using the GitHub web interface, you will need to create a new file and copy the [contents](https://raw.githubusercontent.com/w3f/Grants-Program/master/applications/application-template.md) of the template inside the new one. Make sure you **do not modify the template file directly**. In the case of a maintenance application, use the [maintenance template](https://github.com/w3f/Grants-Program/blob/master/maintenance/maintenance-template.md) instead. 19 | 4. Name the new file after your project: `project_name.md`. 20 | 5. Fill out the template with the details of your project. The more information you provide, the faster the review. Please refer to our [Grant guidelines for most popular grant categories](../Support%20Docs/grant_guidelines_per_category.md) and make sure your deliverables present a similar same level of detail. To get an idea of what a strong application looks like, you can have a look at the following examples: [1](https://github.com/w3f/Grants-Program/blob/master/applications/project_aurras_mvp_phase_1.md), [2](https://github.com/w3f/Grants-Program/blob/master/applications/project_bodhi.md), [3](https://github.com/w3f/Grants-Program/blob/master/applications/pontem.md), [4](https://github.com/w3f/Grants-Program/blob/master/applications/spartan_poc_consensus_module.md). Naturally, if you're only applying for a smaller grant that only consists of, say, UI work, you don't need to provide as much detail. 21 | 6. Once you're done, create a pull request in **our** main [Grants-Program repository](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/README.md). The pull request should only contain _one new file_—the Markdown file you created from the template. 22 | 7. You will see a comment template that contains a checklist. You can leave it as is and tick the checkboxes once the pull request has been created. Please read through these items and check all of them. 23 | 8. Sign off on the [terms and conditions](../Support%20Docs/T&Cs.md) presented by the [CLA assistant](https://github.com/claassistantio) bot as a Contributor License Agreement. You might need to reload the pull request to see its comment. 24 | -------------------------------------------------------------------------------- /docs/Introduction/intro.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | --- 4 | 5 | # Guidelines 6 | 7 | Anyone is welcome to apply for a grant. Projects funded through our programs are broad in scope, but our focus lies on strong **technical** projects that add value to the ecosystem. 8 | 9 | Generally, your project will have better chances to be accepted if: 10 | 11 | - It presents a **well-researched** or tested concept, for which ideally you are able to show some prior work. 12 | - You can demonstrate that the project will be **maintained** after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources or an existing business model. 13 | - Your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine these for past activity and code quality. Naturally, you can also link to projects on other platforms. 14 | - Your application is **rich in technical details** and well-defined. 15 | - You can clearly present how your project stands out among competitors or implements technology that doesn't exist in the ecosystem yet. 16 | 17 | Additionally, it must fulfill the following requirements: 18 | 19 | - All code produced as part of a grant must be **open-sourced**, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT or Unlicense are also acceptable. 20 | - We do not award grants for projects that have been the object of a successful token sale. 21 | - Applications must not mention a specific token. Furthermore, the focus of the application should lie on the software that is being implemented/research being carried out as part of the grant, and less on your project/venture/operation. For the purpose of the application and delivery, think about how others might also benefit from your work. 22 | - As a general rule, teams are asked to finish a grant before applying for another one. 23 | - Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering or criminal activities in general. 24 | 25 | In addition to the information provided on your application, note that your project will need to comply with our [Guidelines for Milestone Deliverables](../Support%20Docs/milestone-deliverables-guidelines.md). In particular, we require all projects to create documentation that explains how their project works. At a minimum, _written_ documentation is required for funding. Tutorials or videos are also helpful for new users to understand how to use your product. 26 | 27 | Please also heed our [Announcement Guidelines](../Support%20Docs/announcement-guidelines.md) for grant-related communications. 28 | 29 | Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognised for their work very seriously. Using others' work with no attribution or indication that this was not your own work as part of a milestone delivery **will lead to immediate termination**. Please reach out to us before submitting if you have any doubts on how to comply with a specific license and we'll be happy to help. 30 | 31 | We also try to enforce our [code of conduct](../../CODE_OF_CONDUCT.md) and based on this may [block users](https://github.blog/2016-04-04-organizations-can-now-block-abusive-users/). 32 | -------------------------------------------------------------------------------- /applications/PolkaKey.md: -------------------------------------------------------------------------------- 1 | # PolkaKey 2 | 3 | * **Proposer:** @HiZhaoYun 4 | * **Payment Address:** 1NUYKUgjDrzXox7ebeT6xkFN5A64S419Xm 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | When user claim their DOTs, they need a native Polkadot address. Now, there are [several ways](https://claims.polkadot.network/) to generate a Polkadot address. Polkadot.js and Polkadot.js browser plugin is less secure than using Subkey. Subkey is secure, but it is ecommended for technically advanced users who are comfortable with command line and compiling Rust code, it is not recommended for general users. 9 | 10 | PolkaKey planned to provide a secure and simple way to generate a Polkadot address for general and technically advanced users. 11 | 12 | PolkaKey is a desktop app build with [Electron](https://www.electronjs.org/) and can run on three platforms (MacOS, Windows, and Linux). 13 | 14 | PolkaKey can generate a Polkadot address without internet connection. In fact, we also recommend that users use it when disconnected from the network. It is secure than using Polkadot.js and Polkadot.js browser plugin. 15 | 16 | PolkaKey will bringing smooth UX to Polkadot, it is simple than subkey. 17 | 18 | PolkaKey is open source for full transparency, so anybody can audit. 19 | 20 | PolkaKey will never save any info locally, the private key is self-owned. 21 | 22 | ## Team :busts_in_silhouette: 23 | 24 | * **Members:** Xianyun Zhao 25 | * **LinkedIn Profiles:** Sorry, we really rarely use LinkedIn in China. 26 | * **Code Repos:** https://github.com/w3finance/PolkaKey 27 | * **Website:** coming soon 28 | * **Legal Structure:** BoBao Technologies co. LTD 29 | * **Team's Experience:** Xianyun has 5 years of developing experience and similar with cross-platform apps development, currently i am working on a [wallet](https://github.com/dotpaytech/sakura) project that designed for Polkadot ecosystem. 30 | 31 | ## Development Roadmap :nut_and_bolt: 32 | 33 | * **Total Estimated Duration:** 3 weeks + 2weeks 34 | * **Total Costs:** 0.5 BTC ~+ 0.1 BTC~ 35 | 36 | ### Milestone 1 37 | 38 | * **Estimated Duration:** 2 weeks 39 | * **Costs:** 0.35 BTC 40 | 41 | | Number | Deliverable | Specification | 42 | | ------------- | ------------- | ------------- | 43 | | 1. | UI for showcase | Create working prototype which can demo the whole workflow | 44 | | 2. | Function implementation | Generate a Polkadot/Kusama address via PolkaKey. Setting functions, include:Language(Chinese + English). Online/Offline Event Detection | 45 | 46 | ### Milestone 2 47 | 48 | * **Estimated Duration:** 1 week 49 | * **Costs:** 0.15 BTC 50 | 51 | | Number | Deliverable | Specification | 52 | | ------------- | ------------- | ------------- | 53 | | 1. | Prepare for release | Add unit test, we use [jest](https://jestjs.io/en/) as our test runner. Fix issue on github, release the MVP version | 54 | 55 | ### ~Milestone 3~ 56 | 57 | * ~**Estimated Duration:** 2 weeks~ 58 | * ~**Costs:** 0.1 BTC~ 59 | 60 | | Number | Deliverable | Specification | 61 | | ------------- | ------------- | ------------- | 62 | | 1. | Add a Chinese + English tutorial | This tutorial is mainly about how to build an Electron app with Polkadot.js API. The tutorial will first be available on the github [Wiki](https://github.com/w3finance/PolkaKey/wiki). If possible, i hope to publish this tutorial on [Polkaworld](https://www.polkaworld.org/) and [Substrate Dev Hub](https://substrate.dev/en/tutorials) | 63 | -------------------------------------------------------------------------------- /applications/polkadotjs-hardware.md: -------------------------------------------------------------------------------- 1 | # Hardware ECDSA for Polkadot JS 2 | 3 | * **Proposer:** @akru 4 | * **Payment Address:** Ekf4HssuTpYjmUEvzy9AAFuqpUcNm9AAkrMF1stTU6Mo1hR (Kusama) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Hardware wallets provide for end-user much more hight grade of security than traditional software wallets because of moving the private key out of general using PC. The most popular, Trezor (https://trezor.io/) and Ledger (https://www.ledger.com/), supports Ethereum / Bitcoin cryptography (ECDSA) by default. But ECDSA crypto is native for the Polkadot ecosystem too that makes hardware wallets fully compatible with Polkadot applications without any changes in hardware wallet firmware. 9 | 10 | This proposal improves already implemented software ECDSA keyring in PolkadotJS (https://github.com/w3f/Open-Grants-Program/pull/6) and planned to be directly integrated into Polkadot JS which is part of the Polkadot ecosystem. 11 | 12 | Plasm Network(https://plasmnet.io) is a scaling Dapps platform on Substrate. Plasm Network is planned to be a parachain in the Polkadot ecosystem. The Plasm token distribution model involves the use of a lockdrop approach in Ethereum and Bitcoin networks where Secp256k1 cryptography is a de facto standard. Plasm team is highly interested in making lockdrop participation process smoothly as much as possible. ECDSA integration into the Polkadot ecosystem is one of the steps to makes it real. 13 | 14 | 15 | ## Team :busts_in_silhouette: 16 | 17 | * **Members:** Aleksandr Krupenkin, Sota Watanabe, Takumi Yamashita, Task Ohmori, Hoon Kim 18 | * **LinkedIn Profiles:** http://linkedin.com/in/krupenkin, https://www.linkedin.com/in/sota-watanabe-b962b3110, http://linkedin.com/in/task-ohmori-604398176 19 | * **Code Repos:** https://github.com/AstarNetwork/astar-frame, https://github.com/hoonsubin/apps/tree/page/custom-signature 20 | * **Website:** https://astar.network 21 | * **Legal Structure:** STAKE TECHNOLOGIES PTE. LTD. 105 CECIL STREET #24-02 THE OCTAGON SINGAPORE (069534) 22 | * **Team's Experience:** Stake Technologies is a technology company that focuses on substrate research and development as same as the business application of given results. Aleksandr Krupenkin, main experience as Haskell Web3 library (https://hs-web3.readthedocs.io/en/latest/index.html) owner, including cryptographic functions for Haskell Ethereum client. 23 | 24 | 25 | ## Development Roadmap :nut_and_bolt: 26 | 27 | * **Total Estimated Duration:** 10 weeks 28 | * **Full-time equivalent (FTE):** 0.6 29 | * **Total Costs:** 10,000 USDT 30 | 31 | ### Milestone 1 32 | 33 | * **Estimated Duration:** 10 weeks 34 | * **Full-time equivalent (FTE):** 0.6 35 | * **Costs:** 10,000 USDT 36 | 37 | Ledger API support for Polkadot JS Apps. 38 | 39 | | Number | Deliverable | Specification | 40 | | ------------- | ------------- | ------------- | 41 | | 1. | Ledger API ECDSA signer | Introducing Ledger API based signed for Polkadot JS. Required API methods already exposed by standard Ledger API: [getPublicKey](https://github.com/LedgerHQ/ledgerjs/blob/96306b2c0d75e1290461fb52b8f69f506a425643/packages/hw-app-btc/src/getWalletPublicKey.js#L16), [signMessage](https://github.com/LedgerHQ/ledgerjs/blob/96306b2c0d75e1290461fb52b8f69f506a425643/packages/hw-app-btc/src/signMessage.js#L6). | 42 | | 2. | Improve documentation | Add Ledger hardware wallet paragraph into Polkadot-js documentation. | 43 | | 3. | Demo video | Provide demo video of Polkadot Apps sign transaction with Trezor wallet. | 44 | -------------------------------------------------------------------------------- /docs/RFPs/Open/decentralized-security-marketplace.md: -------------------------------------------------------------------------------- 1 | # Decentralized Security Marketplace 2 | 3 | * **Status:** Open 4 | * **Proposer:** [Matteo Casonato](https://github.com/0xCaso), [Bhargav Batt](https://github.com/bhargavbh) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | According to the [*Immunefi's 2022 annual report*](https://assets.ctfassets.net/t3wqy70tc3bv/1ObYJk9jzWS4ExHICslYep/e2b5cee51268e47ee164c4dffbd78ad4/Immunefi_Crypto_Losses_2022_Report.pdf), there has been a total loss of ~$3.77B because of hacks in the web3 space. To increase the protocol's security, audits and bug bounties can be a useful tool. 9 | 10 | A **decentralized security marketplace** would allow projects to find reviewers/testers/auditors/whitehats, and vice versa. This would benefit everyone: 11 | - **Projects** would increase their security; 12 | - **Developers** would have the possibility to earn while using their skills, improving them; 13 | - The **ecosystem** would be more secure, with more projects being audited and more developers learning about security. 14 | 15 | The original thought is to make it as a smart contract platform, deployable on an existing parachain (that supports WASM smart contracts, such as [Astar](https://docs.astar.network/docs/getting-started) or [Watr](https://docs.watr.org/builders/substrate-contracts)) using [ink!](https://paritytech.github.io/ink/) ([here](https://github.com/paritytech/awesome-ink) you can see some examples). 16 | 17 | **Note**: This use case can be extended/applied to other areas. The main problem to solve here is to find a way to manage the *delayed* transaction between two parties (i.e., [escrow](https://en.wikipedia.org/wiki/Escrow)), and to ensure fairness and transparency (e.g., a reviewer is not able to deliver all the reports in time, and the project's team would like to decide whether to extend the escrow duration or just to pay a lower percentage of the established bounty). 18 | 19 | ### Actors :busts_in_silhouette: 20 | 21 | To ensure fairness and transparency, the marketplace could have the following actors: 22 | - **Projects** - The projects that want to be reviewed / tested; 23 | - **Auditors** - The developers that want to perform audits / hunt bugs; 24 | - **Arbiters** - The developers that will arbitrate the disputes between projects and auditors (they will be useful if a project opens a dispute for any reason). They could get a small percentage of the bounty. 25 | 26 | ## Deliverables :nut_and_bolt: 27 | 28 | 29 | The followings could be the initial deliverables of the project. Of course, improvements and additions are more than welcome. 30 | 1) Initial **research and design** of the protocol: 31 | - You can refer to what [Immunefi](https://immunefi.com/explore/) and [Code4rena](https://code4rena.com/) are doing (but bring that on-chain); 32 | - How to ensure the trustless interaction (e.g., projects could lock a percentage of the bounty to open the request); 33 | - What types of disputes could be risen and how to solve them; 34 | - How to manage time delays; 35 | - Look for other use cases (in or outside the security field); 36 | 2) Development of the **protocol**: 37 | - Development of the governance smart contract (e.g. to add/remove projects, auditors, arbiters, etc.); 38 | - Development of the auditing smart contract (e.g. to create audits); 39 | - Development of the arbitration smart contract (e.g. to create/solve disputes); 40 | 3) Development of the **frontend**, that enables the actors to interact with the protocol. 41 | -------------------------------------------------------------------------------- /applications/sup.md: -------------------------------------------------------------------------------- 1 | # Sup 2 | 3 | * **Proposer:** [clearloop](https://github.com/clearloop) 4 | * **Payment Address:** 1NKWsqRaWZDNX17cuzfyykcAA317njqzSn 5 | 6 | ## Project Overview :page_facing_up: 7 | 8 | sup is a substrate package manager using git, it allows developer new node-template 9 | and upgrade substrate dependencies in one comamnd. 10 | 11 | Hope this project can help more and more developers to join the ecosystem. 12 | 13 | ## Team :busts_in_silhouette: 14 | 15 | * **Members:** Mercury Fletcher 16 | * **LinkedIn Profiles:** https://www.linkedin.com/in/mercury-fletcher-2277191a3/ 17 | * **Code Repos:** https://github.com/clearloop/sup 18 | * **Website:** https://github.com/clearloop/sup 19 | * **Legal Structure:** Pensonal 20 | * **Team's Experience:** Author of [ElvisJS](https://github.com/elvisjs/elvis), [leetcode-cli](https://github.com/clearloop/leetcode-cli) 21 | 22 | 23 | ## Development Roadmap :nut_and_bolt: 24 | 25 | * **Total Estimated Duration:** 2 days 26 | * **Full-time equivalent (FTE):** 0.285 27 | * **Total Costs:** 0.1 BTC 28 | 29 | ### Milestone 1 — Generate Node-Template in one command 30 | 31 | * **Estimated Duration:** 1 day 32 | * **FTE:** 0.285 33 | * **Costs:** 0.05 BTC 34 | 35 | Just run: 36 | 37 | ``` 38 | $ cargo install sup 39 | $ sup new 40 | $ cd && cargo build 41 | ``` 42 | 43 | And it will work. 44 | 45 | | Number | Deliverable | Specification | 46 | |--------|--------------------------------|-------------------------------------------| 47 | | 0 | `sup new ` | New node-template in one command | 48 | | 1 | `sup update` | Update sup registry | 49 | | 2 | `sup source --query ` | List substrate dependencies with versions | 50 | | 3 | `sup tag --limit ` | List avaiable registry tags | 51 | 52 | 53 | ### Milestone 2 — Upgrading Substrate depencidencies in one command 54 | 55 | * **Estimated Duration:** 1 day 56 | * **FTE:** 0.285 57 | * **Costs:** 0.05 BTC 58 | 59 | Run: 60 | 61 | ``` 62 | $ sup upgrade --tag --registry 63 | ``` 64 | 65 | + Upgrades the registry of substrate by tag for the current project. 66 | + Supports customize subtrate registry(including substrate-based registry) 67 | 68 | | Number | Deliverable | Specification | 69 | | ------ | -------------------------------------------------- | ------------------------------------------------------------ | 70 | | 0 | `sup new --tag --registry ` | New node-template with specified tag and registry | 71 | | 1 | `sup update --registry ` | Update target registry | 72 | | 2 | `sup source --tag --registry ` | List substrate dependencies with versions | 73 | | 3 | `sup tag --registry ` | List avaiable tags of target registry | 74 | | 4 | `sup upgrade --tag --registry ` | Upgrade current project to the target or latest tag of the current or target registry | 75 | 76 | ### Community engagement 77 | 78 | The tutorials and Documentation that we provide will be published as articles in Medium, [rust.cc](rust.cc) and other social media platforms with due mention about Web3 grant. 79 | -------------------------------------------------------------------------------- /docs/RFPs/Open/data_analysis_tools.md: -------------------------------------------------------------------------------- 1 | # Data Analysis Tools for Substrate-based Blockchains 2 | 3 | * **Status:** Open 4 | * **Proposer:** [dsm-w3f](https://github.com/dsm-w3f), [michalisFr](https://github.com/michalisFr) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Block Explorers are tools that index blockchain data and allow people to easily exhibit it using a web user interface. Examples of Block Explorers in the Polkadot/Kusama ecosystem are (not exhaustive) Subscan, Calamar, and Statescan. For common users, the features commonly found in block explorers are enough. However, for advanced users, the data analysis involves accessing many screens and following long paths through blockchain data. 9 | 10 | 11 | For example, Accounts has some provenance information that is pretty difficult or currently impossible to extract in block explorers. The account reference counter, account balance reserved provenance (see: https://docs.substrate.io/reference/account-data-structures/), and OpenGov delegations are examples of it. Some questions raised that use this data: 12 | 13 | 14 | - Which transactions/accounts were responsible for the reserved balance in an account? 15 | - What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references? 16 | - Which accounts have delegated OpenGov votes to an account or to which accounts the account in question has delegated their votes to for each track, taking into account indirect delegations too (e.g. Account A delegates to Account B which delegates to Account C)? 17 | 18 | This information is useful and requested for actual heavy users of the Polkadot/Kusama ecosystem. 19 | 20 | This RFP is not limited to the example above and intends to support other analyses. This RFP is also not limited to adding new features to the existent block explorer, as applicants can propose new analysis tools as well. Please notice that the intention here is not to create new block explorers that would have the same information, presented in the same way, as the current ones. 21 | 22 | ## Deliverables :nut_and_bolt: 23 | 24 | The expected deliverables are the tool features that provide specific data analysis. The data analysis provided by the tool should be detailed in the deliverables. Each analysis should be dynamic, reflecting the current state of the blockchain, and be presented in a web user interface, in a way that advanced non-technical users can consume, i.e., the user does not need to have programming skills. Please list each data analysis that will be supported by the tool in the deliverables including: 25 | 26 | - The data analysis question. (ex: Which transactions were responsible to reserve the balance amount in an account?) 27 | - The expected input for the data analysis (ex: an account) 28 | - The expected output for the data analysis (ex: a set of transactions that made/removed a balance reserve in the input account) 29 | 30 | 31 | The proposed analysis should not overlap with existing ones if the information is easy to extract in block explorers of the Polkadot/Kusama ecosystem. They can, however, overlap if the information is not simple or can't intuitively be found by non-technical users in the current block explorers (ex. based on multiple steps in the block explorer or based on events data). 32 | 33 | The user interface provided should allow the users to make or find the questions that can be answered by the tool. The tools should NOT demand that users need to know or learn technical query languages such as SQL, GraphQL, or any other. 34 | -------------------------------------------------------------------------------- /.github/workflows/README.md: -------------------------------------------------------------------------------- 1 | # Testing workflows 2 | 3 | 4 | ## Fork testing (on GitHub) 5 | 6 | 0. Setup your Google API Credentials on https://console.developers.google.com/ 7 | - Credentials -> Create Credentials -> Service Accounts 8 | - Enable the Google Sheets API under [APIs and Services](https://console.cloud.google.com/apis/dashboard?project=festive-folio-343701) 9 | 10 | 1. Fork the Open Grants repo (or create a private repo and push to it) 11 | 12 | 2. Set up your secrets under the fork/settings: 13 | - GSHEET_PRIVATE_KEY 14 | - GSHEET_CLIENT_EMAIL 15 | - SPREADSHEET_ID 16 | - MATRIX_TOKEN 17 | - MATRIX_CHANNEL_ID (for both matrix vars, refer to [this](https://github.com/fadenb/Matrix-Chat-Message) guide, W3F account is on 1Password) 18 | - ACTIONS_STEP_DEBUG: set this to true for more verbose logs on workflow runs 19 | - ACTIONS_RUNNER_DEBUG: similar as above, haven't tried it 20 | 21 | 3. Branch off from master. Create a PR with only 1 file added (e.g. `cp deliveries/.delivery_testing.md deliveries/.delivery_testing_2.md`, add & commit it). Different workflows are triggered on different conditions. Note: Push any changes to your fork's master branch before you branch off, because the workflow to run will be the one from master. 22 | 23 | ## Local testing 24 | 25 | While it requires some assumptions & is somewhat limited in scope, it's possible to run local testing on some of the workflows 26 | 27 | ### Setup 28 | 0. Setup your Google API Credentials on https://console.developers.google.com/ 29 | - Credentials -> Create Credentials -> Service Accounts 30 | 1. Follow the instructions for installing [act](https://github.com/nektos/act) 31 | 2. The act environment is configured via `.actrc` & `.env` files. For this repo, we set: 32 | - the docker image used for testing to `nektos/act-environments-ubuntu:18.04`, corresponding to GitHub's test environment. Probably not all features are necessary, but we rely for example on the presence of `jq` in the image for JSON parsing. 33 | ``` 34 | echo "-P ubuntu-latest=nektos/act-environments-ubuntu:18.04" > .actrc 35 | ``` 36 | - `ACT=true` environment variable. This way we can distinguish which steps to run 37 | ``` 38 | echo "ACT=true" > .env 39 | ``` 40 | 3. Pull the above mentioned docker image: 41 | ``` 42 | docker pull nektos/act-environments-ubuntu:18.04 43 | ``` 44 | 45 | ### Testing 46 | 47 | 4. Modify the `google_sheet_update.yml` to replace the `parse files` section with `local testing parse files` (since they have the same ID, they can't both be used in the yml or else GitHub will complain). They should both be there by default, it's just a matter of commenting one section out. 48 | 5. Create a sample pull request file: 49 | ``` 50 | echo '{ 51 | "pull_request": { 52 | "head": { 53 | "ref": "10e629ef2f090f55a52b693961de8f5e1206d900" 54 | }, 55 | "base": { 56 | "ref": "10e629ef2f090f55a52b693961de8f5e1206d900" 57 | }, 58 | "state": "open", 59 | "author": "mmagician", 60 | "number": 174, 61 | "body": "# Grant Application Checklist\n- [X] The [application-template.md](https://github.com/w3f/Open-Grants-Program/blob/master/applications/application-template.md) has been copied, renamed ( \"project_name.md\") and updated." 62 | } 63 | }' > .pr_event.json 64 | ``` 65 | 6. ``` 66 | act -s GSHEET_PRIVATE_KEY="$(< .gsheet_private_key)" -s GSHEET_CLIENT_EMAIL="$(< .gsheet_client_email)" -s SPREADSHEET_ID="$(< .spreadsheet_id)" -e .pr_event.json -j update_sheet 67 | ``` 68 | -------------------------------------------------------------------------------- /applications/polkadotjs-ecdsa.md: -------------------------------------------------------------------------------- 1 | # ECDSA for Polkadot JS 2 | 3 | * **Proposer:** @akru 4 | * **Payment Address:** bc1qccvrcny62epea360w0dvy2ynv90vz5luansmg9 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Currently Polkadot/Substrate support three kinds of cryptographic primitives as MultiSignature data type: 9 | 10 | * Ed25519 11 | * Sr25519 12 | * ECDSA 13 | 14 | Unfortunately, right now Polkadot JS support first two only (enhancement issue: https://github.com/polkadot-js/common/issues/506). It's limiting using ECDSA keys for subkey CLI utility only, which makes user experience pipeline a bit difficult. 15 | 16 | Main aim of this project is providing comfortable environment for ECDSA key owners (Ethereum/Bitcoin holders) as same as for Sr/Ed25519 keys. 17 | 18 | Supporting wide range of cryptographic primitives is powerful side of substrate/polkadot ecosystem. This projects makes this side user-friendly introducing cryptographic primitives support on UI side. 19 | 20 | This project planned to be directly integrated into Polkadot JS which is part of Polkadot ecosystem. 21 | 22 | Plasm Network(https://plasmnet.io) is a scaling Dapps platform on Substrate. Plasm Network is planned to be a parachain in Polkadot ecosystem. Plasm token distribution model involves the use of a lockdrop approach in Ethereum and Bitcoin networks where Secp256k1 cryptography is a de facto standard. Plasm team is highly interested in making lockdrop participation process smoothly as much as it possible. ECDSA integration into Polkadot ecosystem is one of steps to makes it real. 23 | 24 | 25 | ## Team :busts_in_silhouette: 26 | 27 | * **Members:** Aleksandr Krupenkin, Sota Watanabe, Takumi Yamashita, Task Ohmori, Kim Hoon 28 | * **LinkedIn Profiles:** http://linkedin.com/in/krupenkin, https://www.linkedin.com/in/sota-watanabe-b962b3110, http://linkedin.com/in/task-ohmori-604398176 29 | * **Code Repos:** https://github.com/staketechnologies/common, https://github.com/staketechnologies/apps 30 | * **Website:** https://stake.co.jp 31 | * **Legal Structure:** Stake Technologies Inc. Avex EYE Avex Blog 3-1-30 Minamiaoyama Minato-ku Tokyo Japan 32 | * **Team's Experience:** Stake Technologies is technological company that focus on substrate research and development as same as business application of given results. Aleksandr Krupenkin, main experience as Haskell Web3 library (https://hs-web3.readthedocs.io/en/latest/index.html) owner, including cryptographic functions for Haskell Ethereum client. 33 | 34 | 35 | ## Development Roadmap :nut_and_bolt: 36 | 37 | * **Total Estimated Duration:** 2 weeks 38 | * **Total Costs:** 0.6 BTC 39 | 40 | ### Milestone 1 41 | 42 | * **Estimated Duration:** 2 weeks 43 | * **Costs:** 0.6 BTC 44 | 45 | Main aim of this is providing compatability layer for secp256k1 keypair into Polkadot JS key management system. 46 | 47 | | Number | Deliverable | Specification | 48 | | ------------- | ------------- | ------------- | 49 | | 1. | Polkadot JS ECDSA sign/verify support | Introducing secp256k1 keypair into Polkadot-js/common repository as same as sr25519 type: https://github.com/polkadot-js/common/blob/master/packages/util-crypto/src/types.ts, implementing Sing/Verify interfaces. | 50 | | 2. | Polkadot JS sign/verify tests | Integration tests for secp256k1 keypair. | 51 | | 3. | Polkadot JS Apps ECDSA support | Introducing secp256k1 key types for Apps account management widget. ECDSA account should be possible to send extrinsics as same as Sr25519 or Ed25519 account. | 52 | | 4. | Improve documentation | Add ECDSA description paragraph into Polkadot-js documentation. | 53 | | 5. | Polkadot JS Apps demo video | Provide demonstration how Polkadot Apps works with Ethereum (secp256k1) private keys. | 54 | -------------------------------------------------------------------------------- /docs/RFPs/Open/formal_guarantees_for_grandpa.md: -------------------------------------------------------------------------------- 1 | # Formal Guarantees for GRANDPA Finality Gadget 2 | * **Status:** Open 3 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 4 | 5 | ## Project Description :page_facing_up: 6 | 7 | Consensus layers are the backbones of blockchains. Any vulnerability in the consensus mechanism can have far reaching consequences on the integrity and security of the whole system. Polkadot’s Relay Chain uses [GRANDPA](https://research.web3.foundation/en/latest/polkadot/finality.html) (a deterministic finality gadget) to achieve consensus in the network. 8 | 9 | This proposal aims to provide formal guarantees of GRANDPA’s correctness and security by modeling the consensus mechanism and verifying it against formal specifications. We expect this exercise would lead to better implementations, since writing formal specs exposes implicit assumptions. Furthermore, developers can identify invariants to guide implementation, and use counterexamples to produce tests that expose bugs. 10 | 11 | We are open to any reasonable formal methods approach that rigorously proves the correctness of GRANDPA’s claims of validity, finality and liveness. Suggested list of techniques include: 12 | - Model-checking (in TLA+ Apalache, Ironfleet, IVY) 13 | - interactive theorem proving (in Isabelle/HOL, Coq, verdi) 14 | - Any other temporal property verification tool for distributed systems 15 | 16 | We envision the project to prove both safety and liveness properties of GRANDPA which interacts with a Block Production mechanism (like [BABE](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html) or [Sassafras](https://research.web3.foundation/en/latest/polkadot/block-production/SASSAFRAS.html)) by assuming an abstract interface. 17 | 18 | ## Deliverables 19 | 20 | The structure of the grant and the milestones depends highly on the project itself. It’s therefore up to the applying team to come up with a milestone and delivery structure. 21 | 22 | The deliverables listed below are just an initial draft, assuming the project uses the approach of Modelcheking in TLA+ and can be changed. Proof of correctness can be delivered in stages. Verification of safety properties is mandatory and liveness properties is an optional objective. 23 | 24 | | Number | Deliverable | Specification | 25 | | ------------- | ------------- | ------------- | 26 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 27 | | 0b. | Documentation | A document describing the design decisions in the modeling process, including justification for abstractions and assumptions (e.g. on the network model, latency, behavior of validators, nature of faults) w.r.t to protocol in the Paper and Spec. In-line comments in the TLA+/ PlusCal models that provide a clear mapping to the feature/property. | 28 | 0c. | Testing Guide | Instructions to set up the required environment to run the analysis, preferably a docker image with all the tools pre-installed. | 29 | | 0d. | Article | High-level document summarizing the results of the verification efforts as well as a final presentation for a broader audience that summarizes the key take-aways. | 30 | | 1 | Proof Artifact| Models and specs in TLA+ that adhere to protocol implementations with reasonable abstraction gaps. As a stepping stone, the block production mechanism could be instantiated with BABE. | 31 | | 2 | Proof Artifact| Formalize the validity, finality and liveness of GRANDPA as temporal properties in TLA+. | 32 | | 3 | Engagements | Engage with the Web3 research team via regular meetings to refine the models and specs. For eg., clarify any assume/ rely reasoning made in the protocols. Engage with Web3 team to determine if detected bugs's are spurious.| 33 | 34 | -------------------------------------------------------------------------------- /docs/RFPs/Open/bpf-contracts.md: -------------------------------------------------------------------------------- 1 | # BPF-based ink! smart contracts 2 | 3 | * **Status:** Open 4 | * **Proposer:** [takahser](https://github.com/takahser) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | Substrate's [FRAME contracts pallet](https://docs.rs/crate/pallet-contracts/latest) allows for WASM-based smartcontracts on Substrate, written in [ink!](https://github.com/paritytech/ink), a Rust-based [eDSL](https://wiki.haskell.org/Embedded_domain_specific_language). WASM comes with a lot of advantages, such as high flexibility, tooling, a good compiler ([wasmtime]([https://xxxwasmtime](https://github.com/bytecodealliance/wasmtime))) and a lot of high level constructs. However, these features comes with a cost: complexity of the API and compiler implementation as well as impacts on performance. For example, Substrate does not embed the API for WASM VM due to its complexity. 9 | 10 | ### eBPF as a WASM alternative 11 | 12 | An alternative to WASM here would be [eBPF](https://ebpf.io/), a technology for running sandboxed programs in an operating system kernel. It originated from BSD's [BPF](https://www.freebsd.org/cgi/man.cgi?bpf) that comes with a [permissive](https://en.wikipedia.org/wiki/Permissive_software_license#:~:text=A%20permissive%20software%20license%2C%20sometimes,usually%20including%20a%20warranty%20disclaimer.) open-source license and represents a Linux-compatible implementation thereof, that instead uses a [viral](https://www.lawinsider.com/dictionary/viral-open-source-license) open-source license. 13 | 14 | ### eBPF constraints 15 | 16 | However, vanilla eBPF has some serious constraints: 17 | 1. [LLD](https://lld.llvm.org/) can't link BPF code (LLD is the [linker](https://en.wikipedia.org/wiki/Linker_(computing)) contained in [LLVM](https://llvm.org/) which is the compiler framework that Rust's compiler `rustc` relies on). 18 | 2. `rustup` doesn't include any `core` nor `std` library for LLVM (and rustc)'s a upstream BPF targets (`bpfeb-unknown-none` and `bpfel-unknown-none`) 19 | 3. Loops are [not fully supported](https://lwn.net/Articles/740157/). 20 | 21 | While 1) and 2) technically can be worked around by using [bpf-linker](https://github.com/aya-rs/bpf-linker), 3) needs further research. Also, 2) will only work if loops are bound statically due to constraints within the LLVM backend. A viable solution here would be to replace this constraint by using [gas metering](https://github.com/paritytech/wasm-instrument/blob/b51701088e3d4f13b77047237a2480b488e6d099/src/gas_metering/mod.rs#L108). 22 | 23 | ### eBPF advantages 24 | 25 | Despite the constraints, eBPF-based ink! smart contracts would be expected to have the following advantages over its WASM-based counterpart: 26 | 27 | - Simplicity: Due to its register-based instruction set it would be easier to compile 28 | - Efficiency and performance 29 | 30 | ### Previous work 31 | 32 | [Alex](https://forum.polkadot.network/u/Alex) and [pepyakin](https://forum.polkadot.network/u/pepyakin) have attempted to use eBPF instead of WASM for ink! smart contracts when attending a hackathon. While they didn't manage to compile to BPF, their resources might be useful as a starting point: 33 | 34 | - eBPF contracts [hack report](https://forum.polkadot.network/t/ebpf-contracts-hackathon/1084/3) 35 | - Version of [pallet-contracts that can run eBPF contracts](https://github.com/pepyakin/substrate-seal-ebpf) 36 | - [Example contract](https://github.com/athei/bpf-adder) 37 | 38 | ### Conclusion 39 | 40 | The goal of this RFP is to allow for eBPF-based smart contracts. 41 | To summarize, the rough process should be: 42 | 43 | 1. Compile Rust-based ink! smart contracts using [rBPF](https://github.com/qmonnet/rbpf), returning an *eBPF ELF file* 44 | 2. Store the ELF file on-chain 45 | 3. Execute the ELF file within the eBPF VM that will convert it to machine code 46 | 47 | -------------------------------------------------------------------------------- /docs/RFPs/Open/user-account-access-analysis.md: -------------------------------------------------------------------------------- 1 | # User Account Access Security Analysis for Wallets 2 | 3 | * **Status:** Open 4 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 5 | * **Objectives** Security analysis of the user interface of Polkadot Wallets, particularly account access and recovery. 6 | 7 | ## Project Description :page_facing_up: 8 | 9 | Security is as strong as its weakest link. More often than not, it's the users (humans) that are the most vulnerable point in the system. This proposal aims to comprehensively analyse the security of user-facing protocols of Polkadot. In particular, Polkadot’s account generation and access is quite complex for users in the ecosystem. Several non-conventional mechanisms for account access like [multi-signatures](https://wiki.polkadot.network/docs/learn-account-multisig), intent-specific [proxies](https://wiki.polkadot.network/docs/learn-proxies), and [social recovery mechanisms](https://github.com/paritytech/substrate/tree/master/frame/recovery) provide interesting functionalities but also result in non-trivial user experiences. 10 | 11 | The proposal intends to first formally model the account generation, access, backup, and recovery mechanism for popular Polkadot wallets considering human-interactions as part of the system. Secondly, a comprehensive security analysis (automated or otherwise) is warranted to detect loop-holes in account access by the user, covering features like multi-signatures and anonymous proxies. A systematic technique for modelling and analysing account access is described in the paper ['User Account Access Graphs'](https://people.inf.ethz.ch/rsasse/pub/AccountAccessGraphs-CCS19.pdf). The security analysis should focus on detecting unauthorised access across attack surfaces, and also detect possible scenarios of genuine users being locked-out of the account. This analysis may also lead to detecting redundancies in the authentication process and streamlining the user experience. 12 | 13 | 14 | ## Deliverables :nut_and_bolt: 15 | 16 | The project is well-suited to be completed as a Bachelor's Thesis/ Master's Thesis/ Internship at an academic institute in collaboration with the Research Team at Web3 Foundation. The deliverables are just a template and can be modified taking into consideration the interests of the appplicant. 17 | 18 | | Number | Deliverable | Specification | 19 | | ------------- | ------------- | ------------- | 20 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 21 | | 0b. | Documentation | Document describing the threat model, scope of the analysis, and description of the approach/methodology used. | 22 | | 1 | Analysis Report| Security analysis report of the current account generation, access, back-up, and restoring mechanism used in popular Polkadot wallets like [Polkadot-JS Browser Extension](https://polkadot.js.org/extension/), [subkey](https://docs.substrate.io/reference/command-line-tools/subkey/), [Polkadot-JS UI](https://github.com/polkadot-js/ui), [Parity Signer](https://www.parity.io/technologies/signer/), [Talisman](https://www.talisman.xyz/) etc. The analysis should also take into consideration features like multi-signatures, stashing, proxies, and anonymous proxies. The analysis includes: 1) sound and complete detection of unauthorised access; 2) minimal counterexamples for exploits if any; 3) lockout risks for users | 23 | | 2 | Analysis Report| Possible improvements in usability (e.g., getting rid of redundant authentication layers during restoration) stemming from the analysis should be documented. | 24 | | 3 | Models/Code | Models developed to formalise and analyse the different wallets. Code and set-up for automated analysis, if any. | 25 | | 4 | Engagements | Engage with the Web3 Foundation teams to validate the correctness of models and the specifications.| 26 | -------------------------------------------------------------------------------- /docs/Support Docs/grant_guidelines_per_category.md: -------------------------------------------------------------------------------- 1 | # Grant guidelines for most popular grant categories 2 | 3 | While we ask teams to provide details of their envisioned solution, we are aware that precise implementation might slightly differ from the initial specification. Should there be large deviations from the original plan, please communicate this to the Grants Team ahead of time. 4 | 5 | The list below serves only as a guide and is not exhaustive. 6 | 7 | ## Runtime Modules/Chains 8 | 9 | ### Applies to 10 | 11 | - Building/extending a Substrate pallet 12 | 13 | ### Requirements 14 | 15 | - List the publicly exposed methods 16 | - For each method, specify (to the best of present knowledge): 17 | - Method signature (incl. parameters with their types, return type) 18 | - Short description (code template) 19 | - Runtime Storage defined by your module 20 | - [Use case diagram](https://www.wikiwand.com/en/Use_case_diagram) with e.g. UML or SysML (or similar tool demonstrating how external users/system components interact with one another) 21 | 22 | 23 | ## Development Tools 24 | 25 | ### Applies to 26 | 27 | - CLI tools 28 | - IDE / IDE plugin 29 | 30 | ### Requirements 31 | 32 | - State what programming language you'll use 33 | - Describe the commands that you want to make available to the users: 34 | - Name 35 | - Parameters 36 | - Result (value returned / file created or modified / application started etc.) 37 | 38 | 39 | ## UI Development 40 | 41 | ### Applies to 42 | 43 | - Building a web application with front-end components 44 | - Developing a mobile app 45 | 46 | ### Requirements 47 | 48 | - Provide mockups and/or wireframes (e.g. Figma) 49 | - List frameworks & tools for development & testing (e.g. React Native, Angular) 50 | 51 | ## Backend Development 52 | 53 | ### Applies to 54 | 55 | - Building a service/mobile app/webapp that relies on a back-end component 56 | 57 | ### Requirements 58 | 59 | - State what language & framework you'll use (e.g. python with Django, Rust with Rocket) 60 | - Define your database requirements and which system you'll use 61 | - Choose how & where will your backend be hosted (cloud provider, IPFS, localhost?) 62 | - Consider scaling & how you plan to handle it 63 | - Consider CI/CD 64 | - If you are (planning on) hosting the backend yourself, consider adding a [security.txt](https://securitytxt.org/) file so people can get in touch with you regarding (potential) security issues 65 | - Provide a link to your Github repository if you already have the structure in place 66 | 67 | 68 | ## Cryptography 69 | 70 | ### Applies to 71 | 72 | - New crypto library 73 | - Extending existing library's functionalities 74 | 75 | ### Requirements 76 | 77 | - Specify what programming language you'll use 78 | - Provide any publications/papers you will base your work on 79 | - Research other crypto libraries providing similar functionalities. State whether/how you plan to use their work. If they don't suit your needs, provide a detailed explanation why and what's missing 80 | - List any existing crypto libraries that you will use as reference implementation (e.g. in a different language) 81 | 82 | ## Research 83 | 84 | ### Applies to 85 | 86 | - Research projects 87 | 88 | ### Requirements 89 | 90 | - Specify the problem(s) that you want to investigate, and why these are important. 91 | - Declare the research questions/hypothesis. 92 | - State the methodology that will be applied. 93 | - Explain how the data will be collected and the analysis procedures. 94 | - Outline the expected results and how they would be double-checked by the grants team (reproducibility of the data analysis). 95 | - Research for relevant related work or declare how the literature review will be conducted. 96 | - Research and declare the intended venue for results publication and the timeline for publication. 97 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/uncollateralized-stablecoin-research.md: -------------------------------------------------------------------------------- 1 | # Uncollateralized Stablecoin Research 2 | 3 | * **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/stardust.md) 4 | * **Proposer:** [Noc2](https://github.com/Noc2) 5 | * **Projects you think this work could be useful for** [optional]: Any Defi Project 6 | 7 | ## Project Description :page_facing_up: 8 | 9 | Stablecoins are cryptocurrencies where the price is designed to be pegged (=fixed exchange rate) to a cryptocurrency, fiat money, or to exchange-traded commodities. Seigniorage-style, uncollateralized or algo stablecoin is a token that uses algorithms to control the circulating supply to get a stable value of the asset. In general the price volatility of cryptocurrencies is one of the biggest barriers to widespread adoption. Stablecoins therefore have become a key component of DeFi applications. However, all successful existing stable coins (e.g. DAI, USDT, USDC, etc) are asset backed. Therefore they are subject to the same volatility and risk associated with the backing asset and the underlying process. Some of the potentially issues based on this are: 10 | - Additional trust assumptions (e.g. USDT) 11 | - Scalability issues (restricted by the underlying asset) 12 | - Devalue under massive crashes in the underlying assets 13 | 14 | Purely algorithmic stablecoin would overcome these risks. Additionally it would be fairly simple to peg an algorithmic stablecoin to different assets (USD, EUR) or in the future even to a consumer price index (CPI). However, until now most algorithmic stablecoins introduced significant additional disadvantages or weren't able to maintain their peg for a longer period of time (e.g. AMPL, ESD, DSD, BAC, NuBits). 15 | 16 | The goal of this RFP is to research and create new uncollateralized stablecoin mechanisms and implement these as ink! smart contract or pallets. The biggest research question hereby is how to efficiently decrease the supply of the token. 17 | 18 | **Useful resources:** 19 | - https://www.basis.io/basis_whitepaper_en.pdf 20 | - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2425270 21 | - https://www.youtube.com/watch?v=bnC5RQsaAXQ 22 | - https://econteric.com/stablecoin/algo/ 23 | - https://assets.fei.money/docs/whitepaper.pdf 24 | - https://www.terra.money/Terra_White_paper.pdf 25 | 26 | ## Deliverables :nut_and_bolt: 27 | 28 | 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. 29 | 30 | * **Total Estimated Duration:** 2 month 31 | * **Full-time equivalent (FTE):** 1 32 | * **Total Costs:** 30k 33 | 34 | ### Milestone 1 - Research & Design 35 | 36 | * **Estimated Duration:** 1 month 37 | * **FTE:** 1 38 | * **Costs:** 10k 39 | 40 | 41 | | Number | Deliverable | Specification | 42 | | ------------- | ------------- | ------------- | 43 | | 1. | Overview of existing solutions | Create an overview of existing and previous uncollateralized stablecoin solutions and why they failed. | 44 | | 2. | Increasing Supply | Develop a mechanism to deal with an increasing demand for the cryptocurrency and analyses potential attack vectors | 45 | | 3. | Decreasing Supply | Develop a mechanism to deal with an decreasing demand for the cryptocurrency and analyses potential attack vectors| 46 | 47 | ### Milestone 2 - PoC Implementation 48 | 49 | *Ideally part of a separate follow-up grant, since it depends on the outcome of the initial research!* 50 | 51 | * **Estimated Duration:** 1 month 52 | * **FTE:** 1 53 | * **Costs:** 20k 54 | 55 | 56 | | Number | Deliverable | Specification | 57 | | ------------- | ------------- | ------------- | 58 | | 1. | Implement PoC| Implement the previous reasearch as ink! Smart contract or pallets | 59 | | 2. | UI (optional) | Implement a basic UI that can be used for testing | 60 | 61 | -------------------------------------------------------------------------------- /docs/RFPs/Closed/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 | -------------------------------------------------------------------------------- /docs/RFPs/Under Development/crowdloan_front_end_template.md: -------------------------------------------------------------------------------- 1 | # Crowdloan Front End Template 2 | 3 | * **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/crowdloan_frontend_template.md), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/Crowdloans-FET.md) 4 | * **Proposer:** [SBalaguer](https://github.com/SBalaguer), [Noc2](https://github.com/Noc2) 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | The following document intends to outline what a front-end white-label template could look like for teams to use to easily build their Polkadot Crowdloan ([see Wiki: Parachain Crowdloans](https://wiki.polkadot.network/docs/learn-crowdloans)) websites. Teams applying for this RFP can change and adapt this. 9 | 10 | The overall objective of this project is to provide a white-label solution to teams to be able to plug into and offer all the information users need to contribute to their Crowdloan. In essence, it's a collection of: 11 | 1. [Project information](#project-information) 12 | 2. [Rewards Schema](#rewards-schema) 13 | 3. [Current contributions](#current-contributions) 14 | 4. [Time left in Crowdloan and competition](#time-left-in-crowdloan-and-competition) 15 | 5. [Contribute CTA](#contribute-cta) 16 | 6. [After the Crowdloan](#after-the-crowdloan) 17 | 18 | All of the above should be done _style agnostic_ so that the project can plug their own look and feel into the site. 19 | 20 | ### Project Information 21 | 22 | This is just a place where the project can talk more about what they are doing. 23 | 24 | ### Rewards Schema 25 | 26 | This is just a place what the reward schema looks like. It's important to know that different teams can have different rewards mechanisms. For example, a team can offer higher contribution to early-birds (first `x_amount_of_contributors`; first `y amount_of_tokens_contributed`), they can offer referrals or even they can get smarter and offer higher rewards if they are losing. 27 | 28 | In the end, for this section it's more important to give the teams the ability to query easily the information than rather to get them a UI pre-defined. In general, it would be good for the template to offer two out-of-the-box mechanisms: 29 | 1. Early Bird contributions. 30 | 2. Rewards schema. 31 | 32 | Whichever the schema, there should be also a way of having this information available later on for the team to effectively give out the rewards. 33 | 34 | ### Current Contributions 35 | 36 | Some teams like to show the number of contributors, others the list of addresses and how much they contributed, and others nothing at all. We need to give them all an option. 37 | 38 | ### Time left in Crowdloan and competition 39 | 40 | Auctions have two phases: `start_period` and `ending_period`. During the `start_period` nothing important really happens, however every block of the `ending_period` matters, as this is when the candle can go out. 41 | 42 | On top of this, teams will have other teams competing for the slots as well. This information needs to be displayed as well. 43 | 44 | ### Contribute CTA 45 | 46 | A simple button to allow users to contribute directly through the UI. This should open PolkadotJS or whatever wallet the user prefers, and add this directly on chain. Important to manage the entire cycle of the contribution: 47 | - contribute -> waiting for finalization -> finalized. 48 | - contribute -> waiting for finalization -> error. 49 | 50 | ### After the Crowdloan 51 | 52 | Once the Crowdloan ends, it will be good for the team to easily query all contributors and have them sort it to calculate the rewards given the [rewads schema](#Rewards-Schema). 53 | 54 | ## Available Tools 55 | - [PolkadotJS Apps](https://polkadot.js.org/docs/) 56 | - [CAPI](https://github.com/paritytech/capi) 57 | 58 | ## Past examples 59 | - [Acala](https://acala.network/acala/join-acala) 60 | - [Calamari](https://mantanetwork.medium.com/the-calamari-crowdloan-on-kusama-74a3cb2a2a4b) 61 | - [Basilisk](https://loan.bsx.fi/) 62 | - [Parachains Info](https://parachains.info/auctions). In here check timeline and competition. 63 | -------------------------------------------------------------------------------- /applications/dart-scale-codec.md: -------------------------------------------------------------------------------- 1 | # dart-scale-codec 2 | 3 | > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. 4 | 5 | * **Proposer:** [NBLTrust](https://github.com/nbltrust) 6 | * **Payment Address:** 1LcdMwwiG1Vt8UmMqUk1RLAd2MUpbeoyba 7 | 8 | ## Project Overview :page_facing_up: 9 | 10 | A Dart implementation of the SCALE (Simple Concatenated Aggregate Little-Endian) Codec. We are building a wallet app called [**Jadewallet**](https://github.com/w3f/General-Grants-Program/pull/338) which will support DOT/KSM, this project is a component of it. 11 | 12 | **Jadewallet** is making a new paradigm of self-custody, which uses **multi-party computation (MPC)** and **threshold signature scheme (TSS)** technology. **MPC based Threshold Signatures** gives clients total autonomy over whose digital assets and multisignature ability with keyless cryptographic security. 13 | 14 | We are building **Jadewallet** with Flutter, although there are Rust, C++ implementations of the SCALE Codec, we think the Dart implementation is the first choice. And we hope the project will also help the Polkadot developer community. 15 | 16 | ## Team :busts_in_silhouette: 17 | 18 | ### Team members 19 | 20 | * Alex Xu 21 | * Hilbert Zhou 22 | 23 | ### Team Website 24 | 25 | * 26 | 27 | ### Legal Structure 28 | 29 | Tuolian (Shanghai) Co., Ltd. 30 | 31 | ### Team's experience 32 | 33 | - Alex Xu: Co-Founder and CTO in NBLTrust for 4 years, core developer in our three custody products. IT Consultant in IBM for 9 years. **Polkadot Ambassador China**. Worked as TA in two training courses hold by Parity in China. 34 | * Hilbert Zhou: 2 years ops experience on AIX, websphere and Power. 7+ years backend service development experience including HFT, CTA and blockchain. 35 | 36 | Founded in 2017 and headquartered in Shanghai, China, Tuolian(Shanghai) Co., Ltd. is a high-tech company specializing in the field of digital asset custody. 37 | 38 | Tuolian has secure custody softwares based on self-developed high-strength classical cryptographic algorithm, hot & cold wallet and hardware wallet products that meet the bank's security level requirements, to provide overall solutions and related technical services for digital asset custody. 39 | 40 | Tuolian provides a full range of custody services for well-known companies or organizations such as Math Wallet and HashQuark. 41 | 42 | ### Team Code Repos 43 | 44 | * 45 | * 46 | 47 | ## Development Roadmap :nut_and_bolt: 48 | 49 | * **Total Estimated Duration:** 1 month 50 | * **Full-time equivalent (FTE):** 1.5 51 | * **Total Costs:** 0.85 BTC. 52 | 53 | ### Milestone 1 — Dart Implementation 54 | 55 | * **Estimated Duration:** 1 month 56 | * **FTE:** 1.5 57 | * **Costs:** 0.85 BTC 58 | 59 | | Number | Deliverable | Specification | 60 | | ------------- | ------------- | ------------- | 61 | | 0a. | License | Apache 2.0 | 62 | | 0b. | Documentation | Delivering document in dart supported format, and publish the package to pub.dev | 63 | | 0c. | Testing Guide | Delivering Unit tests.
Delivering an example of fetching and analyzing binary metadata from chain's runtime.
Delivering an example of sending extrinsics to substrate based chain. | 64 | | 1. | Implementing the Library | Delivering a library that support converting between object/json/binary of following types: MetadataV11 & 12, u8, u16, u32, u64, u256, bool, fixed length array, dynamic length array, bytes, address, String, Compact, Hash256, Balance, Extrinsic, Generalized structure, Generalized Enum | 65 | 66 | ## Future Plans 67 | 68 | We are planning to make our dart-substrate-sdk open source. 69 | 70 | ## Additional Information :heavy_plus_sign: 71 | 72 | ### Are there are any teams who have already contributed (financially) to the project? 73 | 74 | No. 75 | 76 | ### Have you applied for other grants so far? 77 | 78 | [**Jadewallet**](https://github.com/w3f/General-Grants-Program/pull/338) 79 | -------------------------------------------------------------------------------- /static/img/Polkadot_Logo_Horizontal_BlackOnWhite.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /applications/multisignature_management_tool.md: -------------------------------------------------------------------------------- 1 | ## Multi-signature_Management_Tool 2 | 3 | - **Proposer:** [Hong Tao](https://github.com/carlhong) 4 | - **Payment Address:** 3P1DGw78xgkQ2pTPT1hcwmzozY1T93gmTB 5 | 6 | ## Project Description 7 | 8 | When we developed and used the multi-signature feature, we found that there is no multisignature wallet tool that can be used conveniently. The current wallet project is mainly designed for different usage environments, such as mobile wallet app, web wallet, chrome extension, etc. The development of these wallets (except the polkadot.js app) is at an early stage, and lack of multi-signature module . Polkadot.js apps is a very powerful tool, however the user experience and interface of substrate's native multi-signature module integrated in polkadot js is not friendly enough. 9 | 10 | Therefore, we want to develop a Web Multisignature Management Tool (like [gnosis](https://wallet.gnosis.pm/#/wallets) based on Ethereum), implement a Substrate multisignature Portal and Web Tool integration, and bring users a better experience. Besides, subscan will support multisig Extrinsic details display. At current stage, our goal is offering users have a convenient multisignature tool and helping developers reduce the development cost of similar functions. 11 | 12 | - Network scalability 13 | 14 | All chains built on substrate [`as_multi`](https://github.com/paritytech/substrate/blob/v2.0.0-rc6/frame/multisig/src/lib.rs#L235>) module can use our tools to complete related operations directly. The chain that changes the [`as_multi`](https://github.com/paritytech/substrate/blob/v2.0.0-rc6/frame/multisig/src/lib.rs#L235>) module can use our UX design partly or completely according to their needs to reduce the development cost. 15 | 16 | - Platform scalability 17 | 18 | The web Multi-signature Management Tool can only run on PC and use it with extension programs. 19 | 20 | ## Objectives 21 | 22 | - Create multi-signature account and send extrinsic 23 | - Manage multi-signature wallets and extrinsic 24 | - `as_multi` Module subscan browser adaptation 25 | - Support multiple networks that are based on Substrate development 26 | - UX optimization 27 | 28 | ## Team members 29 | 30 | [Wan Bei](https://github.com/woeom), [Hong Tao](https://github.com/carlhong) 31 | 32 | ## Legal Structure 33 | 34 | Shanghai Yitaiyuan Tech 35 | 36 | ## Team Website 37 | 38 | 39 | 40 | ## Team's experience 41 | 42 | Our team is based in Shanghai and Nanjing. We are very interested in substrate and we have done a lot of related development work, such as helping Darwinia build web wallet. 43 | 44 | But our focus has always been Subscan blockchain explorer, which keeps it updated quickly. 45 | 46 | ## Team Code Repos 47 | 48 | 49 | 50 | 51 | 52 | ## Development Roadmap 53 | 54 | ### Basic function: generate Multisig account and send Extrinsic 55 | 56 | - General UI design (in [Figma](https://www.figma.com/proto/WaysNQWlEB4wWK0a4mzYJQ/Multisig?scaling=min-zoom&node-id=0%3A2)) 57 | - backend design doc(in [Notion](https://www.notion.so/backend-doc-e7b4f79ede7b4d9cb39a52769c2aab2d), in [Google Docs](https://docs.google.com/document/d/18OgQ2Oh1oR9LIiZ9Uct35zHQ25f7gN1C-ngiqyrMfxU/edit?usp=sharing)) 58 | - Integrate with polkadot js extension 59 | - Multisig wallet creation and management 60 | - Basic Multisig Extrinsic(transfer) create and process in Multisig wallet 61 | - Multisig wallet support polkadot mainnet 62 | - Build user-friendly UI to list decoded call data with its hash for users who participated in the multi-signatures, data will be verified by hash on frontend 63 | - Use database or other backend service to store the index data. 64 | - Docker Files and Images 65 | - Unit tests and integration test 66 | - Tutorials 67 | 68 | Total for worker implementation: 25 days 69 | 70 | Budget: 1 BTC 71 | 72 | ### Advanced function: more features for multisig wallet and support more network 73 | 74 | - Multisig wallet support more kinds of Extrinsic such as staking, Democracy 75 | - Support kusama ,Darwinia and other network which base on Substrate 2.0 76 | - Docker Files and Images 77 | - Unit tests and integration test 78 | - Tutorials 79 | 80 | Total for worker implementation: 30 days 81 | 82 | Budget: 1 BTC 83 | 84 | 85 | 86 | **Total Budget: 2 BTC.** 87 | -------------------------------------------------------------------------------- /applications/php-rpc-lib.md: -------------------------------------------------------------------------------- 1 | # PHP RPC Lib 2 | 3 | * **Team Name:** [gmajor](https://github.com/gmajor-encrypt) 4 | * **Payment Address:** 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F(Dai) 5 | * **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 6 | 7 | 8 | ## Project Overview :page_facing_up: 9 | 10 | PHP RPC Lib is PHP lib for query http rpc used by substrate. 11 | 12 | ### Overview 13 | 14 | * PHP is an extremely common development language in the web field, and currently there is no RPC library for substrate. 15 | I have already developed https://github.com/gmajor-encrypt/php-scale-codec in the previous grant. PHP RPC Lib is necessary to interact with the chain 16 | 17 | ### Project Details 18 | 19 | * Sr 25519 20 | 21 | Since PHP does not have an encryption library for sr25519 22 | 23 | Will provide the following interfaces 24 | 25 | 1. SR25519.NewKeypairFromSeed(seed) 26 | 2. SR25519.sign(message), 27 | 3. SR25519.verify(message, signature) 28 | 29 | 30 | * Send transaction 31 | 32 | Example 33 | ```php 34 | $api = new SubstrateRpc("websocket_or_http_url"); 35 | $signer = new SubstrateRpc\Util\Keyring\Signer("privatekey");// or HD 36 | $api->setSigner($signer); 37 | $tx = $api->tx->balances->transfer("to_address", 10000); 38 | $tx->signAndSend(); 39 | ``` 40 | 41 | * Read/subscribe HTTP/Websocket to RPC endpoints 42 | 43 | Example 44 | 45 | ```php 46 | $api = new SubstrateRpc("websocket_or_http_url"); 47 | $api->rpc->System->Heath(); 48 | 49 | # or read storage 50 | $api = new SubstrateRpc("websocket_or_http_url"); 51 | $api->rpc->state->System->Account("/ALICE"); 52 | 53 | ``` 54 | 55 | * Support all substrate RPC method https://polkadot.js.org/docs/substrate/rpc 56 | 57 | ### Ecosystem Fit 58 | 59 | Can help php language developers to easily access the substrate (polkadot) ecology 60 | 61 | 62 | ## Team :busts_in_silhouette: 63 | 64 | ### Team members 65 | 66 | * gmajor 67 | 68 | ### Contact 69 | 70 | * **Contact Name:** gmajor 71 | * **Contact Email:** gmajorencrypt@gmail.com 72 | * **Website:** https://github.com/gmajor-encrypt 73 | 74 | ### Legal Structure 75 | 76 | individual 77 | 78 | ### Team's experience 79 | 80 | I have many years of php development experience and nearly three years of blockchain development experience, familiar with PHP, GOLANG, PYTHON, JS 81 | 82 | ### Team Code Repos 83 | 84 | https://github.com/gmajor-encrypt/php-scale-codec 85 | 86 | https://github.com/gmajor-encrypt/php-substrate-api 87 | 88 | ## Development Status :open_book: 89 | 90 | * RPC lib basic framework https://github.com/gmajor-encrypt/php-substrate-api 91 | 92 | 93 | ## Development Roadmap :nut_and_bolt: 94 | 95 | 96 | ### Overview 97 | 98 | * **Total Estimated Duration:** 2 months 99 | * **Total Costs:** 9000 DAI 100 | 101 | ### Milestone 1 102 | 103 | * **Estimated duration:** 1 month 104 | * **FTE:** 1 105 | * **Costs:** 5000 USD 106 | 107 | | Number | Deliverable | Specification | 108 | | -----: | ----------- | ------------- | 109 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 110 | | 0b. | Documentation | Simple documentation on how to use this library | 111 | | 1. | HTTP RPC support | Http Rpc support, include http/websocket | 112 | | 2. | sr25519 | sr25519 bindings | 113 | | 3. | Unit test | Including all the unit tests mentioned above | 114 | | 4. | Packagist | Submit to Packagist for composer to use | 115 | 116 | 117 | ### Milestone 2 118 | 119 | * **Estimated Duration:** 1 month 120 | * **FTE:** 1 121 | * **Costs:** 4,000 USD 122 | 123 | | Number | Deliverable | Specification | 124 | | -----: | ----------- | ------------- | 125 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 126 | | 0b. | Documentation | Simple documentation on how to use this library | 127 | | 1. | Extrinsic encode | Extrinsic encode | 128 | | 2. | Signed Extrinsic send | Send transaction support, include ed25519&sr25519| 129 | | 3. | substrate rpc api | support all substrate rpc like https://polkadot.js.org/docs/substrate/rpc | 130 | | 4. | Unit test | Including all the unit tests mentioned above | 131 | | 5. | Packagist | Submit to Packagist for composer to use | 132 | 133 | 134 | ## Future Plans 135 | 136 | 1. Long-term support, Because I found that the underlying changes of the substrate are still very frequent, like metadata, I expect will be a long-term job in the future 137 | -------------------------------------------------------------------------------- /applications/ink-boxes.md: -------------------------------------------------------------------------------- 1 | # Ink Boxes 2 | 3 | * **Team Name:** Ink Boxes Team 4 | 5 | * **Payment Address:** Bitcoin Address: bc1qtr9993ch6zlr29j5c22zzax57h62x5gj24wtxk 6 | 7 | * **Level:** 1 8 | 9 | 10 | ## Project Overview :page_facing_up: 11 | 12 | ### Overview 13 | 14 | Ink boxes are a collection of helpful Ink smart contract boilerplates along with it's frontend. It will already have polkadot.js library using which frontend can talk with the smart contract deployed. Got inspired by truffle boxes on how easily one can spin up the boilerplate code in no time. 15 | 16 | ### Ecosystem Fit 17 | - Where and how does your project fit into the ecosystem? 18 | Anyone who wants to quickly spin up boilerplate can use our platform. 19 | - Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? 20 | Anyone who wants to create Smart Contracts on top of Ink are our target users. 21 | 22 | 23 | ### User Journey 24 | - User visits Ink boxes website. 25 | - User selects the dApp they want to download. 26 | - User will be able to download the entire dApp code in zip format. 27 | - Contributors can also submit a new dApp if it is fit for the substrate ecosystem. They need to provide the GitHub repo link for the ink box. 28 | 29 | 30 | ### Simillar platforms 31 | 32 | - Truffle Boxes 33 | 34 | 35 | ## Team :busts_in_silhouette: 36 | 37 | ### Team members 38 | 39 | * @nerdsince98 40 | 41 | ### Legal Structure 42 | 43 | * **Registered Legal Entity:** Not yet registered 44 | 45 | ### Team's experience 46 | 47 | * @nerdsince98: Built a centralized exchange and sold it as whitelabel solutions to clients. Rust instructor. Wrote Ink based smart contracts in the past: https://gitlab.com/nerdsince98/learning-ink/ 48 | 49 | ### Team Code Repos 50 | 51 | * https://github.com/avirajkhare00/ink-boxes 52 | 53 | ## Development Roadmap :nut_and_bolt: 54 | 55 | # Overview 56 | 57 | ## Grant level 58 | 59 | Level 1: Up to $10,000, 2 approvals 60 | 61 | 62 | ## Development Roadmap :nut_and_bolt: 63 | 64 | * **Total Estimated Duration:** 4 weeks 65 | 66 | * **Total Costs:** 5,000 USD 67 | 68 | ### Milestone 1 69 | 70 | * **Estimated Duration:** 2 weeks 71 | 72 | * **Costs:** 3,500 USD 73 | 74 | 75 | | Number | Deliverable | Specification | 76 | | ------------- | ------------- | ------------- | 77 | | 0a. | Apache License 2.0 | All code will be published under Apache 2.0 | 78 | | 0b. | Documentation | We will provide both inline documentation of the code. | 79 | | 0c. | Testing and it's Guide | Core functions will be fully covered by comprehensive unit tests written in Jest and UI tests in Cypress to ensure functionality and robustness. In the guide, we will describe how to run these tests. | 80 | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | 81 | | 0e. | Articles | We will publish a series of articles on how to contribute and create new boxes. | 82 | | 0. | Creation of Boxes | We will create boxes in a GitHub repo like NFT-Marketplace, Decentralized Ecommerce platform, ERC-721 with UI functionalities, ERC-20 with UI functionalities. Complete list will be provided in the GitHub repo README and coming soon section of the website. | 83 | 84 | ### Milestone 2 85 | 86 | * **Estimated Duration:** 2 weeks 87 | 88 | * **Costs:** 1,500 USD 89 | 90 | 91 | | Number | Deliverable | Specification | 92 | | ------------- | ------------- | ------------- | 93 | | 0a. | Apache License 2.0 | All code will be published under Apache 2.0 | 94 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to develop a new box. | 95 | | 0c. | Testing and it's Guide | Core functions will be fully covered by comprehensive unit tests written in Rust to ensure functionality and robustness. In the guide, we will describe how to run these tests. | 96 | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | 97 | | 0e. | Articles | We will publish a series of tutorials on how to contribute to website. | 98 | | 0. | Creation of website. | We will create a website where anyone can download the box in zip format and can upload the same. Website will accept the GitHub link of the box. If anyone tries to download the box, GitHub release of the box will be downloaded. | 99 | 100 | 101 | ## Additional Information :heavy_plus_sign: 102 | 103 | * We're currently implementing it in substrate ecosystem. 104 | -------------------------------------------------------------------------------- /applications/java-client.md: -------------------------------------------------------------------------------- 1 | # polkadot-java-client 2 | 3 | * **Proposer:** splix 4 | * **Payment Address:** bc1qce0nvef6txyahe9xvrdjavvw7qemzvhyp4ux55 5 | 6 | ## Project Description :page_facing_up: 7 | 8 | We propose the creation of a Java client library to access Polkadot based networks. 9 | Witch is the main target of JVM based server-side applications. 10 | Java, and JVM in general, are the de-facto standard platform used by an enterprise or large-scale internet services. 11 | It's critical to have a JVM based client library to get adoption by enterprises. 12 | 13 | We have extensive experience with booth blockchain, including Polkadot, and Java technologies. 14 | As an example, we previously created a Java library for Ethereum called Etherjar https://github.com/emeraldpay/etherjar, and a have some implementation of Polkadot protocol in JVM with the project Moonbeam https://github.com/emeraldpay/moonbeam. 15 | We want to continue our work and create a JVM library targeting the Polkadot. 16 | 17 | Please note that a full-featured client library is usually being involved during the whole lifetime of the target system (i.e., Polkadot). 18 | Therefore, as a result of the current project, we expect to build only an initial implementation, which should meet most of the current critical needs by a Java developer. 19 | But over the following months, maybe even years, the library is going to be developed with advanced features. 20 | 21 | The main target is server-side Java 11, which is the current LTS release (2018-2023) of Java. 22 | But in addition, we want to leave a possibility to support older versions and/or Android. 23 | 24 | The library is going to be released under the Apache 2 license. 25 | Build artifacts are going to be published to a publicly accessible Maven repository, with Javadoc and documentation in the Github repo and/or on the company website. 26 | 27 | ## Team :busts_in_silhouette: 28 | 29 | * **Members:** Igor Artamonov 30 | * **LinkedIn Profiles:** https://www.linkedin.com/in/igorartamonov/ 31 | * **Code Repos:** https://github.com/splix, https://github.com/emeraldpay 32 | * **Website:** https://emeraldpay.io 33 | * **Legal Structure:** personal address will be provided via the invoice form 34 | * **Team's Experience:** About 20 years of mostly Java experience, 5 years of blockchain experience 35 | 36 | ## Development Roadmap :nut_and_bolt: 37 | 38 | * **Total Estimated Duration:** 3 months 39 | * **Full-time equivalent (FTE):** 0.8 40 | * **Total Costs:** 4.35 BTC 41 | 42 | ### Milestone 1 43 | 44 | Initial domain specific model, types and encoding. 45 | 46 | * **Estimated Duration:** 1 month 47 | * **FTE:** 0.8 48 | * **Costs:** 1.45 BTC 49 | 50 | | Number | Deliverable | Specification | 51 | | ------------- | ------------- | ------------- | 52 | | 1. | SS58 encoding | Java class to encode/decode with SS58 | 53 | | 2. | SCALE coded | Java class to encode/decode with SCALE | 54 | | 3. | Base types | Java classes to hold and operate Address, Hash, and DOT | 55 | | 4. | Unit Tests | Unit tests covering at least 75% of the code | 56 | | 5. | Documentation | A standalone document, describing usage | 57 | 58 | ### Milestone 2 59 | 60 | Client for HTTP JSON RPC. With the focus on the following APIs: chain, contracts, and state. 61 | 62 | * **Estimated Duration:** 1 month 63 | * **FTE:** 0.8 64 | * **Costs:** 1.45 BTC 65 | 66 | | Number | Deliverable | Specification | 67 | | ------------- | ------------- | ------------- | 68 | | 1. | HTTP Client | A Java wrapper around standard HTTP JSON RPC, to read current state needed by a typical service | 69 | | 2. | Example App | An example app that accesses a node and prints the current status of the blockchain to the console | 70 | | 3. | Unit Tests | Unit tests covering at least 75% of the code | 71 | | 4. | Documentation | A standalone document, describing usage | 72 | 73 | ### Milestone 3 74 | 75 | Modules to read, create and broadcast extrinsic. 76 | Plus the API module which should provide access to the following APIs: account, author, and payment. 77 | 78 | * **Estimated Duration:** 1 month 79 | * **FTE:** 0.8 80 | * **Costs:** 1.45 BTC 81 | 82 | | Number | Deliverable | Specification | 83 | | ------------- | ------------- | ------------- | 84 | | 1. | schnorrkel/sr25519 module | Wrapper around Rust crypto library | 85 | | 2. | Signing and signature validation module | Java classes to sign data or verify an existing signature | 86 | | 3. | Example App | An example app to create and broadcast an extrinsic | 87 | | 4. | Unit Tests | Unit tests covering at least 75% of the code | 88 | | 5. | Documentation | A standalone document, describing usage | 89 | 90 | --------------------------------------------------------------------------------