- ❔ What is an RFP?
- 📜 List of current RFPs
- Availability and Validity - Network Topology
- e-Passport ZK Validation
- RFP: Substrate Identity Directory
- ink!/pallet/solidity performance benchmarking
- DOT & KSM mixer
- Multi-chain Block Explorer
- On-chain Quadratic Funding
- PHP Substrate API
- Polkadot Collator Setup
- Privacy Enhancement for Polkadot Extension
- High-availability validator setup
- SCALE Codec Comparator
- Social Recovery Wallet
- Uncollateralized Stablecoin
- polkadot-validator-setup maintenance
- XCM library & tools
- Sub-consensus mechanism
- 📬 Suggest an RFP
An RFP (Request for Proposals) is a declaration of interest for others to submit a grant application regarding a specific project. They usually revolve around issues that the author (often someone from our team, but anyone can suggest one) deems useful and missing or unsolved in our ecosystem.
If you find an open RFP here that you think you can address, feel free to submit a grant application. There is a section in our application template where you can reference the RFP you are addressing.
-
Published: 2021-11-19
-
Proposer: @infinity0, @skalman, @mmagician
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. In short, it is split in 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. ...
- Total Estimated Duration: 14 weeks
- Total Costs: 90,000 DAI
-
Published: 2021-11-23
-
Proposer: burges, FlorianFranzen
The issue of verifying identities on-chain and providing Proof-of-personhood is a challenging one.
One idea to authenticate users is to ask them to submit the details from their e-passports. While it would provide authentication, it forgoes the aspect of privacy. ...
-
Published: 2021-07-20
-
Proposer: swader
In Substrate-based chains which implement the Identity pallet, users can register on-chain information about themselves. It is currently difficult to search by any of the identity fields. There is also no way to link directly to an on-chain account and see human-readable reports of its interactions with the chain, let alone quickly send tokens to it or otherwise interact directly with that account.
The Identity Directory is a fully client-side web application which makes this possible. ...
-
Published: 2021-07-20
-
Proposer: mmagician
When a new team comes to the ecosystem, they are faced with a decision on how to best implement the logic that they need. Traditionally in substrate, this has been a choice between a smart contract vs. runtime module (a.k.a. pallet) and elaborated on in this StackOverflow question or this entry in Substrate Developer Hub. The choice has since been augmented by the possibility to deploy solidity contracts to an EVM-compatible chain, or even writing solidity code and compiling it to WASM with the help of a solang compiler. ...
- Total Estimated Duration: 4 weeks
- Full-time equivalent (FTE): 1
- Total Costs: 10,000 DAI
-
Published: 2021-11-23
Polkadot uses an account-based Tx model, which easily enables linking activity between accounts. To preserve on-chain anonymity, the options available to the user at the moment are limited to using centralised exchanges. It requires transferring their funds to an exchange-controlled account and withdrawing them at a later point in time, to a different account. ...
-
Published: 2021-11-23
As parachains become an integral part of the Polkadot and Kusama ecosystems, a cross-chain block & accounts explorer becomes all the more useful.
Some of the functionality that should be covered as part of the development: ...
-
Published: 2021-07-20
-
Proposer: Noc2
CLR, short for Constrained Liberal Radicalism algorithm, commonly called quadratic funding (QF), is a way to efficiently fund projects in the Web3 ecosystem. The way it works is that users contribute directly to projects which they value and in doing so, help the projects earn a share of a matching pool of funds. The number and amount of each contribution influences the total amount allocated to a project. This means even a small contribution is valuable and can result in a high matched amount.
Gitcoin is currently using this mechanism to successfully fund and support public goods. However, Gitcoin is centralized. The goal of this RFP is to develop a decentralized solution on top of Substrate, which can potentially be integrated into Kusama, Polkadot or any other Substrate-based chain as a pallet. The on-chain treasury could potentially sustainably fund the matching pool in the long-run. However, the Web3 Foundation would also be committed to fund a matching pool of the solution for initial test rounds. ...
-
Published: 2021-07-20
-
Proposer: swader
The Substrate API is currently most developed in TypeScript and Rust. This RFP is looking for teams willing to implement a PHP version, perhaps in tandem with the PHP SCALE Coded (see relevant RFP).
The PHP API should: ...
The basic deliverable of this project is an API package hosted on Packagist which can instantiate a connection to a Substrate node and talk to constants, chain storage, and RPC endpoints. For inspiration, see the JS version: https://polkadot.js.org/docs
-
Published: 2021-11-23
-
Proposer: mmagician
This is meant as a companion repository to polkadot-validator-setup, which allows anyone to launch a validator node in an automated and secure fashion.
I would like to standardize (as much as possible) the process of spinning up new collator nodes for different parachains. ...
Ideally the PoC would Please list the deliverables of the project in as much detail as possible. Please also estimate the amount of work required and try to divide the project into meaningful milestones.
-
Published: 2021-11-26
-
Proposer: jonasW3F
An increasing number of websites require access to the Polkadot extension with a growing ecosystem. By allowing access to the extension, websites (naturally) can see the addresses that are contained in the extension. This imposes a big risk to privacy, because malicious actors could create lists about which addresses belong to one entity and, in the worst case, even link it to real-world identities (if at least one address is linked to an on-chain identity). A feature to prevent this is currently the "hide" button on single addresses, which prevent websites from seeing that address. However, it is currently cumbersome to handle that feature. The idea of this RFP is to extend on that feature and include a few QOL functionalities to make it easier for users to protect their privacy.
As outlined here, the deliverable should include five features to the extension and a successful completion of this RFP includes a merge of a PR to the main polkadot-js/extension repo. It is of great importance to generate clean code that follows best-practices.
- Total Estimated Duration: 1 month
-
Published: 2021-07-20
-
Proposer: mmagician
Validator leader selection via Raft consensus. Inspired by internal discussions & certus.one active-active validator setup. ...
- Total Estimated Duration: 3 months
- Full-time equivalent (FTE): 1
- Total Costs: 30,000 DAI
-
Published: 2021-07-20
-
Proposer: Marcin Górny
To date, there are 9 published implementations of the SCALE Codec. Since each is implemented by a different team & the reference implementation still introduces small fixes, it would be beneficial to compile a table of feature-completeness. This would provide (some) assurance that the implementation in a given language is safe & sound to use. ...
- Total Estimated Duration: 2+ months
- Full-time equivalent (FTE): 1
- Total Costs: ~ 12,000 DAI
-
Published: 2021-08-02
-
Proposer: Noc2
Managing your own private keys is a difficult task. The average person doesn’t want to spend multiple hours to ensure the security of their keys. This leads to people having difficulties to join the blockchain space or even worse leads to the loss of funds. One solution to this problem is the implementation of a social recovery system. It allows users to recover their accounts if their key or other authentication mechanism has been lost. Therefore you usually set up at least 3 "guardians" (e.g. other devices, friends or family or institutions), of which a majority can cooperate to change the key of the account (often after some delay). Kusama has for this purpose currently the social recovery pallet implemented.
The goal of this RFP is to find teams that are willing to leverage this or similar mechanism to create wallet solutions (desktop, web, mobile, extensions, etc.) which are as easy to use as possible and at the same time offer a high security for the average user. ...
The deliverables highly depend on the exact wallet implementation and therefore aren’t further described as part of this RFP. For the grant application you should take a look at the application template and try to specify the deliverables as detailed as possible.
-
Published: 2021-07-30
-
Proposer: Noc2
Stablecoins are cryptocurrencies where the price is designed to be pegged (=fixed exchange rate) to a cryptocurrency, fiat money, or to exchange-traded commodities. Seigniorage-style, uncollateralized or algo stablecoin is a token that uses algorithms to control the circulating supply to get a stable value of the asset. In general the price volatility of cryptocurrencies is one of the biggest barriers to widespread adoption. Stablecoins therefore have become a key component of DeFi applications. However, all successful existing stable coins (e.g. DAI, USDT, USDC, etc) are asset backed. Therefore they are subject to the same volatility and risk associated with the backing asset and the underlying process. Some of the potentially issues based on this are:
- Additional trust assumptions (e.g. USDT)
- Scalability issues (restricted by the underlying asset) ...
The milestones below are just an initial draft. The milestones can be structured completely differently and the implementation can also leverage other tools and infrastructure as long as the overall goal of the RFP is met.
- Total Estimated Duration: 2 month
-
Published: 2021-11-23
One of the more accessible ways of spinning up validator nodes is by using the polkadot-validator-setup repository, which uses a mix of terraform and ansible tools to create a server, adjust its configuration and install the necessary packages needed for running a substrate node.
This RFP aims at providing maintenance to that repository and add some small features. ...
A list of possible tasks to work on:
- fixing issues and improving documentation
- updating any libraries/deps needed
-
Published: 2021-07-20
-
Proposer: Bryan Chen
XCM is the crosschain communication standard that will be used by all the parachains. Currently XCM is still in early stage but already supports some main use cases such as crosschain transfer of fungible tokens.
There are currently two major areas of XCM that still awaiting to be improves: ...
- ➡️ sub-consensus.md
- Published: 2022-02-23
- Status: Open
- Proposer: mmagician, laboon
Parachain dApps suffer from long confirmation times due to the time taken for the Relay Chain to issue an on-chain verification of the parachain blocks. This proposal aims at providing an alternative mechanism for providing parachain users with an alternative, probabilistic sub-consensus mechanism. ...
- Total Estimated Duration: 3 months
- Full-time equivalent (FTE): 1
- Total Costs: 40,000 DAI
If you think that we should support the development of certain tools or projects (related to Polkadot, Kusama or Substrate) that aren't in the Polkadot/Kusama tech stack, please submit a suggestion using the process described in our Grants program README. We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem.