├── .github ├── ISSUE_TEMPLATE │ └── request-for-proposal.md ├── PULL_REQUEST_TEMPLATE │ └── rfp_pr_template.md ├── labeler.yml ├── pull_request_template.md └── workflows │ ├── README.md │ ├── application_accepted.yml │ ├── check_application_document.yml │ ├── check_broken_links.yml │ ├── cla.yml │ ├── codeql.yml │ ├── enforce-label.yml │ ├── label_comment.yml │ ├── labeler.yml │ ├── private-labeler.yml │ ├── publish.yml │ ├── ready_for_review.yml │ └── stale_checker.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── applications ├── AdMeta.md ├── Afloat.md ├── AgriDot.md ├── Aisland-DocSig.md ├── AlgoCash.md ├── Anchor.md ├── Apron_Network.md ├── ArtZero_InkWhale.md ├── Awesome-Polka.md ├── BCANN.md ├── Banksy_Finance.md ├── CESS.md ├── CILA-omnichain-infrastructure.md ├── Calamar.md ├── Cere_Turnkey_Private_Blockchain_Network.md ├── Claps.md ├── CoinFabrik_On_Ink_Integration_Tests.md ├── CoinFabrik_On_Ink_Integration_Tests_2.md ├── CoinFabrik_On_Ink_Integration_Tests_3.md ├── Coinversation.md ├── Contract_wizard.md ├── CosmWasmVM-CoreProduct.md ├── Crowdloans-FET.md ├── Cyborg.md ├── DAOsign.md ├── DIA_Bridge_Attestation_Oracle.md ├── DICO.md ├── DINFRA.md ├── DKSAP.md ├── DNFT.md ├── Dante_Network.md ├── Datagen_Project.md ├── DeepAccountAnalytics-PolkadotDataAlliance.md ├── Deitos_Network.md ├── Diffy_chat.md ├── DipoleOracle.md ├── DistributedKeyManagement.md ├── DotPay.md ├── DotPulse.md ├── Doter.md ├── Dotflow.md ├── Eiger_Storage_on_Polkadot_1.md ├── ElizaPluginPolkadot.md ├── EverlastingCash.md ├── FIAT-on-off-ramp.md ├── Faucet.md ├── Fennel_Protocol.md ├── FuturFusion.md ├── FuzzLand.md ├── Gafi.md ├── GenesisDAO.md ├── Gluon_decentralized_hardware_crypto_wallet_services.md ├── Grant_management_webapp.md ├── GreenLemon.md ├── High_availability_validator_setup.md ├── Hyperdot.md ├── ISO-8583-implementation.md ├── ISO20022-Implementation-POC.md ├── ISO20022.md ├── Idavoll Network.md ├── Integrating-ISO8583.md ├── Interstellar-Network.md ├── Interstellar-network2.md ├── InvArch.md ├── JsonRpsee-socks5-proxy.md ├── JuniDB.md ├── KSM-embeddable-tip-or-donate-button.md ├── KZero.md ├── Knowledge-Oriented-Framework.md ├── Koiverse.md ├── Lastic.md ├── Libra.md ├── LightSpell-proposal.md ├── LiisaPortfolioTracker.md ├── Lollipop.md ├── MAP-Bridge.md ├── MIXER.md ├── MIXERv2.md ├── Maki.md ├── MangoBOX-Protocol.md ├── MangoSale_Protocol.md ├── MeProtocol.md ├── Melodot.md ├── Meta_Defender.md ├── MigrationEase.md ├── Multix-a-simple-UI-for-complex-multisig.md ├── NFTStore_Network.md ├── NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md ├── NeuroZK.md ├── Nolik.md ├── NuLink.md ├── Omniverse DLT.md ├── OpenSquare-offchain-voting.md ├── OpenSquare_paid_qa_protocol.md ├── P2PStateChannels.md ├── ParaSpell.md ├── ParaSpell_follow-up.md ├── ParaSpell_follow-up2.md ├── Parallel.md ├── Plus-follow-up.md ├── Plus-social-recovery-wallet.md ├── Plus.md ├── Plutonication.md ├── PoCS.md ├── PolkaKey.md ├── PolkaSignIn.md ├── Polkadart.md ├── Polkadot-Dart.md ├── Polkadot-Protocol-Conformance-Tests.md ├── PolkadotSnap.md ├── Polkadot_Web_UI.md ├── Polkaholic.md ├── Polkawatch.md ├── Primis.md ├── PrivaDEX_aggregator.md ├── Profond.md ├── QRUCIAL_DAO.md ├── QSTN.md ├── RainbowDAO Protocol ink Phase 1.md ├── RareLink.md ├── RedStone Network.md ├── RegionX.md ├── Relation-Graph.md ├── Roloi.md ├── RubeusKeeper.md ├── Rubeus_keeper_st2.md ├── RubyProtocol.md ├── SEOR-code-less-smart-contract-platform.md ├── SaaS3.md ├── ScoutCoinFabrik.md ├── ScoutCoinFabrik_2.md ├── Security_Marketplace.md ├── Shivarthu.md ├── Societal.md ├── Solang_Playground.md ├── Solang_developer_experience_improvements.md ├── SpellRouter-proposal.md ├── SpiderDAO.md ├── Standard_Protocol.md ├── Starry_Network.md ├── StorageHub.md ├── Stylograph.md ├── SubDAO-Chrome-Extension.md ├── SubDAO_Network.md ├── SubDAO_PolkaSign.md ├── SubGame_Network.md ├── SubGame_Network_m2.md ├── SubIdentity.md ├── Subcoin.md ├── SubsCrypt.md ├── Subsembly-GRANDPA.md ├── Substrate_Move_System_Pallet_1.md ├── Substrate_Move_System_Pallet_2.md ├── SydTek.md ├── Syncra.md ├── TPScore.md ├── TREX_Network.md ├── Tellor.md ├── ThresholdSignature.md ├── Tokenguard.md ├── Treasureland.md ├── TreasuryTracker.md ├── TuxedoDapp.md ├── UMC-Tokenscribe.md ├── Validator_Monitoring_Service.md ├── WeTEE_Network.md ├── Web3Box.md ├── Web3Go.md ├── Whiteflag-on-Fennel.md ├── XPredictMarket.md ├── Xcavate.md ├── ZK-Snarks tutorial.md ├── Zeeve_Parachain_deployment_zoombienet_testing_automation.md ├── ZeroDAO_Network.md ├── ZeroPool.md ├── Zombienet-Explorer.md ├── _category_.yml ├── ajuna_network_follow_up.md ├── anagolay-project-idiyanale-multi-token-community-contributions-for-verified-creators.md ├── anagolay-project-idiyanale-phase-1.md ├── application-template-research.md ├── application-template.md ├── ares_protocol.md ├── assemblyscript-scale-codec.md ├── asylum.md ├── asylum_follow_up_1.md ├── bdwallet.md ├── binary_merkle_tree.md ├── bison.md ├── bit_country.md ├── bit_country_m2.md ├── blackprint-js.md ├── bldg_app.md ├── blockchainia.md ├── bounce-protocol.md ├── bright_treasury.md ├── c++polkadot-light-client.md ├── cScale.md ├── candle_auction_ink.md ├── canyon_network.md ├── centrifuge-gsrpc-v2.md ├── centrifuge-twamm.md ├── ces_data_store.md ├── chainjs.md ├── chainviz.md ├── cheersland.md ├── choko_wallet.md ├── citadel.md ├── clover_network.md ├── community-health-check.md ├── contracts-tool.md ├── coong_wallet.md ├── create-substrate-app.md ├── cross-chain-wallet.md ├── crossbow.md ├── crowdloan_frontend_template.md ├── cryptex.md ├── cryptolab-staking-reward-collector-front-end.md ├── curve_amm.md ├── cyclops.md ├── dairdrop.md ├── dao-entrance-phase-1.md ├── daos.md ├── dapp_wallet_integration_native_mobile_libraries.md ├── dart-scale-codec.md ├── data_platform_with_deep_indexed_data_and_staking_reports.md ├── dauth_network.md ├── decentral_ml.md ├── decentralized_invoice.md ├── decentralized_well-being_game_api.md ├── deeper_network.md ├── deip.md ├── delightfuldot.md ├── delmonicos.md ├── democratic-governance-1.md ├── distributed_cryptography_for_polkadot_wallets.md ├── dora-factory-molochdao-v1-v2.md ├── dora-factory-multisig.md ├── dorahacks-quadratic-funding.md ├── dot-login.md ├── dot_etl.md ├── dot_marketplace-Phase3.md ├── dot_marketplace-phase2.md ├── dot_marketplace.md ├── dotly.md ├── dotmog.md ├── dotnix-follow-up.md ├── dotnix.md ├── eightfish.md ├── eliza-plugin-dot.md ├── epirus_substrate_explorer.md ├── epirus_substrate_phase_2.md ├── escrow_pallet.md ├── evanesco_networks.md ├── example-project.md ├── faceless.md ├── fair_squares.md ├── faterium.md ├── faucet-bot.md ├── fidi-dotsight-analytics.md ├── fractapp.md ├── frontier-pos-template.md ├── galaxy.md ├── grantmaster.md ├── halva_bootstrapping.md ├── halva_framework.md ├── hamster.md ├── helixstreet.md ├── hex.md ├── hs-web3.md ├── hybrid.md ├── hybrid2.md ├── hybrid_node_research.md ├── hyperfridge.md ├── imbue_network.md ├── index.md ├── infimum.md ├── ink-analyzer-phase-2.md ├── ink-analyzer.md ├── ink-boxes.md ├── ink-explorer.md ├── ink-pallet-benchmarking-phase-2.md ├── ink-pallet-benchmarking.md ├── ink-playground-ide-improvements.md ├── ink-smart-contract-wizard.md ├── inkscope-fuzzer.md ├── ipfs_utilities.md ├── iris.md ├── iris_followup.md ├── ismp.md ├── java-client.md ├── keysafe_network.md ├── klevoya_fuzzer.md ├── kodadot_assethub_nft_indexer_statemine_statemint.md ├── kodadot_assethub_nft_m2.md ├── konomi.md ├── kylin_network.md ├── lastic-grant3.md ├── lastic-price-simulation-2.md ├── ledgerUpgrade.md ├── leetcoin.md ├── liberland.md ├── lip_payments.md ├── logion_wallet.md ├── lunie.md ├── maintenance │ ├── Substratesnap_Maintenance.md │ ├── Zondax-Support.md │ ├── maintenance-template.md │ └── wasm-opt-for-rust.md ├── manta_network.md ├── massbit_route.md ├── mcp-polkadot.md ├── mobile-game-framework.md ├── mobile_dapp_connection.md ├── multichain_identity_indexer.md ├── multisignature_management_tool.md ├── mybank.md ├── myriad_social.md ├── native-bitcoin-vaults.md ├── new-order.md ├── new_bls12_hash_function.md ├── newomega-m3m4.md ├── newomega.md ├── nft_collectibles_wallet.md ├── nft_explorer.md ├── nft_product_analytics_suite.md ├── nftaa.md ├── np-compliant_and_programmable_privacy.md ├── ocelloids_monitoring_sdk.md ├── ocelloids_xcm_monitoring_service.md ├── odyssey_momentum.md ├── on-chain-cash.md ├── open-node-framework.md ├── openPayroll.md ├── openbrush-follow-up-2.md ├── openbrush-follow-up.md ├── openbrush.md ├── openrollup-mvp-phase-1.md ├── orochi-network-orosign-part1.md ├── pacific_store.md ├── pallet-drand-client.md ├── pallet-verifier.md ├── pallet_maci.md ├── pallet_supersig.md ├── panic.md ├── parachain-staking.md ├── parami-protocol.md ├── patron.md ├── perun_app_channels.md ├── perun_channels-integration.md ├── perun_channels.md ├── pesa_pallet.md ├── php-rpc-lib-follow-up.md ├── php-rpc-lib.md ├── php-scale-lib.md ├── php-substrate-api.md ├── plip.md ├── polk-auction.md ├── polkadart_extension.md ├── polkadex.md ├── polkadot-contract-wizard.md ├── polkadot-desktop-app.md ├── polkadot-js-extension-per-account-auth.md ├── polkadot-mempool-explorer-v2.md ├── polkadot-runtime-releaser.md ├── polkadot_agent_kit.md ├── polkadot_analytics_platform.md ├── polkadot_tests.md ├── polkadotjs-ecdsa.md ├── polkadotjs-hardware.md ├── polkadotjs_no_code.md ├── polkaflow.md ├── polkaj_android_support.md ├── polkakeeper.md ├── polkamask.md ├── polkamusic.md ├── polkanalysis.md ├── polkasearch.md ├── polkashots.md ├── polkastarter.md ├── polkastats.md ├── polket_toearnfun.md ├── pontem.md ├── project_1001.md ├── project_aurras_mvp_phase_1.md ├── project_aurras_mvp_phase_2.md ├── project_bodhi.md ├── project_silentdata.md ├── prosopo.md ├── psc.md ├── quadratic-funding.md ├── quantum-guard.md ├── quantumLock.md ├── queryWeb3.md ├── rb_substrate_client.md ├── relaycode.md ├── research-feasibility-go-runtime.md ├── research-feasibiliy-java-host.md ├── research_wallets.md ├── roloi-xcm-payment-automation.md ├── rv-kmir.md ├── saito-game-protocol-and-engine.md ├── sandox.md ├── sarp-basic-functionality.md ├── scale-codec-comparator.md ├── sensio_network.md ├── sequester.md ├── setheum-launchpad-crowdsales-pallet.md ├── setheum.md ├── shadows-network.md ├── si-front-end-template.md ├── signac.md ├── signet.md ├── sirato_substrate_phase3.md ├── skyekiwi-protocol.md ├── skyepass.md ├── skynet-substrate-integration.md ├── slonigiraf.md ├── slothunter.md ├── social_recovery_wallet.md ├── societal_grant2.md ├── societal_saas_pricing.md ├── sol2ink-follow-up.md ├── sol2ink.md ├── solidity-trie-verifier.md ├── solidity-verifier-for-accountable-light-client.md ├── spacewalk-bridge.md ├── spartan_poc_consensus_module.md ├── sr25519_donna.md ├── ssal-commods-dex.md ├── stable-asset.md ├── staking-rewards-collector-front-end.md ├── staking_rewards.md ├── stardust.md ├── starks_network.md ├── stone-index-on-substrate.md ├── sub_consensus_mechanism.md ├── subalfred.md ├── subauction.md ├── subdex.md ├── subquery.md ├── subrelay.md ├── subscript_lang.md ├── subsmt.md ├── substats.md ├── substrate-evm-adapter.md ├── substrate-identity-directory.md ├── substrate-parachain-PoS-template.md ├── substrate-tutorials.md ├── substrate_client_java.md ├── substrate_core_polywrapper.md ├── substrate_startkit_GUI.md ├── subvt-telegram-bot.md ├── subwallet.md ├── subxt-python.md ├── sukhavati_poc_module.md ├── sunrise-dex.md ├── sunshine-keybase.md ├── sup.md ├── supersig_fellowship.md ├── swarm-nl.md ├── swush-dex-aggregator.md ├── tdot.md ├── tokenomics-survey-2022.md ├── tracking_chain.md ├── tribal_protocol.md ├── tux0.md ├── tuxedo.md ├── tuxedo_parachain.md ├── typechain-polkadot-follow-up-2.md ├── typechain-polkadot-follow-up.md ├── typechain-polkadot.md ├── typechain_revived.md ├── typink.md ├── uke-protocol.md ├── uke.md ├── unified_collator_node_deployment.md ├── universaldot-me.md ├── universaldot.me.md ├── upgradeability-by-proxy.md ├── uplink.md ├── validated-streams.md ├── validators_selection.md ├── vanguard.md ├── ventur.md ├── vera_defi.md ├── verida_network.md ├── visualize_rust_lifetime.md ├── vue-typescript-substrate-frontend-template.md ├── walt-id_nft-infra.md ├── wasm-opt-for-rust.md ├── wasm_runtimes_fuzzing.md ├── wasmedge_substrate.md ├── web3-association-open-source-contributor-funding-experiment-setup.md ├── web3-compatible-api.md ├── wika_network.md ├── workflow_testing.md ├── xNFT.md ├── xbi-format-psp-t3rn.md ├── xcNFT.md ├── xcm-domain-service.md ├── xcm-sdk.md ├── xcm-tools-follow-up-2.md ├── xcm-tools-follow-up.md ├── xcm-tools.md ├── xcmsend.md ├── xtokens.md ├── yatima.md ├── yiban_chen1.md ├── yieldscan_phase_2.md ├── zenlink-cross-chain-dex.md ├── zenlink-smart-contract.md ├── zenlink.md ├── zero-network.md ├── zk-plonk.md ├── zk-rollups.md ├── zkverse.md └── zkwasm-rollups-transfer.md ├── babel.config.js ├── docs ├── Introduction │ ├── ideas.md │ ├── intro.md │ ├── levels.md │ ├── support.md │ └── team.md ├── Process │ ├── changes.md │ ├── how-to-apply.md │ ├── milestone_delivery.md │ └── review.md ├── RFPs │ ├── IDE_for_ink_Smart_Contracts.md │ ├── ISO_20022.md │ ├── ISO_8583.md │ ├── Static-Analysis-for-Runtime-Pallets.md │ ├── a-and-v-topology.md │ ├── action_research_opengov.md │ ├── alternative-polkadot-js-api-console.md │ ├── alternative_polkadot_host_implementations.md │ ├── analysis-website-and-data-platform.md │ ├── anti-collusion_infrastructure.md │ ├── appi.md │ ├── bpf-contracts.md │ ├── candle-auction.md │ ├── crowdloan_front_end_template.md │ ├── data_analysis_tools.md │ ├── decentralized-security-marketplace.md │ ├── epassport-zk-validation.md │ ├── formal_guarantees_for_grandpa.md │ ├── grant_management_webapp.md │ ├── identity-directory.md │ ├── implementation-benchmarking.md │ ├── ink_smart_contract_block_explorer.md │ ├── jsonrpsee-proxy-support.md │ ├── ksm-tipping-button.md │ ├── move_smart_contract_pallet.md │ ├── multi-chain-block-explorer.md │ ├── on-chain-quadratic-funding.md │ ├── parachain_validation_conformance_testing.md │ ├── php-api.md │ ├── php-scale.md │ ├── polkadot-collator-setup.md │ ├── polkadot-protocol_conformance_tests.md │ ├── privacy-enhancement-polkadot-extension.md │ ├── raft-validators.md │ ├── scale-codec-comparator.md │ ├── social-recovery-wallet.md │ ├── staking-rewards-collector-front-end.md │ ├── sub-consensus.md │ ├── suggestion-template.md │ ├── uncollateralized-stablecoin-research.md │ ├── uptane-for-substrate-design-and-scope.md │ ├── user-account-access-analysis.md │ ├── validator-selection-algorithm.md │ ├── validator-setup-maintenance.md │ ├── wallet-aggregator-library.md │ └── xcm-tool.md ├── Support Docs │ ├── T&Cs.md │ ├── announcement-guidelines.md │ ├── grant-badge-guidelines.md │ ├── grant_guidelines_per_category.md │ ├── milestone-deliverables-guidelines.md │ ├── polkadot_stack.md │ └── privacy_policy.md ├── contribute.md ├── faq.md ├── funding.md ├── help.md ├── index.md ├── introduction.md ├── maintenance.md ├── office-hours.md ├── process.md ├── referral-program.md ├── rfps.md └── suggesting.md ├── docusaurus.config.js ├── package-lock.json ├── package.json ├── sidebars.js ├── src ├── components │ ├── HomepageFeatures.js │ └── HomepageFeatures.module.css ├── css │ └── custom.css └── pages │ ├── index.js │ └── index.module.css └── static ├── .nojekyll ├── CNAME └── img ├── Grants_Program.png ├── Learn.svg ├── Polkadot_Logo_Horizontal_BlackOnWhite.svg ├── Reddit.svg ├── Twitter.svg ├── Web.svg ├── Web3Foundation.png ├── Wiki.svg ├── Youtube.svg ├── badge_black.svg ├── favicon-32x32.png ├── rfp-header.png ├── w3f_logo.svg └── web3 foundation grants_black.jpg /.github/ISSUE_TEMPLATE/request-for-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Request for Proposal 3 | about: Suggest a project idea that should be funded by the Grants Program 4 | title: "[RFP] " 5 | labels: rfp 6 | assignees: '' 7 | 8 | --- 9 | 10 | * **Status:** **Open** (anyone is allowed to apply) / **Closed** (invited respondents only) 11 | * **Projects you think this work could be useful for** [optional]: Link(s) 12 | 13 | ## Project Description 14 | 15 | Please describe exactly why you are proposing this RFP. Make sure to point out why it’s needed and/or useful for your project or other projects in the ecosystem. 16 | 17 | ## Deliverables 18 | 19 | Please list potential deliverables of the project in as much detail as possible, but keep in mind that this roadmap is not binding and that applications might deviate from it. 20 | 21 | Please also estimate the amount of work required and try to divide the project into meaningful milestones. 22 | 23 | * **Total Estimated Duration:** Expected duration of the whole project 24 | * **Full-time equivalent (FTE):** Expected number of full-time employees working on the project throughout its duration ([see](https://en.wikipedia.org/wiki/Full-time_equivalent)) 25 | * **Total Costs:** Expected amount required, in USD, for the whole project. 26 | 27 | ### Milestone 1 28 | 29 | * **Estimated Duration:** Expected duration of Milestone 1 30 | * **FTE:** Expected number of full-time employees working on this milestone 31 | * **Costs:** Expected amount required, in USD, for Milestone 1 32 | 33 | 34 | | Number | Deliverable | Specification | 35 | | ----------- | --------------- | ----------------- | 36 | | 1. | Title of the deliverable | Please describe the deliverable here as detailed as possible | 37 | | 2. | ... | ... | 38 | 39 | 40 | ### Milestone 2 41 | 42 | ... 43 | 44 | --- 45 | 46 | * **Proposer:** Your GitHub username 47 | * **Your Project(s):** [optional]: Link(s) 48 | -------------------------------------------------------------------------------- /.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/labeler.yml: -------------------------------------------------------------------------------- 1 | "admin-review": 2 | - changed-files: 3 | - any-glob-to-any-file: applications/** 4 | 5 | "update docs": 6 | - all: 7 | - changed-files: 8 | - any-glob-to-any-file: 'docs/**' 9 | - all-globs-to-all-files: '!docs/RFPs/**' 10 | 11 | "rfp": 12 | - changed-files: 13 | - any-glob-to-any-file: docs/RFPs/** 14 | -------------------------------------------------------------------------------- /.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 (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable). 18 | - [ ] I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application. 19 | - [ ] I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check. 20 | - [ ] The software delivered for this grant will be released under an open-source license specified in the application. 21 | - [ ] The initial PR contains only one commit (squash and force-push if needed). 22 | - [ ] 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)). 23 | - [ ] 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) 24 | -------------------------------------------------------------------------------- /.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 | -------------------------------------------------------------------------------- /.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 | get_filename: 10 | if: contains(github.event.pull_request.body, 'Project Abstract') 11 | runs-on: ubuntu-latest 12 | outputs: 13 | filename: ${{ steps.files.outputs.added }} 14 | steps: 15 | 16 | - name: Get application filename # We assume there's only one 17 | id: 'files' 18 | uses: Ana06/get-changed-files@v2.0.0 19 | with: 20 | filter: 'applications/*.md' 21 | format: 'csv' 22 | 23 | parse_document: 24 | needs: get_filename 25 | if: needs.get_filename.outputs.filename 26 | runs-on: ubuntu-latest 27 | permissions: 28 | pull-requests: write 29 | issues: write 30 | steps: 31 | - name: Checkout 32 | uses: actions/checkout@v4 33 | - name: Parse application file 34 | id: grant_parser 35 | uses: w3f/parse-grant-application-action@master 36 | with: 37 | path: "${{ github.workspace }}/${{ needs.get_filename.outputs.filename }}" 38 | -------------------------------------------------------------------------------- /.github/workflows/check_broken_links.yml: -------------------------------------------------------------------------------- 1 | name: Broken Links 2 | 3 | on: 4 | repository_dispatch: 5 | workflow_dispatch: 6 | schedule: 7 | - cron: '0 0 1 * *' # Trigger the workflow every month 8 | 9 | jobs: 10 | build_and_check: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v4 14 | 15 | - name: Link Checker 16 | id: lychee 17 | uses: lycheeverse/lychee-action@v1.8.0 18 | env: 19 | GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} 20 | with: 21 | args: --verbose --no-progress !./applications/* 22 | 23 | - name: Create Issue From File 24 | if: env.lychee_exit_code != 0 25 | uses: peter-evans/create-issue-from-file@v4 26 | with: 27 | title: Link Checker Report 28 | content-filepath: ./lychee/out.md 29 | labels: report, automated issue 30 | -------------------------------------------------------------------------------- /.github/workflows/cla.yml: -------------------------------------------------------------------------------- 1 | name: "CLA Assistant" 2 | on: 3 | issue_comment: 4 | types: [created] 5 | pull_request_target: 6 | types: [opened,closed,synchronize] 7 | 8 | # explicitly configure permissions, in case your GITHUB_TOKEN workflow permissions are set to read-only in repository settings 9 | permissions: 10 | actions: write 11 | contents: write 12 | pull-requests: write 13 | statuses: write 14 | 15 | jobs: 16 | CLAAssistant: 17 | runs-on: ubuntu-latest 18 | steps: 19 | - name: "CLA Assistant" 20 | if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read and hereby sign the Contributor License Agreement.') || github.event_name == 'pull_request_target' 21 | uses: contributor-assistant/github-action@v2.3.0 22 | env: 23 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 24 | # the below token should have repo scope and must be manually added by you in the repository's secret 25 | # This token is required only if you have configured to store the signatures in a remote repository/organization 26 | PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }} 27 | with: 28 | path-to-signatures: 'signatures/version1/cla.json' 29 | path-to-document: 'https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/T%26Cs.md' 30 | # branch should not be protected 31 | branch: 'master' 32 | allowlist: semuelle,takahser,Noc2,nikw3f,dsm-w3f,keeganquigley,laboon,github-actions[bot] 33 | 34 | # the followings are the optional inputs - If the optional inputs are not given, then default values will be taken 35 | remote-organization-name: w3f 36 | remote-repository-name: grants-cla 37 | #create-file-commit-message: 'For example: Creating file for storing CLA Signatures' 38 | #signed-commit-message: 'For example: $contributorName has signed the CLA in $owner/$repo#$pullRequestNo' 39 | custom-notsigned-prcomment: 'Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our [Contributor License Agreement](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/T%26Cs.md) before we can accept your contribution. Please submit the following text as a separate comment:' 40 | custom-pr-sign-comment: 'I have read and hereby sign the Contributor License Agreement.' 41 | #custom-allsigned-prcomment: 'pull request comment when all contributors has signed, defaults to **CLA Assistant Lite bot** All Contributors have signed the CLA.' 42 | lock-pullrequest-aftermerge: false # if you don't want this bot to automatically lock the pull request after merging (default - true) 43 | #use-dco-flag: true - If you are using DCO instead of CLA 44 | -------------------------------------------------------------------------------- /.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@v4 44 | 45 | # Initializes the CodeQL tools for scanning. 46 | - name: Initialize CodeQL 47 | uses: github/codeql-action/init@v3 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@v3 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@v3 75 | with: 76 | category: "/language:${{matrix.language}}" 77 | -------------------------------------------------------------------------------- /.github/workflows/enforce-label.yml: -------------------------------------------------------------------------------- 1 | name: Enforce PR labels 2 | 3 | on: 4 | pull_request: 5 | types: [labeled, unlabeled, opened, edited, synchronize] 6 | jobs: 7 | enforce-label: 8 | runs-on: ubuntu-latest 9 | steps: 10 | - uses: yogevbd/enforce-label-action@2.1.0 11 | with: 12 | BANNED_LABELS: "admin-review" 13 | BANNED_LABELS_DESCRIPTION: "Remove `admin-review` label for merge" 14 | -------------------------------------------------------------------------------- /.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://grants.web3.foundation/docs/Support%20Docs/grant_guidelines_per_category) 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://grants.web3.foundation/docs/faq#what-activitiespositions-do-you-fund) 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 | -------------------------------------------------------------------------------- /.github/workflows/labeler.yml: -------------------------------------------------------------------------------- 1 | name: "Pull Request Labeler" 2 | on: 3 | - pull_request_target 4 | 5 | jobs: 6 | labeler: 7 | permissions: 8 | contents: read 9 | pull-requests: write 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/labeler@v5 13 | with: 14 | github_token: ${{ secrets.GITHUB_TOKEN }} 15 | -------------------------------------------------------------------------------- /.github/workflows/private-labeler.yml: -------------------------------------------------------------------------------- 1 | name: Check for private discussion 2 | 3 | on: 4 | workflow_dispatch: 5 | pull_request: 6 | types: [opened, edited] 7 | 8 | jobs: 9 | discussion_private: 10 | if: | 11 | contains(github.event.pull_request.body, 'Project Abstract') && ( 12 | !contains(github.event.pull_request.body, '- [ ] I prefer the discussion') || 13 | ( 14 | contains(github.event.pull_request.body, '- [ ] I prefer the discussion') && 15 | !contains(github.event.pull_request.body, '@_______:matrix.org') 16 | ) 17 | ) 18 | runs-on: ubuntu-latest 19 | steps: 20 | - name: Add 'discussion private' label if the application is private 21 | uses: actions/github-script@v6 22 | with: 23 | github-token: ${{ secrets.GITHUB_TOKEN }} 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 | -------------------------------------------------------------------------------- /.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@v4 15 | - uses: actions/setup-node@v4 16 | with: 17 | node-version: "18.19.0" 18 | - uses: actions/checkout@v4 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 | -------------------------------------------------------------------------------- /.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 }}; -------------------------------------------------------------------------------- /.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 | -------------------------------------------------------------------------------- /.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/ 69 | -------------------------------------------------------------------------------- /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/_category_.yml: -------------------------------------------------------------------------------- 1 | position: 12 2 | label: 'List of Grants' -------------------------------------------------------------------------------- /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 | * https://www.nbltrust.com/#/en/team 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 | * https://github.com/nbltrust 45 | * https://github.com/alexxuyang 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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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:** https://github.com/orgs/halva-suite 17 | * **Website:** https://wintex.pro/en/ 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 | -------------------------------------------------------------------------------- /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:** https://github.com/orgs/halva-suite 21 | * **Website:** https://wintex.pro/en/ 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 | -------------------------------------------------------------------------------- /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 | https://www.subscan.io/ 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 | https://github.com/itering/subscan 49 | 50 | https://github.com/itering/subscan_ui 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-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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /babel.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | presets: [require.resolve('@docusaurus/core/lib/babel/preset')], 3 | }; 4 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /docs/Introduction/intro.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | --- 4 | 5 | # Guidelines 6 | 7 | While applications are open to all, the W3F grants program prioritizes projects with a **strong technical focus** that demonstrably add value to the Polkadot ecosystem. Furthermore, successful applicants will be expected to present a solid and compelling long-term roadmap, supported by evidence of the project's significance to the community. This could include: 8 | 9 | - Research-oriented projects: Demonstrated significance to the community and potential impact through academic publications or community engagement metrics. 10 | - Business-oriented projects: A comprehensive market analysis documenting target audience, market size, competitive landscape, and go-to-market strategy. 11 | - Open-source projects: Proven experience in building strong communities, evidenced by user adoption, active development contributions, and community engagement initiatives. 12 | 13 | Generally, your project will have better chances to be accepted if: 14 | 15 | - it presents a **well-researched** or tested concept, for which ideally you are able to show some prior work; 16 | - you have tangible proof of how and to what extent the project is a **benefit to the Polkadot ecosystem** and its users; 17 | - 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; 18 | - 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 for past activity and code quality. Naturally, you can also link to projects on other platforms; 19 | - your application is **rich in technical details** and well-defined; 20 | - you can present how your project stands out among competitors or implements technology that **doesn't exist** in the ecosystem yet. 21 | 22 | Additionally, it must fulfill the following requirements: 23 | 24 | - 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. 25 | - We do not award grants for projects that have been the object of a successful **token sale**. 26 | - 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. 27 | - As a general rule, teams are asked to **finish a grant** before applying for another one. 28 | - Lastly, we **do not fund** projects that actively encourage gambling, illicit trade, money laundering, or criminal activities in general. 29 | - The beneficiaries of the grant must successfully go through a **KYC/KYB check** during the application phase in order to be eligible. 30 | 31 | 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. 32 | 33 | Please also heed our [Announcement Guidelines](../Support%20Docs/announcement-guidelines.md) for grant-related communications. 34 | 35 | Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognized 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. 36 | 37 | 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/). 38 | -------------------------------------------------------------------------------- /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 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/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. Generally, Parity's [Alpha Program](https://polkadot.com/alpha-program), which provides strategical long-term support and access to various resources, is available for anyone to join. You can find general documentation and more information on Polkadot and the Polkadot SDK on [polkadot.com](https://docs.polkadot.com/), and we encourage you to join the [community](https://polkadot.com/community/) in order to get help with specific issues or to stay up to date with the most recent developments. 8 | 9 | For real-time conversations, check out the Polkadot Developer Support groups on [Telegram](https://t.me/substratedevs) and [Matrix](https://matrix.to/#/#substratedevs:matrix.org). 10 | 11 | For questions about the grants program itself, see our [FAQ](docs/faq.md#frequently-asked-questions). 12 | -------------------------------------------------------------------------------- /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 | - [Santiago Balaguer](https://github.com/SBalaguer) 14 | - [Aeron Buchanan](https://github.com/aeronbuchanan) 15 | - [Aleksandar Dimitrijevic](https://github.com/alexdimes) 16 | - [David Hawig](https://github.com/Noc2) 17 | - [Sebastian Müller](https://github.com/semuelle) 18 | - [Bill Laboon](https://github.com/laboon) 19 | - [Keegan Quigley](https://github.com/keeganquigley) 20 | - [Raul Romanutti](https://github.com/rrtti) 21 | - [Seraya Takahashi](https://github.com/takahser) 22 | - [Gavin Wood](https://github.com/gavofyork) 23 | - [Piet Wolff](https://github.com/PieWol) 24 | 25 | ## W3F Grants Evaluators 26 | 27 | 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. 28 | 29 | - [David Hawig](https://github.com/Noc2) 30 | - [Sebastian Müller](https://github.com/semuelle) 31 | - [Keegan Quigley](https://github.com/keeganquigley) 32 | - [Seraya Takahashi](https://github.com/takahser) 33 | - [Piet Wolff](https://github.com/PieWol) 34 | 35 | ## W3F Operations Team 36 | 37 | The Operations Team takes care of legal documents, invoicing and remittances. 38 | 39 | - [Melanie Diener](https://github.com/meldien) 40 | - [Rouven Pérez](https://github.com/RouvenP) 41 | -------------------------------------------------------------------------------- /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/Process/how-to-apply.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | title: 1. Application 4 | --- 5 | 6 | :::tip 7 | If you want to apply in **private** or your project does not fit this program, you can reach out to us [:arrow_right: here](https://grants.web3.foundation/docs/office-hours). We are happy to discuss or recommend alternative funding initiatives. 8 | ::: 9 | 10 | :::info 11 | 12 | At least 50% (as defined in your grant agreement) of each milestone payment is made in DOT (linearly vesting over 2 years). The remainder is paid in USDC on the Polkadot [AssetHub](https://wiki.polkadot.network/docs/learn-assets). Please indicate your preference in the application [as outlined in our application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md?plain=1#L8). 13 | ::: 14 | 15 | 16 | ## How to apply: 17 | 18 | 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. 19 | 2. [Fork](https://github.com/w3f/Grants-Program/fork) our grants program repository. 20 | 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. 21 | 4. Name the new file after your project: `project_name.md`. 22 | 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 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. 23 | 6. Once you're done, create a pull request. The pull request should only contain _one new file_—the Markdown file you created from the template. 24 | 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. 25 | 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. 26 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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/RFPs/IDE_for_ink_Smart_Contracts.md: -------------------------------------------------------------------------------- 1 | # Browser based IDE for ink! Smart Contracts 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/ink-playground-ide-improvements.md), [Implemented](https://github.com/sandoxio/sandox) 8 | * **Proposer:** [David Hawig](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | [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. 13 | 14 | The goal of this RFP is to find teams that would like to maintain the browser-based ink! Playground for editing, compiling & sharing ink! smart contracts. [ink! Playground](https://ink-playground.substrate.io/), previously maintained by Parity, utilizes Typescript, React, Docker, and [Monaco Editor](https://microsoft.github.io/monaco-editor/). 15 | 16 | **Useful resources:** 17 | - [ink!](https://use.ink/) 18 | - ~~[ink-playground](https://ink-playground.substrate.io)~~ (no longer hosted) 19 | - ~~[GitHub ink-playground](https://github.com/paritytech/ink-playground)~~ (no longer hosted) 20 | - [GitHub: ink! Remix plugin](https://github.com/blockchain-it-hr/ink-remix-plugin) 21 | 22 | ## Deliverables 23 | 24 | We recommend to initially apply for a [regular grant](https://github.com/w3f/Grants-Program#pencil-process) to fix the following issues and make the playground compatible with different versions of ink! as well as automatic updates: 25 | 26 | - https://github.com/paritytech/ink-playground/issues/427 27 | - https://github.com/paritytech/ink-playground/issues/197 28 | - https://github.com/paritytech/ink-playground/issues/460 29 | - https://github.com/paritytech/ink-playground/issues/428 30 | 31 | After this we would sign a [maintenance grant](https://w3f.github.io/Grants-Program/docs/maintenance), which allows a more flexible structure and roadmap. The list of issues and features to be covered by the grant should be discussed with the previous maintainers and the community, but it is generally up to the applying team to come up with a milestone and delivery structure. 32 | 33 | 34 | -------------------------------------------------------------------------------- /docs/RFPs/ISO_20022.md: -------------------------------------------------------------------------------- 1 | # RFP: ISO 20022 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** Closed ([Grant 1](https://github.com/w3f/Grants-Program/blob/master/applications/ISO20022.md), [Grant 2](https://github.com/w3f/Grants-Program/blob/master/applications/hyperfridge.md)) 8 | * **Proposer:** [Noc2](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | 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: 15 | 16 | - (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. 17 | - Proof of concepts, potentially leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/learn/offchain-operations/) that show the advantages of using ISO 20022 together with Substrate. 18 | - Efficient on-chain representation of the ISO 20022 XML or ASN.1-based syntax 19 | 20 | **Useful resources:** 21 | - https://www.iso20022.org/ 22 | - https://www.swift.com/standards/iso-20022/iso-20022-programme 23 | - https://github.com/element36-io/ocw-ebics 24 | 25 | ## Deliverables 26 | 27 | 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. 28 | -------------------------------------------------------------------------------- /docs/RFPs/ISO_8583.md: -------------------------------------------------------------------------------- 1 | # RFP: ISO 8583 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/Integrating-ISO8583.md), [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/ISO-8583-implementation.md) 8 | * **Proposer:** [Noc2](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | Even though ISO 8583 is going to be replaced by [ISO 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_20022.md), it might take some time before it’s actually fully replaced. 15 | 16 | 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: 17 | 18 | - (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. 19 | - Proof of concepts, potentially leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/learn/offchain-operations/) that show the advantages of using ISO 8583 together with Substrate. 20 | - Efficient on-chain representation of the ISO 8583 syntax 21 | 22 | **Useful resources:** 23 | - https://www.iso.org/standard/31628.html 24 | - https://github.com/element36-io/ocw-ebics 25 | 26 | ## Deliverables 27 | 28 | 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. 29 | -------------------------------------------------------------------------------- /docs/RFPs/Static-Analysis-for-Runtime-Pallets.md: -------------------------------------------------------------------------------- 1 | # Static Analysis of Runtime Pallets 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/sarp-basic-functionality.md) 8 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | [Runtime Pallets](https://docs.substrate.io/fundamentals/runtime-development/) are modules for writing the business logic of blockchains in [Substrate](https://github.com/paritytech/polkadot-sdk/tree/master/substrate) (a Rust framework for building 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: 13 | * [incorrect origin](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/incorrect-origin/description.md) of dispatchable functions. 14 | * [unsigned transaction](https://github.com/bhargavbh/MIRAI/blob/main/substrate_examples/unsigned-transaction/description.md) validation. 15 | * tracking bad randomness: ensure bad randomness does not leak into sensitive functions. 16 | * 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. 17 | * tracking unsanitised input leakage for sensitive functions. 18 | 19 | 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. 20 | 21 | ## Deliverables 22 | 23 | The deliverables listed are an initial draft and can be modified taking into consideration the interests of the applicant. 24 | 25 | | Number | Deliverable | Specification | 26 | | ------------- | ------------- | ------------- | 27 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 28 | | 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.| 29 | | 0c. | Testing Guide | Test-suite which exercises various features. | 30 | | 0d. | Article | A brief outreach article describing the high-level technique used and outcomes of the grant, including a sample of minimal examples. | 31 | | 1 | Tool | A robust static analysis tool that works on Substrate runtime pallets and analyses vulnerabilities classes described above. | 32 | | 2 | Engagement | Engage with teams at Web3 Foundation and Parity to prioritise targeting vulnerability classes.| 33 | 34 | -------------------------------------------------------------------------------- /docs/RFPs/alternative-polkadot-js-api-console.md: -------------------------------------------------------------------------------- 1 | # Alternative javascript console for Polkadot JS API 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** Closed 8 | * **Proposer:** [muddlebee](https://github.com/muddlebee) 9 | * **Projects you think this work could be useful for** [optional]: Javascript console at https://polkadot.js.org/apps/#/js 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | ### Current State 14 | 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/) 15 | 16 | 17 | **Link** - [https://polkadot.js.org/apps/#/js](https://polkadot.js.org/apps/#/js), UI screenshot below 18 | 19 | ![image](https://user-images.githubusercontent.com/8139783/197954316-1449075f-b8be-4a30-a759-873c15f8a14f.png) 20 | 21 | 22 | **Current limitations of the above console**: 23 | Cannot save code properly, not many keyboard shortcuts, cannot customize configurations. 24 | 25 | **Alternative polkadot js API playground** 26 | 1. [https://github.com/subdirectory/subshell](https://github.com/subdirectory/subshell) 27 | 28 | 29 | ### Proposed-RFP 30 | 31 | A new Polkadot-JS API playground with VS Code-like configurations like save the code, workspace, keyboard shortcuts, etc. 32 | [https://polkadot.js.org/apps/#/js](https://polkadot.js.org/apps/#/js) 33 | 34 | some examples -> https://playground.substrate.dev/ 35 | here we have to manually build and run our js bundles 36 | ![image](https://user-images.githubusercontent.com/8139783/198254152-abdd0f2e-62d4-4f0f-aad1-bcfdd6d48a74.png) 37 | 38 | **Why alternative javascript console for Polkadot-JS API**? 39 | 40 | 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. 41 | 42 | 43 | 44 | ## Deliverables :nut_and_bolt: 45 | 46 | The following items could be the initial deliverables of the project. Of course, improvements and additions are more than welcome. 47 | 48 | - Initial research: 49 | - study how the current javascript console is developed at https://polkadot.js.org/apps/#/js 50 | - understand the libaries currently integrated from [polkadot JS API docs](https://polkadot.js.org/docs/) 51 | 52 | - Development: 53 | - design a new UI/UX with better experience than current javascript console with features like 54 | - save code preferably with secure session management 55 | - keyboard shortcuts 56 | - [example](#Proposed-RFP) 57 | 58 | Any additional features which make the Polkadot-JS experience more productive and smoother are welcome. 59 | 60 | -------------------------------------------------------------------------------- /docs/RFPs/alternative_polkadot_host_implementations.md: -------------------------------------------------------------------------------- 1 | # Alternative Polkadot Host Implementation 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | - **Status:** Under Development 8 | - **Proposer:** [Noc2](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | 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/). 15 | 16 | **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.** 17 | 18 | Currently the following implementations are under development: 19 | 20 | - [Gossamer: A Go implementation of the Polkadot Host](https://github.com/ChainSafe/gossamer) 21 | - [Kagome - C++ implementation of Polkadot Host](https://github.com/soramitsu/kagome) 22 | - [Polkadot Node Implementation in Rust](https://github.com/paritytech/polkadot) 23 | - [Smoldot - A Lightweight Substrate and Polkadot client in Rust](https://github.com/paritytech/smoldot) 24 | - [Zondax: Mayon - C/C++ implementation of the Polkadot Host](https://github.com/Zondax/mayon) 25 | 26 | Research has been completed for: 27 | 28 | - [LimeChain - Java](https://github.com/LimeChain/java-host-research)] 29 | 30 | ## Deliverables :nut_and_bolt: 31 | 32 | For Polkadot Host Implementations, it’s probably too complex to structure the entire implementation via milestones. Components of the Polkadot host are: 33 | 34 | - Networking components such as Libp2p that facilitates network interactions. 35 | - State storage and the storage trie along with the database layer. 36 | - Consensus engine for GRANDPA and BABE. 37 | - Wasm interpreter and virtual machine. 38 | - Low level primitives for a blockchain, such as cryptographic primitives like hash functions. 39 | - Availability & Validity components to support parachains. 40 | -------------------------------------------------------------------------------- /docs/RFPs/analysis-website-and-data-platform.md: -------------------------------------------------------------------------------- 1 | # Analytics Website/Data Platform 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/pull/1716), [Under Development 2](https://github.com/w3f/Grants-Program/pull/1768), [Under Development 3](https://github.com/w3f/Grants-Program/blob/master/applications/fidi-dotsight-analytics.md) 8 | * **Proposer:** [Keegan Quigley](https://github.com/keeganquigley) 9 | * **Teams/People that could deliver the RFP**: @web3go-xyz 10 | 11 | ## Project Description :page_facing_up: 12 | 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. 13 | 14 | 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. 15 | 16 | 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. 17 | 18 | ## Deliverables :nut_and_bolt: 19 | The following items could be potential expected deliverables for the project. Of course, improvements and additions are more than welcome. 20 | 21 | - Define a common dataset and data model for Substrate that can be shared for interactive querying use cases such as on Dune Analytics. 22 | - 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. 23 | - Users should be able to perform simple SQL queries in a matter of minutes, and create visualizations and dashboards using these queries. 24 | - Provide the ability to integrate data from backend services such as Subsquid, Subquery. 25 | - 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. 26 | -------------------------------------------------------------------------------- /docs/RFPs/anti-collusion_infrastructure.md: -------------------------------------------------------------------------------- 1 | # Anti-Collusion Infrastructure 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Under Development](https://grants.web3.foundation/applications/infimum) 8 | * **Proposer:** [Noc2](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | ## Deliverables :nut_and_bolt: 15 | 16 | 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. 17 | 18 | ### Milestone 1 - Anti-collusion 19 | 20 | | Number | Deliverable | Specification | 21 | | ------------- | ------------- | ------------- | 22 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 23 | | 0b. | Documentation | Inline documentation of the code and a basic tutorial that explains how a developer can use the project | 24 | | 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 | 25 | | 0d. | Article/Tutorial | Article or tutorial that explains the work done as part of the grant. 26 | | 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) | 27 | | 2. | Voting Example | Integrate a basic voting example that lets you test the mechanism | 28 | 29 | ### Previous grant applications 30 | 31 | - [Maki](https://github.com/w3f/Grants-Program/pull/1144) 32 | - [pallet-maci](https://github.com/w3f/Grants-Program/pull/232) 33 | - [Infimum](https://github.com/w3f/Grants-Program/pull/1948) 34 | -------------------------------------------------------------------------------- /docs/RFPs/bpf-contracts.md: -------------------------------------------------------------------------------- 1 | # BPF-based ink! smart contracts 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Closed](https://forum.polkadot.network/t/ebpf-contracts-hackathon/1084/13?u=david) 8 | * **Proposer:** [takahser](https://github.com/takahser) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | ### eBPF as a WASM alternative 15 | 16 | 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. 17 | 18 | ### eBPF constraints 19 | 20 | However, vanilla eBPF has some serious constraints: 21 | 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). 22 | 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`) 23 | 3. Loops are [not fully supported](https://lwn.net/Articles/740157/). 24 | 25 | 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). 26 | 27 | ### eBPF advantages 28 | 29 | Despite the constraints, eBPF-based ink! smart contracts would be expected to have the following advantages over its WASM-based counterpart: 30 | 31 | - Simplicity: Due to its register-based instruction set it would be easier to compile 32 | - Efficiency and performance 33 | 34 | ### Previous work 35 | 36 | [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: 37 | 38 | - eBPF contracts [hack report](https://forum.polkadot.network/t/ebpf-contracts-hackathon/1084/3) 39 | - Version of [pallet-contracts that can run eBPF contracts](https://github.com/pepyakin/substrate-seal-ebpf) 40 | - [Example contract](https://github.com/athei/bpf-adder) 41 | 42 | ### Conclusion 43 | 44 | The goal of this RFP is to allow for eBPF-based smart contracts. 45 | To summarize, the rough process should be: 46 | 47 | 1. Compile Rust-based ink! smart contracts using [rBPF](https://github.com/qmonnet/rbpf), returning an *eBPF ELF file* 48 | 2. Store the ELF file on-chain 49 | 3. Execute the ELF file within the eBPF VM that will convert it to machine code 50 | 51 | -------------------------------------------------------------------------------- /docs/RFPs/candle-auction.md: -------------------------------------------------------------------------------- 1 | # Candle auction smart contract 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented](https://github.com/agryaznov/candle-auction-ink/tree/master) 8 | * **Proposer:** [mmagician](https://github.com/mmagician) 9 | 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | Auctions will come in handy for various types of applications, but especially for NFTs. 14 | 15 | 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. 16 | 17 | 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. 18 | 19 | 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. 20 | 21 | ## Deliverables :nut_and_bolt: 22 | 23 | * **Total Estimated Duration:** 1 month 24 | * **Full-time equivalent (FTE):** 1 25 | 26 | ### Milestone 1 - Basic auction 27 | 28 | * **Estimated Duration:** 3 weeks 29 | * **Costs:** 7500 DAI 30 | 31 | 32 | | Number | Deliverable | Specification | 33 | | ------------- | ------------- | ------------- | 34 | | 1. | Start & close period | Create an auction mechanism that has a fixed start and end period | 35 | | 2. | Accept bids | Any user can call the contract with a bid that is higher than the last highest bid | 36 | | 3. | Find winner | Determine a winner at the close period | 37 | | 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 | 38 | | 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) | 39 | 40 | ### Milestone 2 - Random close 41 | 42 | * **Estimated Duration:** 1 weeks 43 | * **Costs:** 2500 DAI 44 | 45 | 46 | | Number | Deliverable | Specification | 47 | | ------------- | ------------- | ------------- | 48 | | 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 | 49 | | 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.) 50 | 51 | -------------------------------------------------------------------------------- /docs/RFPs/data_analysis_tools.md: -------------------------------------------------------------------------------- 1 | # Data Analysis Tools for Substrate-based Blockchains 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | - **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/pull/1716), [Under Development 2](https://github.com/w3f/Grants-Program/pull/1768), [Under Development 3](https://github.com/w3f/Grants-Program/pull/1883) 8 | - **Proposer:** [dsm-w3f](https://github.com/dsm-w3f), [michalisFr](https://github.com/michalisFr) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | 15 | 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: 16 | 17 | 18 | - Which transactions/accounts were responsible for the reserved balance in an account? 19 | - What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references? 20 | - 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)? 21 | 22 | This information is useful and requested for actual heavy users of the Polkadot/Kusama ecosystem. 23 | 24 | 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. 25 | 26 | ## Deliverables :nut_and_bolt: 27 | 28 | 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: 29 | 30 | - The data analysis question. (ex: Which transactions were responsible to reserve the balance amount in an account?) 31 | - The expected input for the data analysis (ex: an account) 32 | - The expected output for the data analysis (ex: a set of transactions that made/removed a balance reserve in the input account) 33 | 34 | 35 | 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). 36 | 37 | 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. 38 | -------------------------------------------------------------------------------- /docs/RFPs/decentralized-security-marketplace.md: -------------------------------------------------------------------------------- 1 | # Decentralized Security Marketplace 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Under Development](https://github.com/w3f/Grants-Program/pull/1726) 8 | * **Proposer:** [Matteo Casonato](https://github.com/0xCaso), [Bhargav Batt](https://github.com/bhargavbh) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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 a protocol's security, audits and bug bounties can be a useful tool. 13 | 14 | A **decentralized security marketplace** would allow projects to find reviewers/testers/auditors/whitehats and vice versa to pursue structured tests and audits. This would benefit everyone: 15 | - **Projects** would increase their security; 16 | - **Developers** would have the possibility to earn while using their skills, improving them; 17 | - The **ecosystem** would be more secure, with more projects being audited and more developers learning about security. 18 | 19 | Ideally, this marketplace would be built as a smart contract platform deployable on any 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). 20 | 21 | **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). 22 | 23 | ### Actors :busts_in_silhouette: 24 | 25 | To ensure fairness and transparency, the marketplace could have the following actors: 26 | - **Projects** - The projects that want to be reviewed / tested; 27 | - **Auditors** - The developers that want to perform audits / hunt bugs; 28 | - **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. 29 | 30 | ## Deliverables :nut_and_bolt: 31 | 32 | The followings could be the initial deliverables of the project. Of course, improvements and additions are more than welcome. 33 | 34 | 1) Initial **research and design** of the protocol: 35 | - You can refer to what [Immunefi](https://immunefi.com/explore/) and [Code4rena](https://code4rena.com/) are doing (but bring that on-chain); 36 | - How to ensure the trustless interaction (e.g., projects could lock a percentage of the bounty to open the request); 37 | - What types of disputes could be risen and how to solve them; 38 | - How to manage time delays; 39 | - Look for other use cases (in or outside the security field); 40 | 2) Development of the **protocol**: 41 | - Development of the governance smart contract (e.g. to add/remove projects, auditors, arbiters, etc.); 42 | - Development of the auditing smart contract (e.g. to create audits); 43 | - Development of the arbitration smart contract (e.g. to create/solve disputes); 44 | 3) Development of the **frontend**, that enables the actors to interact with the protocol. 45 | -------------------------------------------------------------------------------- /docs/RFPs/epassport-zk-validation.md: -------------------------------------------------------------------------------- 1 | # e-Passport ZK Validation [ON HOLD PENDING REVISIONS] 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** On Hold 8 | * **Proposer:** [burges](https://github.com/burges), [FlorianFranzen](https://github.com/FlorianFranzen) 9 | 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | The issue of verifying identities on-chain and providing Proof-of-personhood is a challenging one. 14 | 15 | 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. 16 | 17 | 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. 18 | 19 | ## Deliverables :nut_and_bolt: 20 | 21 | 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. 22 | 23 | ### Milestone 1 - transparent solution PoC on substrate 24 | 25 | * **Estimated Duration:** 3 months (incl. research) 26 | * **Costs:** 60,000 kUSD 27 | 28 | 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. 29 | 30 | Deliverables: 31 | - Chain can store the necessary certificates from CSCA 32 | - User can upload their DSO (Document Security Object) as well as the associated DSC (Document Signer Certificate) on chain 33 | - The chain logic verifies: 34 | - DSC is valid against CSCA 35 | - the signature contained within the DSO checks out against DSC 36 | 37 | ### Milestone 2 - adding ZK functionality 38 | 39 | * **Estimated Duration:** 5 months 40 | * **Costs:** 100,000 kUSD 41 | 42 | 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. 43 | 44 | There should be two parts to this functionality: off-chain prover and on-chain verifier. 45 | 46 | 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. 47 | 48 | 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. 49 | 50 | ### Milestone 3 - Updateability 51 | 52 | * **Estimated Duration:** 1 month 53 | * **Costs:** 20,000 kUSD 54 | 55 | The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furthermore, countries are expected to publish the revocations of any compromised certificates. 56 | 57 | It is important that both prover and verifier circuits are updated accordingly - else the proof won't match. 58 | -------------------------------------------------------------------------------- /docs/RFPs/formal_guarantees_for_grandpa.md: -------------------------------------------------------------------------------- 1 | # Formal Guarantees for GRANDPA Finality Gadget 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** Closed 8 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | 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. 15 | 16 | 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: 17 | - Model-checking (in TLA+ Apalache, Ironfleet, IVY) 18 | - interactive theorem proving (in Isabelle/HOL, Coq, verdi) 19 | - Any other temporal property verification tool for distributed systems 20 | 21 | 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/Polkadot/protocols/block-production/Babe) or [Sassafras](https://research.web3.foundation/Polkadot/protocols/block-production/SASSAFRAS)) by assuming an abstract interface. 22 | 23 | ## Deliverables 24 | 25 | 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. 26 | 27 | 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. 28 | 29 | | Number | Deliverable | Specification | 30 | | ------------- | ------------- | ------------- | 31 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 32 | | 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. | 33 | 0c. | Testing Guide | Instructions to set up the required environment to run the analysis, preferably a docker image with all the tools pre-installed. | 34 | | 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. | 35 | | 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. | 36 | | 2 | Proof Artifact| Formalize the validity, finality and liveness of GRANDPA as temporal properties in TLA+. | 37 | | 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.| 38 | 39 | -------------------------------------------------------------------------------- /docs/RFPs/ink_smart_contract_block_explorer.md: -------------------------------------------------------------------------------- 1 | # RFP: ink! block explorer 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Implemented 1](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_explorer.md), [Implemented 2](https://github.com/w3f/Grants-Program/blob/master/applications/ink-explorer.md) 8 | * **Proposer:** [Noc2](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | ## Deliverables 15 | 16 | The structure of the grant and the milestones depends highly on the supported features of the block explorer. 17 | -------------------------------------------------------------------------------- /docs/RFPs/move_smart_contract_pallet.md: -------------------------------------------------------------------------------- 1 | # Move Smart Contract Pallet 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/Substrate_Move_System_Pallet_1.md) 8 | * **Proposer:** [David Hawig](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | [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. 15 | 16 | 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. 17 | 18 | **Useful resources:** 19 | - [Move: A Language With Programmable Resources](https://developers.diem.com/papers/diem-move-a-language-with-programmable-resources/2020-05-26.pdf) 20 | - [Move virtual machine pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm) 21 | - [Move on Aptos](https://aptos.dev/guides/move-guides/move-on-aptos) 22 | 23 | ## Deliverables 24 | 25 | 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. 26 | 27 | 28 | -------------------------------------------------------------------------------- /docs/RFPs/multi-chain-block-explorer.md: -------------------------------------------------------------------------------- 1 | # Multi-chain Block Explorer 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented 1](https://github.com/colorfulnotion/polkaholic), [Implemented 2](https://polkadot.subscan.io/) 8 | * **Teams/People that could deliver the RFP:** @clearloop, @carlhong 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | As parachains become an integral part of the Polkadot and Kusama ecosystems, a cross-chain block & accounts explorer becomes all the more useful. 13 | 14 | Some of the functionality that should be covered as part of the development: 15 | - 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. 16 | - input an address and see Tx's on all the selected mainnets, including teleports/XCMs between various parachains 17 | - when a Tx includes a XCM, it should be easy and intuitive to open the relevant block from the other chain(s). 18 | -------------------------------------------------------------------------------- /docs/RFPs/parachain_validation_conformance_testing.md: -------------------------------------------------------------------------------- 1 | # Parachain Validation Conformance Testing 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** Closed 8 | * **Proposer:** [bkchr](https://github.com/bkchr) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | Each Polkadot host implementation that wants to take part in consensus needs to implement the Parachains protocol. Part of the Parachains protocol is the execution of the Parachain Validation Function (`PVF`). The `PVF` is a wasm blob that is required to provide the `validate_block` 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 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 make use of it. The execution of these `PVF`s is required to stay in certain limits to reach consensus across different node implementations, node versions, different hardware configuration and OS configurations. Some of these limits are: 13 | 14 | - A deterministic maximum stack depth. All node implementations should support the same stack depth. 15 | - A deterministic maximum memory. All node implementations should support the same maximum memory usage per `PVF` execution. 16 | - A deterministic maximum execution time. All node implementations should execute a given `PVF` in the same maximum time frame. 17 | - 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. 18 | 19 | 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 to have conformance tests. These should include basic execution of valid wasm files over to complex wasm files that ensure that the compilation/preparation stays in the given limits and/or helps to define these limits properly across different implementations. 20 | 21 | **Useful resources:** 22 | - [The Polkadot Parachain Host Implementers' Guide](https://paritytech.github.io/polkadot/book/index.html) 23 | - [Pre-checking for PVF Compilation time](https://github.com/paritytech/polkadot/issues/3211) 24 | 25 | ## Deliverables :nut_and_bolt: 26 | 27 | - Basic conformance tests that are running valid wasm files 28 | - Conformance tests that are resulting in running over the limits. 29 | - Fuzzing across different implementations ensuring that all are coming to the same result 30 | 31 | This is more some never ending task trying to find issues in different implementations, getting them fixed and searching for new vulnerabilities. In the end these tests should ensure that updating wasm engines, introducing new node implementations 32 | etc can be done in a sane way without hoping for the best. 33 | -------------------------------------------------------------------------------- /docs/RFPs/php-api.md: -------------------------------------------------------------------------------- 1 | # PHP Substrate API 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Proposer:** [swader](https://github.com/api) 8 | * **Status:** [Implemented](https://github.com/gmajor-encrypt/php-substrate-api) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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). 13 | 14 | The PHP API should: 15 | 16 | - be able to hook into a running Substrate node via WS or HTTP 17 | - read and write to RPC endpoints (will need SCALE codec - see relevant related RFP) 18 | 19 | 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). 20 | 21 | ## Deliverables :nut_and_bolt: 22 | 23 | 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 24 | 25 | Example use: 26 | 27 | - reading from RPC 28 | 29 | ```php 30 | $api = new SubstrateApi\Api("websocket_or_http_url"); 31 | echo $api->rpc->system->chain(); // Kusama 32 | ``` 33 | 34 | - writing a tx: 35 | 36 | ```php 37 | $api = new SubstrateApi\Api("websocket_or_http_url"); 38 | $signer = new SubstrateApi\Keyring\Signer("privatekey"); 39 | $api->setSigner($signer); 40 | $tx = $api->tx->balances->transfer("recipient_address", 10000); 41 | $tx->signAndSend(); 42 | ``` 43 | 44 | ## Notes 45 | 46 | - look into https://github.com/paritytech/scale-info 47 | -------------------------------------------------------------------------------- /docs/RFPs/php-scale.md: -------------------------------------------------------------------------------- 1 | # PHP Version of SCALE Codec 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Proposer:** [swader](https://github.com/swader) 8 | * **Status:** [Done](https://github.com/w3f/Grants-Program/pull/235) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | ## Deliverables :nut_and_bolt: 15 | 16 | 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. 17 | 18 | The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusively 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. 19 | -------------------------------------------------------------------------------- /docs/RFPs/polkadot-collator-setup.md: -------------------------------------------------------------------------------- 1 | # Polkadot Collator Setup 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | - **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/unified_collator_node_deployment.md) 8 | - **Proposer:** mmagician 9 | - **Your Project(s):** https://mmagician.github.io/ 10 | - **Projects you think this work could be useful for** Any parachain team 11 | 12 | ## Project Description :page_facing_up: 13 | 14 | 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. 15 | 16 | I would like to standardize (as much as possible) the process of spinning up new collator nodes for different parachains. 17 | 18 | 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: 19 | 20 | 1. Have a single collator ansible role, and each branch would correspond to a specific parachain 21 | 2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed. 22 | 23 | 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 independent chains without meddling with git branching too much. 24 | 25 | ## Deliverables :nut_and_bolt: 26 | 27 | Ideally the PoC would 28 | 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. 29 | 30 | - **Total Estimated Duration:** Duration of the whole project 31 | - **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)) 32 | - **Total Costs:** Amount of Payment in USD for the whole project. 33 | 34 | ### Milestone 1 35 | 36 | Please add additional milestones in the same way: 37 | - **Estimated Duration:** Duration of milestone 1 38 | - **FTE:** Amount of time (in days) required for a single person to complete this milestone 39 | - **Costs:** Amount of Payment in USD for milestone 1 40 | 41 | 42 | | Number | Deliverable | Specification | 43 | | ------------- | ------------- | ------------- | 44 | | 1. | Title of the deliverable | Please describe the deliverable here as detailed as possible | 45 | | 2. | ... |...| 46 | -------------------------------------------------------------------------------- /docs/RFPs/polkadot-protocol_conformance_tests.md: -------------------------------------------------------------------------------- 1 | # Polkadot Protocol Conformance Tests 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Under Development (Zondax)](https://github.com/w3f/Grants-Program/pull/1956), [Under Development (LimeChain)](https://github.com/w3f/Grants-Program/pull/1950) 8 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 9 | * **Objectives:** Create and maintain a comprehensive test-suite for conformance of core functionalities of Polkadot Host. 10 | 11 | ## Project Description :page_facing_up: 12 | The reliability and security of the Polkadot network crucially depends on bug-free implementation of Hosts/Nodes. Currently, Substrate and Smoldot (in Rust) are implementations in production, while [Gossamer (in Go)](https://github.com/ChainSafe/gossamer) and [Kagome (in C++)](https://github.com/soramitsu/kagome/) are in advanced stages of development. This RFP invites teams to create and maintain a comprehensive test-suite to check conformance of Host implementations against the official [Polkadot Protocol Specification](https://spec.polkadot.network/). 13 | 14 | The objectives are multifold. The test-suite can: 15 | - be used to objectively evaluate the conformance of a Host Implementation against the Spec. 16 | - help implementers in early stages and steer their development efforts. 17 | - complement the specifications to clarify corner cases and intricacies of the Spec. In several scenarios, precise tests are highly valuable in clarifying the inevitable ambiguities in the Spec. 18 | 19 | Initially, the focus would be on unit tests with tests designed and generated at the right layer of abstraction to accommodate the existing implementations. The scope of the test-suite covers all the components/protocols described in the Specification but we would like to prioritise the following: 20 | 21 | - Mapping the consensus attack surface and producing fuzzing targets accordingly. An indicative, non-exhaustive list of potential targets: 22 | - Host API 23 | - Sequences of storage and child-storage operations 24 | - Cryptography primitives, particularly those exposed in the Host API 25 | - Trie root 26 | - BABE 27 | - Block import 28 | - Block validation 29 | - Next/current validators aka VRF/block lottery 30 | - Secondary slot verification 31 | - GRANDPA 32 | - Block import 33 | - Block validation 34 | - Justification import & validation/verification 35 | - Trie proof verification 36 | - Scale encoding and decoding, for specific message types, and randomly generated ones 37 | - Parachain candidate validation 38 | 39 | The goal of the initial grant should be to develop a PoC. The long-term goal should be to develop a comprehensive test suite that is funded by the on-chain treasury. 40 | 41 | **Useful resources:** 42 | - [Polkadot Protocol Specification](https://spec.polkadot.network/) 43 | - [GitHub polkadot-tests](https://github.com/w3f/polkadot-tests) 44 | - [Chopsticks](https://github.com/AcalaNetwork/chopsticks) 45 | - [Zombienet](https://github.com/paritytech/zombienet) 46 | - [try-runtime](https://paritytech.github.io/try-runtime-cli/try_runtime/) 47 | 48 | ## Deliverables 49 | 50 | The structure of the grant and the milestones depends highly on the project itself and the goal of the initial PoC. It’s therefore up to the applying team to come up with a milestone and delivery structure. 51 | -------------------------------------------------------------------------------- /docs/RFPs/privacy-enhancement-polkadot-extension.md: -------------------------------------------------------------------------------- 1 | # Privacy Enhancement for Polkadot Extension 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/polkadot-js-extension-per-account-auth.md). GH [issue](https://github.com/polkadot-js/extension/issues/1037) has been closed. 8 | * **Proposer:** jonasW3F 9 | * **Projects you think this work could be useful for** [optional]: https://github.com/polkadot-js/extension 10 | * **Teams/People that could deliver the RFP:** @celrisen 11 | 12 | ## Project Description :page_facing_up: 13 | 14 | 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. 15 | 16 | ## Deliverables :nut_and_bolt: 17 | 18 | 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**. 19 | 20 | * **Total Estimated Duration:** 1 month 21 | * **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)) 22 | * **Total Costs:** $10'000. 23 | 24 | ### Milestone 1 25 | 26 | * **Estimated Duration:** 1 month 27 | * **FTE:** Amount of time (in days) required for a single person to complete this milestone 28 | * **Costs:** $10'000 29 | 30 | 31 | | Number | Deliverable | Specification | 32 | | ------------- | ------------- | ------------- | 33 | | 1. | "Hide all" | A global button that hides/un-hides all addresses | 34 | | 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. | 35 | | 3. | "Privacy Mode" | A setting that automatically changes the extension to a specific view group (which could be "hide all"). | 36 | | 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. | 37 | | 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. | 38 | -------------------------------------------------------------------------------- /docs/RFPs/scale-codec-comparator.md: -------------------------------------------------------------------------------- 1 | # SCALE Codec Comparator 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented for ten encoding types](https://github.com/w3f/Grants-Program/blob/master/applications/scale-codec-comparator.md) 8 | * **Proposer:** [Marcin Górny](https://github.com/mmagician/) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | To date, there are [9 published](https://docs.substrate.io/reference/scale-codec/) 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. 13 | This would provide (some) assurance that the implementation in a given language is safe & sound to use. 14 | 15 | 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. 16 | 17 | 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. 18 | 19 | ## Deliverables :nut_and_bolt: 20 | 21 | * **Total Estimated Duration:** 2+ months 22 | * **Full-time equivalent (FTE):** 1 23 | * **Total Costs:** ~ 12,000 DAI 24 | 25 | ### Milestone 1: Feature-completeness & FFI to Rust 26 | 27 | * **Estimated Duration:** 2 months 28 | * **FTE:** 1 29 | * **Costs:** ~ 10,000 DAI 30 | 31 | For each library listed on [substrate.dev](https://docs.substrate.io/reference/scale-codec/): 32 | * Create a PR, providing a FFI to Rust's reference implementation. 33 | * Ensure feature completeness, by ensuring there are comprehensive unit tests for each data type. 34 | 35 | ### Milestone 2: Badge integration 36 | 37 | * **Estimated Duration:** 1 week 38 | * **FTE:** 1 39 | * **Costs:** ~ 2000 DAI 40 | 41 | * Create a GitHub badge for SCALE feature complete libs 42 | * 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) 43 | 44 | 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. 45 | -------------------------------------------------------------------------------- /docs/RFPs/social-recovery-wallet.md: -------------------------------------------------------------------------------- 1 | # Social Recovery Wallet 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented 1](https://github.com/w3f/Grants-Program/blob/master/applications/Plus-social-recovery-wallet.md), [Implemented 2](https://github.com/hypha-dao/hashed-wallet), [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/dauth_network.md) 8 | * **Proposer:** [Noc2](https://github.com/Noc2) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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). 13 | 14 | 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. 15 | 16 | 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. 17 | 18 | **Existing Social Recovery Wallets on Ethereum:** 19 | - https://www.argent.xyz/ 20 | - https://loopring.io/#/ 21 | 22 | **Other interesting sources:** 23 | - https://www.parity.io/social-recovery-on-substrate/ 24 | - https://vitalik.ca/general/2021/01/11/recovery.html 25 | - https://github.com/paritytech/substrate/blob/master/frame/recovery 26 | - https://github.com/paritytech/substrate/tree/master/frame/proxy 27 | - https://github.com/paritytech/substrate/tree/master/frame/multisi 28 | 29 | ## Deliverables :nut_and_bolt: 30 | 31 | 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. 32 | -------------------------------------------------------------------------------- /docs/RFPs/staking-rewards-collector-front-end.md: -------------------------------------------------------------------------------- 1 | # Front-End for Staking Rewards Collector 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **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) 8 | * **Proposer:** JonasW3F 9 | * **Your Project(s):** - 10 | * **Projects you think this work could be useful for** Staking operations of all nominators and validators. 11 | * **Teams/People that could deliver the RFP** - 12 | 13 | ## Project Description :page_facing_up: 14 | 15 | 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. 16 | 17 | The backend is already written in javascript, this should make it quite easy to host as a website and develop a front-end. 18 | 19 | ## Deliverables :nut_and_bolt: 20 | 21 | In order to apply for the project, we will require you to propose the design in the form of mock-ups. 22 | 23 | - **Implementation of a user interface**: 24 | - **Query input parameters (from the users)**: 25 | - Addresses (multiple ones are supported by the code). 26 | - Start and end date 27 | - Does the user want price data linked to staking rewards? 28 | - What are the startBalances of each address? 29 | 30 | - **Data output viewer**: 31 | - The code produces a .csv and .json file which should be displayed in the browser. 32 | - Visualization for the varying number of input addresses. 33 | - Some sorting based on network / amount. 34 | - Search for specific entries like dates. 35 | - Option to download to local storage. 36 | - **Help page / buttons:** 37 | - Both the input query and output viewer should have several help buttons to give explanations for all users. 38 | 39 | - **Compatibility**: 40 | - 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). 41 | - **Hosting** 42 | - Centralized and preferably decentralized (IPFS). 43 | - **Testing** 44 | - Test if the code behaves as expected. 45 | 46 | * **Total Estimated Duration:** 3 Weeks 47 | * **Full-time equivalent (FTE):** 15 days 48 | * **Total Costs:** 4000 USD (provisional) 49 | 50 | ### Milestone 1 (Implementation) 51 | 52 | * **Estimated Duration:** 9 days 53 | * **FTE:** 9 54 | * **Costs:** 3500 USD 55 | 56 | 57 | | Number | Deliverable | Specification | 58 | | ------------- | ------------- | ------------- | 59 | | 1. | UI for user input | Develop an UI to request necessary data from the users. | 60 | | 2. | UI for data visualizer | Develop an environment to display the output (.csv and .json) for the end user in a pleasurable way. | 61 | | 3. | Help pages / comments | Implement help texts and descriptions for users. | 62 | | 4. | Internal testing | Unit tests covering the functionality and logic | 63 | 64 | 65 | ### Milestone 2 (Testing) 66 | 67 | * **Estimated Duration:** 3 days 68 | * **FTE:** 3 days 69 | * **Costs:** 500 USD 70 | 71 | 72 | | Number | Deliverable | Specification | 73 | | ------------- | ------------- | ------------- | 74 | | 1. | Deployment | Deploy the code on a centralized server and IPFS. | 75 | | 2. | Test live environment | Test the homepage with various different OS and browsers and provide a report | 76 | | 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. | 77 | 78 | 79 | -------------------------------------------------------------------------------- /docs/RFPs/sub-consensus.md: -------------------------------------------------------------------------------- 1 | # Sub-consensus mechanism 2 | 3 | :::danger 4 | This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** Closed 8 | * **Proposer:** mmagician, laboon 9 | * **Projects you think this work could be useful for:** All parachains 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | ### Summary 14 | 15 | 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. 16 | 17 | ### Project Details 18 | 19 | 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. 20 | 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) 21 | 22 | ## Deliverables :nut_and_bolt: 23 | 24 | * **Total Estimated Duration:** 3 months 25 | * **Full-time equivalent (FTE):** 1 26 | * **Total Costs:** 40,000 DAI 27 | 28 | ### Milestone 1 - Research and technical specification 29 | 30 | * **Total Estimated Duration:** 2 months 31 | * **Full-time equivalent (FTE):** 1 32 | * **Total Costs:** 20,000 DAI 33 | 34 | 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. 35 | 36 | At the end of the milestone, a detailed document should contain, at a minimum, the following parts: 37 | - summary of the current technical implementation and its limitations 38 | - technical proposal, including full specification of any pallets needed, as well as necessary changes (if any) to upstream substrate/cumulus repositories 39 | - security analysis of the proposed solution 40 | - summary of adoption of the proposed solution by a parachain team (either case study or general guidelines) 41 | 42 | ### Milestone 2 - PoC 43 | 44 | * **Total Estimated Duration:** 2 months 45 | * **Full-time equivalent (FTE):** 1 46 | * **Total Costs:** 20,000 DAI 47 | 48 | A proof of concept implementation of the proposed solution, or a full-fledged delivery. 49 | The scope of this milestone is highly dependant on the proposal submitted in M1. 50 | -------------------------------------------------------------------------------- /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/uncollateralized-stablecoin-research.md: -------------------------------------------------------------------------------- 1 | # Uncollateralized Stablecoin Research 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/stardust.md) 8 | * **Proposer:** [Noc2](https://github.com/Noc2) 9 | * **Projects you think this work could be useful for** [optional]: Any Defi Project 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | 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: 14 | - Additional trust assumptions (e.g. USDT) 15 | - Scalability issues (restricted by the underlying asset) 16 | - Devalue under massive crashes in the underlying assets 17 | 18 | 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). 19 | 20 | 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. 21 | 22 | **Useful resources:** 23 | - https://www.basis.io/basis_whitepaper_en.pdf 24 | - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2425270 25 | - https://www.youtube.com/watch?v=bnC5RQsaAXQ 26 | - https://econteric.com/stablecoin/algo/ 27 | - https://assets.fei.money/docs/whitepaper.pdf 28 | - https://www.terra.money/Terra_White_paper.pdf 29 | 30 | ## Deliverables :nut_and_bolt: 31 | 32 | 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. 33 | 34 | * **Total Estimated Duration:** 2 month 35 | * **Full-time equivalent (FTE):** 1 36 | * **Total Costs:** 30k 37 | 38 | ### Milestone 1 - Research & Design 39 | 40 | * **Estimated Duration:** 1 month 41 | * **FTE:** 1 42 | * **Costs:** 10k 43 | 44 | 45 | | Number | Deliverable | Specification | 46 | | ------------- | ------------- | ------------- | 47 | | 1. | Overview of existing solutions | Create an overview of existing and previous uncollateralized stablecoin solutions and why they failed. | 48 | | 2. | Increasing Supply | Develop a mechanism to deal with an increasing demand for the cryptocurrency and analyses potential attack vectors | 49 | | 3. | Decreasing Supply | Develop a mechanism to deal with an decreasing demand for the cryptocurrency and analyses potential attack vectors| 50 | 51 | ### Milestone 2 - PoC Implementation 52 | 53 | *Ideally part of a separate follow-up grant, since it depends on the outcome of the initial research!* 54 | 55 | * **Estimated Duration:** 1 month 56 | * **FTE:** 1 57 | * **Costs:** 20k 58 | 59 | 60 | | Number | Deliverable | Specification | 61 | | ------------- | ------------- | ------------- | 62 | | 1. | Implement PoC| Implement the previous research as ink! Smart contract or pallets | 63 | | 2. | UI (optional) | Implement a basic UI that can be used for testing | 64 | 65 | -------------------------------------------------------------------------------- /docs/RFPs/user-account-access-analysis.md: -------------------------------------------------------------------------------- 1 | # User Account Access Security Analysis for Wallets 2 | 3 | :::danger 4 | This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** Closed 8 | * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2) 9 | * **Objectives** Security analysis of the user interface of Polkadot Wallets, particularly account access and recovery. 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | 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. 14 | 15 | 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. 16 | 17 | 18 | ## Deliverables :nut_and_bolt: 19 | 20 | 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. 21 | 22 | | Number | Deliverable | Specification | 23 | | ------------- | ------------- | ------------- | 24 | | 0a. | License | Apache 2.0 / MIT / Unlicense | 25 | | 0b. | Documentation | Document describing the threat model, scope of the analysis, and description of the approach/methodology used. | 26 | | 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 | 27 | | 2 | Analysis Report| Possible improvements in usability (e.g., getting rid of redundant authentication layers during restoration) stemming from the analysis should be documented. | 28 | | 3 | Models/Code | Models developed to formalise and analyse the different wallets. Code and set-up for automated analysis, if any. | 29 | | 4 | Engagements | Engage with the Web3 Foundation teams to validate the correctness of models and the specifications.| 30 | -------------------------------------------------------------------------------- /docs/RFPs/validator-selection-algorithm.md: -------------------------------------------------------------------------------- 1 | # RFP: Validator Selection Algorithm 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Closed](https://github.com/w3f/Grants-Program/blob/master/applications/validators_selection.md) 8 | * **Proposer:** [jonasW3F](https://github.com/jonasW3F) 9 | 10 | ## Project Description 11 | 12 | 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. 13 | 14 | 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. 15 | 16 | 17 | ## Deliverables :nut_and_bolt: 18 | 19 | The aim of this project is only a backend. The final result will be a Python flask application exposing its functionality via RESTful API 20 | 21 | - **Functionality**: 22 | - **Providing a pair of validators for comparison**: 23 | - Input: 24 | - previous comparisons 25 | - Output: 26 | - next pair 27 | - current model’s quality 28 | - current model 29 | - **Providing a ranking for a given model** 30 | - Input: 31 | - model 32 | - Output: 33 | - ranking of validators 34 | - **Accepting new data** 35 | - Input: 36 | - validators.csv file that contains information of recent era data from trusted sources 37 | 38 | - **Requirements**: 39 | - Linux system with python 3 and listed packages installed 40 | - 2GB of RAM 41 | - GPU (optional) 42 | - Network configuration allowing for communication on a selected port 43 | 44 | - **Testing** 45 | - Test if the code behaves as expected. 46 | 47 | * **Total Estimated Duration:** 6 weeks 48 | * **Full-time equivalent (FTE):** 30 days 49 | * **Total Costs:** 9000 USD (provisional) 50 | 51 | ### Milestone 1 (Implementation) 52 | 53 | * **Estimated Duration:** 4 weeks 54 | * **FTE:** 20 days 55 | * **Costs:** 6000 USD 56 | 57 | 58 | | Number | Deliverable | Specification | 59 | | ------------- | ------------- | ------------- | 60 | | 1. | Next pair | Develop an algorithm for efficient calculations of the next pair to be compared to maximize the model’s information gain. | 61 | | 2. | Ranking calculation | Develop an algorithm calculating a score for each validator | 62 | | 3. | New data | Develop a function for the data preprocessing | 63 | | 4. | Internal testing | Unit tests covering the functionality and logic | 64 | 65 | 66 | ### Milestone 2 (Testing) 67 | 68 | * **Estimated Duration:** 2 weeks 69 | * **FTE:** 10 days 70 | * **Costs:** 3000 USD 71 | 72 | 73 | | Number | Deliverable | Specification | 74 | | ------------- | ------------- | ------------- | 75 | | 1. | Deployment | Deploy the code on a provided server. | 76 | | 2. | Test live environment | Test the server efficiency and provide a report | 77 | | 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. | 78 | -------------------------------------------------------------------------------- /docs/RFPs/validator-setup-maintenance.md: -------------------------------------------------------------------------------- 1 | # polkadot-validator-setup maintenance 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Closed](https://github.com/polkachu/polkadot-validator) 8 | * **Teams/People that could deliver the RFP:** @melozo, @pmensik, @tylerztl, @bLd75 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | This RFP aims at providing maintenance to that repository and add some small features. 15 | **UPDATE:** This repo has been archived. 16 | 17 | ## Deliverables :nut_and_bolt: 18 | 19 | A list of possible tasks to work on: 20 | - fixing issues and improving documentation 21 | - updating any libraries/deps needed 22 | - 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) 23 | - investigate pass-phrased ssh key deployment: [issue 109](https://github.com/w3f/polkadot-validator-setup/issues/109) 24 | - 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) 25 | -------------------------------------------------------------------------------- /docs/RFPs/wallet-aggregator-library.md: -------------------------------------------------------------------------------- 1 | # Wallet Aggregator Library 2 | 3 | :::danger 4 | This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment. 5 | ::: 6 | 7 | * **Status:** [Implemented: SubConnect](https://github.com/Koniverse/SubConnect), [Implemented: talisman-connect](https://github.com/TalismanSociety/talisman-connect) 8 | * **Proposer:** [Matteo Casonato](https://github.com/0xCaso) 9 | 10 | ## Project Description :page_facing_up: 11 | 12 | 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. 13 | 14 | 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. 15 | 16 | ## Deliverables :nut_and_bolt: 17 | 18 | The following items could be the initial deliverables of the project. Of course, improvements and additions are more than welcome. 19 | - Initial **research**: 20 | - study from the [RainbowKit](https://www.rainbowkit.com/docs/introduction) library (which is the same thing, already developed for EVM chains); 21 | - understand which wallets/extensions can be integrated, what is needed to connect to them, etc.; 22 | - Library **development**: 23 | - various connectors for each wallet; 24 | - UI components (connect button, account and chain selector, etc.); 25 | - UI/UX (for both users/devs) **improvement**: 26 | - addition of a tool that scaffolds a new project with the wallet connection library (firable, for example, with `npm init @user/wallet-aggregator@latest`); 27 | - selective account disclosure implementation (view [this](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/privacy-enhancement-polkadot-extension.md) RFP). 28 | -------------------------------------------------------------------------------- /docs/RFPs/xcm-tool.md: -------------------------------------------------------------------------------- 1 | # XCM library & tools 2 | 3 | :::caution 4 | This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team. 5 | ::: 6 | 7 | * **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/ParaSpell_follow-up2.md), [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/xcm-tools.md), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/xcm-domain-service.md) 8 | * **Proposer:** [Bryan Chen](https://github.com/xlc) 9 | * **Projects you think this work could be useful for** : Every parachain. 10 | 11 | ## Project Description :page_facing_up: 12 | 13 | XCM is the crosschain communication standard that will be used by all the parachains. Currently XCM is still in an early stage, but already supports some main usecases such as crosschain transfer of fungible tokens. 14 | 15 | There are currently two major areas of XCM that are still awaiting to be improved: 16 | 17 | - Extend & improve [xcm-format](https://github.com/paritytech/xcm-format) to support more use cases 18 | - We have few issues & PRs so we are on track on getting this done, but of couse more help is as always welcome 19 | - Implement library & tools to ease the development of XCM related code 20 | - [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 21 | - We need some tool to allow developers to test XCM related code: https://github.com/paritytech/polkadot/issues/2544 22 | - To implement more complicated XCM scenarios, we need some tools to help with async programming 23 | 24 | The scope of the new project count be one of: 25 | 26 | - Develop tools to help developers to test XCM-related code 27 | - Develop pallets or utility libraries to better handle the async nature of XCM communication 28 | - Develop a pallet to handle crosschain transfers of NFTs ([relevant discussion](https://github.com/paritytech/xcm-format/pull/35)https://github.com/paritytech/xcm-format/pull/35) 29 | -------------------------------------------------------------------------------- /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/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/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 | -------------------------------------------------------------------------------- /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! Check out [our current **job openings**](https://web3.bamboohr.com/jobs/) and apply! If there currently is no suitable job listed, don't hesitate to apply regardless or [reach out](./help.md) if you have any questions. 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 | -------------------------------------------------------------------------------- /docs/funding.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 8 3 | title: 🪙 Alternative Funding 4 | --- 5 | 6 | :::tip 7 | For an overview of funding initiatives, ecosystem support and implementation partners, also check https://web3.foundation/funding-support. 8 | ::: 9 | 10 | 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. 11 | 12 | :::note 13 | If you are unsure about what's the best next step for you and your project, consider signing up for the [Polkadot Alpha Program](https://polkadot.network/development/alpha/). 14 | ::: 15 | 16 | ### Treasury 17 | 18 | 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: 19 | 20 | - [Treasury Bounties](https://polkadot.subsquare.io/treasury/bounties) 21 | - [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) 22 | - [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) 23 | 24 | ### Hackathons 25 | 26 | 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. 27 | 28 | The best way to find out about upcoming hackathons is by following Polkadot on the various social channels, such as Element or Twitter. 29 | 30 | ### Other Grant or Bounty Programs 31 | 32 | Below is a list of other grant and bounty programs in the Polkadot/Substrate ecosystem: 33 | 34 | - [Acala Ecosystem Program](https://acala.network/ecosystem-program) 35 | - [Aleph Zero Funding Program](https://alephzero.org/ecosystem-funding-program) 36 | - [Avail Uncharted Grants](https://github.com/availproject/avail-uncharted/blob/main/grants/grants.md) 37 | - [Darwinia Grants Program](https://github.com/ringecosystem/collaboration) 38 | - [Decentralized JAM](https://jam.web3.foundation/) 39 | - [HydraDX Grants and Bounties](https://immunefi.com/bug-bounty/hydration/information/) 40 | - [ink!ubator](https://use.ink/ubator/) 41 | - [Moonbeam Grants Program](https://moonbeam.foundation/grants/) 42 | - [Moondance Labs Ecosystem Funding Program](https://www.moondancelabs.com/ecosystem-grants-w3f) 43 | - [peaq Ecosystem Grant Program](https://www.peaq.network/grant-program) 44 | - [Polkadot Open Source Developer Grants Bounty](https://github.com/PolkadotOpenSourceGrants) 45 | - [SubQuery Developer Guild](https://github.com/subquery/developer-guild) 46 | - [Pendulum / Amplitude Grant Programs](https://pendulumchain.org/ecosystem-grant) 47 | - [Polkadot Assurance Legion](https://polkadotassurance.com/) 48 | -------------------------------------------------------------------------------- /docs/help.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 7 3 | title: 💡 Help 4 | --- 5 | 6 | 7 | ### Real-time Conversation 8 | 9 | - [Matrix channel for **grant-related questions and activities**](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org). Head over there to ask grants-related questions, share your experience with other applications and grantees, or simply hang out: 10 | - Program-specific Matrix channels for the [**Decentralized Futures Program**](https://matrix.to/#/#df:web3.foundation) and the [**JAM Prize**](https://matrix.to/#/#jam:polkadot.io): 11 | - For **technical questions**, check out the Polkadot Developer Support groups on [Telegram](https://t.me/substratedevs) and [Matrix](https://matrix.to/#/#substratedevs:matrix.org). 12 | - We also have general purpose Matrix channels and spaces for discussions on **Web3** and **Polkadot**. Join the conversation! 13 | - [Web3 Foundation Chat](https://matrix.to/#/#w3f:matrix.org) 14 | - [Polkadot Space](https://matrix.to/#/#polkadot:web3.foundation) 15 | - [Kusama Space](https://matrix.to/#/#kusama:web3.foundation) 16 | 17 | ### Additional Information 18 | 19 |
20 | 21 | | | | | | | 22 | | :-: | :-: | :-: | :-: | :-: | 23 | | [W3F Website](https://web3.foundation) | [W3F Twitter](https://twitter.com/web3foundation) | [W3F Medium](https://medium.com/web3foundation) | [Polkadot Wiki](https://wiki.polkadot.network/en/) | [W3F YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) | 24 | 25 |
26 | -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | draft: true 3 | --- 4 | 5 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /docs/office-hours.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 7 3 | title: 💼 Office Hours 4 | --- 5 | 6 | **Ecosystem Funding Office Hours** are a chance to ask the W3F Ecosystem Funding team questions regarding a specific project, a (potential) grant application or about funding opportunities in general. It offers 7 | 8 | - **general guidance** regarding the various grants programs and prizes, 9 | - some quick **initial feedback** about project ideas, RFPs, roadmaps, etc. and 10 | - help how to navigate the ecosystem and to find the right resources. 11 | 12 | [Apply for Office Hours](https://forms.gle/54xkiqU37WwdN9UR6) if you 13 | 14 | - want to find out what kind of **support** there might be available for your needs, 15 | - need **feedback** before submitting an application or 16 | - look for help finding other **resources** you might need. 17 | 18 | Applying is as simple as giving us a brief outline of the project or questions you would like to discuss and your availabilities. To do so, please fill out the [Office Hours form](https://forms.gle/54xkiqU37WwdN9UR6). We will then follow up with an invitation to book a 30-minute call with one of our Ecosystem Development team members. Be as specific as possible, so we can help you as efficiently as possible. 19 | 20 | :::tip 21 | Please note: Office Hours is **not** a chance to _pitch_ your project, especially since the various programs and prizes have different evaluation criteria and decision makers and only a small subset of the Ecosystem Development team will participate in the call. 22 | 23 | ::: 24 | -------------------------------------------------------------------------------- /docs/process.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Apply 3 | --- 4 | 5 | :::tip 6 | Check out the [Polkadot Alpha Program](https://polkadot.network/development/alpha/) for all kinds of ecosystem support opportunities. 7 | 8 | ::: 9 | If you are certain you want to apply for a W3F grant, head straight to our [application process documentation](Process/how-to-apply.md). Alternatively, the flowchart below outlines where we think the grants program fits in relation to other popular funding opportunities. 10 | 11 | ## Funding Opportunities Overview 12 | 13 | ```mermaid 14 | flowchart LR 15 | A(Project Focus) 16 | A -->|Development| B[Stage of Development] 17 | A -->|Research| C[Grants Program] 18 | A -->|Other| D[Business model exists] 19 | B -->|Existing POC| E[Treasury or Decentralized Futures] 20 | B -->|No POC| F[Grants Program] 21 | D -->|No|H[Treasury] 22 | D -->|Yes|J[Decentralized Futures] 23 | style C stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 24 | style E stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 25 | style F stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 26 | style H stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 27 | style J stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 28 | 29 | click C "Process/how-to-apply" "Apply now" 30 | click F "Process/how-to-apply" "Apply now" 31 | click H "https://wiki.polkadot.network/docs/en/learn-treasury" "https://wiki.polkadot.network/docs/en/learn-treasury" _blank 32 | click J "https://futures.web3.foundation/" "https://futures.web3.foundation/" _blank 33 | ``` 34 | 35 | For a longer list and a description of the programs listed below, check out [our page on alternative funding opportunities](funding.md). 36 | -------------------------------------------------------------------------------- /docs/referral-program.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 7 3 | title: 💰 Referral Program 4 | --- 5 | 6 | We give away 500 USD, payable in USDC on Polkadot AssetHub, 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 and currency of choice for the referral bonus (see the [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md)). 9 | -------------------------------------------------------------------------------- /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/w3f/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 | -------------------------------------------------------------------------------- /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": "^3.5.2", 18 | "@docusaurus/mdx-loader": "^3.5.2", 19 | "@docusaurus/preset-classic": "^3.5.2", 20 | "@docusaurus/theme-mermaid": "^3.5.2", 21 | "@mdx-js/react": "^3.0.0", 22 | "@svgr/webpack": "^7.0.0", 23 | "clsx": "^1.1.1", 24 | "file-loader": "^6.2.0", 25 | "katex": "^0.16.9", 26 | "mermaid": "^10.8.0", 27 | "prettier": "^2.6.2", 28 | "pretty-quick": "^3.1.3", 29 | "prism-react-renderer": "^2.1.0", 30 | "react": "^18.2.0", 31 | "react-countup": "^6.4.0", 32 | "react-dom": "^18.2.0", 33 | "rehype-katex": "^7.0.0", 34 | "remark-math": "^6.0.0", 35 | "semver": "^7.5.4", 36 | "url-loader": "^4.1.1" 37 | }, 38 | "resolutions": { 39 | "semver": "^7.5.4", 40 | "trim": "^0.0.3", 41 | "got": "13.0.0" 42 | }, 43 | "browserslist": { 44 | "production": [ 45 | ">0.5%", 46 | "not dead", 47 | "not op_mini all" 48 | ], 49 | "development": [ 50 | "last 1 chrome version", 51 | "last 1 firefox version", 52 | "last 1 safari version" 53 | ] 54 | } 55 | } 56 | -------------------------------------------------------------------------------- /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/office-hours' 55 | }, 56 | { 57 | type: 'doc', 58 | id:'docs/faq' 59 | }, 60 | { 61 | type: 'doc', 62 | id:'docs/suggesting' 63 | }, 64 | { 65 | type: 'doc', 66 | id:'docs/referral-program' 67 | }, 68 | { 69 | type: 'html', 70 | value: '', 71 | }, 72 | { 73 | type: 'html', 74 | className: 'sidebar-title', 75 | value: 'Beyond', 76 | defaultStyle: true, 77 | }, 78 | { 79 | type: 'doc', 80 | id:'docs/funding' 81 | }, 82 | { 83 | type: 'doc', 84 | id:'docs/contribute' 85 | }, 86 | { 87 | type: 'doc', 88 | label: '📜 List of Grants', 89 | id:'applications/index' 90 | }, 91 | { 92 | type: 'category', 93 | label: '🪧 Requests for Proposal', 94 | link: {type:'doc', id:'docs/rfps'}, 95 | items: [{type: 'autogenerated', dirName: 'docs/RFPs'}] 96 | }, 97 | { 98 | type: 'category', 99 | label: '🦮 Supporting Documents', 100 | items: [{type: 'autogenerated', dirName: 'docs/Support Docs'}] 101 | }, 102 | ] 103 | }; 104 | 105 | module.exports = sidebars; 106 | -------------------------------------------------------------------------------- /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: 1500, 10 | description: ( 11 | <>applications 12 | 13 | ), 14 | }, 15 | { 16 | title: 600, 17 | description: ( 18 | <>projects funded 19 | 20 | ), 21 | }, 22 | { 23 | title: 54, 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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | const HomepageHeader = () => { 12 | const { siteConfig } = useDocusaurusContext(); 13 | 14 | const links = [ 15 | { 16 | to: './docs/Process/how-to-apply', 17 | text: 'Apply', 18 | style: { backgroundColor: 'rgb(0, 0, 0)', color: 'rgb(250, 250, 250)' }, 19 | }, 20 | { 21 | to: './docs/office-hours', 22 | text: 'Office Hours', 23 | }, 24 | { 25 | to: './docs/rfps', 26 | text: 'Browse RFPs', 27 | }, 28 | { 29 | to: 'https://jam.web3.foundation', 30 | text: 'JAM Prize ↗', 31 | style: { backgroundColor: 'rgb(250, 250, 250)' }, 32 | }, 33 | ]; 34 | 35 | return ( 36 |
37 |
38 | Web3 Foundation Grants 39 |

{siteConfig.tagline}

40 |
41 | {links.map((link, index) => ( 42 | 48 | {link.text} 49 | 50 | ))} 51 |
52 |
53 |
54 | ); 55 | }; 56 | 57 | export default function Home() { 58 | const { siteConfig } = useDocusaurusContext(); 59 | return ( 60 | 61 | 62 |
63 | 64 |
65 |
66 | ); 67 | } 68 | -------------------------------------------------------------------------------- /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: 10vh 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 | } -------------------------------------------------------------------------------- /static/.nojekyll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3f/Grants-Program/04fe69c87408bd329e3c3e108780ded593aeaca5/static/.nojekyll -------------------------------------------------------------------------------- /static/CNAME: -------------------------------------------------------------------------------- 1 | grants.web3.foundation 2 | -------------------------------------------------------------------------------- /static/img/Grants_Program.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3f/Grants-Program/04fe69c87408bd329e3c3e108780ded593aeaca5/static/img/Grants_Program.png -------------------------------------------------------------------------------- /static/img/Learn.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/Polkadot_Logo_Horizontal_BlackOnWhite.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/Reddit.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/Twitter.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/Web.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/Web3Foundation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3f/Grants-Program/04fe69c87408bd329e3c3e108780ded593aeaca5/static/img/Web3Foundation.png -------------------------------------------------------------------------------- /static/img/Wiki.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/Youtube.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /static/img/favicon-32x32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3f/Grants-Program/04fe69c87408bd329e3c3e108780ded593aeaca5/static/img/favicon-32x32.png -------------------------------------------------------------------------------- /static/img/rfp-header.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3f/Grants-Program/04fe69c87408bd329e3c3e108780ded593aeaca5/static/img/rfp-header.png -------------------------------------------------------------------------------- /static/img/w3f_logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 8 | Web3Foundation_4 9 | 12 | 13 | -------------------------------------------------------------------------------- /static/img/web3 foundation grants_black.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3f/Grants-Program/04fe69c87408bd329e3c3e108780ded593aeaca5/static/img/web3 foundation grants_black.jpg --------------------------------------------------------------------------------