Update RFP statuses (#2048)

* clarifications * Update intro.md small spelling fixes * Update statuses and admonitions --------- Co-authored-by: David Hawig <[email protected]>
w3f · Oct 12, 2023 · 87c366d · 87c366d
1 parent 55d580d
commit 87c366d
Show file tree

Hide file tree

Showing 12 changed files with 62 additions and 37 deletions.
diff --git a/docs/Introduction/intro.md b/docs/Introduction/intro.md
@@ -4,28 +4,28 @@ sidebar_position: 1
 
 # Guidelines
 
-Anyone is welcome to apply for a grant. Projects funded through our programs are broad in scope, but our focus lies on strong **technical** projects that add value to the ecosystem.
+Anyone is welcome to apply for a grant. Projects funded through our program are broad in scope, but our focus lies on projects with a strong **technical** focus that add value to the ecosystem. Furthermore, you should be able to demonstrate a solid, long-term roadmap, be it through the project's significance to the community (such as for research-oriented projects) or an in-depth market analysis (for business-oriented projects).
 
 Generally, your project will have better chances to be accepted if:
 
-- It presents a **well-researched** or tested concept, for which ideally you are able to show some prior work.
-- 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.
-- Your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine these for past activity and code quality. Naturally, you can also link to projects on other platforms.
-- Your application is **rich in technical details** and well-defined.
-- You can clearly present how your project stands out among competitors or implements technology that doesn't exist in the ecosystem yet.
+- it presents a **well-researched** or tested concept, for which ideally you are able to show some prior work;
+- 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;
+- 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;
+- your application is **rich in technical details** and well-defined;
+- you can present how your project stands out among competitors or implements technology that doesn't exist in the ecosystem yet.
 
 Additionally, it must fulfill the following requirements:
 
-- 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.
+- 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.
 - We do not award grants for projects that have been the object of a successful token sale.
-- 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.
+- 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.
 - As a general rule, teams are asked to finish a grant before applying for another one.
-- Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering or criminal activities in general.
+- Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering, or criminal activities in general.
 
 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.
 
 Please also heed our [Announcement Guidelines](../Support%20Docs/announcement-guidelines.md) for grant-related communications.
 
-Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognised for their work very seriously. Using others' work with no attribution or indication that this was not your own work as part of a milestone delivery **will lead to immediate termination**. Please reach out to us before submitting if you have any doubts on how to comply with a specific license and we'll be happy to help.
+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.
 
-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/).
+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/).
diff --git a/docs/RFPs/ISO_20022.md b/docs/RFPs/ISO_20022.md
@@ -1,5 +1,9 @@
 # RFP: ISO 20022
 
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
 * **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/ISO20022.md)
 * **Proposer:** [Noc2](https://github.com/Noc2)
 

diff --git a/docs/RFPs/alternative-polkadot-js-api-console.md b/docs/RFPs/alternative-polkadot-js-api-console.md
@@ -1,10 +1,10 @@
 # Alternative javascript console for Polkadot JS API
 
-:::caution
-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.
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
 :::
 
-* **Status:** [Under Development](https://w3f.github.io/Grants-Program/applications/sandox)
+* **Status:** Closed
 * **Proposer:** [muddlebee](https://github.com/muddlebee)
 * **Projects you think this work could be useful for** [optional]: Javascript console at https://polkadot.js.org/apps/#/js
 

diff --git a/docs/RFPs/anti-collusion_infrastructure.md b/docs/RFPs/anti-collusion_infrastructure.md
@@ -1,6 +1,10 @@
 # Anti-Collusion Infrastructure
 
-* **Status:** Open
+:::caution
+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.
+:::
+
+* **Status:** [Under Development](https://grants.web3.foundation/applications/infimum)
 * **Proposer:** [Noc2](https://github.com/Noc2)
 
 ## Project Description :page_facing_up: 

diff --git a/docs/RFPs/formal_guarantees_for_grandpa.md b/docs/RFPs/formal_guarantees_for_grandpa.md
@@ -1,4 +1,9 @@
 # Formal Guarantees for GRANDPA Finality Gadget
+
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
 * **Status:** Open
 * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh),  [David Hawig](https://github.com/Noc2)
 
@@ -13,7 +18,7 @@ We are open to any reasonable formal methods approach that rigorously proves the
 - interactive theorem proving (in Isabelle/HOL, Coq, verdi)
 - Any other temporal property verification tool for distributed systems
 
-We envision the project to prove both safety and liveness properties of GRANDPA which interacts with a Block Production mechanism (like [BABE](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html) or [Sassafras](https://research.web3.foundation/en/latest/polkadot/block-production/SASSAFRAS.html)) by assuming an abstract interface. 
+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. 
 
 ## Deliverables
 

diff --git a/docs/RFPs/grant_management_webapp.md b/docs/RFPs/grant_management_webapp.md
@@ -1,10 +1,10 @@
 # Grant Management Web Application
 
-:::caution
-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.
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
 :::
 
-* **Status:** Under Development [here](https://github.com/w3f/Grants-Program/pull/1766) as well as [here](https://github.com/w3f/Grants-Program/pull/1765)
+* **Status:** Closed
 * **Proposer:** [randombishop](https://github.com/randombishop)
 
 

diff --git a/docs/RFPs/parachain_validation_conformance_testing.md b/docs/RFPs/parachain_validation_conformance_testing.md
@@ -1,25 +1,22 @@
 # Parachain Validation Conformance Testing
 
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
 * **Status:** Open
 * **Proposer:** [bkchr](https://github.com/bkchr)
 
 ## Project Description :page_facing_up: 
 
-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:
+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:
 
 - A deterministic maximum stack depth. All node implementations should support the same stack depth.
 - A deterministic maximum memory. All node implementations should support the same maximum memory usage per `PVF` execution.
 - A deterministic maximum execution time. All node implementations should execute a given `PVF` in the same maximum time frame.
 - 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.
 
-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. 
+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. 
 
 **Useful resources:**
 - [The Polkadot Parachain Host Implementers' Guide](https://paritytech.github.io/polkadot/book/index.html) 
@@ -31,6 +28,5 @@ stays in the given limits and/or helps to define these limits properly across di
 - Conformance tests that are resulting in running over the limits.
 - Fuzzing across different implementations ensuring that all are coming to the same result
 
-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 
+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 
 etc can be done in a sane way without hoping for the best.
diff --git a/docs/RFPs/sub-consensus.md b/docs/RFPs/sub-consensus.md
@@ -1,5 +1,9 @@
 # Sub-consensus mechanism
 
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
 * **Status:** Open
 * **Proposer:** mmagician, laboon
 * **Projects you think this work could be useful for:** All parachains

diff --git a/docs/RFPs/uptane-for-substrate-design-and-scope.md b/docs/RFPs/uptane-for-substrate-design-and-scope.md
@@ -1,6 +1,10 @@
 # Designing Upchain: A framework for securing Substrate software update systems
 
-* **Status:** Open
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
+* **Status:** Closed
 * **Proposer:** taqtiqa-mark
 * **Your Project(s):** N.A.
 * **Projects you think this work could be useful for** [Substrate runtime upgrades](https://docs.substrate.io/build/upgrade-the-runtime/) and [Substrate network upgrades](https://docs.substrate.io/tutorials/get-started/upgrade-a-running-network/)

diff --git a/docs/RFPs/user-account-access-analysis.md b/docs/RFPs/user-account-access-analysis.md
@@ -1,5 +1,9 @@
 # User Account Access Security Analysis for Wallets
 
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
 * **Status:** Open
 * **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2)
 * **Objectives** Security analysis of the user interface of Polkadot Wallets, particularly account access and recovery.

diff --git a/docs/RFPs/xcm-tool.md b/docs/RFPs/xcm-tool.md
@@ -1,5 +1,9 @@
 # XCM library & tools
 
+:::caution
+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.
+:::
+
 * **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)
 * **Proposer:** [Bryan Chen](https://github.com/xlc)
 * **Projects you think this work could be useful for** : Every parachain.

diff --git a/docs/rfps.md b/docs/rfps.md
@@ -24,13 +24,11 @@ If you find an open RFP here that you think you can address, feel free to [submi
 | RFP | Last Updated |
 | :-- | :----------: |
 | [anti-collusion_infrastructure.md](RFPs/anti-collusion_infrastructure.md) | 21.09.2023 |
-| [formal_guarantees_for_grandpa.md](RFPs/formal_guarantees_for_grandpa.md) | 07.10.2022 |
-| [ISO_20022.md](RFPs/ISO_20022.md) | 20.09.2023 |
+| [formal_guarantees_for_grandpa.md](RFPs/formal_guarantees_for_grandpa.md) | 12.10.2023 |
+| [ISO_20022.md](RFPs/ISO_20022.md) | 12.10.2023 |
 | [parachain_validation_conformance_testing.md](RFPs/parachain_validation_conformance_testing.md) | 18.01.2023 |  
 | [sub-consensus.md](RFPs/sub-consensus.md) | 23.02.2022 |
-| [uptane-for-substrate-design-and-scope.md](RFPs/uptane-for-substrate-design-and-scope.md) | 04.03.2023 |
 | [user-account-access-analysis.md](RFPs/user-account-access-analysis.md) | 07.01.2023 |
-| [xcm-tool.md](RFPs/xcm-tool.md) | 21.09.2023 |
 
 </details>
 
@@ -39,11 +37,9 @@ If you find an open RFP here that you think you can address, feel free to [submi
 | RFP | Last Updated |
 | :-- | :----------: |
 | [alternative_polkadot_host_implementations.md](RFPs/alternative_polkadot_host_implementations.md) | 02.03.2023 |
-| [alternative-polkadot-js-api-console.md](RFPs/alternative-polkadot-js-api-console.md) | 19.05.2023 |
 | [analysis-website-and-data-platform.md](RFPs/analysis-website-and-data-platform.md) | 21.09.2023 |
 | [data_analysis_tools.md](RFPs/data_analysis_tools.md) | 21.09.2023 |  
 | [decentralized-security-marketplace.md](RFPs/decentralized-security-marketplace.md) | 25.09.2023 |  
-| [grant_management_webapp.md](RFPs/grant_management_webapp.md) | 25.09.2023 |
 | [identity-directory.md](RFPs/identity-directory.md) | 20.09.2023 |
 | [IDE_for_ink_Smart_Contracts.md](RFPs/IDE_for_ink_Smart_Contracts.md) | 20.09.2023 |
 | [implementation-benchmarking.md](RFPs/implementation-benchmarking.md) | 20.09.2023 |
@@ -53,6 +49,7 @@ If you find an open RFP here that you think you can address, feel free to [submi
 | [polkadot-protocol_conformance_tests.md](RFPs/polkadot-protocol_conformance_tests.md) | 21.09.2023 |
 | [raft-validators.md](RFPs/raft-validators.md) | 23.05.2023 |
 | [Static-Analysis-for-Runtime-Pallets.md](RFPs/Static-Analysis-for-Runtime-Pallets.md) | 27.09.2023 |
+| [xcm-tool.md](RFPs/xcm-tool.md) | 21.09.2023 |
 
 </details>
 
@@ -62,11 +59,13 @@ If you find an open RFP here that you think you can address, feel free to [submi
 | RFP | Last Updated |
 | :-- | :----------: |
 | [a-and-v-topology.md](RFPs/a-and-v-topology.md) | 04.09.2023 |
+| [alternative-polkadot-js-api-console.md](RFPs/alternative-polkadot-js-api-console.md) | 19.05.2023 |
 | [appi.md](RFPs/appi.md) | 20.07.2021 |
 | [bpf-contracts.md](RFPs/bpf-contracts.md) | 06.01.2023 |
 | [candle-auction.md](RFPs/candle-auction.md) | 02.02.2022 |  
 | [crowdloan_front_end_template.md](RFPs/crowdloan_front_end_template.md) | 25.04.2023 |  
 | [epassport-zk-validation.md](RFPs/epassport-zk-validation.md) | 21.03.2023 |
+| [grant_management_webapp.md](RFPs/grant_management_webapp.md) | 25.09.2023 |
 | [ksm-tipping-button.md](RFPs/ksm-tipping-button.md) | 20.07.2021 |  
 | [multi-chain-block-explorer.md](RFPs/multi-chain-block-explorer.md) | 27.09.2023 |
 | [on-chain-quadratic-funding.md](RFPs/on-chain-quadratic-funding.md) | 29.03.2022 |  
@@ -78,6 +77,7 @@ If you find an open RFP here that you think you can address, feel free to [submi
 | [social-recovery-wallet.md](RFPs/social-recovery-wallet.md) | 03.03.2023 |
 | [staking-rewards-collector-front-end.md](RFPs/staking-rewards-collector-front-end.md) | 20.07.2021 |  
 | [uncollateralized-stablecoin-research.md](RFPs/uncollateralized-stablecoin-research.md) | 01.01.2023 |
+| [uptane-for-substrate-design-and-scope.md](RFPs/uptane-for-substrate-design-and-scope.md) | 04.03.2023 |
 | [validator-selection-algorithm.md](RFPs/validator-selection-algorithm.md) | 25.09.2023 |
 | [validator-setup-maintenance.md](RFPs/validator-setup-maintenance.md) | 24.08.2023 |
 | [wallet-aggregator-library.md](RFPs/wallet-aggregator-library.md) | 09.03.2023 |