Merge branch 'w3f:master' into master

w3f · Oct 15, 2023 · c3e3df6 · c3e3df6
2 parents cd8aec6 + c15c989
commit c3e3df6
Show file tree

Hide file tree

Showing 25 changed files with 358 additions and 101 deletions.
diff --git a/applications/index.md b/applications/index.md
diff --git a/applications/infimum.md b/applications/infimum.md
diff --git a/applications/spacewalk-bridge.md b/applications/spacewalk-bridge.md
@@ -2,7 +2,8 @@
 
 - **Team Name:** Pendulum
 - **Payment Address:** [0x41826C59a853969DA6B819130E1c32A9fd7c94ba](https://etherscan.io/address/0x41826C59a853969DA6B819130E1c32A9fd7c94ba#tokentxns) (DAI)
-- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/749#issuecomment-1740030612)
 
 ## Project Overview :page_facing_up:
 

diff --git a/applications/tracking_chain.md b/applications/tracking_chain.md
@@ -46,9 +46,9 @@ The application will handle all the necessary infrastructure setup for transacti
 
 The project will consist of 9 microservices, each with a well-defined task.
 
-![TrackingChainSchema](https://github.com/FedeC87p/PublicImage/assets/58514549/74186f4f-ac66-4ac6-afc1-90f19c9b479d)  
+![TrackingChainSchema](https://github.com/TrackingChains/TrackingChain/assets/58514549/919aebe1-c0d6-4cbf-bb02-097920863a37)  
 
-![StepTracking](https://github.com/FedeC87p/PublicImage/assets/58514549/7f535c65-fc16-4cdb-a34a-b3b9cac13bea)
+![StepTracking](https://github.com/TrackingChains/TrackingChain/assets/58514549/f8f4c074-7bb3-4231-8a02-367b7e781b89)
 
 1. Triage API:
    - Purpose: Receives tracking requests, consults the registry, and associates a destination smart contract with each request based on a Profile.
@@ -80,8 +80,6 @@ The project will consist of 9 microservices, each with a well-defined task.
 
 9. Tx Monitor Worker:
    - Purpose: Monitor the status of transactions to proceed with any automatic actions or to launch alerts in the event of transactions that cannot be managed automatically. 
-
-![Screenshot_Insert](https://github.com/FedeC87p/TrackingChainGrant/assets/58514549/2e850a3b-1375-4889-a371-8593410b3282)
 
 ### **Overview of the technology stack to be used**
 We are planning on using a combination of blockchain technology, cloud services, and front-end development tools to build a performant, secure, and user-friendly platform.
@@ -140,7 +138,7 @@ I'm working on a project for a censorship-resistant decentralized video platform
 
 - **Total Estimated Duration:** 6.5 month
 - **Full-Time Equivalent (FTE):**  1
-- **Total Costs:** 16.500 USD
+- **Total Costs:** 16.200 USD
 
 ### Milestone 1 — Basic functionality
 
@@ -205,9 +203,9 @@ I'm working on a project for a censorship-resistant decentralized video platform
 
 ### Milestone 4 — Ink Generation Call Improvement
 
-- **Estimated duration:** 1 month
+- **Estimated duration:** 3 weeks
 - **FTE:**  1
-- **Costs:** 2.000 USD
+- **Costs:** 1.700 USD
 
 
 | Number | Deliverable | Specification |
@@ -218,11 +216,10 @@ I'm working on a project for a censorship-resistant decentralized video platform
 | **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
 | 0e. | Article | We will publish an **article**/workshop that explains how to use. |
 | 1. | Tx Generator Worker | Improvement to wait for the transaction to be finalized in order to skip the "Tx Watcher Phase" (this mode will be an option present in the configuration) it's will also allow for better support for chains that don't have access to subscans. To achieve this we will listen via socket in order to wait for the finalization of the generated Tx |
-| 2. | Frontend Registry | Improvement that allows you to view not only the data present in the Registry but also to take directly from the data saved in the onchain smart contract |
 
 ## Future Plans
 
-- Pres ent the demo to customers and onboard our first major customer.
+- Present the demo to customers and onboard our first major customer.
 - Continue meetings with customers interested in entering the web3 and onboard other customers.
 - Participate in events to be able to demonstrate how our demo works, also showing the portfolio of customers who have already chosen to use it.
 - Integration DID with Kilt
@@ -254,5 +251,3 @@ I'm working on a project for a censorship-resistant decentralized video platform
    - No, all "Future Plans" will be covered by new clients or carried forward by me.
 3. Have you applied for other grants so far?
    - No
-
-
diff --git a/applications/vue-typescript-substrate-frontend-template.md b/applications/vue-typescript-substrate-frontend-template.md
@@ -3,6 +3,7 @@
 - **Team Name:** Wunderbar Network
 - **Payment Address:** 0x6F76BED39E9B9D57cAb4d9b81D65d2fa088cB68E (DAI)
 - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1601#issuecomment-1758669016) 
 
 ## Project Overview :page_facing_up:
 

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/a-and-v-topology.md b/docs/RFPs/a-and-v-topology.md
@@ -9,9 +9,9 @@ This Request for Proposals is _closed_, meaning we are not looking for any more
 
 ## Project Description :page_facing_up:
 
-A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficienct block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.
+A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficient block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.
 
-The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validitiy of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.
+The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validity of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.
 
 Currently, the gossip network among the relay chain validators does not make use of the public assignment of a the first subgroup of validators to a particular parachain. Instead, the candidate block is passed around the network until it reaches 2/3+ of approvals, causing an additional delay in the process of finalization of the candidate.
 

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/epassport-zk-validation.md b/docs/RFPs/epassport-zk-validation.md
@@ -52,6 +52,6 @@ Later, the proof is uploaded on-chain, and the chain logic performs verification
 * **Estimated Duration:** 1 month
 * **Costs:** 20,000 kUSD
 
-The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furhtermore, countries are expected to publish the revocations of any compromised certificates.
+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.
 
 It is important that both prover and verifier circuits are updated accordingly - else the proof won't match.
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/identity-directory.md b/docs/RFPs/identity-directory.md
@@ -51,7 +51,7 @@ The individual events and positions in the various columns should be **linkable*
 #### Default Plugins
 
 - `basic info`: a column with basic information about an account, similar to the sidebar on Polkadot JS Apps UI. Should discern between registrars - it should list each registrar who verified this identity and the verification level they gave (i.e. KnownGood vs KnownBad etc.)
-- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as decribed above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
+- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as described above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
 - `treasury`: a history of an account's interactions with the treasury - tip proposals and endorsements, treasury proposals and grant wins, votes on TP motions if user was council at the time (and clear marks if the user FAILED to vote on a TP motion during his activity as councilor).
 - `validator`: showing the history/summary of the account's participation in securing the network
 #### Optional Plugins

diff --git a/docs/RFPs/ksm-tipping-button.md b/docs/RFPs/ksm-tipping-button.md
@@ -23,7 +23,7 @@ The tip begins its closing process (a countdown) when more than a half of counci
 
 ## Proposal
 
-The Kusama Tip Button sould be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
+The Kusama Tip Button should be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
 
 Before the user interacts with the button, the button's embedded code should: