From 7b6f018c5363837ab7364c8ab04821a3fb924778 Mon Sep 17 00:00:00 2001 From: Rhys Balevicius <64676514+rhysbalevicius@users.noreply.github.com> Date: Wed, 11 Oct 2023 11:58:16 -0400 Subject: [PATCH 01/10] Add infimum application (#1948) --- applications/infimum.md | 230 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 230 insertions(+) create mode 100644 applications/infimum.md diff --git a/applications/infimum.md b/applications/infimum.md new file mode 100644 index 00000000000..99a6f68c89a --- /dev/null +++ b/applications/infimum.md @@ -0,0 +1,230 @@ +# Infimum + +- **Team Name:** Apollos Collective +- **Payment Address:** 0x9c10EbAEB989CFd239679d47B9100dc4ad57A536 (ERC20 USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +This application is in response to the [anti-collusion infrastructure RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/anti-collusion_infrastructure.md). + +### Overview + +Helping to empower the realization of trust in, and verification of, voting systems within Substrate parachains. + +The goal of this proposal is to provide a minimum viable implementation of Vitalik Buterin’s [“Minimal Anti-Collusion Infrastructure”](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) as a substrate pallet and CLI (for performing off-chain work, i.e. encrypting votes, processing messages, and generating proofs). + +The scope of this proposal is intended to be a proof of concept, of which contributes to the development of a genuine *minimal* anti-collusion infrastructure within the Substrate ecosystem. + +Governance, and by extension voting systems, are critical facets of society at large and have become a crucial value proposition of many blockchain applications. It is therefore imperative to develop systems which not only promote a sense of underlying trust, but also can intrinsically verify their own integrity. + +The team is interested in cryptographic voting as a research domain. They would like to further explore this area in order to provide a meaningful contribution to the community. Refer to “Future Plans” section to preview how we’d like to see this project evolve. + +### Project Details + +There are two primary deliverables outlined in this proposal: + +1. A Substrate pallet which facilitates the voting apparatus and on-chain verification of poll results, and; + +2. A CLI tool to facilitate the generation of arguments passed to the methods exposed by the pallet. + +The goal of this system is to deincentivize collusion between participants given that any participant can secretly change or nullify their vote. + +![Use case diagram](https://cdn.rhys.tech/infimum-ucd.png) + +Deliverables: + +1. Substrate pallet + 1. Description + 1. Facilitates transparency and provenance of poll interactions and outcome. Users can register as either coordinators or participants, create polls, and interact with polls. On-chain verification of zero-knowledge proofs (which have been generated off-chain) that establish the correctness of the poll tallying computations (which have been performed off-chain) must occur prior to the acceptance of, and publishing of poll outcome. + 2. Public methods + 1. `registerAsCoordinator` Permits the caller to create polls, and stores their (public) keys. + 2. `rotatePublicKey` Permits a coordinator to rotate their public,private keypair. Rejected if called during an ongoing poll. + 3. `rotateVerifyKey` Permits a coordinator to rotate their verification key. Rejected if called during an ongoing poll. + 4. `registerAsParticipant` Permits a user to participate in a poll. Rejected if called after voting period. + 5. `createPoll` Instantiates a new poll object with the caller as the designated coordinator. Emits an event with the poll data. + 6. `interactWithPoll` Inserts a message into the message tree for future processing by the coordinator. Valid messages include: a vote, and a key rotation. Rejected if sent outside of the timeline specified by the poll config. Participants may secretly call this method (i.e. from a different address) to override their vote, thereby deincentivizing bribery. + 7. `mergePollState` Used by the coordinator to compute roots of message state tree, which is used as a commitment value by the proof verification logic. Rejected if called prior to poll end. + 8. `commitProcessedMessages` Verifies the proof that the current batch of messages have been correctly processed and, if successful, updates the current verification state. Rejected if called prior to the merge of poll state. + 9. `commitTallyResult` Verifies the proof that the current batch of votes has been correctly tallied and, if successful, updates the current verification state. On verification of the final batch the poll result is recorded in storage and an event is emitted containing the result. Rejected if called before messages have been processed. + 3. Runtime storage + 1. Public key store: mapping between coordinators and their public keys (which are used by participants to encrypt their votes) + 2. Verifying key store: mapping between coordinators and their verifying keys used in the on-chain verification of proofs + 3. Poll store: mapping between poll id and the current state of the poll + 4. Poll message state: mapping between poll id and a merkle tree of secret participant messages (i.e. votes and/or nullifiers) + 5. Poll Result: mapping between poll id and outcome + 4. Dependencies + 1. We will rely on the [Groth16](https://eprint.iacr.org/2016/260.pdf) verifier provided by [bellman](https://github.com/zkcrypto/bellman/blob/main/src/groth16/verifier.rs) under the [MIT license](https://github.com/zkcrypto/bellman/blob/main/LICENSE-MIT). +2. CLI tool + 1. Description + 1. Facilitates off-chain computations performed by participants and trusted operators. In particular, generating the values (e.g. encryption keys, proofs) required by the function signatures specified in the first deliverable (1.Susbtrate Pallet). This will be provided as a TypeScript library (in order to serve as a starting point for future integration into dApps) with a simple CLI wrapper. + 2. Technologies used + 1. Circom + 2. Typescript + 3. Node.js + 4. snarkjs + 3. Commands available to users + 1. `generateKeypair` Used by both participants and coordinator. Outputs a keypair used for encrypting and decrypting the messages which represent poll interactions. + 2. `generateProof` Used by the coordinator. Generates a proof of correctness for the current batch of message processing computations (including final vote tally). + 3. `encodeMessage` Used by participants. Accepts their vote as input, and outputs an encoded message which may only be decrypted and read by the coordinator. + + +Poll lifecycle: + +1. Poll is created (by a coordinator). Prior to the start time of the poll: + 1. The coordinator may perform any permitted alterations to the poll configuration, or close the poll + 2. Individuals can begin to register as participants in the poll +2. Poll starts: + 1. Coordinator may no longer preform any alterations to the poll (e.g. update signing key) + 2. Participants may interact with the poll (vote, revote, nullify vote, switch keys) +3. Poll ends: + 1. Participants may no longer sign up or interact with the poll + 2. Coordinator may start to compute the outcome of the poll +4. Poll result becomes “finalized” once: + 1. The coordinator publishes the result of the poll alongside proofs of the computations + 2. The result of the poll is committed to storage if and only if every proof passes verification + 3. At this point it is sensible for external actions to be taken in response to the outcome of the poll + +Constraints and limitations of the deliverables to be aware of: + +- A coordinator may only manage a single poll at a time (there may be multiple coordinators each with their own poll at any given time) +- Users can only cast a vote of weight 1 +- Votes must be processed, and tallied, in batches +- Non-transparent proof system (Groth16); requires a trusted setup + +We intend to improve upon these limitations in future work (see the section below). + +### Ecosystem Fit + +- Useful in governance schemes, e.g. crowd funding applications. +- The target audience is parachain developers, e.g. a candidate integration could be the [imbue network](https://github.com/ImbueNetwork/imbue). +- The overall intended trajectory is to help establish a sense of integrity within democratized systems. Participants in these systems are empowered to verify by default. +- The team is not aware of any projects in the Substrate/Polkadot/Kusama which are currently attempting to achieve feature parity (or beyond) with MACI in the Ethereum ecosystem. + +## Team :busts_in_silhouette: + +### Team members + +- Rhys Balevicius + +### Contact + +- **Contact Name:** Rhys Balevicius +- **Contact Email:** rhys@apollos.tech +- **Website:** [https://rhys.tech](https://rhys.tech) + +### Legal Structure + +- **Registered Address:** 173 Presidial Avenue, Oshawa, ON Canada +- **Registered Legal Entity:** Apollos Web3 Collective Inc. + +### Team's experience + +Rhys Balevicius is a software developer with over half a decade of professional experience in full-stack development, software design, and software architecture in various industries, of which include blockchain technologies and fintech. He is also currently studying Mathematics and Computer Science at University of Toronto. + +He is a founding software engineer at Dropverse, which is a gamified blockchain-based app where users can collect tokens, participate in drops, etc. in the real world. It is primarily integrated with the Ethereum ecosystem (in particular, there is currently support for any EVM compatible chain). Major achievements in this role include building a microservice that relay meta-transactions originating from user custodial wallets. + +Rhys also has previous experience in research and development, and some of this work has been patented. In particular, he designed and implemented a novel algorithm which utilized sequential image recognition in order to synchronize secondary content with the current timestamp of a video. The patent can be found here: [https://patents.google.com/patent/US11082679B1/en?oq=US11082679B1](https://patents.google.com/patent/US11082679B1/en?oq=US11082679B1) + +### Team Code Repos + +The majority of Rhys’ work has been client-based work and is closed-source. His interest in other projects has led him to also contribute to various open-source projects, some of which can be found here: + +- [https://github.com/cytoscape/cytoscape.js](https://github.com/cytoscape/cytoscape.js) +- [https://github.com/rhysbalevicius/huh](https://github.com/rhysbalevicius/huh) +- [https://github.com/rhysbalevicius/lipsync](https://github.com/rhysbalevicius/lipsync) + +GitHub profile: [https://github.com/rhysbalevicius](https://github.com/rhysbalevicius) + + +### Team LinkedIn Profiles (if available) + +- **Rhys Balevicius:** [https://www.linkedin.com/in/rhys-balevicius/](https://www.linkedin.com/in/rhys-balevicius/) + + +## Development Status :open_book: + +This application is in response to the [anti-collusion infrastructure RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/anti-collusion_infrastructure.md). + +Development status will be found over at [https://github.com/rhysbalevicius/infimum](https://github.com/rhysbalevicius/infimum). This is empty at the time of submission. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 6 months +- **Full-Time Equivalent (FTE):** 0,5 FTE +- **Total Costs:** $27,000 + +### Milestone 1 — Voting apparatus without verification + +- **Estimated duration:** 2 months +- **FTE:** 0,5 +- **Costs:** 9,000 USD + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | MIT | +| 0b. | Documentation | Inline documentation. Basic guide explaining how to interact with the pallet will be provided in the README. | +| 0c. | Testing | Unit tests, GitHub actions CI workflow, and brief guide for running tests locally | +| 0d. | Docker | Dockerfiles and docker-compose.yml for running a development environment which locally spins up a node and frontend template for observing events, calling pallet extrinsics, and performing state queries. | +| 1. | Substrate pallet | Methods 1.ii.a to 1.ii.i (listed under deliverables in the project overview) without verification functionality provided by Groth16 proving system. | + +### Milestone 2 — On-chain verification logic and circuits + +- **Estimated Duration:** 2 months +- **FTE:** 0,5 +- **Costs:** 9,000 USD + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | MIT | +| 0b. | Documentation | Inline documentation. Amendment to the original guide explaining the requirements for satisfying the verification logic. | +| 0c. | Testing | Unit tests for methods added. Updated unit tests for amended methods. | +| 1a. | Pallet: verification methods | Private methods for verifying proofs which have been generated off-chain by the CLI delivered in Milestone 3. Relies on the verification logic provided by bellman (https://github.com/zkcrypto/bellman). | +| 1b. | Pallet: method modifications | Modifications to methods 1.ii.h and 1.ii.i (listed under deliverables in the project overview) to call the private verification methods defined in Milestone 2.1.a — these modifications will guard against storage updates in the case that verification fails, and publish the final poll outcome in the case of success. | +| 2. | Circom circuits | Fork of MACI circuits defined here (https://github.com/privacy-scaling-explorations/maci/tree/master/circuits/circom) and licensed under MIT, amended as necessary for consumption within our off-chain proof generation pipeline. | + +### Milestone 3 — CLI tool and docsite + +- **Estimated Duration:** 2 months +- **FTE:** 0,5 +- **Costs:** 9,000 USD + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | MIT | +| 0b. | Documentation | Inline documentation. Instructions for setting up and interacting with the CLI will be provided in the README. | +| 0c. | Testing | Integration test scripts will be provided. | +| 0e. | Article | We will provide an article directed towards parachain developers detailing: the motivation and general use case, an overview of the individual components of the system, the poll lifecycle, limitations and trust assumptions of the system, as well as an open invitation to contribute to the project. | +| 1a. | TypeScript library | A library which exposes the functionality described in 2.iii.a to 2.iii.c (listed under deliverables in the project overview), as well as all related helper functions. | +| 1b. | CLI for operators | CLI wrapper around 1a. Provides command line accessibility to the functionality required by operators to successfully interact with the pallet. | +| 1c. | CLI for participants | CLI wrapper around 1a. Provides command line accessibility to the functionality required by participants to successfully interact with the pallet. | +| 2a. | Docsite | We will package the article in 0e., all documentation, and all necessary setup and usage instructions into a readable and user friendly docsite. This will be hosted and associated with the project under the URL section of the repository as well as linked to in the README. | +| 2b. | Voting Example | The docker-compose.yml will be updated to (optionally) provision a simple coordinator script (using Node.js and TypeScript) which manages an example poll. | +| 2c. | Voting Tutorial | We will provide a tutorial which provides explicit step-by-step instructions on how to setup and interact with the voting example. | + + +## Future Plans + +1. Experimentation with alternative architectures + 1. In particular, we are interested in architectures which support on-chain tallying utilizing partial or fully homomorphic encryption, and verifiable computation schemes such as [Rinnochio](https://eprint.iacr.org/2021/322.pdf?ref=blog.icme.io). + 2. Secure multi-party computation architecture which relies on multiple coordinators; this would enable complete secrecy of individual voter preferences. Ideally this would be combined with (1.i). +2. Features and enhancements to deliverables + 1. Integration of transparent zk-SNARKS + 2. Reduce number of extrinsic calls required in the tallying phase, e.g. with [Nova](https://github.com/microsoft/Nova) + 3. Support for different voting schemes, e.g. quadratic, ranked choice +3. Additional systems and example integrations + 1. Off-chain worker (and potentially a backend service) to automatically perform the message processing, tallying, and proof generation computations + 2. dApp which provides a rich user interface for creating and participating in polls + 3. Example ink! smart contract demonstrating how to interface with the pallet, e.g. a fungible-token contract wherein the voting power of a single participant corresponds to the number of tokens they own +4. Outreach + 1. Obtain a security audit of infrastructure + 2. Network with faculty and peers with the aim of collaborating on research goals + 3. Seek out possible integrations with a parachain, e.g. [imbue](https://github.com/ImbueNetwork/imbue) + +Where appropriate, we would like to deliver some subset of these in follow up proposals. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Personal recommendation from a colleague. From b5ec791fb8de7e9ebc0b25b26aa1077f8677bdd5 Mon Sep 17 00:00:00 2001 From: Federico Cicciarella <58514549+FedeC87p@users.noreply.github.com> Date: Wed, 11 Oct 2023 18:19:01 +0200 Subject: [PATCH 02/10] Update M4 tracking_chain.md (#2041) --- applications/tracking_chain.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/applications/tracking_chain.md b/applications/tracking_chain.md index 64182b5403a..f1d05c0719c 100644 --- 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 - - From e82d1f8b9a159c60e8ac137bddd8763f6d0e0121 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Wed, 11 Oct 2023 19:53:39 +0200 Subject: [PATCH 03/10] Update index.md Add Infimum --- applications/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/applications/index.md b/applications/index.md index 2bb82122cee..e8b0ba1fb6f 100644 --- a/applications/index.md +++ b/applications/index.md @@ -48,6 +48,7 @@ Besides, **there is a clear difference between an application being accepted and | [Livetree Community Ltd](https://github.com/livetreetech/) | [DecentralML](./decentral_ml.md) | [GitHub](https://github.com/livetreetech/) | ☐ | ☐ | ☐ | | [LimeChain](https://github.com/LimeChain) | [Polkadot Protocol Conformance Tests Research](./Polkadot-Protocol-Conformance-Tests.md) | [GitHub](https://github.com/LimeChain) | ☐ | ☐ | ☐ | | [KodaDot](https://kodadot.xyz/) | [AssetsHub NFT indexer](./kodadot_assethub_nft_indexer_statemine_statemint.md) | [GitHub](https://github.com/kodadot) | ☐ | ☐ | ☐ | +| [Apollos Collective](https://rhys.tech) | [Infimum](./infimum.md) | [GitHub](https://github.com/rhysbalevicius) | ☐ | ☐ | ☐ | ### 🏄 Wave 19 - Q3 2023 From dbc8fa985baa7807cdc4021b6a0baefd854f9af6 Mon Sep 17 00:00:00 2001 From: Keegan | W3F <35080151+keeganquigley@users.noreply.github.com> Date: Thu, 12 Oct 2023 02:05:21 -0400 Subject: [PATCH 04/10] Update index.md (#2043) --- applications/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/applications/index.md b/applications/index.md index e8b0ba1fb6f..3f6575e99ff 100644 --- a/applications/index.md +++ b/applications/index.md @@ -55,7 +55,7 @@ Besides, **there is a clear difference between an application being accepted and | Team | Project | Link | Terminated | First Delivery | Completed | | :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :---------: | :------------: | :--------: | | [Protofire](https://protofire.io/) | [Contract Wizard](./Contract_wizard.md) | [GitHub](https://github.com/protofire/polkadot-contract-wizard/) | ☐ | ☐ | ☐ | -| [ZeroDAO](https://github.com/ZeroDAO) | [Melodot](./Melodot.md) | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☐ | +| [ZeroDAO](https://github.com/ZeroDAO) | [Melodot](./Melodot.md) | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☒ | | [Starks](https://github.com/tur461) | [XCM tool for NFTs](./xNFT.md) | [GitHub](https://github.com/tur461) | ☐ | ☐ | ☐ | | [ChainSafe](https://chainsafe.io/) | Polkadot Snap Maintenance | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☐ | ☐ | | [justmert](https://github.com/justmert) | [DOTLY: Revolutionizing Polkadot Account Statistics](./dotly.md) | [GitHub](https://github.com/justmert/dotly) | ☐ | ☐ | ☐ | From 3b94d9b2f48b76c6b26d7f0f188d67cc151f8a26 Mon Sep 17 00:00:00 2001 From: Keegan | W3F <35080151+keeganquigley@users.noreply.github.com> Date: Thu, 12 Oct 2023 02:57:44 -0400 Subject: [PATCH 05/10] Update vue-typescript-substrate-frontend-template.md (#2045) --- applications/vue-typescript-substrate-frontend-template.md | 1 + 1 file changed, 1 insertion(+) diff --git a/applications/vue-typescript-substrate-frontend-template.md b/applications/vue-typescript-substrate-frontend-template.md index b2287ea4353..4ab2a36a13a 100644 --- 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: From 55d580dbab9b787a851e9c9a6b0e6233e12c0c13 Mon Sep 17 00:00:00 2001 From: Keegan | W3F <35080151+keeganquigley@users.noreply.github.com> Date: Thu, 12 Oct 2023 06:58:51 -0400 Subject: [PATCH 06/10] Cancel spacewalk-bridge.md (#2042) --- applications/spacewalk-bridge.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/applications/spacewalk-bridge.md b/applications/spacewalk-bridge.md index 60a06e95569..a18cbb63498 100644 --- 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: From 87c366d6e3420c09686b96041a093f7fc90e107d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20M=C3=BCller?= Date: Thu, 12 Oct 2023 18:40:16 +0200 Subject: [PATCH 07/10] Update RFP statuses (#2048) * clarifications * Update intro.md small spelling fixes * Update statuses and admonitions --------- Co-authored-by: David Hawig --- docs/Introduction/intro.md | 22 +++++++++---------- docs/RFPs/ISO_20022.md | 4 ++++ .../alternative-polkadot-js-api-console.md | 6 ++--- docs/RFPs/anti-collusion_infrastructure.md | 6 ++++- docs/RFPs/formal_guarantees_for_grandpa.md | 7 +++++- docs/RFPs/grant_management_webapp.md | 6 ++--- ...arachain_validation_conformance_testing.md | 18 ++++++--------- docs/RFPs/sub-consensus.md | 4 ++++ .../uptane-for-substrate-design-and-scope.md | 6 ++++- docs/RFPs/user-account-access-analysis.md | 4 ++++ docs/RFPs/xcm-tool.md | 4 ++++ docs/rfps.md | 12 +++++----- 12 files changed, 62 insertions(+), 37 deletions(-) diff --git a/docs/Introduction/intro.md b/docs/Introduction/intro.md index fc02ed87e87..ea5629fa7fb 100644 --- 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 index 6d2c1611c53..5070b715d61 100644 --- 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 index cb0db15523d..e6e82dc82f2 100644 --- 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 index 7c202fdfa3f..f9616d3682d 100644 --- 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 index dce19cb08b7..94649968635 100644 --- 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 index 37eb528dacf..17a865f5030 100644 --- 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 index 3c28fba93dd..d2b1f67134c 100644 --- 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 index f2102639099..1221a57cdae 100644 --- 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 index f419262f612..184174eaf7b 100644 --- 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 index 7d2b3d8b6cf..266cc959980 100644 --- 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 index d328524adfc..8f13bd41645 100644 --- 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 index 0b2cc5278b7..73ab405b258 100644 --- 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 | @@ -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 | @@ -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 | From c8aecf16d4b10739962df2d2951e5a525eba2f52 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20M=C3=BCller?= Date: Fri, 13 Oct 2023 12:19:26 +0200 Subject: [PATCH 08/10] Application list fixes --- applications/index.md | 88 ++++++++++++++++++++++--------------------- 1 file changed, 46 insertions(+), 42 deletions(-) diff --git a/applications/index.md b/applications/index.md index 3f6575e99ff..7b9afc76afe 100644 --- a/applications/index.md +++ b/applications/index.md @@ -13,31 +13,33 @@ Furthermore, the page lists terminations that happened due to a breach of the te Besides, **there is a clear difference between an application being accepted and the successful delivery of the respective project**, and only teams that have successfully delivered a milestone are allowed to make public announcements on the matter or to use our [badge](https://github.com/w3f/General-Grants-Program/blob/master/grants/grant-badge-guidelines.md). The badge can also never be used as a general endorsement for a team. Violations to this policy can be reported [here](mailto:grants@web3.foundation). ::: + + - [2023](#2023) - - [🏄 Wave 20 - Q4 2023](#️-wave-20---q4-2023) - - [🏄 Wave 19 - Q3 2023](#️-wave-19---q3-2023) - - [🏄 Wave 18 - Q2 2023](#️-wave-18---q2-2023) - - [🏄 Wave 17 - Q1 2023](#️-wave-17---q1-2023) + - [🏄 Wave 20 - Q4 2023](#-wave-20---q4-2023) + - [🏄 Wave 19 - Q3 2023](#-wave-19---q3-2023) + - [🏄 Wave 18 - Q2 2023](#-wave-18---q2-2023) + - [🏄 Wave 17 - Q1 2023](#-wave-17---q1-2023) - [2022](#2022) - - [🏄 Wave 16 - Q4 2022](#️-wave-16---q4-2022) - - [🏄 Wave 15 - Q3 2022](#️-wave-15---q3-2022) - - [🏄 Wave 14 - Q2 2022](#️-wave-14---q2-2022) - - [🏄 Wave 13 - Q1 2022](#️-wave-13---q1-2022) + - [🏄 Wave 16 - Q4 2022](#-wave-16---q4-2022) + - [🏄 Wave 15 - Q3 2022](#-wave-15---q3-2022) + - [🏄 Wave 14 - Q2 2022](#-wave-14---q2-2022) + - [🏄 Wave 13 - Q1 2022](#-wave-13---q1-2022) - [2021](#2021) - - [🏄 Wave 12 - Q4 2021](#️-wave-12---q4-2021) - - [🏄 Wave 11 - Q3 2021](#️-wave-11---q3-2021) - - [🏄 Wave 10 - Q2 2021](#️-wave-10---q2-2021) - - [🏄 Wave 9 - Q1 2021](#️-wave-9---q1-2021) + - [🏄 Wave 12 - Q4 2021](#-wave-12---q4-2021) + - [🏄 Wave 11 - Q3 2021](#-wave-11---q3-2021) + - [🏄 Wave 10 - Q2 2021](#-wave-10---q2-2021) + - [🏄 Wave 9 - Q1 2021](#-wave-9---q1-2021) - [2020](#2020) - - [🏄 Wave 8 - Q4 2020](#️-wave-8---q4-2020) - - [🏄 Wave 7 - Q3 2020](#️-wave-7---q3-2020) - - [🏄 Wave 6 - Q2 2020](#️-wave-6---q2-2020) - - [🏄 Wave 5 - Q1 2020](#️-wave-5---q1-2020) + - [🏄 Wave 8 - Q4 2020](#-wave-8---q4-2020) + - [🏄 Wave 7 - Q3 2020](#-wave-7---q3-2020) + - [🏄 Wave 6 - Q2 2020](#-wave-6---q2-2020) + - [🏄 Wave 5 - Q1 2020](#-wave-5---q1-2020) - [2019](#2019) - - [🏄 Wave 4 - Q4 2019](#️-wave-4---q4-2019) - - [🏄 Wave 3 - Q3 2019](#️-wave-3---q3-2019) - - [🏄 Wave 2 - Q2 2019](#️-wave-2---q2-2019) - - [🏄 Wave 1 - Q1 2019](#️-wave-1---q1-2019) + - [🏄 Wave 4 - Q4 2019](#-wave-4---q4-2019) + - [🏄 Wave 3 - Q3 2019](#-wave-3---q3-2019) + - [🏄 Wave 2 - Q2 2019](#-wave-2---q2-2019) + - [🏄 Wave 1 - Q1 2019](#-wave-1---q1-2019) ## 2023 @@ -50,6 +52,8 @@ Besides, **there is a clear difference between an application being accepted and | [KodaDot](https://kodadot.xyz/) | [AssetsHub NFT indexer](./kodadot_assethub_nft_indexer_statemine_statemint.md) | [GitHub](https://github.com/kodadot) | ☐ | ☐ | ☐ | | [Apollos Collective](https://rhys.tech) | [Infimum](./infimum.md) | [GitHub](https://github.com/rhysbalevicius) | ☐ | ☐ | ☐ | +[🔝](#top) + ### 🏄 Wave 19 - Q3 2023 | Team | Project | Link | Terminated | First Delivery | Completed | @@ -57,7 +61,7 @@ Besides, **there is a clear difference between an application being accepted and | [Protofire](https://protofire.io/) | [Contract Wizard](./Contract_wizard.md) | [GitHub](https://github.com/protofire/polkadot-contract-wizard/) | ☐ | ☐ | ☐ | | [ZeroDAO](https://github.com/ZeroDAO) | [Melodot](./Melodot.md) | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☒ | | [Starks](https://github.com/tur461) | [XCM tool for NFTs](./xNFT.md) | [GitHub](https://github.com/tur461) | ☐ | ☐ | ☐ | -| [ChainSafe](https://chainsafe.io/) | Polkadot Snap Maintenance | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☐ | ☐ | +| [ChainSafe](https://chainsafe.io/) | [Polkadot Snap Maintenance](./maintenance/Substratesnap_Maintenance.md) | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☐ | ☐ | | [justmert](https://github.com/justmert) | [DOTLY: Revolutionizing Polkadot Account Statistics](./dotly.md) | [GitHub](https://github.com/justmert/dotly) | ☐ | ☐ | ☐ | | [Federico Cicciarella](https://www.linkedin.com/in/federicocicciarella/?originalSubdomain=it) | [Tracking Chain](./tracking_chain.md) | [GitHub](https://github.com/TrackingChains/TrackingChain) | ☐ | ☒ | ☐ | | [TPScore](https://github.com/its-a-setup) | [TPScore](./TPScore.md) | [GitHub](https://github.com/its-a-setup) | ☐ | ☒ | ☒ | @@ -88,7 +92,7 @@ Besides, **there is a clear difference between an application being accepted and | [Coong Crafts](https://coongcrafts.io/) | [DelightfulDOT](delightfuldot.md) | [GitHub](https://github.com/CoongCrafts) | ☐ | ☐ | ☐ | | [Lastic](https://www.lastic.xyz/) | [Lastic](Lastic.md) | [GitHub](https://github.com/LasticXYZ) | ☐ | ☐ | ☐ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 18 - Q2 2023 @@ -131,7 +135,7 @@ Besides, **there is a clear difference between an application being accepted and | [Davanti](https://github.com/liangjh) | [Dot-ETL Project](dot_etl.md)| [GitHub](https://github.com/liangjh) | ☐ | ☐ | ☐ | | [ParaSpell](https://github.com/paraspell) | [LightSpell: XCM API](LightSpell-proposal.md)| [GitHub](https://github.com/paraspell) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 17 - Q1 2023 @@ -184,7 +188,7 @@ Besides, **there is a clear difference between an application being accepted and | [Polkadrys Labs](https://github.com/rtomas) | [Open Payroll](./openPayroll.md) | [GitHub](https://github.com/rtomas) | ☐ | ☒ | ☐ | | [Itering](https://www.itering.io/) | [Solidity Verifier Implementation for Accountable Light Client](./solidity-verifier-for-accountable-light-client.md) | [GitHub](https://github.com/darwinia-network) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ## 2022 @@ -232,7 +236,7 @@ Besides, **there is a clear difference between an application being accepted and | [Aband-Network](https://a.band/) | [Substrate Parachain PoS Template](substrate-parachain-PoS-template.md) | [GitHub](https://github.com/Aband-Network/substrate-parachain-PoS-template) | ☐ | ☒ | ☒ | | [MangoBOX labs](https://www.mangobox.xyz/) | [MangoSale Protocol](MangoSale_Protocol.md) | [GitHub](https://github.com/Mangoboxlabs) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 15 - Q3 2022 @@ -278,7 +282,7 @@ Besides, **there is a clear difference between an application being accepted and | [Standard Protocol](https://standard.tech/) | [New Order - a full onchain orderbook dex with indexers](./Standard_Protocol.md) | [GitHub](https://github.com/standardweb3) | ☒ | ☐ | ☐ | | [hack-ink](https://github.com/hack-ink) | [Subalfred](./subalfred.md) | [GitHub](https://github.com/hack-ink/subalfred) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 14 - Q2 2022 @@ -321,7 +325,7 @@ Besides, **there is a clear difference between an application being accepted and | [Hypha Hashed Partners](https://hypha.earth/) | [Social Recovery Wallet](./social_recovery_wallet.md) | [GitHub](https://github.com/hypha-dao) | ☐ | ☒ | ☒ | | [MangoBOX labs](http://mangobox.xyz/) | [MangoBOX Protocol](./MangoBOX-Protocol.md) | [GitHub](https://github.com/Mangoboxlabs) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 13 - Q1 2022 @@ -360,7 +364,7 @@ Besides, **there is a clear difference between an application being accepted and | [NUTS Finance](https://nuts.finance) | [DOT-pegged derivative built on top of the stable asset protocol](./tdot.md) | [GitHub](https://github.com/nutsfinance/) | ☒ | ☒ | ☐ | | [Strategy Object](https://strategyobject.com/) | [Substrate Client for Java](./substrate_client_java.md) | [GitHub](https://github.com/strategyobject/substrate-client-java) | ☐ | ☒ | ☐ | -[🔝](#2023) +[🔝](#top) ## 2021 ### 🏄 Wave 12 - Q4 2021 @@ -391,7 +395,7 @@ Besides, **there is a clear difference between an application being accepted and -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 11 - Q3 2021 @@ -424,7 +428,7 @@ Besides, **there is a clear difference between an application being accepted and | [Skye Kiwi](https://skye.kiwi/) | [SkyeKiwi Protocol](./skyekiwi-protocol.md) | [GitHub](https://github.com/skyekiwi) | ☐ | ☒ | ☒ | | [Evercity](https://evercity.io/) | Sustainable Finance Protocol | [GitHub](https://github.com/EvercityEcosystem) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 10 - Q2 2021 @@ -460,7 +464,7 @@ Besides, **there is a clear difference between an application being accepted and | [CryptoLab](https://www.cryptolab.network) | [Staking Reward Collector](./cryptolab-staking-reward-collector-front-end.md) | [GitHub](https://github.com/cryptolab-network) | ☐ | ☒ | ☒ | | [Yatima Inc](https://github.com/yatima-inc/yatima) | [Lambda-VM and programming language for Substrate](./yatima.md) | [GitHub](https://github.com/yatima-inc/yatima) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 9 - Q1 2021 @@ -481,7 +485,7 @@ Besides, **there is a clear difference between an application being accepted and | [SEOR](https://www.seor.io) | [Multi-chain smart contract development platform](./SEOR-code-less-smart-contract-platform.md) | [GitHub](https://github.com/SealSC) | ☐ | ☒ | ☐ | | [Polkastarter](https://polkastarter.com/) | [Crowdloan UI](./polkastarter.md) | [GitHub](https://github.com/polkastarter) | ☒ | ☐ | ☐ | | [Equilibrium.io](https://equilibrium.io/en) | [Curve AMM Pallet](./curve_amm.md) | [GitHub](https://github.com/equilibrium-eosdt) | ☐ | ☒ | ☒ | -| [Zondax](https://zondax.ch/) | [Ledger maintenance + recovery extensions + support](./Zondax-Support.md) | [GitHub](https://github.com/Zondax) | ☐ | ☒ | ☒ | +| [Zondax](https://zondax.ch/) | [Ledger maintenance + recovery extensions + support](./maintenance/Zondax-Support.md) | [GitHub](https://github.com/Zondax) | ☐ | ☒ | ☒ | | [Nuclei Studio](https://nuclei.studio/) | [Voting Pallets](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/nuclei_governance_os_voting.md) | [GitHub](https://github.com/NucleiStudio) | ☐ | ☒ | ☒ | | [RAMP DEFI](https://app.rampdefi.com/#/) | [Polkakeeper - A Community-Led Value Assurance Protocol](./polkakeeper.md) | [GitHub](https://github.com/RAMP-DEFI) | ☐ | ☐ | ☐ | | [Stone](https://stonedefi.io) | [Index project which aims to track the portfolio of multiple digital assets](./stone-index-on-substrate.md) | [GitHub](https://github.com/stonedefi/) | ☐ | ☒ | ☒ | @@ -515,7 +519,7 @@ Besides, **there is a clear difference between an application being accepted and | [Vera](https://veraprotocol.org/) | [NFT Lending + Exchange](./vera_defi.md) | [GitHub](https://github.com/veraprotocol) | ☐ | ☒ | ☒ | | [Parallel Finance](https://parallel.fi/#/) | [Decentralized lending/borrowing and staking protocol](./Parallel.md) | [GitHub](https://github.com/parallel-finance/parallel) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ## 2020 @@ -567,7 +571,7 @@ Besides, **there is a clear difference between an application being accepted and | [HugoByte](https://hugobyte.com/) | [Project Aurras: Event Manager](./project_aurras_mvp_phase_1.md) | [GitHub](https://github.com/HugoByte) | ☐ | ☒ | ☒ | | [Bounce Protocol](https://bounce.finance/) | [Decentralized Auction Protocol](./bounce-protocol.md) | [GitHub](https://github.com/bouncefinance/bounce-network) | ☐ | ☐ | ☐ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 7 - Q3 2020 @@ -605,7 +609,7 @@ Besides, **there is a clear difference between an application being accepted and | [sup](https://github.com/clearloop/sup) | [Command line tool for generating or upgrading a Substrate node](./sup.md) | [GitHub](https://github.com/clearloop/sup) | ☐ | ☒ | ☒ | | [Shard Labs](https://shardlabs.io) | [Tip or Donate KSM Embeddable Button](./KSM-embeddable-tip-or-donate-button.md) | [GitHub](https://github.com/Shard-Labs) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 6 - Q2 2020 @@ -645,7 +649,7 @@ Besides, **there is a clear difference between an application being accepted and | [Zondax](http://zondax.ch/) | Ledgeracio: A command-line tool and Ledger app designed for staking operations | [GitHub](https://github.com/paritytech/ledgeracio) | ☐ | ☒ | ☒ | | [Dipole Tech](https://www.dipole.tech) | [Dipole Oracle: Distributed energy resource management](./DipoleOracle.md) | [GitHub](https://github.com/DipoleTech/dipole-oracle) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 5 - Q1 2020 @@ -689,7 +693,7 @@ Besides, **there is a clear difference between an application being accepted and | [Lyken](https://lyken.rs/) | [Rust trait system revamp](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/rust_trait_system_revamp.md) | [GitHub](https://github.com/LykenSol) | ☐ | ☒ | ☐ | | [Chorus One](https://chorus.one/) | Grandpa light client in Tendermint | [GitHub](https://github.com/ChorusOne) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ## 2019 @@ -722,9 +726,9 @@ Besides, **there is a clear difference between an application being accepted and | [HashQuark](https://www.hashquark.io/) | Validator Dashboard | [GitHub](https://github.com/hashquark-io) | ☐ | ☒ | ☒ | | [Stacktical](https://stacktical.com/) | [Performance Management Runtime Modules](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/predictive_performance_management_runtime_module.md) | [GitHub](https://github.com/Stacktical) | ☐ | ☒ | ☐ | | [Sean Young](https://www.mess.org/) | Solidity to WASM compiler | [GitHub](https://github.com/hyperledger-labs/solang) | ☐ | ☒ | ☒ | -| [Chain Security](https://chainsecurity.com/) | Tool for validating correctness of Polkadot runtimes | [GitHub](https://github.com/ChainSecurity/polpatrol) | ☐ | ☒ | ☒ | +| [Chain Security](https://chainsecurity.com/) | Tool for validating correctness of Polkadot runtimes | [GitHub](https://github.com/ChainSecurity/polpatrol) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 3 - Q3 2019 @@ -745,7 +749,7 @@ Besides, **there is a clear difference between an application being accepted and | [Phala.Network](https://phala.network/) | [pLibra, Privacy Bridge between Polkadot and Libra chain](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/pLIBRA.md) | [GitHub](https://github.com/Phala-Network/) | ☐ | ☒ | ☐ | | [Wiv](http://wiv.io/) | Supply chain modules and front-end UI | [GitHub](https://github.com/wivtech) | ☒ | ☐ | ☐ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 2 - Q2 2019 @@ -764,7 +768,7 @@ Besides, **there is a clear difference between an application being accepted and | [Mailchain](https://mailchain.xyz/) | a Multi-Blockchain Messaging Application | [GitHub](https://github.com/mailchain) | ☐ | ☒ | ☒ | | [Usetech](http://usetech.com/blockchain.html) | [Polkadot C++ API](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/cpp_api.md) | [GitHub](https://github.com/usetech-llc/polkadot_api_cpp) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) ### 🏄 Wave 1 - Q1 2019 @@ -781,4 +785,4 @@ Besides, **there is a clear difference between an application being accepted and | [Protos](http://protosmanagement.com/) | Open Source Node Explorer | [GitHub](https://github.com/protos-research/polkadot-node-explorer) | ☒ | ☒ | ☐ | | [Supercomputing Systems](https://www.scs.ch/) | [Substrate Transaction Privacy using Intel SGX](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/substrate_sgx_proposal.md) | [GitHub](https://github.com/scs/substraTEE) | ☐ | ☒ | ☒ | -[🔝](#2023) +[🔝](#top) From 3bf6522f2fe5d360a64f3682a4c19baa18de88c8 Mon Sep 17 00:00:00 2001 From: vuittont60 <81072379+vuittont60@users.noreply.github.com> Date: Fri, 13 Oct 2023 18:45:06 +0800 Subject: [PATCH 09/10] docs: fix typo (#2049) --- docs/RFPs/a-and-v-topology.md | 4 ++-- docs/RFPs/epassport-zk-validation.md | 2 +- docs/RFPs/identity-directory.md | 2 +- docs/RFPs/ksm-tipping-button.md | 2 +- docs/RFPs/php-scale.md | 2 +- docs/RFPs/polkadot-collator-setup.md | 2 +- docs/RFPs/staking-rewards-collector-front-end.md | 2 +- docs/RFPs/uncollateralized-stablecoin-research.md | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/RFPs/a-and-v-topology.md b/docs/RFPs/a-and-v-topology.md index 18b0ec67aaa..507c9a5428d 100644 --- 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/epassport-zk-validation.md b/docs/RFPs/epassport-zk-validation.md index 60609bf07d7..301ff0a4474 100644 --- 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/identity-directory.md b/docs/RFPs/identity-directory.md index 0e469da1a23..5bc40ce5164 100644 --- 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 index 5debd7c4631..6142d0b3f6f 100644 --- 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: diff --git a/docs/RFPs/php-scale.md b/docs/RFPs/php-scale.md index 0fa1df40061..1c6161ce63c 100644 --- a/docs/RFPs/php-scale.md +++ b/docs/RFPs/php-scale.md @@ -15,4 +15,4 @@ The SCALE codec is the de-factor encoding method in Substrate-based chains. It i 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. -The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusivley a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone. +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. diff --git a/docs/RFPs/polkadot-collator-setup.md b/docs/RFPs/polkadot-collator-setup.md index 14e1aa2ace4..fc63b89f51c 100644 --- a/docs/RFPs/polkadot-collator-setup.md +++ b/docs/RFPs/polkadot-collator-setup.md @@ -20,7 +20,7 @@ I understand it might be tricky to bundle all the parachain launch setups into o 1. Have a single collator ansible role, and each branch would correspond to a specific parachain 2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed. -I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independant chains without meddling with git branching too much. +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. ## Deliverables :nut_and_bolt: diff --git a/docs/RFPs/staking-rewards-collector-front-end.md b/docs/RFPs/staking-rewards-collector-front-end.md index c717e0498dc..ed1d64a38ca 100644 --- a/docs/RFPs/staking-rewards-collector-front-end.md +++ b/docs/RFPs/staking-rewards-collector-front-end.md @@ -14,7 +14,7 @@ This Request for Proposals is _closed_, meaning we are not looking for any more 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. -The backend is already written in javascript, this should make it quite easy to host as a website and develope a front-end. +The backend is already written in javascript, this should make it quite easy to host as a website and develop a front-end. ## Deliverables :nut_and_bolt: diff --git a/docs/RFPs/uncollateralized-stablecoin-research.md b/docs/RFPs/uncollateralized-stablecoin-research.md index 33bf291b45f..d89129c7c8c 100644 --- a/docs/RFPs/uncollateralized-stablecoin-research.md +++ b/docs/RFPs/uncollateralized-stablecoin-research.md @@ -59,6 +59,6 @@ The milestones below are just an initial draft. The milestones can be structured | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 1. | Implement PoC| Implement the previous reasearch as ink! Smart contract or pallets | +| 1. | Implement PoC| Implement the previous research as ink! Smart contract or pallets | | 2. | UI (optional) | Implement a basic UI that can be used for testing | From c15c989d5a18d6f144418c186e63f9a94ceaf9dc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20M=C3=BCller?= Date: Fri, 13 Oct 2023 16:58:50 +0200 Subject: [PATCH 10/10] clarifications (#2046) Co-authored-by: David Hawig